Page History

• Revisiting "Collection dropdown in submission”  (Estimation Angular 1 day6h, REST no changes needed - or very limited <1h): 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

...

• Handling change collection with template item (Estimation Angular 6h, REST different options from 0 to 1 day): 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 applying 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 itemtemplate 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)

...

• performance issues: https://github.com/DSpace/dspace-angular/issues/487 (Estimation Angular 2 days, REST 1 day - two options provided) 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 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)
    

...

• Changing Collection doesn't work when new collection has a different form definition: https://github.com/DSpace/dspace-angular/issues/621 (Estimation Angular 4h2h - up to 6h if  done without the hangling change collection with template item, REST no changes needed) this is not strictly related to the collection dropdown but is a projection issue easy to solve without performance issues. 
  

• Changing Collection would result in a different form definition (Estimation Angular 2h, REST no changes needed): 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

    Jira
    server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key DS-4502

    
    

• Further considerations (specify the collection from the mydspace) (Estimation Angular 4h, REST it will be based on work done for performance issues): 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 infrequently 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 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, along 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.