Changes between Initial Version and Version 1 of Ticket #11949, comment 7
- Timestamp:
- Feb 9, 2015, 7:32:55 AM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #11949, comment 7
initial v1 6 6 > [By the way, I agree a separate ticket creator field wouldn't be desirable. I think my preference would be to disallow setting the reporter when creating a ticket and only allow it to be modified afterwards (although that would mean the author receiving notifications for that ticket which they might not want).] 7 7 8 For your use case I think you could just revoke `TICKET_ADMIN` for the newticket realm using TracFineGrainedPermissions to prevent users from setting the reporter field. Unless the `TICKET_ADMIN` permission actually grants the ability to perform a workflow action or effects some other behavior on the newticket page, which seems like a rare circumstance, then you should see no side-effects from revoking `TICKET_ADMIN` for the realm.8 For your use case I think you could just revoke `TICKET_ADMIN` for the newticket realm using TracFineGrainedPermissions to prevent users from setting the reporter field. Unless the `TICKET_ADMIN` permission actually grants the ability to perform a workflow action (which will only be possible in 1.1.3 and later) or effects some other behavior on the newticket page, which seems like a rare circumstance, then you should see no side-effects from revoking `TICKET_ADMIN` for the realm. 9 9 10 10 More generally, it's worth considering whether only users with `TRAC_ADMIN` should be able to edit the reporter field from the newticket page, simply because the change is not tracked in the `ticket_change` table, like you've explained. I'll have to give it more thought and ask for input from the other devs.