-
Notifications
You must be signed in to change notification settings - Fork 495
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Returning to author now requires a reason that is sent by email to the author #10137
Returning to author now requires a reason that is sent by email to the author #10137
Conversation
…is sent by email to the author
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One more question.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding feedback from @sbarbosadataverse (from Slack).
Co-authored-by: Philip Durbin <[email protected]>
…acts of collection in return to author email
Here is the demo of the last version : demo_return_to_author_v3.mp4 |
@@ -781,7 +781,8 @@ notification.email.createDataverse=Your new dataverse named {0} (view at {1} ) w | |||
# Bundle file editors, please note that "notification.email.createDataset" is used in a unit test | |||
notification.email.createDataset=Your new dataset named {0} (view at {1} ) was created in {2} (view at {3} ). To learn more about what you can do with a dataset, check out the Dataset Management - User Guide at {4}/{5}/user/dataset-management.html . | |||
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.wasReturnedByReviewer={0} (view at {1} ) was returned by the curator of {2} (view at {3} ). | |||
notification.email.wasReturnedByReviewer={0} (view at {1} ) was returned by the curator of {2} (view at {3} ).{4} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be a good opportunity to be more precise :)
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
@@ -781,7 +781,8 @@ notification.email.createDataverse=Your new dataverse named {0} (view at {1} ) w | |||
# Bundle file editors, please note that "notification.email.createDataset" is used in a unit test | |||
notification.email.createDataset=Your new dataset named {0} (view at {1} ) was created in {2} (view at {3} ). To learn more about what you can do with a dataset, check out the Dataset Management - User Guide at {4}/{5}/user/dataset-management.html . | |||
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})\! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
Hello @pdurbin, it seems like everybody's desire has been listened, how can we move forward on this PR ? |
@luddaniel yes, thanks for being so responsive! Next we check with @cmbz and @scolapasta to see where this fits into priorities, etc. |
2023/12/11
|
2023/12/11: Updated labels to match original issue: #3702 |
@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. |
Mentionning the SPA frontend issue for this PR to appear there : |
2024/01/08: Moved to sprint ready as per prioritization meeting |
@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? |
As time is precious, I prefer option 2. Waiting for your response @pdurbin @philippconzett |
Thanks, @luddaniel! Option 2 is fine for us. Please make sure to include the instruction in the release notes and the guide update. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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!
I'm having second thoughts (sorry!) about this feature being mandatory for all Dataverse installations starting with v6.2, for a couple of reasons:
Thus, I wonder how we could mitigate the trouble this feature might cause for repositories with established curation workflows. Here are some suggestions: Suggestion a is preferable. Can someone estimate the resources necessary to implement solution b. I know I should have realized and discussed this earlier, but I think in the future, we should have some guidelines for how ideas of features which might have unfortunate consequences for other installations should be handled before PRs are created and merged. For example, in the Invenio RDM community, new feature ideas are first discussed in GitHub Discussions and only after enough votes and a consensus, they are moved forward. Thanks! |
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 asWorkflowComment
on aDatasetVersion
, 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 #3702Suggestions on how to test this:
All the XHTML part with
required
field andremoteCommand
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.