Permission to edit your own (submitted and assigned) tickets

[Mojca Miklavec]

Hi,

At MacPorts we have a concept of "maintainers". These are people
without commit access to our repositories and without any elevated
permissions. These are volunteers who are responsible for maintaining
individual packages (providing patches etc.), but all their changes
need to be approved and committed by "senior" members who do some
quality control first. This is meant to lower the barrier to entry,
allowing anyone to volunteer to do the work even if they don't have
sufficient experience yet.

The problem is that these users get tickets assigned to them, but they
cannot do anything about them other than leaving further comments and
adding attachments. They cannot change title, edit description, add
keywords, CC any further developer to ask for help, ...

Another problem is that people who open a new ticket have no way to
make any further change to the ticket once they click a submit button.

Is there any way to give more permissions to owners of tickets and to
those who open the ticket?

There are some ancient potentially relevant tickets, but I suspect
that they were forgotten after so many years:

https://trac.edgewall.org/ticket/7438
https://trac.edgewall.org/ticket/10175

The request came from one of our users:
https://trac.macports.org/ticket/53755

Mojca

[Peter Suter]

Hi,

Can you try this cook book recipe?
https://trac.edgewall.org/wiki/CookBook/PermissionPolicies#GrantapermissiontotheTicketOwner

Peter

[RjOllos]

That looks nice, and similar questions come up quite often so thanks for adding the CookBook recipe. I think we can use a variation to satisfy #1453 (1) on trac-hacks.org.

The other point for MacPorts to consider is what permissions are necessary to assign (set the owner of) a ticket. 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. 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.

(1) https://trac-hacks.org/ticket/1453#comment:10

(2) https://trac.edgewall.org/wiki/TracWorkflow#BasicTicketWorkflowCustomization

(3) https://trac.edgewall.org/wiki/ExtraPermissionsProvider

[Mojca Miklavec]

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?)

> 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?

> 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?)

> (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

[RjOllos]

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

 

[RjOllos]

On Thursday, March 9, 2017 at 10:31:18 AM UTC-8, Peter Suter wrote:

Some ideas generated from your implementation can be found in:
https://trac.edgewall.org/ticket/12719

- Ryan