Skip to content
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

dashboard: add option to manager widget to remove Uploaders and Reviewers #94

Closed
GraemeWatt opened this issue Apr 12, 2017 · 6 comments · Fixed by #474
Closed

dashboard: add option to manager widget to remove Uploaders and Reviewers #94

GraemeWatt opened this issue Apr 12, 2017 · 6 comments · Fixed by #474
Assignees
Labels
complexity: medium priority: high type: bug Indicates an unexpected problem or unintended behaviour

Comments

@GraemeWatt
Copy link
Member

Currently new Uploaders or Reviewers can be added from the Dashboard, but not removed.

@alex-t-grecu
Copy link

This feature would be useful if coordinators nominate any users for these roles by mistake. On rare occasions it really happens (when paper title are quite similar).

@GraemeWatt GraemeWatt added complexity: medium priority: high type: bug Indicates an unexpected problem or unintended behaviour labels Feb 4, 2021
@alisonrclarke
Copy link
Contributor

alisonrclarke commented Dec 16, 2021

A few questions:

  • Should we notify users when they have been removed from a submission?
  • If so, should we give the coordinator the ability to add a message?
  • Is is worth keeping the SubmissionParticipant record (e.g. with status 'deleted') in case we want to see the deleted users later on?

@GraemeWatt
Copy link
Member Author

I don't think that a notification is necessary and we can just delete the SubmissionParticipant entry.

The "delete" button should only appear next to Reserve Uploaders/Reviewers, i.e. the Coordinator needs to first demote from Primary to Reserve before they can delete.

Related to this issue is #191, i.e. adding a button to the manager widget to allow a Coordinator to resend primary Uploader/Reviewer invitations, preferably with the option to add a personalised message. The option to add a message should also be added when an Uploader/Reviewer is promoted from Reserve to Primary. Currently, messages can be added to invitations when a submission is initially created, but not when Uploaders/Reviewers are added later from the Dashboard.

@alisonrclarke
Copy link
Contributor

Have begun work on delete-participants branch - still need to add tests.

Just wondering whether it could be confusing for users in the case @alex-t-grecu mentions: they will receive an invitation email, but they could be removed from the submission before clicking the link, so will get a 'Sorry, you don't have permissions to access this record.' page. Is it not better to explain what's going on?

@alex-t-grecu
Copy link

Oh, this is quite an old feature request. And since the feature with promoting/demoting reviewers and uploaders was implemented, I do not know if it is any more of interest. I think however there is a special case when uploaders/reviewers proposed by the collaboration do not actually use the email address sent to the coordinator in order to enrol them in HepData (or this data if not valid). It would be useful to know/document how role definition for already enrolled people can be edited in case there is some typo in the e-mail and/or name and, more important, whether such editing operation triggers another email message to be sent, to the corrected email for instance.
I acknowledge that alternatively the coordinator could always demote and delete then reinstate the role with the correct contact data. So in my opinion as long as these mechanisms detailed above work I think one could avoid pursuing this issue any further.
Related to this, there is however an interesting feature that could help coordinators, namely, a basic mechanism to inform the coordinator when the persons nominated to different roles regarding an on-going encoding actually interact with the HepData portal based either on the email they receive or simply by accessing the temporary record created for the encoding. This would be of great help in order to understand why for some records there is no progress for a long time and it could help in re-opening discussions about the feasibility of publishing some specific record to HepData (some times proponents are urged to prepare their measurement for HepData, but discover at some point during journal review there is either no time to invest in this action or there are no more available human resources for the task). I think what I propose is to have a limited amount of time (a few months) for an invitation to expire and then have the dashboard pop-up some warning that the record is "forgotten". I could open a different issue on the subject if you consider it worthy of debate.

@GraemeWatt
Copy link
Member Author

Just wondering whether it could be confusing for users in the case @alex-t-grecu mentions: they will receive an invitation email, but they could be removed from the submission before clicking the link, so will get a 'Sorry, you don't have permissions to access this record.' page. Is it not better to explain what's going on?

OK, maybe better to send an email (with an optional message from the Coordinator). But permissions are already lost when demoting an Uploader/Reviewer from Primary to Reserve, so better to send an email at that stage, then a further email is not needed when an Uploader/Reviewer is deleted. I had assumed that the Coordinator would only remove permissions if they were not needed by the Uploader/Reviewer and keep them informed privately, but of course it is better for communication to be made automatically by the HEPData submission system.

Thanks for the comments, @alex-t-grecu. Yes, it happens sometimes that wrong email addresses are entered, due to either a typo or just using a different email address to the one associated with a user's HEPData account (e.g. CERN/institutional). An ability to edit email addresses might be useful, but it could be complicated if permissions have already been claimed. Editing email addresses could effectively be accomplished in a few steps (demote, delete, add new), which is probably sufficient.

Your other proposal is very interesting, but I'll move it to a new issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
complexity: medium priority: high type: bug Indicates an unexpected problem or unintended behaviour
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants