Users and Access

beadops controls who sees what through program access, project access, role assignments, and group-based landing pages. Users are directed to the right entry point (e.g., program index, audit index, or subrecipient portal) based on their groups and permissions.

Landing Pages and Groups

After login, users are typically sent to a landing page that matches their primary role:

• Program index — Users who manage programs (e.g., “cms_primary” or internal staff) land on the program list and can open any program they have access to.
• Subrecipient (SR) landing — Users in the “sr” (subrecipient) group land on a page that lists their projects (or projects they have access to). They don’t see the full program list; they see only the projects they work on.
• Audit landing — Users in the “audit_primary” group land on the audit index so they can open audits they have access to.
• Dashboard (e.g., LC) — Users with a dashboard-only group (e.g., “lc_dashboard”) and no “internal” group may land on a limited dashboard view instead of the full program index.
• Password reset — Users in “require_new_password” are forced to change password before using the system.

These behaviors are configurable (e.g., via Django groups and view logic) so that different deployments can define different default landings.

Program Access

• ProgramAccess — Links a user to a program. Users with access can open that program and (subject to project access and roles) see its tabs, projects, payment requests, and settings.
• Program roles — Programs can define roles (e.g., Program Manager, Finance Reviewer). These roles can be assigned to users at the project level (ProjectRole) so that a user is the “Program Manager” for a given project.

Project Access

• ProjectAccess — Links a user (and optionally an applicant) to a project with an access type. This controls whether the user can view or edit that project, its payment requests, budget, and reports.
• Project roles — ProjectRole links a user to a project and a program role (e.g., “Project Manager” for this project). Used for display and for workflow assignments (e.g., “Notify the Project Manager when the request is submitted”).

Audit Access

• Audit user access — Each audit has its own list of users who can open that audit. Auditors do not need program or project access; they only need to be added to the audit.

Permissions and Visibility

• Tabs — Program and project tabs can be shown or hidden by configuration; some tabs may be restricted by role or access type.
• Fields — Custom fields (program header fields, line-item fields, payment request fields) can have permission or visibility rules so that certain roles see or edit only certain fields.
• Actions — Workflow actions (e.g., Approve, Return) are available only when the record is in the right step and the user is assigned (or has the right role) for that step.

Summary

Users and access in beadops are managed by:

• Groups — Drive landing page and high-level entry (program list vs. subrecipient list vs. audit list).
• Program and project access — Determine which programs and projects a user can open.
• Roles — Assign titles (e.g., Program Manager) to users at the project level and optionally drive workflow and visibility.
• Audit access — Separate list of users per audit for read-only audit access.

This keeps the experience appropriate for each user type: program staff see the full program list; subrecipients see only their projects; auditors see only their assigned audits.