TICKET_MODIFY groups others Permissions and also incorporates unique permission caracteristics that could'nt be used alone ("TICKET_STATE_UPDATER")

[gustavovera@…]

According to the documentation, the TICKET_MODIFY permission Includes both TICKET_APPEND and TICKET_CHGPROP, and in addition allows resolving tickets

What if I only want to allow a user to "resolve" tickets, but not to allow him to change properties like the version or priority??. I could almost "lost" the visibility of an important ticket if, by mistake or intentionally, it property "Version" y changed to a very distant in future one.

TICKET_MODIFY is acting as a grouping clause for the permissions TICKET_APPEND, TICKET_CHGPROP and "TICKET_STATE_UPDATER" (or something like that).

That could by fine…. but trac could be more flexifle if the permissions defined where more granular.

We can achieve the same results that the ones why get asigning the current TICKET_MODIFY using Permision Groups (I think this is something already Implemented too!!!), but I can't get the effect (or I don't know how to) of an only asigned "TICKET_STATE_UPDATER"

[sid]

Duplicate of #3163. Please read the comments there for ideas for directions this work can go.

[osimons]

With 0.11 this can be achieved using WorkFlow / TracWorkflow - even to the point of having different permissions for each resolution or state change. With a plugin, a workflow can also be combined with a new permission type for any particular purpose by implementing the IPermissionRequestor interface.

See trunk/sample-plugins/workflow/CodeReview.py​ for an example plugin.

Bordering on a 'worksforme'…