-
Notifications
You must be signed in to change notification settings - Fork 54
User roles
This page explains the various user roles and how to modify them
The available user role types are ADMIN
, USER
, ENTRY_ONLY
, ALL_FACILITIES
, TEST_RESULT_UPLOAD_USER
and NO_ACCESS
. You can check backend/src/main/java/gov/cdc/usds/simplereport/config/authorization/OrganizationRole.java
for a list of available roles
-
ADMIN
- an organization admin with full access to their organization -
USER
- a site user the has access to everything in their organization but the gear icon -
ENTRY_ONLY
- a site user that only has access to the Conduct Test tab -
ALL_FACILITIES
- a site user that can access all facilities in their organization -
NO_ACCESS
- a member of an organization who has no permissions without possessing other roles. Every member of an org has this role, so it is used to list all users in an organization -
TEST_RESULT_UPLOAD_USER
- a member of the CSV Uploader pilot program, active as of 8/23/22. See more information about this role here
These roles are controlled via Okta groups (in deployed environments and if you are running the app locally with Okta) or through the application-local.yaml
file (if you are running the app locally without Okta)
When running the app locally without Okta, by default the local test user is an organization admin role. If you need to change this value to test out other permissions, it can be set in application-local.yaml.
If you have not created one run:
touch backend/src/main/resources/application-local.yaml
Organization roles can be set by adding the following to application-local.yaml:
simple-report:
demo-users:
default-user:
authorization:
granted-roles: ADMIN
Support admins can access the /admin
paths and support admin APIs.
You can make your user a support admin by assigning yourself the SR-DEV-ADMINS
group in Okta Preview.
You can make the default user a site admin by adding the following to application-local.yaml
:
simple-report:
demo-users:
site-admin-emails:
- bob@example.com
- Getting Started
- [Setup] Docker and docker compose development
- [Setup] IntelliJ run configurations
- [Setup] Running DB outside of Docker (optional)
- [Setup] Running nginx locally (optional)
- [Setup] Running outside of docker
- Accessing and testing weird parts of the app on local dev
- Accessing patient experience in local dev
- API Testing with Insomnia
- Cypress
- How to run e2e locally for development
- E2E tests
- Database maintenance
- MailHog
- Running tests
- SendGrid
- Setting up okta
- Sonar
- Storybook and Chromatic
- Twilio
- User roles
- Wiremock
- CSV Uploader
- Log local DB queries
- Code review and PR conventions
- SimpleReport Style Guide
- How to Review and Test Pull Requests for Dependabot
- How to Review and Test Pull Requests with Terraform Changes
- SimpleReport Deployment Process
- Adding a Developer
- Removing a developer
- Non-deterministic test tracker
- Alert Response - When You Know What is Wrong
- What to Do When You Have No Idea What is Wrong
- Main Branch Status
- Maintenance Mode
- Swapping Slots
- Monitoring
- Container Debugging
- Debugging the ReportStream Uploader
- Renew Azure Service Principal Credentials
- Releasing Changelog Locks
- Muting Alerts
- Architectural Decision Records
- Backend Stack Overview
- Frontend Overview
- Cloud Architecture
- Cloud Environments
- Database ERD
- External IDs
- GraphQL Flow
- Hibernate Lazy fetching and nested models
- Identity Verification (Experian)
- Spring Profile Management
- SR Result bulk uploader device validation logic
- Test Metadata and how we store it
- TestOrder vs TestEvent
- ReportStream Integration
- Feature Flag Setup
- FHIR Resources
- FHIR Conversions
- Okta E2E Integration
- Deploy Application Action
- Slack notifications for support escalations
- Creating a New Environment Within a Resource Group
- How to Add and Use Environment Variables in Azure
- Web Application Firewall (WAF) Troubleshooting and Maintenance
- How to Review and Test Pull Requests with Terraform Changes