Edgewall Software

Changes between Initial Version and Version 1 of Ticket #11949, comment 7


Ignore:
Timestamp:
Feb 9, 2015, 7:32:55 AM (9 years ago)
Author:
Ryan J Ollos

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #11949, comment 7

    initial v1  
    66> [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).]
    77
    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.
     8For 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.
    99
    1010More 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.