Menu
▾
▴
phpbt-dev
|
From: Ulf E. <ulf...@fa...> - 2005-02-13 19:37:28
|
Hoi, I have implemented different permissions for users and developers when they are the reporter/owner of a bug and not. For instance, I allow comments from anyone who is logged in. Managers and project leaders may change almost everything at any time, users and developers only when they are reporter or owner of a bug. The severity is for the reporter only and the priority is for the owner only. (BTW, I have split your severity into report type and severity) Now, there is a huge number of requests for all sorts of permission levels in the trackers. My implementation is good enough for me, but the way the new rules are enforced wouldn't attract everyone. I would be willing to try make my implementation general enough to satisfy other peoples needs as well, *if* there can be some discussion on what people actually want and how this can be achieved. The current silence isn't very encouraging.. 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.. Here are some of the reports I have found that seem related. If you know more please post those links as well. It should be possible to find a solution general enough to be applied to all/most of these issues. Anyone willing to help find it? User Permission Levels http://sourceforge.net/tracker/index.php?func=detail&aid=829858&group_id=14939&atid=364939 Project Admin cannot change assignments http://sourceforge.net/tracker/index.php?func=detail&aid=1060247&group_id=14939&atid=114939 Managers Cannot Change Bug Details http://sourceforge.net/tracker/index.php?func=detail&aid=1017788&group_id=14939&atid=114939 Stricter editing ? http://sourceforge.net/tracker/index.php?func=detail&aid=618641&group_id=14939&atid=364939 Guest login http://sourceforge.net/tracker/index.php?func=detail&aid=579407&group_id=14939&atid=364939 Non-editable fields when not logged in http://sourceforge.net/tracker/index.php?func=detail&aid=579849&group_id=14939&atid=364939 New user can set another reporter for bug http://sourceforge.net/tracker/index.php?func=detail&aid=1034495&group_id=14939&atid=114939 How to restrain task assignment only to users at admin group http://sourceforge.net/tracker/index.php?func=detail&aid=782962&group_id=14939&atid=114939 |
|
From: Benjamin C. <php...@be...> - 2005-02-15 14:08:38
|
Ulf Erikson wrote: > Hoi, > > I have implemented different permissions for users and developers when > they are the reporter/owner of a bug and not. For instance, I allow > comments from anyone who is logged in. Managers and project leaders may > change almost everything at any time, users and developers only when > they are reporter or owner of a bug. The severity is for the reporter > only and the priority is for the owner only. (BTW, I have split your > severity into report type and severity) 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). 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, 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. :) > > Now, there is a huge number of requests for all sorts of permission > levels in the trackers. My implementation is good enough for me, but the > way the new rules are enforced wouldn't attract everyone. I would be > willing to try make my implementation general enough to satisfy other > peoples needs as well, *if* there can be some discussion on what people > actually want and how this can be achieved. The current silence isn't > very encouraging.. > > 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. > > Here are some of the reports I have found that seem related. If you know > more please post those links as well. It should be possible to find a > solution general enough to be applied to all/most of these issues. > Anyone willing to help find it? > > > User Permission Levels > http://sourceforge.net/tracker/index.php?func=detail&aid=829858&group_id=14939&atid=364939 > > > Project Admin cannot change assignments > http://sourceforge.net/tracker/index.php?func=detail&aid=1060247&group_id=14939&atid=114939 > > > Managers Cannot Change Bug Details > http://sourceforge.net/tracker/index.php?func=detail&aid=1017788&group_id=14939&atid=114939 > > > Stricter editing ? > http://sourceforge.net/tracker/index.php?func=detail&aid=618641&group_id=14939&atid=364939 > > > Guest login > http://sourceforge.net/tracker/index.php?func=detail&aid=579407&group_id=14939&atid=364939 > > > Non-editable fields when not logged in > http://sourceforge.net/tracker/index.php?func=detail&aid=579849&group_id=14939&atid=364939 > 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. > > New user can set another reporter for bug > http://sourceforge.net/tracker/index.php?func=detail&aid=1034495&group_id=14939&atid=114939 > 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 to restrain task assignment only to users at admin group > http://sourceforge.net/tracker/index.php?func=detail&aid=782962&group_id=14939&atid=114939 > > |
|
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 |
|
From: Ulf E. <ulf...@fa...> - 2005-02-20 18:47:19
|
* Benjamin Curtis [2005-02-15 15:06]: > 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). Hmm.. I must have missed this earlier. Do you mean that you would like to difference EditStatus in permission to close a bug or not? How about other enforcements on what Statuses and Resolutions one can chose depending on the current status? That would finally lead to something similar to the WorkFlow: http://sourceforge.net/tracker/index.php?func=detail&aid=648867&group_id=14939&atid=364939 There are also requests on keeping comments and/or whole bugs restricted to people with the right permissions: http://sourceforge.net/tracker/index.php?func=detail&aid=626884&group_id=14939&atid=364939 >> New user can set another reporter for bug >> http://sourceforge.net/tracker/index.php?func=detail&aid=1034495&group_id=14939&atid=114939 > > 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. Do you mind if I suggest more blockers? ;-) The earlier security issue should probably be revisited once more, and considering the speed of development it would probably be a very good idea to make sure that both php5 and MySQL 4.1 are possible platforms for phpBugTracker 1.0. -- Ulf |
|
From: Benjamin C. <php...@be...> - 2005-02-24 15:22:23
|
Ulf Erikson wrote: > * Benjamin Curtis [2005-02-15 15:06]: > >> 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). > > > Hmm.. I must have missed this earlier. Do you mean that you would like > to difference EditStatus in permission to close a bug or not? > > How about other enforcements on what Statuses and Resolutions one can > chose depending on the current status? That would finally lead to > something similar to the WorkFlow: > http://sourceforge.net/tracker/index.php?func=detail&aid=648867&group_id=14939&atid=364939 > > You know, I'm not sure that I realized the full meaning of what I was typing until your reply, but yeah, we certainly could do a permission per status. That would go quite a bit of the way towards workflow customization. > There are also requests on keeping comments and/or whole bugs restricted > to people with the right permissions: > http://sourceforge.net/tracker/index.php?func=detail&aid=626884&group_id=14939&atid=364939 > > >>> New user can set another reporter for bug >>> http://sourceforge.net/tracker/index.php?func=detail&aid=1034495&group_id=14939&atid=114939 >> >> >> >> 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. > > > Do you mind if I suggest more blockers? ;-) The earlier security issue > should probably be revisited once more, and considering the speed of > development it would probably be a very good idea to make sure that both > php5 and MySQL 4.1 are possible platforms for phpBugTracker 1.0. > Heh, sure, more blockers are always fun. Yes, the security issues need to be reviewed again, and I can vote for PHP5 support. I'm not sure about MySQL 4.1, though, as I had some problems with it combined with transaction support while trying to use adodb. Of course, I probably just didn't spend enough time on it to nail down the exact problem. :) |
|
From: Ulf E. <ulf...@fa...> - 2005-03-01 19:25:26
|
* Benjamin Curtis [2005-02-24 16:21]: > > Ulf Erikson wrote: > >>* Benjamin Curtis [2005-02-15 15:06]: >> >> >>>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). >> >> >>Hmm.. I must have missed this earlier. Do you mean that you would like >>to difference EditStatus in permission to close a bug or not? >> >>How about other enforcements on what Statuses and Resolutions one can >>chose depending on the current status? That would finally lead to >>something similar to the WorkFlow: >>http://sourceforge.net/tracker/index.php?func=detail&aid=648867&group_id=14939&atid=364939 >> >> > > > You know, I'm not sure that I realized the full meaning of what I was > typing until your reply, but yeah, we certainly could do a permission > per status. That would go quite a bit of the way towards workflow > customization. This quickly grows beyond what I have done.. any chance that you one day can help with sketching on what tables and fields to use and how it all ought to be connected? (i assume this will be hard to squeeze into the current structure, but maybe i am wrong) -- Ulf |
|
From: Ulf E. <ulf...@fa...> - 2005-03-01 19:25:40
|
* Benjamin Curtis [2005-02-24 16:21]: > > Ulf Erikson wrote: >>Do you mind if I suggest more blockers? ;-) The earlier security issue >>should probably be revisited once more, and considering the speed of >>development it would probably be a very good idea to make sure that both >>php5 and MySQL 4.1 are possible platforms for phpBugTracker 1.0. >> > > > Heh, sure, more blockers are always fun. Yes, the security issues need > to be reviewed again, and I can vote for PHP5 support. I'm not sure > about MySQL 4.1, though, as I had some problems with it combined with > transaction support while trying to use adodb. Of course, I probably > just didn't spend enough time on it to nail down the exact problem. :) This is the only issue I have had with PHP5: http://sourceforge.net/mailarchive/forum.php?thread_id=6535282&forum_id=4570 Basically get_class() no longer returns a string with only lowercase characters. Simply use DB::isError in your own code, and make sure to update PEAR to have a functional isError. (the one i tried used is_a(), but that function still couldn't handle it) If nothing else helps, how about renaming all "DB_Error" to "db_error" such that all old tests still work? What problems do you think phpBugTracker will have with MySQL 4.1? (and how is ADOdb related?) I assumed that using myqsli.php instead of mysql.php would take care of all API changes. The big bulk of old queries must still be valid. or.. ? -- Ulf |
|
From: Ulf E. <ulf...@fa...> - 2005-09-16 21:40:38
|
I'm planning to introduce a set of new permissions. There are currently only four permissions in phpBugTracker: Admin, Editbug, EditAssignment, Assignable. I wish to extend this such that it is possible to decide what fields users of the different groups may enter/change/delete as either the report, owner or neither. The discussion half a year ago http://sourceforge.net/mailarchive/message.php?msg_id=10850283 quikly grow into something real big and ambitious. I'll try to keep it a bit simpler this time. It will be configurable, but as extreme as suggested earlier.. I need your help to find a good balance. If you have ideas for a new permission system please let me know. Any editable fields that you wish to control who may edit? Reporter, Owner, Priority, Description, Target version, Status, Closing the bug, or anything else that you need to control? -- Ulf |
|
From: Ulf E. <ulf...@fa...> - 2005-10-13 09:45:42
|
* Ulf Erikson [2005-09-16, 23:40:10 +0200]: > I'm planning to introduce a set of new permissions. There are currently > only four permissions in phpBugTracker: Admin, Editbug, EditAssignment, > Assignable. I wish to extend this such that it is possible to decide > what fields users of the different groups may enter/change/delete as > either the report, owner or neither. I plan to add: AddBug, EditProject, EditComponent, EditStatus, CloseBug, EditResolution, EditPriority, EditSeverity, and AddComment. > The discussion half a year ago > http://sourceforge.net/mailarchive/message.php?msg_id=10850283 > quikly grow into something real big and ambitious. I'll try to keep it a > bit simpler this time. It will be configurable, but [NOT] as extreme as > suggested earlier.. I need your help to find a good balance. As discussed with Benjamin I plan to introduce roles as a complement to the current groups. I'm thinking of: AnonymousGuest, AuthenticatedUser, BugReporter, BugAssignee, ComponentOwner, ProjectAdmin, and BugTrackerAdmin. (The last two will not be configurable) Having a role can only give you more permissions. (logical OR with your current permissions) I think some hierarchie can be good here: A user should also be a guest, and a reporter or assignee should also be a user (and thus also a guest). Comments? -- Ulf |
|
From: Benjamin C. <php...@be...> - 2005-10-13 13:41:22
|
Looks good. :) On Oct 13, 2005, at 2:45 AM, Ulf Erikson wrote: > * Ulf Erikson [2005-09-16, 23:40:10 +0200]: > >> I'm planning to introduce a set of new permissions. There are >> currently >> only four permissions in phpBugTracker: Admin, Editbug, >> EditAssignment, >> Assignable. I wish to extend this such that it is possible to decide >> what fields users of the different groups may enter/change/delete as >> either the report, owner or neither. >> > > I plan to add: AddBug, EditProject, EditComponent, EditStatus, > CloseBug, > EditResolution, EditPriority, EditSeverity, and AddComment. > > >> The discussion half a year ago >> http://sourceforge.net/mailarchive/message.php?msg_id=10850283 >> quikly grow into something real big and ambitious. I'll try to >> keep it a >> bit simpler this time. It will be configurable, but [NOT] as >> extreme as >> suggested earlier.. I need your help to find a good balance. >> > > As discussed with Benjamin I plan to introduce roles as a > complement to > the current groups. I'm thinking of: AnonymousGuest, > AuthenticatedUser, > BugReporter, BugAssignee, ComponentOwner, ProjectAdmin, and > BugTrackerAdmin. (The last two will not be configurable) > > Having a role can only give you more permissions. (logical OR with > your > current permissions) > > I think some hierarchie can be good here: A user should also be a > guest, > and a reporter or assignee should also be a user (and thus also a > guest). > > Comments? > > -- > Ulf > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Power Architecture Resource Center: Free content, downloads, > discussions, > and more. http://solutions.newsforge.com/ibmarch.tmpl > _______________________________________________ > phpbt-dev mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phpbt-dev > |
|
From: Ulf E. <ulf...@fa...> - 2005-10-13 19:42:32
Attachments:
patch-HEAD.uen.roles.1.txt
|
Benjamin Curtis wrote: > Looks good. :) Thanks:) Here is a first draft of my patch. It's very very untested still.. that's why I am sending a patch instead of committing it all to CVS (that and that i am missing pgsql/oci8 support and an upgrade script). Please try it anyway. Pull a new version from CVS and apply this patch. Don't try to upgrade! Just play with some new projects, bugs and users. I'd like to get some feedback on this such that it can be finished on time for 1.1.. I will not have time to look at it for next week myself > On Oct 13, 2005, at 2:45 AM, Ulf Erikson wrote: >> * Ulf Erikson [2005-09-16, 23:40:10 +0200]: >> >>> I'm planning to introduce a set of new permissions. There are currently >>> only four permissions in phpBugTracker: Admin, Editbug, EditAssignment, >>> Assignable. I wish to extend this such that it is possible to decide >>> what fields users of the different groups may enter/change/delete as >>> either the report, owner or neither. >> >> I plan to add: AddBug, EditProject, EditComponent, EditStatus, CloseBug, >> EditResolution, EditPriority, EditSeverity, and AddComment. >> >>> The discussion half a year ago >>> http://sourceforge.net/mailarchive/message.php?msg_id=10850283 >>> quikly grow into something real big and ambitious. I'll try to keep >>> it a >>> bit simpler this time. It will be configurable, but [NOT] as extreme as >>> suggested earlier.. I need your help to find a good balance. >> >> As discussed with Benjamin I plan to introduce roles as a complement to >> the current groups. I'm thinking of: AnonymousGuest, AuthenticatedUser, >> BugReporter, BugAssignee, ComponentOwner, ProjectAdmin, and >> BugTrackerAdmin. (The last two will not be configurable) >> >> Having a role can only give you more permissions. (logical OR with your >> current permissions) >> >> I think some hierarchie can be good here: A user should also be a guest, >> and a reporter or assignee should also be a user (and thus also a >> guest). >> >> Comments? |
