Joshua, thank you for the feedback. Having "may be assigned to" and "may assign/re-assign" capabilities may give people the granularity they're looking for. It seems sensible to default developers/admins so that they possess both "may be assigned to" and "assign/re-assign" capabilities, but as it would be a separate capability, users can grant these permissions however they want.
My only reservation with "may be assigned to" is that it complicates matters a little. Interface wise, I originally had just a textbox in which a username could be typed, and if it didn't match anyone, nothing catastrophic would happen, and it could just be re-assigned. The "may be assigned to" capability introduces a subset of users, which would suggest having a drop down instead of a plain textbox. I'll have to play around with this to see what feels right. If anyone has further suggestions on the look/feel, or implementation, please let me know. -----Original Message----- From: "Joshua Paine" <[email protected]> Sent: Thursday, May 13, 2010 11:11am To: [email protected] Subject: Re: [fossil-users] ticket assignment On 05/12/2010 10:37 PM, zachtodd wrote: > Jeremy, a per project security attribute that allows all developers > to assign to each other is an interesting idea. That's not what's being asked for. In fossil there are a set of available capabilities. For each user, admin can check a box whether that user has a given capability. There are some convenient groupings of capabilities to make it easy to assign common sets to users, and admin can change what capabilities are contained in each grouping. So if there's a capability to be added that doesn't wholly belong to any existing capability, to be consistent with the rest of fossil it should be its own capability that can be assigned or not to any actual user or capability group. E.g., On some of my projects, the repos are private. I've disabled all public and anonymous access, and I've added those capabilities to Reader. Who are Readers for me? They're the several other stakeholders who work with the software I'm developing but aren't developers. I give them source reading access so they can see the timeline, and they can create tickets to document issues they find. I also create tickets for them sometimes when there's some related information gathering, etc.. that needs to be done. In my case, I would give ticket re-assign capability to Readers (them) as well as to Developers (me), since if I create a ticket for the wrong person or someone else has the free time first, I want them to be able to reassign tickets as needed. But this brings up the issue that apparently to use your new ticket assignment system--which lists developers only as possible assignees--I would have to make all my other users developers, even though they shouldn't have write access to the source. I think "may be assigned tickets" should be one capability belonging to developers by default, and "may reassign tickets" should be another capability belonging to admins or developers by default. In the small-team proprietary projects I've worked on and the larger open source ones I've observed, reassigning would have been a capability of any developer, limited by group expectations, but if you work with the existing capability system, who gets the capability is easily changed, so I have no strong opinion on whether reassign should be admins-only by default. -- Joshua Paine LetterBlock: Web applications built with joy http://letterblock.com/ 301-576-1920 _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
