On Friday, March 10, 2017 at 2:33:47 AM UTC-8, Mojca Miklavec wrote: > > Hi, > > On 9 March 2017 at 22:20, RjOllos wrote: > > On Thursday, March 9, 2017 at 10:31:18 AM UTC-8, Peter Suter wrote: > >> On 09.03.2017 10:16, Mojca Miklavec wrote: > >> > > >> > Is there any way to give more permissions to owners of tickets and to > >> > those who open the ticket? > >> > >> Can you try this cook book recipe? > >> > >> > https://trac.edgewall.org/wiki/CookBook/PermissionPolicies#GrantapermissiontotheTicketOwner > > >> > >> Peter > > Thanks a lot for the hint. This looks reasonable/doable. (I just need > to wait for the admin to try this out, I don't have permissions to > change this myself, I'll report once we test it.) > > > The other point for MacPorts to consider is what permissions are > necessary > > to assign (set the owner of) a ticket. > > Assigning the owner of a ticket can currently be done by any developer > (with commit access), so basically by anyone who currently holds the > right to modify a ticket (changing title, description, add people to > CC, ...). > > Non-developers cannot even assign the newly opened tickets. Users are > asked to CC maintainer. > Our usual workflow is that some developers go over tickets from time > to time and assign the owner. If maintainer is also a developer (with > elevated rights), he would get an email when being CC-ed and assign > the ticket to himself. If a maintainer doesn't have elevated rights, > this step would usually be done by another developer. > > This doesn't seem to be problematic. > > The only potential "problem" I see is that sometimes packages have > multiple maintainers and only one can be assigned as the owner by > Trac. Ideally I would give all the maintainers the same permissions, > but the only sane way to fix this would probably be to allow multiple > owners. (That's probably something that Trac developers might not be > willing to change?) >
It has been requested, but not yet implemented. I don't know that it will ever be implemented since there are trade-offs in allowing this. I have yet to see an issue tracking system that allows it, for example I don't know that it can be done in JIRA. https://trac.edgewall.org/ticket/2662 I would be interested to see examples of issue tracking system that allow this. There is a way you could support multiple maintainers but it would be more complex. It looks like the package name is contained in your "Port" field. You could have a IPermissionPolicy that used the "Port" rather than owner to determine which "maintainers" have elevated permissions for a ticket. There would be a few problems to solve: (1) You'd need to store the list of maintainers so that you could query them in the permission policy. You could write a small plugin to support that, and store the maintainers in a flat file or the database. I plan to eventually do something like that for trac-hacks.org. On trac-hacks.org the "maintainer" concept is slightly different from MacPorts. The maintainer has elevated permissions for the repository, tickets and wiki page associated with a single plugin. The plugin name is stored in the ticket Component field, the maintainer is stored in the Component owner field, and currently only one maintainer is supported. (2) Anyone could change the "Port" so you may to put restrictions on who can edit that custom field. It could be also be done in a plugin, but it would be simpler if custom fields had a permission attribute. I've been considering looking into adding that. You probably don't want to add that complexity now, but if you find it's important to support multiple maintainers then it can be done. > > As long as something like the default > > workflow (1) is used where TICKET_MODIFY is required to assign a ticket, > and > > only "senior members" have TICKET_MODIFY, the permission policy should > work > > fine without further configuration. > > That's probably what I described above? > Yes, sounds like it will work well. > > In this context I'm loosely using > > "assign" to mean a workflow action with a set_owner operation. In more > > complex scenarios a special permission (3) may be desirable to restrict > who > > can assign a ticket, thereby granting the elevated permissions. > > I don't think we need any special kind of permissions to assign the > owner of the ticket. (Can the owner assign another owner and thus > loose his rights? Or can that be prevented?) > If assign, accept and similar actions (any action with a set_owner operation) require TICKET_MODIFY, which is the default, and since you've stated that "maintainers" don't have TICKET_MODIFY, they won't be able to reassign tickets. Take a look at your workflow to confirm, but sounds like the relevant workflow actions do require TICKET_MODIFY, > > (1) https://trac-hacks.org/ticket/1453#comment:10 > > (2) > > > https://trac.edgewall.org/wiki/TracWorkflow#BasicTicketWorkflowCustomization > > (3) https://trac.edgewall.org/wiki/ExtraPermissionsProvider > > Thanks to both, > Mojca > - Ryan -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
