fine grained permissions and tags/fields

[Sam Halliday]

Hi all,

I've had a read of

  http://trac.edgewall.org/wiki/TracPermissions

  http://trac.edgewall.org/wiki/TracFineGrainedPermissions

and I'm still not sure how to implement a policy that I want to use.

I'd like to set up permissions so that named users/groups can have access to wiki pages (which have a tag, using TagsPlugin, of a particular value) and tickets (which have a field of a particular value - which might be a custom field).

For example: user "joe.blogs" has access to pages (and their attachments) with tag "joe" and tickets (and their attachments) which contain the keyword "joe" or are filed against a component called "Joe's Component". He's also allowed to look in the "Joe's Repository" repository (direct svn access is controlled elsewhere).

Is this possible? Has anyone done something like this in the past?

Regards, Sam

[Ethan Jucovy]

It should be possible, but I don't know of a plugin that does what you want already.  You'll need to write a plugin that implements IPermissionPolicy, and in its check_permission method you'll want to return True if the user is allowed to view the resource, and False otherwise -- that is, I am assuming that you want joe.blogs to be *unable* to view tickets which *don't* contain the keyword "joe", etc.  You will then need to install your plugin and configure it in front of your permission_policies configuration option as described in those wiki pages.  The bulk of the work will be figuring out, on each check_permission call, whether your plugin should have an opinion or not, and what the "relevant resource" is.

Trac passes a ``resource`` object to check_permission which might be a ticket, repository, source file, wiki page, attachment, milestone, or any other kind of Trac resource.  So you'll need to check the resource's "realm" (which will indicate the type of the resource e.g. "ticket", "repository", etc) and then poke around its attributes to find the things that matter to your permission policy.

You might want to look at the SensitiveTicketsPlugin to see the general idea of how this works: https://bitbucket.org/hasienda/t-h.o_shadow/src/ec2c58e517b9/sensitiveticketsplugin/trunk/sensitivetickets/sensitivetickets.py#cl-90

For some resources -- attachments, and resources within a repository -- you'll need to walk up the resource tree to find the "relevant" resource.  For example, with an attachment you'll want to walk up each resource's parent until you find a resource with realm == "ticket" (or "wiki") and then use that ancestor resource to determine permissions.  If you want to control Browser/Repository access here too, you'll also need to walk the resource tree for repository resources: when viewing a specific file or changeset, the chain of resource.parent pointers will lead you to the repository that houses that file.  Here's an example of how to do this:

https://gist.github.com/3394993

The self.parent_repository() bit is where the "relevant resource" is found.  Basically, you'd need to expand that parent_repository() code to cover *all* resource realms of interest -- you'd want to walk up the tree for any resource, until you find a repository, ticket, or wiki page; and then use the attributes of that ancestor to determine whether the permission request should be granted, denied, or deferred to the rest of Trac's permission system.

Hope this helps,

Ethan

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/trac-users/-/jLFKn2t0H4wJ.
To post to this group, send email to trac-...@googlegroups.com.
To unsubscribe from this group, send email to trac-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/trac-users?hl=en.