Unique permission for assigning a ticket to a milestone

[RjOllos]

I'm wondering if anyone knows a fairly simple way to implement the
following in Trac 0.12. Our software development plan requires that
*only* Ticket Review Board members have the ability to assign tickets
to a milestone. There are two groups, trb and developers. The
developers need to be able to see which ticket a milestone is assigned
to, but shouldn't be able to change the milestone that a ticket is
assigned to. Developers also need to be able to view milestones and
currently have the MILESTONE_VIEW permission.

With the MILESTONE_VIEW permission, a user can assign tickets to a
milestone (1). So I need to revoke the ability for users with
MILESTONE_VIEW to assign tickets to a milestone, and add a permission
for assigning tickets to a milestone (e.g. TICKET_CHGMILESTONE).
Actually, the latter is probably not necessary since members of trb
have MILESTONE_CREATE and MILETONE_MODIFY permission.

So, basically it looks like I just need to figure out how to revoke
"assign tickets to a milestone" for users with MILESTONE_VIEW
permission, but retain the ability to review the milestone.

(1) http://trac.edgewall.org/wiki/TracPermissions#Roadmap

[Cooke, Mark]

Hmm, while I don't have an answer, I had not realised that the _VIEW permission allowed to assign tickets, surely `_VIEW` should be a read-only permission?

I would be tempted to put this in as an enhancement request, perhaps with a MILESTONE_ASSIGN permission for what you want?

~ mark c

[RjOllos]

On Tuesday, May 1, 2012 2:28:42 AM UTC-7, Cooke, Mark wrote:

Hmm, while I don't have an answer, I had not realised that the _VIEW permission allowed to assign tickets, surely `_VIEW` should be a read-only permission?

I would be tempted to put this in as an enhancement request, perhaps with a MILESTONE_ASSIGN permission for what you want?

When searching, I found that I had opened a ticket for this about 3 years ago (1), which is vaguely familiar.

I did some more testing and found that what I originally said was mostly correct. If and only if a user has TICKET_CHGPROP (or TICKET_MODIFY, TICKET_ADMIN or TRAC_ADMIN) permission, they'll be able to change the milestone. However, if they don't have the MILESTONE_VIEW permission, they won't be able to see any milestones in the drop-down list of an existing ticket, other than the milestone that the ticket is assigned to. They can remove the milestone entry, setting the milestone to be an empty field. They are also able to set the milestone when a ticket is created.

 (1) http://trac.edgewall.org/ticket/8778

 

[RjOllos]

My previous comment might have been a bit confusing. I think the rules can be summarized like this:

MILESTONE_VIEW: allows setting the milestone at the time a ticket is created, but a user can't change the milestone for an existing ticket without TICKET_CHGPROP.

TICKET_CHGPROP (or permission that grants same privileges, such as TICKET_MODIFY): Allows milestone for a ticket to changed, but it can only be changed to NULL if user doesn't have MILESTONE_VIEW (or permission that grants same privileges, such as MILESTONE_MODIFY).

MILESTONE_VIEW + TICKET_CHGPROP: Change milestone for an existing ticket.

Without MILESTONE_VIEW or TICKET_CHGPROP, a user can still see the milestone field for a ticket, and therefore see the name of the milestone to which a ticket is assigned.

[RjOllos]

On Wednesday, May 2, 2012 11:14:58 PM UTC-7, RjOllos wrote:

However, if they don't have the MILESTONE_VIEW permission, they won't be able to see any milestones in the drop-down list of an existing ticket, other than the milestone that the ticket is assigned to. They can remove the milestone entry, setting the milestone to be an empty field. They are also able to set the milestone when a ticket is created.

 (1) http://trac.edgewall.org/ticket/8778

 

This issue is dealt with in #10984. With the changes proposed in #10984 the milestone select will be completely hidden when the user doesn't have MILESTONE_VIEW for any milestone resources.

http://trac.edgewall.org/ticket/10984#comment:11