4. Control Who Can Do What
Right now your app has no rules — anyone who signs in can create events, delete records, or edit anything. That’s not how a real app should work.
In this tutorial, you’ll describe two types of users in plain English, and your AI will set up the permission rules automatically:
- Organizer — can create, edit, and delete events; can see all RSVPs
- Attendee — can browse events and manage only their own RSVPs
By the end you’ll have:
- Two roles set up in your backend
- Your pages automatically showing or hiding actions based on who’s signed in
- A way to test both roles in your browser
Time: About 15 minutes.
Prerequisites
- Completed 3. Build Your Pages
- Your events listing and admin pages are working
Describe Your User Roles
Say this to your AI:
Set up two roles in my app:
Organizer: Can create, read, update, and delete events. Can read all RSVPs for any event.
Attendee: Can read published events only. Can create RSVPs. Can read and update their own RSVPs. Cannot delete anything.
Your AI will create the role definitions and permission policies in your DaaS backend. It will also update your pages to respect these rules — hiding the “Delete” button from Attendees, for example, and blocking the admin area for non-Organizers.
When it finishes, it will tell you the roles are ready to assign to users.
Assign Roles to Test Users
Go to DaaS Studio → Users → find your account → click on your user record → set your Role to Organizer.
To test the Attendee experience, you’ll need a second account. Create one on your sign-in page, then come back to DaaS Studio and set that new user’s Role to Attendee.
If your AI asks “Should I restrict Attendees from accessing the /admin pages?” — answer Yes, redirect non-organizers to the events page with a “not authorised” message.
Test as an Organizer
Sign in with your Organizer account at http://localhost:3000. Check what you can do:
/admin/events— you should see the full management table with create, edit, and delete/events— you should see all events including drafts- Any event’s RSVP list — you should be able to see all registrations
Test as an Attendee
Sign out and sign in with your Attendee test account. Check what’s different:
/admin/events— you should be redirected away (not allowed)/events— you should only see published events, not drafts- RSVP form — you can still submit a registration
- Your own RSVPs — you can view and cancel your own, but not others’
If the permissions aren’t working as expected, describe the problem to your AI:
The attendee can still see the delete button on events. Please fix the permissions so only organizers see that button.
Lock Down the RSVP List
One more permission to add — attendees shouldn’t be able to see other people’s RSVPs:
Say this to your AI:
On the event detail page, Attendees should only see their own RSVP confirmation (not a list of all attendees). Organizers should see the full RSVP list with names and emails.
After this change, visiting an event as an Attendee will just show “You’re registered!” without exposing other people’s information.
What Just Happened?
Your AI set up Role-Based Access Control (RBAC) — a standard security pattern for apps with multiple types of users.
| What changed | How it works |
|---|---|
| Permission policies in DaaS | Define what each role can read/write on each collection |
| UI components updated | CollectionForm and CollectionList automatically hide or disable actions the current user doesn’t have permission to take |
| Route protection added | /admin/* pages redirect non-Organizers away |
The best part: your UI components read the permissions automatically. You didn’t need to add individual “if user is organizer” checks to every button — the components handled that.
Peek under the hood (optional)
Each role gets a permission policy per collection. For example, the Attendee role for rsvps might look like:
- Read: Only records where
attendee_email = $CURRENT_USER.email - Create: Allowed
- Update: Only own records
- Delete: Not allowed
These rules are enforced at the API level — not just in the UI. Even if someone tried to call the API directly, they’d get a “forbidden” response.
What’s Next
Your app is secure. In the next tutorial, you’ll add a home dashboard so you can see at a glance how many events and RSVPs you have.