-
Notifications
You must be signed in to change notification settings - Fork 53
User roles
This page explains the various user roles and how to modify them.
These are the way roles are described from a functional perspective. Non-technical folks, including support, use the following names and descriptions when talking about user roles.
- Global Admin (Global Scope)
- Authenticated account via Okta
- Also sometimes called support admin
- Access to support admin page and ability to use all tools on that page
- Can assume org admin permissions at any org using tenant data access feature
- Able to add/edit devices
- Update org ID verification flag for new orgs (done after verifying identity)
- User/patient/admin management
- Granted only to SimpleReport and support team members
- This role is not described in user-facing documentation or made visible on the app because it's not relevant to them
- Org Admin (Organization Scope)
- Authenticated account via Okta
- To SimpleReport users, this role is just called Admin
- Has all permissions of standard user with all facility access, plus any others listed here
- Can see the dashboard view
- Can update org information
- Can manage individual facilities, inc devices and ordering provider info
- Can manage users in that org
- Standard User (Facility Staff Member)
- Authenticated account via Okta
- Has all permissions of entry-only user, plus any others listed here
- Can view Results page and filter results by facilities they have access to
- Can manage results they can view (send to patient, print, correct)
- Can upload results via bulk upload tool
- Can add/edit patients
- Permission is granted on a facility basis, or user can be given all-facility access to be able to perform actions for patients in all facilities in the org
- Entry-only user (Facility Staff Member)
- Authenticated account via Okta
- Can see the Conduct tests page and test cards
- Can add test cards by searching for a patient on the Conduct tests page
- Permission is granted on a facility basis, or user can be given all-facility access to be able to perform actions for patients in all facilities in the org
- Patient - for accessing Patient Experience Pages (PXP)
- Does not have an account, authenticated by verifying DOB when accessed via a unique URL (and link is only sent to patient contact info on file)
- Not managed by org admins, granted to any patient who authenticates
- View-only of individual test result record for that person
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:
- [email protected]
- 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