Description of problem: Current policy is hard coded and applies to *everyone*. Group policy would put systems and users in Primary groups and those groups would be able to define their own policy. Things that would be determined by group policy: System Behaviour for this Group - Max watchdog reservation (for entire recipe) [One Day,Three days, Week, None] - Max systems in use by one user for this group [ 0 = unlimited ] - Systems can be provisioned Manually (X) by owner ( ) by Site Administrators ( ) by Group Admins ( ) by Anyone in group ( ) by Anyone - [ ] Allow loaning outside of Group - Systems can be loaned (X) by Owner ( ) by Site Administrators ( ) by Group Admins ( ) by Anyone in group ( ) by Anyone - Systems can be power cycled (X) by owner ( ) by Site Administrators ( ) by Group Admins ( ) by Anyone in group ( ) by Anyone Results Behaviour for this Group - Retention tag can only be changed (X) by Owner ( ) by Site Administrators ( ) by Group Admins ( ) by Anyone in group ( ) by Anyone - Ack/Nak Results (X) by Owner ( ) by Site Adminsitrators ( ) by Group Admins ( ) by Anyone in group ( ) by Anyone - Results are viewable only (X) by Owner ( ) by Site Administrators ( ) by Group Admins ( ) by Anyone in Group ( ) by Anyone This list will grow and change over time..
Password Policy [ ] Group Password [ ] Allow custom passwords
- Job/recipe can be cancelled by (X) by Owner ( ) by Site Adminsitrators ( ) by Group Admins ( ) by Anyone in group ( ) by Anyone
Bulk reassignment of issues as Bill has moved to another team.
While we do plan to do something along these lines in the 1.x series, the exact structure is going to be different. 1. As a starting point, user groups don't have fine-grained permissions enforced by Beaker. Instead, when an owner submits a job as a "group job" (by marking it as such in the XML), then the whole group gets full ownership privileges. Finer grained permissions can be handled by convention outside of Beaker, or by creating additional subgroups and making use of the system pool permissions planned for Beaker 1.1 2. Rather than having a preselected set of groups, the system pool permissions will each have a list of groups next to them, and systems will be able to be part of multiple pools. A user will be able to perform action <X> (e.g. loan, power cycle, manually provision, run recipes) on a system if they are a member of any group that has permission to do <X> on at least one pool that includes that system.
Related desgin proposals (work in progress) http://beaker-project.org/dev/proposals/enhanced-user-groups.html http://beaker-project.org/dev/proposals/system-pools.html http://beaker-project.org/dev/proposals/event-driven-scheduler.html http://beaker-project.org/dev/proposals/effective-job-priorities.html