[Epic] Add permission gating E2E tests

[aasimsyed]

Description

Currently, most edit/create/delete E2E tests run as an authenticated admin. Coverage is weak for how the UI behaves under real permission rules: who sees mutation controls depends on auth state and whether the viewer may manage that specific entity.

This epic extends permission-gating tests across entity types and editable sections.

Permission model (current product understanding)

1. Unauthenticated users must not see or trigger edit/create/delete controls for protected content.
2. Admins retain the expected broad access (positive controls where the product grants admin mutation rights).
3. Non-admin members may create, read, update, and delete their own entities (and related sub-resources, e.g. FAQs on an event they manage) when the backend grants them that scope — but they must not see or trigger those same mutation controls on entities owned or controlled by others (other users’ events, orgs/groups they don’t administer, etc.).

So E2E must distinguish member + own resource vs member + someone else’s resource, not treat “non-admin” as uniformly denied everywhere.

The existing gate test faq-keyboard-navigation-permissions.spec.ts covers FAQ drag-handle visibility and keyboard reordering for events only. This epic tracks extending the pattern across all entity types and sections.

This remains a high-priority quality gap: regressions that show mutation UI to the wrong user (or hide it from the right one) should be caught in CI.

Auth states

State	Role	Use in tests
Admin (default global state where applicable)	Platform/org-style admin	admin / admin — positive control where admins should see controls
Member	Authenticated non-admin	activist_0 / password (seeded by populate_db, confirmed, no org/event admin roles) — use on own vs other fixtures (see below)
Unauthenticated	None	storageState: { cookies: [], origins: [] }

Fixtures for “own” vs “other” (member)

• Member + own entity: navigate to an event/org/group (or FAQ/resource under it) that activist_0 is allowed to manage per seed data and API rules.
• Member + other’s entity: navigate to an event/org/group (or child content) that another user or admin owns; mutation controls must not appear for the member.

Concrete URLs/IDs should come from populate_db (or documented test data) so specs stay deterministic. Add or document fixtures if the seed set does not yet expose both cases.

Subtasks

• 0. Add member.json non-admin auth state to global-setup.ts — sign in as activist_0 / password and save session to test-e2e/.auth/member.json, following the same pattern as admin.json
• 1. Patch missing page object locators — add getFAQDeleteButton, getResourceDeleteButton, and group about edit icons (see page object changes below)
• 2. Event About page — permission gating (event-about-permissions.spec.ts)
• 3. Event FAQ page — permission gating (event-faq-permissions.spec.ts)
• 4. Event Resources page — permission gating (event-resources-permissions.spec.ts)
• 5. Organization About page — permission gating (organization-about-permissions.spec.ts)
• 6. Organization FAQ page — permission gating (organization-faq-permissions.spec.ts)
• 7. Organization Resources page — permission gating (organization-resources-permissions.spec.ts)
• 8. Organization Group About page — permission gating (organization-group-about-permissions.spec.ts)
• 9. Organization Group FAQ page — permission gating (organization-group-faq-permissions.spec.ts)
• 10. Organization Group Resources page — permission gating (organization-group-resources-permissions.spec.ts)

Tests per subtask

Each spec should cover four situations where the product differentiates access (adjust naming to match each page’s entities):

About pages (events, orgs, groups)

• Unauthenticated: edit icons and social add/edit/delete controls are not visible (or not usable as defined in UI).
• Member on other’s entity: same — mutation controls not visible.
• Member on own entity: edit / social / connect controls are visible where the member is permitted to manage that about content.
• Admin: controls visible where admins are expected to manage (positive control).

FAQ pages (events, orgs, groups)

• Unauthenticated: create / edit / delete FAQ controls not visible.
• Member on other’s entity: create / per-card edit / delete not visible.
• Member on own entity: create / edit / delete visible where API allows that member to manage FAQs for that parent.
• Admin: all relevant controls visible (positive control).

Resources pages (events, orgs, groups)

• Unauthenticated: add / edit / delete resource controls not visible.
• Member on other’s entity: add / edit / delete not visible.
• Member on own entity: add / edit / delete visible for resources they may manage.
• Admin: positive control as for admins.

If a given surface does not distinguish “own” vs “other” in seeds yet, land unauthenticated + admin first, then add member cases once fixtures exist.

Page object changes required

The following locators are missing and must be added before specs can be written (no new files, additions to existing page objects only):

• EventFAQPage.ts — add getFAQDeleteButton(index)
• OrganizationFAQPage.ts — add getFAQDeleteButton(index)
• EventResourcesPage.ts — add getResourceDeleteButton(index)
• OrganizationResourcesPage.ts — add getResourceDeleteButton(index)
• OrganizationGroupAboutPage.ts — add aboutCardEditIcon, getInvolvedCardEditIcon, connectCardEditIcon

Implementation order

1. Add member.json auth state to global-setup.ts
2. Confirm or add populate_db (or test constants) for member-manageable vs member-read-only URLs per entity type
3. Patch missing page object locators (above)
4. Write event specs (most complete page objects — establishes the pattern)
5. Write organization specs (copy-adapt from events)
6. Write organization group specs (note: uses tab navigation, not direct URL routing)

Contribution

No response

[andrewtavis]

Thanks for the epic, @aasimsyed! Makes total sense. We'll need to add some issues here once expand the roles in #1973 :)