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

Make participants editable by editors #1569

Closed
janno42 opened this issue Mar 14, 2021 · 2 comments · Fixed by #1639
Closed

Make participants editable by editors #1569

janno42 opened this issue Mar 14, 2021 · 2 comments · Fixed by #1639
Assignees
Labels
[C] Backend Focuses on backend implementation [C] Frontend Focuses on frontend implementation [P] Major Major priority
Milestone

Comments

@janno42
Copy link
Member

janno42 commented Mar 14, 2021

Editors are currently not able to change participants of an evaluation and have to send a message asking for changes instead. This results in a lot of work for the evaluation team. Since recently, all changes are logged, so editors can be allowed to change the participants themselves, and staff users can see what changes have been made.

This should be done as follows;

  • The list of participants should become an editable form field just like in the staff form and should be placed at the same position as in the staff form instead of at the end of the page.
  • The field (both for editors and staff) should be changed to contain exactly one person per line (by changing the select2 elements' CSS).
  • If the log contains participant changes done by users who are not staff and the evaluation was not yet approved by a staff user, the participant field in the staff form should show a warning (e.g., by having a yellow border).
@janno42 janno42 added [C] Backend Focuses on backend implementation [C] Frontend Focuses on frontend implementation [P] Medium Medium priority [P] Major Major priority and removed [P] Medium Medium priority labels Mar 14, 2021
@karyon
Copy link
Collaborator

karyon commented Mar 14, 2021

That's pretty cool. And a little obvious in hindsight again :D

It does feel a little weird to me to use the logging component for business logic. An alternative could be a boolean flag on the evaluation, like "participations_modified". This might even be simpler and more robust in the end than searching those JSONs for participation changes. The flag could also be cleared easily if need be (perhaps when sending the evaluation back to editors?), that would be a lot harder with logging entries.

Or maybe display a filtered log with all the entries that should be reviewed somewhere above the save buttons?

If not, I suppose marking (e.g. coloring) log entries that should be reviewed in the log below the save buttons could help so staff users have to search less if the log gets long.

Or maybe move the entire log above the buttons, but by default only show entries that should be reviewed, and provide a "Show full log" button?

:)

@janno42
Copy link
Member Author

janno42 commented Mar 15, 2021

I'm fine with both using the flag and coloring log entries. For the time being, we could also omit the warning part, because another larger issue with logging/highlighting refactoring for the evaluation form will be added soon.
Making the participants editable is especially important and can be implemented even if the other requirements have not yet been fully specified.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[C] Backend Focuses on backend implementation [C] Frontend Focuses on frontend implementation [P] Major Major priority
Development

Successfully merging a pull request may close this issue.

3 participants