|
From: Ulf E. <ulf...@fa...> - 2005-02-17 22:27:08
|
* Benjamin Curtis [2005-02-15 15:06]: > Ulf Erikson wrote: >> I have implemented different permissions for users and developers when >> they are the reporter/owner of a bug and not. For instance, ... > This works for me, except the priority part. Very often a reporter > might want to change the priority of a bug (in organizations where the > developer doesn't have as much determination about which bugs get > addressed first). True. I doubt there is a single set of rules that will satisfy everyone. That's why editable permission would be a nice inclusion ;-) > Perhaps we could have a list of permissions assigned > to roles (in addition to -- or maybe in replacement of -- groups). That > way you could have a reporter role, and an owner role, and a > "third-party" role, and each of these could be assigned particular > permissions (like EditAssignemt, EditPriority, etc.) as desired. So, I would prefer "in addition to" and not "in replacement of" the current group permission scheme. The third-party permissions should be more strict for users than for project leaders, for instance. (or it should at least be possible to set them so) > basically, users could change roles per bug, but they could have a > different set of permissions by virtue of their group memberships on a > more general basis (users in the QA group would always have CloseBug > permission, regardless of reporter/owner/witness role). We'd have to > decide how to handle conflicts between group permissions and role > permissions. :) How about this thought: Your current group permissions determine what you may or not may as a third-part. Being the reporter or bug-owner you can only be granted more rights. A few extra bits might be needed to specify the roles.. There is also the TBL_USER_PERM. It's not used at all? Have about adding an add/remove bit and let that table add or remove a single permission to a single user regardless of role? (now we are probably down to too low-level fine tuning) >> What kind of user levels would you like to have? By what granularity? >> How would you like to be able to configure this (I'm thinking of my >> earlier group permission editor, but that wouldn't scale too well with >> an increasing number of permission flags..)? The more ideas the >> better. The more detailed descriptions on how to operate this the more >> likely that it might happen.. > > I haven't had a chance to apply your permission editor patch, so I don't > know what the UI is, but I could see a page with each Role or Group > listed, beneath each being a grid of checkboxes with the permission > names as labels. Yes. That's what I thought of as non-scalable. But maybe the number of roles and fields low enough to not be a problem.. Talking about granularity in permission you have also reports in the tracker that talk about disallow users to change the password of guest accounts, or to even visit the personal page. And how about an Anonymous user to tell the permission for not logged-in visitors? >> Here are some of the reports I have found that seem related. >> Non-editable fields when not logged in > > The "Non-editable fields" one is fixed with JavaScript warning a user > about not making changes when not logged in. I don't know that this one > is very permission related. Oops. Sorry. I didn't mean to include closed bugs. What I do, and hope to convince you to, is use real non-editable fields. Like what you do for the EditAssignment. That's why I added some extra parameters for 'lookup'. ;-) A similar idea is to give extra fields such as assigned-to, to people with the right permissions (EditAssignment), already when the bug is reported. Let the forms be a bit dynamic met the role. >> New user can set another reporter for bug > > This set another reporter bug is one that I'd really like to fix before > 1.0, but I haven't put enough thought yet into what is the best approach. How about an "EditReporter" bit that only project managers have set? -- Ulf |