TICKET_MODIFY permission acting like TICKET_ADMIN

[Shawn Baker]

I recently upgraded from a Trac 0.11 server to 1.0.2.  I am seeing what I think is weird behavior for ticket permissions.

I have a "new" ticket that my user submitted (user1).  Trac is setup to default the ticket ownership to a specific user (user2).  So user1 is the reporter, but and user2 is currently owner of this ticket.  However, I have the following ticket modification options available to user1:

Leave as new The owner will remain user2.

Accept. Next status will be 'accepted'.

Reassign to <user drop down>. The owner will be changed from user2 to the selected user. Next status will be 'new'.

Requires more information and assign to <user drop down>. The owner will be changed from user2 to the selected user. Next status will be 'needinfo'.

Close as <resolution drop down>. The resolution will be set. Next status will be 'closed'.

These are the permissions for user1:
TICKET_APPEND, TICKET_CHGPROP, TICKET_CREATE, TICKET_MODIFY, TICKET_VIEW

This is the workflow for a ticket in this status:
new_accepted = new,needinfo, reopened -> accepted
new_accepted.default = 3
new_accepted.name = Accept.
new_accepted.permissions = TICKET_MODIFY
new_needinfo = new -> needinfo
new_needinfo.default = 1
new_needinfo.name = Requires more information and assign
new_needinfo.operations = set_owner
new_needinfo.permissions = TICKET_MODIFY
new_reassign = new -> new
new_reassign.default = 2
new_reassign.name = Reassign
new_reassign.operations = set_owner
new_reassign.permissions = TICKET_MODIFY
leave = * -> *
leave.default = 4
leave.name = Leave
leave.operations = leave_status
closed = new,needinfo,reopened,open -> closed
closed.default = 0
closed.name = Close
closed.operations = set_resolution
closed.permissions = TICKET_MODIFY
closed.set_resolution = wontfix,invalid,duplicate,limitation

So, my question, am I missing something with Trac 1.0.2 to disallow users from changing the status of tickets other than their own?

Thanks for any help,
Shawn

[Ryan Ollos]

The behavior you are seeing looks like what I'd expect for the configuration you've shown. There's nothing to limit the ticket workflow actions to tickets for which the user is the owner. That would require a plugin with a custom permissions policy. Nothing has changed in that regard since 0.11 as far as I know.  I'll post an example shortly.

[Ryan Ollos]

First a side note. Your "new_accepted" action seems to be a "dead-end". You don't show any actions that could move your ticket out of the accepted state. Insert [[Workflow]] into a wiki page and you can see that there are no transitions out of the accepted state with your workflow. There also aren't any actions to move a ticket out of the closed state, e.g. reopen.

With the permission policy I'll propose, you'll need to define additional workflow actions that would allow someone with higher permissions to deal with tickets that don't have an owner, or have an owner that won't do any work on the ticket. That is, unless you've configured your system to avoid every one of these situations. For example, you may want to also allow someone with TICKET_ADMIN to perform all the workflow action. Just append TICKET_ADMIN to the permissions attribute of each workflow action you want to allow, e.g.

new_reassign.permissions = TICKET_CHANGE_STATE, TICKET_ADMIN

To implement the permissions policy:

Add RestrictTicketActionsPolicy to the permission_policies in the [trac] section of trac.ini: permission_policies = RestrictTicketActions, DefaultPermissionPolicy, LegacyAttachmentPolicy

If you are using finer-grained policies such as AuthzPolicy, they may need to go before RestrictTicketActions.

Grant TICKET_CHANGE_STATE to users that should be able to change the states of tickets that they own. This might be all authenticated users.

Copy the following into a file named restrict_actions.py in your environment or shared plugins directory:

# -*- coding: utf-8 -*-
#
# Copyright (C) 2014 Edgewall Software
# All rights reserved.
#
# This software is licensed as described in the file COPYING, which
# you should have received as part of this distribution. The terms
# are also available at http://trac.edgewall.org/wiki/TracLicense.
#
# This software consists of voluntary contributions made by many
# individuals. For the exact contribution history, see the revision
# history and logs, available at http://trac.edgewall.org/log/.

