5.7.240. Bugzilla::Extension::Workflows::GroupApproval¶
5.7.240.1. NAME¶
Bugzilla::Extension::Workflows::GroupApproval
5.7.240.2. DESCRIPTION¶
This workflow uses bugs and flags to control group membership requests. Two forms are provided, one for admins to configure the groups being managed, and one for users to initiate the workflow. The process revolves around standard bug process, with the requestees either acking or nacking flags, and the extension processing updates and closing the bugs when all flags are acked or nacked.
Security is paramount for this process. A new product is created specifically for this workflow. Only the system account is able to create bugs in this product; users use the form to trigger bug creation. Users only have access to bugs that they are directly involved in. There are minimal changes required for this, it is mostly configuring the product and flags properly, then manipulating the CC & groups when creating bugs.
This Workflow intercepts Group changes made in the Admin UI or RPC interfaces, and redirects them through this workflow if the groups requested are being managed.
All groups in the Red Hat, Partner, and Admin categories must be managed and no one will be able to grant membership to such groups until they are configured properly.
Request Creation Page¶
This page, accessible via the “My Links”->”Request Group Membership” menu, consists of a form the user fills out to start the workflow.
The form has these fields:
- Groups:
- For each Group classification with managed groups there is a multi-select field for the user to select groups they wish to become a member of.
These fields show groups the user qualifies for based on the rules specified on the admin page.
The user will never see groups they cannot apply for, which includes groups they are already members of, including inherited groups.
If a user cannot see a group they wish to become a member of then they will need to contact the site administrators to see why they do not qualify. See the “Help”->”Contacts” menu for contact details.
- Rationale:
- A text field for the user to enter why they wish membership of these groups.
- Submit:
- A button to submit the form.
This form can be pre-populated by adding &groups=foo to the URL, this can be set multiple times if multiple groups are required.
Request creation workflow¶
Once the user submits the form the request workflow it triggered.
- Request is validated
- A bug is created
- The user is added as a CC to the bug
- For each group requested
- If the group has an approval group
- the approval group is added to the bug
- the approvals_request flag for the group is set to “?”
- else
- the user’s manager is looked up in LDAP
- the user’s manager is added as a CC on the bug
- the approvals_request flag for the group is set to “?” targeted at the user’s manager
- The bug is submitted
- Email is sent to all related parties
Approver workflow¶
Once the approver submits a bug update the extension processes the bug changes. This happens after the normal bug update process, so most invalid flag changes will have prevented the update from getting this far.
The extension performs a secondary check to ensure all rules are met my both requester and approver.
Approvers can track their outstanding requests on the “My Links”->”My Requests” menu.
- For each flag modified
- If the flag was ACK’d
The Requester is added to the requested group
- if the flag was NAK’d
The Requester is removed from the group
- else
No changes are made.
- Adds a comment to the bug to record the changes it made.
- If all flags have been completed, closes the bug
Admin Configuration Page¶
This page consists of several tabs, one for each group category, group settings are edited inline. There are several tabs to simplify the user experience.
Documentation for the API can be found at Bugzilla::Extension::Workflows::WebService::GroupRequest
The tables have the following columns.
- name:
- The name of the group.
- managed:
- Are we exposing this group in the approvals system? Users will not see this group in the self service form if this is not enabled.
- invite only:
- Is membership in this group invite only? If so only users in the approval group can nominate users for membership. Users will not see this group in the self service form.
- login regex:
- A regex to limit who can join this group. This can be a broader regex than the auto approve set on the group. If a group is not invite only then this field is also used to restrict who can see this group on the self service form.
- Approval Group:
- The group that can ack requests for this flag. If not set then the user’s manager will be looked up in LDAP and asked to approve. The manager must have a Bugzilla account for this to be possible. Groups for non Red Hat accounts must always have an approval group set to be actionable. This is a drop down and is synced to the grant_group on the flag.
- CCs:
- A comma-separated list of email addresses to CC when this flag is requested. This sets the “CC List” on the flag.
- Flag:
- The name of the flag tracking requests for this group.
- Actions:
- Icons for:
- Saving changes
- a link to the group admin page
- a link to the flag admin page
- a link to a search for pending requests for this group
Each group that is managed will has it’s own flag “approvals_request_<group_name>” this flag will have it’s grant_group set to the approval_group if it is set
For manager approved groups the flags is “specifically requestable”. For group approved groups the flags is not “specifically requestable” and is locked to the grant_group.
If the flag for the group does not exist it is created when the changes are saved.
Product Setup¶
To properly secure the process is set-up in the following way:
- A group “approval_admin” is created, used for bugs ON, secure_mail ON
- A classification “Workflows” is created, sortkey 300
- A new product “Group Membership” is created
- A new component “Self service” is created
- The product has its access control set to
approval_admin “Mandatory/Mandatory, ENTRY, editcomponents, editbugs”
- The product has “Bugs must always be private” ON
Admin Workflow¶
When an admin modifies a group on the admin page the request is handled as follows.
- If the manage check box is enabled
- If the group flag does not exist, create it with the following values
Name: "approvals_request_<group_name>" Description: "Approval flag for the <group_name> group." Inclusion: "Group Membership":__Any__ Sort Key: 9001 Active: True Requestable: True CC List: As supplied specifically requestable: False if no regex, else True multiplicable: False View Group: None Request Group: approval_admin Grant Group: "Approval Group" if set Flag Type Category: unset, possibly a new type if it helps the UI experience.
- If the group flag is not requestable, make it requestable
- If the manage check box is disabled
- If the group flag is requestable, set requestable to False
- If the approval group is set, ensure the group flag is not “specifically requestable”
- If the approval group is not set, ensure the group flag is “specifically requestable”
- Set the CC List field on the group flag
- Ensure the group flag grant group is “Approval Group” if set
- If the “Approval Group” is set, ensure the group is “Shown/Shown” on the product access controls
Partner group restriction change¶
Previously if a Partner group had a regex set for auto group membership then Red Hat Bugzilla would limit group membership to users matching that regex.
Now, if a group workflow has a regex set then this new regex will override the auto membership regex when validating a user’s membership in that Partner group.
