Edgewall Software

Opened 13 years ago

Closed 13 years ago

#8310 closed defect (worksforme)

Hide ticket by milestone (Python permissionpolicy recursion error)

Reported by: Tony Owned by:
Priority: normal Milestone:
Component: general Version: 0.12dev
Severity: trivial Keywords: permissionpolicy
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:



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

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.

Attachments (0)

Change History (7)

comment:1 by Christian Boos, 13 years ago

Keywords: permissionpolicy added; hide ticket by milestone removed
Milestone: 0.12
Resolution: wontfix
Status: newclosed

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:


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

comment:2 by Tony, 13 years ago

Resolution: wontfix
Status: closedreopened
Summary: Hide ticket by milestoneHide ticket by milestone (Python permissionpolicy recursion error)
Type: enhancementdefect

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.
    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':
        # Check whether we're dealing with a ticket resource
        while resource:
            if resource.realm == 'ticket':
            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",
            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):

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.

comment:3 by anonymous, 13 years ago

Milestone: 0.12

Same problem here…

comment:4 by Christian Boos, 13 years ago

Milestone: 0.12

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:

comment:5 by Tony, 13 years ago

Resolution: fixed
Status: reopenedclosed


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

comment:6 by Christian Boos, 13 years ago

Resolution: fixed
Status: closedreopened

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.

comment:7 by Christian Boos, 13 years ago

Resolution: worksforme
Status: reopenedclosed


Modify Ticket

Change Properties
Set your email in Preferences
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none) to the specified user.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.