Collection dropdown in submission

• Revisiting "Collection dropdown in submission”  (Estimation Angular 6h, 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

        <submission-process name="traditional">

            <step id="collection"/>

            <!--Step will be to Describe the item. -->

            <step id="traditionalpageone"/>

            <step id="traditionalpagetwo"/>

            <!--Step will be to Upload the item -->

            <step id="upload"/>

            <!-- <step id="upload-with-embargo"/> -->

            <!-- <step id="detect-duplicate"/> -->

            <!--Step will be to Sign off on the License -->

            <step id="license"/>

            <!-- <step id="creative-commons"/> -->

            <!-- <step id="verify"/> -->

        </submission-process>

This will made “Collection dropdown” configurable giving the opportunity to the user to completely disable this feature if not liked. 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 (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, 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 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)

   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: 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)
    

   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: https://github.com/DSpace/dspace-angular/issues/621 (Estimation Angular 2h - 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 Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    

• 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 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.