Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
  • Revisiting "Collection dropdown in submission”  (Estimation REST 1 day including small contract change / Angular 1 day): the existence of the “Collection dropdown”  within the submission can be associated with the configuration of the "collection" step. If the collection step is not defined in the submission definition the “Collection dropdown” will be not showed


This will made “Collection dropdown” configurable giving the opportunity to the user to completely disable this feature if not liked.Template item: we . Please note that both POST to workspaceitem without or with a collection already works if collection step is omitted.

  • Handling change collection with template item: if the user try to change the collection toward a collection that has a template item the “Collection dropdown” show a warning message asking confirmation to the user. The user will be allowed to decide if they want to confirm the collection change, applyng the item template, or not. We don't need to know this information for all the available collection but only for the one that the user has selected as replacement so to show a warning if appropriate. This mean that we can get this information with a single call to the single collection endpoint. On REST side there are two different possibilities to expose this information :
    • If we are ok in showing the item template to the submitter we can use the existing endpoint just to check if the itemtempate exists or not
    • otherwise we suggest to add a flag in the collection object returned by REST to indicate that such collection includes a template item. The flag is needed to avoid permission issue in reading the actual item template that is not really needed to be known by the client (for the submitter).


    • It could be included for a specific projection or get with a dedicated endpoint. (Estimation REST 1 day including small contract change)

   Please note that applying item template we'll overwrite any same metadata in the item, i.e. if the item template has a dc.publisher and the current item also have a value for it, the value of the item template will override the current dc.publisher value

  • performance issues: (Estimation Angular 2 days) the dropdown collection component had better be refactored by using pagination for the collection list and by retrieving community by the new `parentCommunity` collection’s link that will be embedded with proper projection. It will work like the scrollable dropdown component works now. When a user scroll to the bottom of the list more entries will be loaded if there are any. The lookup function needs the findAuthorized method to be revisited if the collection list is paginatingbe improved by adding a query parameter. On REST side lookup functionality should be implemented in two ways :
    • using solr. This means to add a plugin, very similar to the current ResourceRestrictionPlugin, that saves the info of who can submit in a given collection within the solr record of the collection. This allow to add order by community first and collection name, making the scrolling more friendly. Moreover, this will provide better performance and reliability in searching the collection name (Estimation REST 1 day)
    • using DB (Estimation REST 1 day)

   the effort is almost identical, anyway we think the first solution is better.

  • Changing Collection doesn't work when new collection has a different form definition: (Estimation Angular 4h) this is not strictly related to the collection dropdown but is a projection issue issue easy to solve without performance issues. 
  • Changing Collection would result in a different form definition (Estimation Angular 2h): similar to the scenario of the template item a warning can be shown and if the user need to explicitly confirm the switch. Estimation no change required on the REST side.
  • Handling metadata and bitstreams on change collection:  the REST part already delete all the metadata that doesn't apply to the new form definition (i.e usually the dc.title is available in all the form definition so it is keep - just an example the actual list is discovered looking to the configuration). The files are left untouched, there two possible solution to handle it :
    • eventually drop the files (after confirmation) if the new submissions don't include the upload step and leave them otherwise. To drop all the files when appropriate 2h on the REST side should be enough.
    • If the new configuration differ for the access conditions it would be better to have the upload step to deal with the "error" related to selection of an invalid option - also because this could happen for long running submission if the repository manager change the configuration so it would be useful regardless of the collection change. REST estimation should stay in the range 8-24 hours,  Estimation Angular 12h. We've created a new issue to address the problem because it could occur regardless of the collection change
      serverDuraSpace JIRA

  • Further considerations Starting a new submission from the “new item” sidebar’s link is not always usable for a not admin user. We hear from our customers that many researchers use the repository unfrequently and they don’t know and don’t remember about the repository structure, for them it is pointless to make a search because essentially they don’t know the available options. They expect to have list / tree to browse, for them a lookup is not the best approach to use. Moreover it does not consider the user's permissions on collections. Considering this, a new feature which allows to select the start collection could be implemented in the mydspace page. It could be realized starting from community-list tree considering authorizations issuesalong with the "new item" sidebar link, the same collection dropdown present in the submission should be used to start a new submission from the mydspace page.