Flexible Access Control in RSVP System: How Role Types Work

When you manage a platform used by a town government, a university housing office, and a neighborhood association — sometimes all at once — access control becomes a surprisingly hard problem. Who can post an announcement? Who can approve a room reservation? Who can manage the Library's calendar but not the Town Clerk's?

RSVP System solves this with a two-dimensional role design called Role Types. It is simple enough to explain in a meeting, powerful enough to handle complex real-world organizations, and composable enough to grow as your community's needs grow.

Two Dimensions, Not One

Most platforms give you a flat list of roles: Admin, Editor, Viewer. That works fine for small teams, but it breaks down the moment you have multiple departments, buildings, or communities that share the same platform — each with their own staff and their own content.

RSVP System uses two distinct dimensions of role:

Dimension 1: Position Roles

A Position Role represents what a person is in the organization and what kinds of operations they are permitted to perform. These are standard Drupal roles with readable, descriptive names:

admin — full site and platform access
tech_support — platform maintenance, no content management
marketing — can manage content across any community
senior_director, director — leadership with content approval authority
coordinator — day-to-day community content management and moderation
librarian, town_clerk, select_board — role-specific access for common municipal and library positions
student_staff, student_manager — tiered access for university housing staff

These roles say nothing about which community a person manages. That is the job of the second dimension.

Dimension 2: Community Roles

A Community Role connects a user to a specific community — a library branch, a residence hall, a town department, a neighborhood. One Drupal role is created for each community term in the platform, using a consistent naming convention: the community_ prefix followed by the community's machine name.

Examples: community_library, community_town_office, community_elm_hall, community_whitingham.

A user can hold multiple Community Roles — a staff member who works across three residence halls gets all three.

Access Control as an Intersection

Here is where the design pays off. Access control in RSVP System is determined by the combination of a user's Position Role and their Community Role, not by either one alone.

Think of it as a grid: Position Roles run along one axis, Community Roles along the other. A user's permissions are defined by where they sit on that grid.

Some examples:

Position Role	Community Role	Result
`coordinator`	`community_library`	Can manage Library content and moderate submissions
`marketing`	`community_library`	Can manage Library content (marketing manages any community)
`senior_director`	`community_library`	Acts as Community Manager for the Library
(none)	`community_library`	Library member — can view content, reserve resources per rules
`coordinator`	(none)	Has coordinator permissions but no community context — limited utility

The important insight: Community Manager is not a separate role. It is a derived status — what you get when a management-level Position Role and a Community Role combine. This keeps the role count manageable as the platform grows.

Real-World Examples

Town Government

A town has a Select Board, a Town Clerk's office, and a Library — each a separate community on the platform. The Town Clerk holds town_clerk + community_town_office, which allows managing town office announcements and documents. A Select Board member holds select_board + community_whitingham. The Library Director holds senior_director + community_library, making them the Community Manager for library content. An admin manages the whole platform and sees everything.

No role explosion. Each staff member holds exactly two roles: what they are, and where they work.

University Housing

A large residence hall system has ten buildings. Student staff are hired each semester and assigned to specific halls. A returning student manager might cover two halls. In RSVP System, they get student_staff or student_manager as their Position Role, and one or more community_elm_hall-style roles for the halls they cover. When they move buildings, their Community Role changes — no form redesign needed.

Neighborhood Association

A neighborhood association uses the platform for a community room reservation calendar and a shared announcements board. Most members hold only a Community Role for their neighborhood — they can view the calendar and submit reservation requests. A volunteer coordinator holds coordinator + community_neighborhood, which lets them approve reservations and post announcements on behalf of the association.

Primary Community: Low-Friction Defaults for Multi-Community Users

Staff who work across multiple communities — a coordinator covering three residence halls, a marketing director active in every department — hold multiple Community Roles. That flexibility is by design. But it raises a practical UX question: when someone creates a new announcement or posts an event, which community should appear as the default?

RSVP System addresses this with the Primary Community field on every user profile. An account can belong to as many communities as needed, but one is designated primary. The platform uses this field to pre-fill community pickers on content forms, set default dashboard views, and reduce the number of decisions an editor has to make on every content creation task.

The result: a staff member who primarily works in the Library but occasionally covers the Recreation Center opens a new announcement form and sees the Library pre-selected — ready to post with no extra clicks. Changing the selection is always possible, but the default is almost always right.

Primary Community is set by administrators at account setup and can be updated as roles change. For SSO deployments, it can be derived automatically from the user's primary Grouper group.

Resource Reservations: Fine-Grained Gating

Community Roles also gate specific resource reservations. A library conference room can be configured to require coordinator + community_library to book — staff-only. But the reservation calendar is visible to everyone in the community. Members can see when the room is available without being able to book it directly.

If no position requirement is set on a resource, any community member can reserve it.

Enterprise SSO and Grouper Integration

For university and institutional deployments that use a central identity provider, RSVP System integrates with SimpleSAML PHP. Both Role Types are provisioned automatically at login from Grouper groups.

Compliance and IT teams appreciate this: users live in Grouper, not in Drupal. Grouper group membership drives platform access with no manual synchronization step. When a student's housing assignment changes, their access updates at next login — automatically.

For deployments without SSO, administrators assign both role types manually after account creation.

The Bottom Line

The Role Types system is designed for organizations that are real — ones that have multiple departments, buildings, or programs all sharing a platform, where staff rotate, where some people work across several communities, and where access needs to be auditable without becoming a maintenance burden.

Two roles per person. One that says what they are. One that says where they work. Everything else follows from the intersection.