@@ -20,6 +20,7 @@ There are a good number of reasons that could be made for doing audits, but the
### What is audited
- Customer Support Operations projects
- Zendesk Global
- Zendesk US Government
@@ -27,30 +28,43 @@ There are a good number of reasons that could be made for doing audits, but the
On the 1st day of each quarter, issues will be generated via the [System Audits](https://gitlab.com/gitlab-support-readiness/system-audits) project. After issue creation, audits are then performed.
## Customer Support Operations projects
This is done via the `bin/ops_project_audit` script. When the script runs, it does the following:
- Gathers a list of all projects within our group
- Gathers all protected branches within the found projects
- Gathers all merge request settings within the found projects
- Analyzes all projects for issues, including:
- Incorrect author approval settings
- Incorrect commit approval settings
- Incorrect approval override settings
- Incorrect approval retention settings
- Incorrect list of those who can merge
- Incorrect list of those who can push to the default branch
- Creates an issue detailing all findings
Those working the issue generated will review the issue for any problems and look into any issue present in the issue.
After rectifying any problems, the issue is then closed out.
## Zendesk Global audit
This is done via the `bin/zendesk_global` script. When the script runs, it does the following:
- Gathers Support team information from the Support Team YAML files
- Gathers a list of all agents in Zendesk (i.e. those with a role of `admin` or `agent`)
- Creates three lists of users:
- Light agents (those with a custom role ID of `360004984553`)
- Admins (those with a custom role ID of `360004957599`)
- Full agents (those not listed in the Light agents and Admins lists)
- Loops over the Support team information, checking:
- If they have a corresponding Zendesk user (as they should)
- If they are a light agent (as they should not be)
- If their Zendesk name matches the name for their Support team information (as it should)
- If their Zendesk email matches the name for their Support team information (as it should)
- If they incorrectly have the Zendesk administrator role (as this is closely controlled)
- Loops over all agents in Zendesk to check if any of them are suspended (as they should not be)
- Creates an issue, detailing the following
- List of all light agents
- List of all full agents
- List of all admins
- List of all failed checks
- List of all suspended agents
Those working the issue generated will review the issue for any problems and look into any failed checks that arose.
Those working the issue generated will review the issue for any problems and look into any issue present in the issue.
After rectifying any problems, the issue is then closed out.
@@ -58,23 +72,18 @@ After rectifying any problems, the issue is then closed out.
This is done via the `bin/zendesk_us_government` script. When the script runs, it does the following:
- Gathers Support team information from the Support Team YAML files
- Gathers a list of all agents in Zendesk (i.e. those with a role of `admin` or `agent`)
- Creates three lists of users:
- Light agents (those with a custom role ID of `360008074111`)
- Admins (those with a custom role ID of `360016820032`)
- Full agents (those not listed in the Light agents and Admins lists)
- Loops over the Support team information, checking:
- If their Zendesk name matches the name for their Support team information (as it should)
- If their Zendesk email matches the name for their Support team information (as it should)
- If they incorrectly have the Zendesk administrator role (as this is closely controlled)
- Loops over all agents in Zendesk to check if any of them are suspended (as they should not be)
- Creates an issue, detailing the following
- List of all light agents
- List of all full agents
- List of all admins
- List of all failed checks
- List of all suspended agents
Those working the issue generated will review the issue for any problems and look into any failed checks that arose.
Those working the issue generated will review the issue for any problems and look into any issue present in the issue.
After rectifying any problems, the issue is then closed out.
