Revisit auto-save behavior of Submission, especially when metadata is added dynamically on server side

[tdonohue]

This ticket is a reminder to revisit the decisions made in #835 for the 7.0 release.

As noted in #835, there are scenarios where metadata may be added/enhanced on the server-side within an active submission form. Some of those scenarios include:

• Adding Entity relationships to the current submission (this relates directly to #858 which may modify how those relationships are added). Adding an relationship can result in virtual metadata (pulled from the related entity) to be added to the submission (e.g. creating a new Journal Issue & relating it to the Journal may pull in the Journal ISSN as virtual metadata).
• Enhancing the metadata entered into the submission form via a DOI (or other identifier) lookup. When a DOI is entered into the form, it's possible to use that DOI to obtain metadata from external sources and add that metadata (server side) into the active submission. See also https://github.com/DSpace/DSpace/issues/2834
• Enhancing the metadata entered into the submission form via a file upload. For example, if the uploaded file has embedded metadata (e.g. BibTex), or if the file can be parsed such that metadata can be extracted (e.g. Grobid PDF extraction), then that metadata might be added (server side) into the active submission. See also https://github.com/DSpace/DSpace/issues/2833

In all of these scenarios, this implies that it might be possible that metadata could be added on both the client side (by the submitter) and the server side (via lookup or extraction). In that situation, we'd need to know which metadata is most "trusted", and perhaps determine a way to "diff" or compare the dynamically added metadata vs manually added metadata to determine which should be used.

In #835, @atarix83 added some general ideas on how this might be achievable in this comment.

In 7.0, we decided to simplify our implementation to trust the client side & limit scenarios of automated metadata extraction on the server-side.

Therefore, this ticket is an opportunity to now re-analyze the current auto-save behavior and determine whether it is still "good enough" (in which case this ticket can be closed) or whether it requires work to better support automated metadata extraction or enhancement.

[abollini]

@tdonohue we suggest to close this task as nothing more is needed in regards to the auto-save behavior

[tdonohue]

Per today's meeting discussion, we decided this ticket relates back to #858 , as current 7.0 auto-save behavior may (or may not) require reanalysis once that Submission code refactor is completed. So, this task should be analyzed as part of #858 or after #858 has been better scoped.

At that time, it may be that we decide to still just close this ticket...but, for now, I'll leave this open as a reminder that auto-save behaviors need to be revisited/reanalyzed as we refactor the submission code.