from trac.core import *
from trac.perm import IPermissionPolicy, IPermissionRequestor
from trac.ticket.model import Ticket


class RestrictTicketActionsPolicy(Component):
    """Provides a permission for restricting ticket actions to the
    ticket owner.
    """

    implements(IPermissionPolicy, IPermissionRequestor)

    # IPermissionRequestor methods

    def get_permission_actions(self):
        return ['TICKET_CHANGE_STATE']

    # IPermissionPolicy methods

    def check_permission(self, action, username, resource, perm):
        if action == 'TICKET_CHANGE_STATE' \
                and resource is not None \
                and resource.realm == 'ticket' \
                and resource.id is not None:
            ticket = Ticket(self.env, resource.id)
            return ticket['owner'] == username
        return None

[Shawn Baker]

I suppose it is possible that the Agilo plugin (which we are no longer using) had permissions to not allow anyone but TICKET_ADMIN or the owner of the ticket to change the status of the tickets.  I really thought that Trac would have something like this out of the box.  It seems odd to me that anyone who is authenticated in the system can change the status of any ticket as they see fit.

[Shawn Baker]

I did not post the entire workflow in my original email, only the workflow sufficient for a ticket in the "new" state.  I definitely have states to move tickets out of accepted and any other state. 

On Thursday, November 20, 2014 10:34:21 AM UTC-5, RjOllos wrote:

First a side note. Your "new_accepted" action seems to be a "dead-end". You don't show any actions that could move your ticket out of the accepted state. Insert [[Workflow]] into a wiki page and you can see that there are no transitions out of the accepted state with your workflow. There also aren't any actions to move a ticket out of the closed state, e.g. reopen.

Thanks a lot for the permission policy.  I will take a look at it and see how it works out.

[Ryan Ollos]

On Nov 20, 2014 12:11 PM, "Ryan Ollos" <ryan.j...@gmail.com> wrote:

>
>
> On Nov 20, 2014 11:57 AM, "Shawn Baker" <scbak...@gmail.com> wrote:
> >
> > I suppose it is possible that the Agilo plugin (which we are no longer using) had permissions to not allow anyone but TICKET_ADMIN or the owner of the ticket to change the status of the tickets.  I really thought that Trac would have something like this out of the box.  It seems odd to me that anyone who is authenticated in the system can change the status of any ticket as they see fit.
>

Right, with the default data that ships with trac authenticated users will have TICKET_MODIFY and therefore be able to change tickets in the default workflow . The aim is to impose as little on the user as possible, and let users customize it for their needs. Usually it is simple to customize, but it does get more complex with specialized requirements such as permissions depending on ticket properties. If we receive repeated requests for certain requirements we might try to bundle the functionality into tracopt or sample-plugins.

I'll probably add this permissions policy to the CookbBook pages in the meantime.

[Shawn Baker]

Do I just put the restrict_actions.py file in my plugins directory? I don't need to do anything else with it?

[Steffen Hoffmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 20.11.2014 20:57, Shawn Baker wrote:
> It seems odd to me that anyone who is authenticated in the system can
> change the status of any ticket as they see fit.

Less restriction doesn't yield a mess automatically. Fact remains, that
this is how it works for a good number of projects. Personally I know
community-driven as well as commercial ones, but the number of
authenticated users varies a lot between all of them. The critical point
is, that you can track changes all the time.
Trac (timeline with RSS feed, individual change ticket/wiki/.. history)
also with RSS feed, these are powerful ways of social control in good
wiki common sense that work.

Steffen Hoffmann
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlRuTtcACgkQ31DJeiZFuHf6ngCdFw6oisLgXwvW/52EySIzXgRp
5PEAnjTAYvuZE2qrK7N8++NSowgfzsKx
=lVpy
-----END PGP SIGNATURE-----

[RjOllos]

Yes, that's all that is needed if you are running a single Trac environment. If you have multiple Trac environments (i.e. projects), then you might want to use the shared plugins directory:
http://trac.edgewall.org/wiki/TracIni#inherit-section

[RjOllos]

Did a quick write-up in the CookBook:
http://trac.edgewall.org/wiki/CookBook/PermissionPolicies

Please add to or comment on it based on your experience using the permission policy.