Opened 9 years ago

Closed 9 years ago

Last modified 4 years ago

#1662 closed enhancement (fixed)

Separate regular account permissions and dev/admin account permissions

Reported by: nickm Owned by:
Priority: Medium Milestone:
Component: Internal Services/Service - trac Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I think we need to separate accounts further into "user" and "developer", with basically everybody who works on a project getting called "developer".

In particular, I think that regular users shouldn't have the ability to close bugs, assign bugs, modify bugs, and so on; some of the

If it's at all possible, I'd like users to be able to edit and close bugs that they themselves opened, but not other bugs. I don't know if this is possible with Trac, but it might be neat to check it out.

This proposal should get discussed some and not just implemented on my say-so; If some dev disagrees with me, they should have a chance to object.

See this history of Bug 1656 as an example of why we might want to do this.

Child Tickets

Change History (9)

comment:1 Changed 9 years ago by Sebastian

I agree.

Additionally, it would be useful if one could edit (their own for users, everyone's for devs) comments and not only the original bugreports.

comment:2 Changed 9 years ago by nickm

It would also be neat if we could section off the wiki space to devs and non-devs. For instance, nobody outside of Tor should be modifying projects* or sponsors* .

comment:3 Changed 9 years ago by atagar

I like the split permissions idea but is Trac able to do this? Seems like a moot point until Erinn comments on what the options are (unless we're planning on forking Trac for this).

comment:4 Changed 9 years ago by nickm

"Go with default Trac" and "Fork trac" are not the only options; trac has a pretty robust plug-in system.

Heck, two of the sample plugins in the current trac distribution are there just to show you how to write new permissions sets. One of them is for defining new wiki permissions on a subset of wiki pages.

See also wiki:TracPermissions for an overview of the existing permissions system and http://trac-hacks.org/ and http://trac-hacks.org/tags/'permissions' for plugins that may or may not work.

comment:5 Changed 9 years ago by erinn

Current authenticated users have TICKET_CREATE and TICKET_MODIFY properties associated with them. The TICKET_MODIFY property is a superset of TICKET_APPEND and TICKET_CHGPROP, but has an additional property allowing the users to close bugs. My proposal for the tickets is that we remove the TICKET_MODIFY property from authenticated users and allow them to have TICKET_APPEND and TICKET_CHGPROP. TICKET_APPEND might be sufficient for most use cases, though. Since all developers are also Trac and wiki admins, this will not affect their ability to change things, even though they are also among the 'authenticated' users. Nick/Sebastian, what do you think of this? (If I'm not being clear, please look at the TracPermissions page that Nick linked.)

Sebastian, regarding the ability to edit one's own comments, that is in Trac 0.12, so we'll get it when we upgrade. (There's no package available for it yet, as far as I know.)

I'm looking into the wiki permissions now and will report back shortly.

comment:6 Changed 9 years ago by erinn

The wiki permission problem has a relatively simple answer for our current setup, where all devs are admins: mark a protected page readonly and then only other devs can modify it. Authenticated users will still be able to read it, but that's it.

If there's a need for private wiki pages rather than just non-modifiable-by-users wiki pages, the available plugins on that page seem more appropriate.

I've also removed the TICKET_MODIFY permission from 'authenticated' users and given them just the TICKET_APPEND permission for now. If people decide this is too restrictive, we can try something else.

comment:7 Changed 9 years ago by nickm

Hm. I'm okay with making the all the project/ pages read-only, but I worry that we'd miss some. I guess we can just try it and hope for the best.

I don't think we're currently planning on any kind of non-world-readable data any time in the near future, so we can hold off on that or now.

The TICKET_MODIFY vs TICKET_APPEND solution seems fine. I'd slightly prefer a situation where submitters could edit properties on their own tickets, but not so much that it's worth spending lots of effort on it. Let's say that the bikeshed is now pretty enough, and we don't need to repaint it until the neighbors complain. (IOW: seems good enough; let's revisit if there's trouble.)

Seems okay to close by me.

comment:8 Changed 9 years ago by erinn

Resolution: fixed
Status: newclosed

comment:9 Changed 4 years ago by qbi

Component: TracService - trac

Move all tickets from trac to "Service - trac" component.

Note: See TracTickets for help on using tickets.