Returning to author now requires a reason that is sent by email to the author

[luddaniel]

What this PR does / why we need it:

It displays a required textarea inside the "return to author" popup that is used to comment the reason of the return. This comment is sent by email to the author.

Which issue(s) this PR closes:

Closes #3702

Special notes for your reviewer:

This PR does not cover the management of displaying reasons of return in notification page.
Notification does not share the same architecture as WorkflowComment on a DatasetVersion, so it's not easy to join on comment to a notification in case there is multiple return to the author on the same Dataset version.

Bundle.properties new values must be arbitrated, as the closing of #3702

Suggestions on how to test this:

All the XHTML part with required field and remoteCommand seems really "delicate", an attention must be paid to the other commands in the dataset (like editing/saving a dataset).
Also, validation message seems to be removed a bit too fast when tags are updated, it might need a little improvement.

Does this PR introduce a user interface change?

return_to_author.mp4

Is there a release notes update needed for this change?:

Definitely yes.

[coveralls]

coverage: 20.273% (-0.002%) from 20.275%
when pulling 0028b90 on Recherche-Data-Gouv:3702-return-to-author
into de45c13 on IQSS:develop.

[pdurbin]

Wow, I'm impressed by how little code is needed. Great job, @luddaniel!

Also, I love the video!

Now I think it's a matter of seeing if we want this or not. And if so, where it falls in our priorities.

[pdurbin]

One more question.

[pdurbin]

Adding feedback from @sbarbosadataverse (from Slack).

[luddaniel]

Here is the demo of the last version :

demo_return_to_author_v3.mp4

[DS-INRA]

Would be a good opportunity to be more precise :)

Suggested change

	notification.email.wasReturnedByReviewer={0} (view at {1} ) was returned by the curator of {2} (view at {3} ).{4}
	notification.email.wasReturnedByReviewer=Your dataset named {0} (view at {1} ) was returned by the curator of {2} (view at {3} ).{4}

Also in wasSubmittedForReview, see other suggestion

[DS-INRA]

Suggested change

	notification.email.wasSubmittedForReview={0} (view at {1} ) was submitted for review to be published in {2} (view at {3} ). Don''t forget to publish it or send it back to the contributor, {4} ({5})\!
	notification.email.wasSubmittedForReview=Your dataset named {0} (view at {1} ) was submitted for review to be published in {2} (view at {3} ). Don''t forget to publish it or send it back to the contributor, {4} ({5})\!

see other comment

[luddaniel]

Hello @pdurbin, it seems like everybody's desire has been listened, how can we move forward on this PR ?

[pdurbin]

@luddaniel yes, thanks for being so responsive! Next we check with @cmbz and @scolapasta to see where this fits into priorities, etc.

[cmbz]

2023/12/11

• @luddaniel @pdurbin As per conversation with @scolapasta we're adding it to the 6.2 proposals.
• Forgot to add: this needs sizing; please suggest a size.

[cmbz]

2023/12/11: Updated labels to match original issue: #3702

[pdurbin]

@cmbz thanks!

My only reservation is that it's a new required field. Will some curators be annoyed by it? And does the API allow you to get around this requirement? We should probably have consistency between the UI and API, either required or not. And maybe it should be configurable (globally, for now) if it's required or not. @luddaniel do you have thoughts on this?

As for size, if we accept the code as-is with no changes, it's probably a 3. If we need to meet and discuss what the behavior should be, it's probably higher. Maybe we can continue discussing here.

[DS-INRA]

Mentionning the SPA frontend issue for this PR to appear there :

• Feature request : Return to Author - feedback note in the UI  dataverse-frontend#201

[cmbz]

2024/01/08: Moved to sprint ready as per prioritization meeting

[pdurbin]

@luddaniel over at #3702 (comment) @philippconzett is asking if the feature can be turned off. What do you think? Should we make it configurable? Make it possible to turn it off?

[luddaniel]

@luddaniel over at #3702 (comment) @philippconzett is asking if the feature can be turned off. What do you think? Should we make it configurable? Make it possible to turn it off?

1. I think we can do that with some work; Can we agree and the spec before developments/tests ?
   A new setting must be added, named :ReturnToAuthorReasonRequired, by default true (if absent) and can be disabled using this curl command curl -X PUT -d false http://localhost:8080/api/admin/settings/:ReturnToAuthorReasonRequired.
   This setting set to false will act the same on GUI popin (not displayed therefore not required) and API endpoint (not required).

2. OR; @philippconzett can you handle this by explain to curators to type something like "A curation report with feedback and suggestions/instructions will follow in another email ?".
   I mean this required reason can be addressed with whatever meaningful informations as long as a minimum of 1 character...
   The release note can be decorated by Do not consider this requirement as a barrier as it can be supplemented with a creative and meaningful comment such as "The author would like to modify his dataset", "Files are missing", "Nothing to report", "A curation report with comments and suggestions/instructions will follow in another email".

As time is precious, I prefer option 2.

Waiting for your response @pdurbin @philippconzett
Regards

[philippconzett]

Thanks, @luddaniel! Option 2 is fine for us. Please make sure to include the instruction in the release notes and the guide update.

[sekmiller]

Looks like all of the previous update requests have been implemented. @luddaniel can you please make sure that this branch is up to date with the latest from develop? thanks!