08:38 < neena> btw, I'm unable to change bug attributes on trac... http://codesurfers.net/~neena/trac.png
08:39 < atagar> I heard this from Sukhbir, evidently Mike changed something in response to some spam. We need to change it back.
08:39 < atagar> One sec, I'll open a ticket.
I've heard from both Ravi and Sukhbir that they can't change ticket statuses. We should revert whatever changed recently (... or make everyone who helps admins). This is getting in the way of them helping.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items ...
Show closed items
Linked items 0
Link issues together to show that they're related.
Learn more.
An alternative possibility is to add them to GRP_devel, which contains the relevant permissions without granting them site-wide admin privileges.
Great, I didn't know that was an option. I was just kidding about the admin privileges...
08:44 < neena> Trac should have support for groups, making everyone an admin sounds a little dangerous.
08:48 < atagar> Yea, that's something we certainly wouldn't be doing. ;)
08:49 < atagar> That would grant page deletion permission. Iirc we've had problems in the past because trac doesn't provide us with very granular permissions. People were simply admins or not-admins
08:50 < atagar> From what Sukhbir said Mike got upset because a user closed one of his tickets, so he revoked ticket status changing for all non-admins. That seems a tad bit overkill to me, but there might be more to the story.
08:51 < atagar> pity we don't have a mikeperry around
... the fewer people that can delete trac pages the better. One gotcha with the GRP_devel option is that it will mean more overhead for us and volunteers as new people try to join our community.
... the fewer people that can delete trac pages the better. One gotcha with the GRP_devel option is that it will mean more overhead for us and volunteers as new people try to join our community.
True, and it will be difficult to automate if community participation accelerates, but as long as normal users can comment, that's the most important privilege (especially for cypherpunk). As far as i can tell, there are only a handful (or two or three) of people who actually actively work on tickets and not being able to change from "new" -> "needs review" or "needs revision" -> "needs review" slows down the entire process and adds unnecessary confusion.
At this point, for the time-being, the only real option is to ask someone with permission in #tor-dev to adjust the status, so we're not losing anything by using groups - just adding a few more tickets to the list.
08:50 < atagar> From what Sukhbir said Mike got upset because a user closed one of his tickets, so he revoked ticket status changing for all non-admins. That seems a tad bit overkill to me, but there might be more to the story.
Hrrm.. I guess I misread the trac permissions help for TICKET_CHGPROP and TICKET_MODIFY. My goal was simply to make the keyword and priority field only available to developers, since normal users tend to fill them with junk and set crazy priorities. From my read of http://trac.edgewall.org/wiki/TracPermissions, it sounded like removing TICKET_CHGPROP permission would do exactly this.
I did not intend to prevent non-developers from changing other ticket state, but it does sort of seem like something you should be a 'developer' to do?
But yes, I did not change GRP_devel. Those users should still have the same permissions, and should be able to change all ticket fields as far as I can tell?