Hide ticket by milestone (Python permissionpolicy recursion error)

[Tony]

Hello

I was looking for a way to hide tickets that have a specific milestone in their milestone field, but it shoul be hidden only to specific groups of users.

Example: If ticket has milestone1 only users with MILESTONE1_VIEW can see them. If this same ticket milestone is changed to milestone 2 then only users with MILESTONE2_VIEW can see them.

I searched for plugins, googled, etc. I found no way to do this by now. I also tried the fine grained permissions using

[milestone:milestone1:ticket:*]
admin = !TICKET_VIEW

hoping this would hide the tickets in milestone1.

If someone have a way to do this please add a comment to this ticket.

[Christian Boos]

That's a typical example of custom need that can be easily achieved by writing a small PermissionPolicy plugin.

See source:branches/0.11-stable/sample-plugins/permissions/vulnerability_tickets.py​ for a good starting point.

Note that:

[milestone:milestone1:ticket:*]

can't work as tickets are not considered to be sub-resources of a milestone.

[Tony]

Thanks for the hint on the file. Im getting some erros while using this code bellow:

from trac.core import *
from trac.perm import IPermissionPolicy, IPermissionRequestor

revision = "$Rev$"
url = "$URL$"

class MilestoneOneTicketsPolicy(Component):
    """Prevent public access to security sensitive tickets.
    
    Add the VULNERABILITY_VIEW permission as a pre-requisite for any
    other permission check done on tickets that have the words
    "security" or "vulnerability" in the summary or keywords fields.

    Once this plugin is enabled, you'll have to insert it at the appropriate
    place in your list of permission policies, e.g.
    {{{
    [trac]
    permission_policies = SecurityTicketsPolicy, AuthzPolicy, 
                          DefaultPermissionPolicy, LegacyAttachmentPolicy
    }}}
    """
    
    implements(IPermissionPolicy, IPermissionRequestor)

    # IPermissionPolicy methods

    def check_permission(self, action, username, resource, perm):
        # We add the 'VULNERABILITY_VIEW' pre-requisite for any action
        # other than 'VULNERABILITY_VIEW' itself, as this would lead
        # to recursion.
        if action == 'MILESTONE_ONE_TICKETS_VIEW':
            return
        
        # Check whether we're dealing with a ticket resource
        while resource:
            if resource.realm == 'ticket':
                break
            resource = resource.parent

        if resource and resource.realm == 'ticket' and resource.id is not None:
            db = self.env.get_db_cnx()
            cursor = db.cursor()
            cursor.execute("SELECT milestone, reporter FROM ticket WHERE id=%s",
                           (resource.id,))
            for milestone, reporter in cursor:
                fields = ''.join([f for f in (milestone, reporter) if f]).lower()
                if 'milestone1' in fields and username not in fields:
                    if 'MILESTONE_ONE_TICKETS_VIEW' not in perm:
                        return False

    # IPermissionRequestor methods

    def get_permission_actions(self):
        yield 'MILESTONE_ONE_TICKETS_VIEW'

It should hide a ticket if it has milestone1 in field milestone and the logged user is not the ticket reporter.

It gives me: Maximum recursion loop reached. So it is entering in an infinite loop or something like this.

Any help is welcome.

[anonymous]

Same problem here…

[Christian Boos]

Sorry, no milestone for errors in plugins … until you demonstrate this is really a bug with Trac, which is not the case here. Look at the backtrace, this is often enough to figure out what logical error caused the recursion (and without that info, the error isn't immediately obvious to me).

Also, why put miletone and reporter into a fields string (not even space separated), and check using "in"? Seems more straightforward to do something like:

   if milestone == 'milestone1' and username != reporter:

[Tony]

Solved

There were 2 fine grained permissions scripts in my environment, both were related to a single milestone, so one was requesting permission to the other generating an infinite recursion.

Was fixed by just removing one of the scripts (Was no more necessary).

[Christian Boos]

Thanks for the update!

I was sure there was a missing piece somewhere ;-)

However we only close tickets as fixed here when this involve some kind of code change on our side.

[Christian Boos]

(worksforyou)