View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002404 | HTML & PERL | Feature Request - Misc | public | 2016-03-01 04:06 | 2016-03-06 00:41 |
| Reporter | Hinoe | Assigned To | DerIdiot | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Summary | 0002404: Disallow assigning locked creqs or unlock on assign | ||||
| Description | if I assign a locked creq to someone, only that someone can reassign it (or at least I can't reassign it); accidentally assigning a creq to the wrong person can create all sorts of trouble. So it makes sense that this should be prevented by forcing me to first unlock the creq, instead of assigning a locked creq. This can be achieved by either disallowing the assignment of locked creqs altogether or by unlocking on assignment. | ||||
| Steps To Reproduce | Lock creq as handler. Assign to random user. Despair. | ||||
| Additional Information | Follow-up to testing 0002219 but not directly related. If any class has the power to reassign creqs locked by others, this ticket doesn't necessarily apply to them, but probably should anyway, as a safety/sanity precaution. | ||||
| Tags | No tags attached. | ||||
|
|
On second thought, I realized there are circumstances where you might want to assign a creq with a lock on it, to prevent the user from randomly revoking it while the new mod doesn't arrive or something. So I propose a separate plan instead, with the following two points: 1. Add a confirmation step to the effect of: "you are about to assign a LOCKED creq to USERNAME (UID), who holds the rank of (ADMIN/SENIOR MOD/MOD/ADV USER/etc). proceed?" And if the user doesn't normally have the power to handle that creq (not mod+/maintainer/verifier, as applicable), ask for confirmation _another_ time ("USERNAME isn't a mod for this creq, proceed anyway?"), just in case. 2. Ensure that at least senior mods can unlock creqs assigned to others no matter the circumstances, as a safety precaution. It may also be interesting to have two different assign buttons: "unlock and assign" and "assign locked creq", with the latter triggering all the warnings from point 1. Point 2 should be implemented regardless, assuming it's not that way already. |
