What is RBAC?
RBAC stands for Role-Based Access Control. It's a system that determines what each user can see and do within Marketspread based on their assigned role.
Why It Matters
RBAC helps your organization by:
- Security - Users only access what they need, reducing risk of accidental changes
- Efficiency - Staff see relevant features without clutter from unused tools
- Compliance - Track who has access to sensitive data like finances
- Delegation - Safely give team members specific responsibilities
How It Works
The RBAC system has three key concepts:
| Concept | Description |
|---|---|
| Users | People who log into Marketspread |
| Roles | Collections of permissions (like 'Manager' or 'Accountant') |
| Permissions | Specific actions users can take (like 'view invoices') |
You assign a role to a user, and they receive all the permissions that role contains.
Understanding Roles
Marketspread provides four default roles designed for common organizational needs. You can also create custom roles for specific situations.
Administrator
Full access to everything. Administrators can manage all aspects of the organization including settings, user management, finances, and system configuration.
Best for:
- Organization owners and primary decision-makers
- IT staff responsible for system setup
- Users who need unrestricted access
Manager
Day-to-day operations access. Managers can handle most operational tasks like working with vendors, managing events, and processing invoices. They cannot change system settings or manage forms.
Best for:
- Market managers handling vendor relationships
- Team leads coordinating daily operations
- Staff who need broad operational access
What Managers can't do: Edit organization settings, manage custom forms, activate events, or edit layouts.
Accountant
Financial view-only access. Accountants can view all financial data including invoices, credits, payouts, and disputes. They cannot modify data, ensuring your financial records remain secure.
Best for:
- External bookkeepers and accountants
- Financial auditors
- Compliance officers reviewing transactions
Reporter
Reports-only access. Reporters can view and generate reports but cannot access other system features. This is the most limited default role.
Best for:
- Board members who need periodic reports
- Stakeholders who only need analytics
- Consultants reviewing performance data
Role Comparison
| Role | Access Level | Can Edit Data? | Primary Use |
|---|---|---|---|
| Administrator | Full Access | Yes - All | System owners |
| Manager | Most Features | Yes - Operations | Daily operations |
| Accountant | Financial Only | No - View Only | Finance review |
| Reporter | Reports Only | No - View Only | Analytics access |
Understanding Permissions
Permissions are the building blocks of roles. Each permission grants the ability to perform a specific action within Marketspread.
Permission Format
Permissions follow a consistent format: group.action
For example:
invoices.view- Can view invoicesvendors.edit- Can edit vendor informationvendor-applications.review- Can review vendor applications
Permission Hierarchy
Some permissions imply others. If you can edit something, you can usually also view it. The hierarchy typically follows:
| Level | Includes | Example |
|---|---|---|
| activate/publish | Edit | events.activate |
| edit/create | View | invoices.edit |
| release/review | View | invoices.release |
| view | Nothing else | invoices.view |
This means giving someone invoices.edit automatically lets them view invoices too - you don't need to add both permissions.
Permission Groups
Permissions are organized into functional groups. Here's what each group controls:
Financial Permissions
| Group | Controls |
|---|---|
| invoices | Invoice creation, viewing, editing, payments, refunds |
| credits | Credit balance viewing and adjustments |
| payouts | Vendor payout viewing and notifications |
| disputes | Payment dispute viewing and notifications |
| orders | E-commerce order management and payments |
Vendor Management Permissions
| Group | Controls |
|---|---|
| vendors | Vendor profile viewing, alias, tags, and documents |
| vendor-applications | Vendor application review and status changes |
| vendor-events | Placing vendors into events and editing tags |
| vendor-notes | Internal notes on vendors |
| vendor-forms | Custom forms shown to vendors |
Events & Scheduling Permissions
| Group | Controls |
|---|---|
| events | Market event/season creation and activation |
| event-days | Individual event day details and attendance |
| event-day-notes | Notes attached to specific event days |
| event-day-forms | Forms shown on event days |
| scheduler | Booth scheduling grid, bookings, and pricing |
| sales-reporting | Vendor sales report collection and fees |
Forms & Content Permissions
| Group | Controls |
|---|---|
| forms | Custom form creation and publishing |
| surveys | External survey campaigns |
| posts | Content and blog posts |
| products | Vendor product catalog |
| store | Online store management |
Reporting Permissions
| Group | Controls |
|---|---|
| data-reports | Interactive data grid reports (ag-Grid) |
| html-reports | Formatted printable HTML reports |
| dashboard | Dashboard widgets and views |
System & Administration Permissions
| Group | Controls |
|---|---|
| settings | Organization, market, and vendor settings |
| rbac | Role and permission management |
| messenger | Organization-wide messaging system |
| metrics | System metrics and analytics |
| notifications | Notification preferences and alerts |
| calendar | Calendar viewing and administration |
| customers | Customer information management |
Entity-Specific Permissions
| Group | Controls |
|---|---|
| applications | Application form setup and activation |
| layouts | Market/venue layout management |
| bookings | Venue booking management |
| members | Association member management |
| market-applications | Vendor's view of market applications |
Scoped Permissions
Scoped permissions let you limit access to specific items rather than granting full access to a category. This is powerful when you want someone to work with only certain vendors, events, or forms.
What Scoping Means
Instead of granting access to all items, you can limit access to specific ones:
| Full Access | Scoped Access |
|---|---|
| Can view ALL vendors | Can view only Vendor A and Vendor B |
| Can edit ALL events | Can edit only Summer Market events |
| Can manage ALL forms | Can manage only the Application Form |
| Can view ALL reports | Can view only specific saved reports |
Permission Groups That Support Scoping
The following permission groups can be scoped to specific items:
- vendors - Scope to specific vendors
- vendor-events - Scope to specific events/seasons
- vendor-applications - Scope to specific applications
- events - Scope to specific events/seasons
- event-days - Scope to specific events/seasons
- scheduler - Scope to specific events/seasons
- sales-reporting - Scope to specific events/seasons
- forms - Scope to specific forms
- data-reports - Scope to specific saved reports
- html-reports - Scope to specific saved reports
- applications - Scope to specific application forms
- layouts - Scope to specific layouts
- dashboard - Scope to specific dashboard views
When to Use Scoped Permissions
- Volunteer coordinators - Access only to specific event days they manage
- Vendor liaisons - Access only to vendors they're responsible for
- Seasonal staff - Limited to specific seasons or events
- External partners - Access to only their related data
- Department heads - Access to forms and reports for their area only
How to Apply Scopes
When editing a user's role permissions, look for the scope option next to permissions that support it. You can then select specific items instead of granting full access. If no scope is selected, the user gets access to all items in that category.
Tip: Start with scoped access and expand as needed. It's easier to grant additional access than to remember to restrict it later.
Common Scenarios
Here are solutions for common access control situations:
"I want to give someone full access"
Solution: Assign the Administrator role.
| Role | Administrator |
| Result | Full access to all features and settings |
"I need a read-only finance user"
Solution: Assign the Accountant role.
| Role | Accountant |
| Result | Can view all financial data, cannot modify anything |
| Permissions | invoices.view, credits.view, payouts.view, disputes.view, reports |
"I want someone to only manage applications"
Solution: Create a custom role with only application permissions.
| Role Name | Application Reviewer |
| Permissions | vendor-applications.view, vendor-applications.review, vendors.view, vendor-notes.view, vendor-notes.edit |
"I want a manager who can't access finances"
Solution: Create a custom role based on Manager, minus financial permissions.
| Base Role | Copy Manager permissions |
| Remove | invoices.*, credits.*, payouts.*, disputes.*, orders.* |
| Result | Full operational access without financial data |
"I want a volunteer to manage only the Saturday market"
Solution: Create a custom role with scoped permissions.
| Role Name | Saturday Market Volunteer |
| Permissions | event-days.view, event-days.attendance, vendor-events.view |
| Scope | Limit to 'Saturday Farmers Market' event only |
"I want someone to only run reports"
Solution: Assign the Reporter role.
| Role | Reporter |
| Result | Can view and run reports, no other access |
| Permissions | data-reports.view, html-reports.view |
How to Manage Roles
Adding a Team Member
Step 1: Access User Management
- Log in as an Administrator
- Go to Settings (gear icon in the sidebar)
- Select 'Team Members' or 'User Management'
Step 2: Add the User
- Click 'Add Team Member' or 'Invite User'
- Enter their email address
- They'll receive an invitation to create an account
Step 3: Assign a Role
- Choose a default role (Administrator, Manager, Accountant, Reporter)
- Or select 'Custom' to pick individual permissions
- If using scoped permissions, select the specific items they can access
Step 4: Save and Notify
- Click 'Save' or 'Send Invitation'
- The user's access is active immediately upon accepting the invitation
Modifying Existing Access
- Go to Settings → Team Members
- Find the user you want to modify
- Click on their name or the edit button
- Adjust their role or permissions
- Save changes - they take effect immediately
Removing Access
- Go to Settings → Team Members
- Find the user to remove
- Click 'Remove' or the trash icon
- Confirm the removal
Important: When a team member leaves your organization, remove their access immediately. They will no longer be able to log in or view any data.
Best Practices
Principle of Least Privilege
Give users only the permissions they need to do their job. This reduces risk and makes it easier to audit who has access to what.
- Start with the most restrictive role that allows them to work
- Add permissions as needed rather than removing them later
- Use scoped permissions when someone only needs access to specific items
Regular Access Reviews
Periodically review who has access to your organization:
- Quarterly review all team members and their roles
- Remove access for people who no longer need it
- Downgrade permissions for users who have more than they need
- Document why custom roles were created
Role Documentation
Keep track of custom roles and why they exist:
- Name custom roles descriptively (e.g., 'Saturday Volunteer' not 'Custom Role 1')
- Note who uses each custom role
- Review custom roles periodically to see if they're still needed
Security Tips
- Limit Administrators - Only organization owners should have full admin access
- Use Accountant for auditors - Read-only financial access prevents changes
- Separate duties - The person creating invoices shouldn't also approve payments
- Offboard promptly - Remove access the same day someone leaves
- Review after incidents - If something goes wrong, check if permissions contributed
Quick Reference
Default Roles Summary
| Role | Financial | Vendors | Events | Settings | Reports |
|---|---|---|---|---|---|
| Administrator | Full | Full | Full | Full | Full |
| Manager | Full | Full | View/Edit | View Only | Full |
| Accountant | View Only | None | None | None | View |
| Reporter | None | None | None | None | View |
Permission Actions
| Action | Meaning |
|---|---|
| view | Can see the data but not change it |
| edit | Can modify existing items (usually includes view) |
| release | Can release draft invoices for payment |
| review | Can review and change application status |
| place | Can assign vendors to events or applications |
| publish | Can publish forms to make them active |
| activate | Can activate events or applications |
| add-payment | Can record payments on invoices |
| refund | Can process refunds |
| notify | Receives email notifications for this area |
Permission Groups by Category
Financial:
invoices, credits, payouts, disputes, orders
Vendor Management:
vendors, vendor-applications, vendor-events, vendor-notes, vendor-forms
Events & Scheduling:
events, event-days, event-day-notes, event-day-forms, scheduler, sales-reporting
Content & Forms:
forms, surveys, posts, products, store
Reporting:
data-reports, html-reports, dashboard
System:
settings, rbac, messenger, metrics, notifications, calendar, customers