id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc,branch,changelog,apichanges,internalchanges 10833,"ConfigurableTicketWorkflow's ""Reassign To"" ignores fine-grained permissions with restrict_owner=True",Ethan Jucovy ,Ethan Jucovy ,"When `[ticket] restrict_owner = True`, the default ticket workflow implementation renders a dropdown box for actions that perform a `set_owner` operation. If the set of possible owners is not specified in the workflow configuration, it is populated with a call to `PermissionSystem(env).get_users_with_permission('TICKET_MODIFY')`, just like the similar dropdowns that are rendered by `TicketSystem.eventually_restrict_owner` on the new ticket form and query builder. However, after fetching the list of all known users with TICKET_MODIFY, the workflow does not check whether those users have the TICKET_MODIFY permission for the current ticket. If the system is configured to use a fine-grained permission policy like browser:trunk/sample-plugins/permissions/vulnerability_tickets.py, where the global TICKET_MODIFY permission does not guarantee TICKET_MODIFY for any given ticket, this could result in strange states where the ticket's owner does not have permission to close, modify or reassign the ticket. I'm not sure whether this actually is a bug that should be fixed. For one thing, as long as the users who have permission to reassign a ticket are trusted to know what they're doing, it's not really a problem. It's also not necessarily Trac's job to ensure that the owner field is restricted to ""sensible"" choices, and anyway there are plenty of other ways that the system could end up in a similar state with certain combinations of configuration.",defect,closed,normal,1.1.3,ticket system,,normal,fixed,,,,Fine-grained permission check is used to populate the list of owners when `[ticket] restrict_owner = True`.,`EnvironmentStub` has an `insert_known_users` method for populating the `session` table with known users.,