Ticket/Report view permissions dependent on owner (or user logged in)

[StefanW@…]

We are a software development company and give access to our trac-page to our customers over internet so that they can add feature requests and post bugs-fix-requests. It turned out, that it is not good, that some of our customers can see tickets, which where added by our developers. We only want the costumers to see the tickets, which they added cause some customers are afraid of bug-tickets which where created by our developers. So we need some kind of permission that the customer only sees the tickets what he added. We thought also for some kind of dynamic view of reports dependent on the login-name. So our developers can choose the 'All active tickets' and the customer can only see and choose the report 'active ticket from [LoggedInUser]'.

Customers who are familiar with software development are not afraid of a growing ticket list caused by bug-fixing-requests created by our developers. But customers who are not familiar with software development don't know that it is absolute normal through a software-development-live-cycle that bugs are occuring and they have to be written down somewhere and beeing fixed when the right time comes. Would be nice if you could comment this ticket whether that is a priority feature for you to implement in the next few months or not. Group permissions would also be cool in that case. So we could split up the users in 'developers' and 'customers' (or 'partner-developers'…) If money could increase the speed of development of this feature, let me know.

[Christopher Lenz]

Note for 0.9.

[raven@…]

I'm also very interested in such feature as a quick solution i did the following:

• users in "group" developer can see all tickets
  
• all other users can only see self created oder assigned tickets.
  

edit all reports below "view tickets" and limit the sql statements to developer "group", e.g. the "view all tickets" sql should be as follows (look for the perm keyword):

SELECT p.value AS __color__,
   id AS ticket, summary, component, version, milestone, t.type AS type, severity, 
   (CASE status WHEN 'assigned' THEN owner||' *' ELSE owner END) AS owner,
   time AS created,
   changetime AS _changetime, description AS _description,
   reporter AS _reporter
  FROM ticket t, enum p, permission perm
  WHERE status IN ('new', 'assigned', 'reopened') 
AND p.name = t.priority AND p.type = 'priority' AND perm.action = 'developer' and perm.username='$USER'
  ORDER BY p.value, milestone, severity, time

in trac.ini disable the custom query link, so nobody can create querys

[components]
trac.ticket.query.* = disabled

[anonymous]

I would like to see this feature too

[anonymous]

To expand on this theme:

It would be nice if tickets could be set to be "public" or not. A simple version could be a ticket attribute that is a permissions group. A full implementation would probably allow a list of users/groups to be attached to each ticket. Naturally, there should be a default, and the value of this attribute should be changeable as the ticket proceeds though its lifetime. Presumably, regardless of this setting any given ticket should be visible to its creator and owner.

This would be very helpful for managing "moderated" public access to tickets.

[anonymous]

To add an actual case (happened to me tonight):

A developer or friend finds a security issue in the software. They report it on trac. Now I want to see this ticket, and the reporter too. But I don't want others to see it until I addressed the issue. That way the security sites wont find the ticket until I have a vender supplied patch.

I'll try Raven's post tomorrow.

[minaguib]

I would also very much like to see exactly what "03/06/06 16:34:46: Modified by anonymous" described. An "only for group XYZ" property that could be set on individual tickets.

We're a small IT team in a company and we use Trac internally to manage all our requests and multiple projects. As of right now requests hitting our team have to be proxied through someone in the team who creates the Trac tickets. We would love to open Trac to the rest of the company to allow them direct access to create their own tickets, however we absolutely need a way to hide certain sensitive tickets from the public view.

[Christian Boos]

See related discussion in ​Trac-Dev:476 about the PermissionPolicy features.

[Matthew Good]

This will be a part of the PermissionPolicy in 0.11.

[Christian Boos]

who's alect? ;)

[anonymous]

any updates on this?

[Noah Kantrowitz <coderanger@…>]

This is implemented in 0.10 in the ​PrivateTickets plugin.

[kuahyeow@…]

how about in 0.11dev?

[Christian Boos]

Yeah, I'm thinking about re-doing the PermissionPolicy based on WikiContexts.

[Christian Boos]

#3466 was closed as duplicate of this one.

There's also #2393, which is not strictly a duplicate, but request the same thing for the TICKET_APPEND permission.

Note that the PermissionPolicy feature is seeing good progress, so those features will likely get implemented (or be easily implementable as a plugin) soon.

[Christian Boos]

#2393 discussed a variation of the same theme.

I think we could add a sample PermissionPolicy plugin for this functionality.

[yura ivanov]

I need an option to actually hide tickets from reports, not only restrict to see (or comment) them. Is it possible? I mean if you can see all tickets (title, owner, reporter, summary) listed in report you actually have an access to restricted area… I understand that this ticket only about permissions, but need to be able use restriction table to hide restricted tickets. Simply add join to the report query and to be sure that all treestyle permissions will be cosidered (Customers→Company A→John can see in a report and view/comment only their company tickets).

[Alec Thomas]

TracDev/SecurityBranch merged in r5514. However, currently only the Wiki and attachment subsystems have been converted, so until the ticket, report and query subsystems are done (which will happen before 0.11) this will not actually be possible.

A sample plugin implementing authz based access control is included as an example.

[Christian Boos]

Besides adding the fine grained permissions to the ticket subsystem, I think we could add two useful sample plugins:

1. PrivateTicketsPolicy: restrict ticket viewing to the ones the user have created
2. SecurityTicketsPolicy: prevent any ticket flagged with a security keyword to be viewed by unprivileged users or the ticket reported

(stealing ticket away from aat, hope this will wake him up ;-) )

[Alec Thomas]

Bah! Still thinking about ways to fix the attachment problem actually.

Those two plugins are good sample ones too. Another might be to allow anybody in a group of users to view tickets created by other users in that group - a PrivateGroupPolicy.

[Christian Boos]

#5878 was marked as duplicate.

[Alec Thomas]

Since r5958 tickets are subject to the fine grained permission policies. The report and query subsystems will follow.

[Alec Thomas]

Also added a sample plugin that will deny access to tickets with "security" or "vulnerability" in the summary or keyword fields.

[Christian Boos]

Done in the source:sandbox/context-refactoring branch.

[Christian Boos]

Now in trunk (r6139). Please file any new issue with ticket permission as a new ticket.