Google Drive RBAC

Last updated: May 19, 2026

Google Drive RBAC

Wevion enforces two layers of RBAC for Creative Hub files: 1) Wevion in-app visibility via creative-hub.helpers.ts getVisibleSessionIds() (super_admin / owner see all; others see own + explicitly shared), and 2) Google Drive permissions for external sharing via the Drive permissions API (role='writer', type='user'). Both layers active simultaneously and serve different purposes.

Who is this for

Admins designing team folder structures. Owners auditing who has access to what. Anyone confused about why a teammate can see a file in Wevion but not open it in Drive (or vice versa).

The two layers

Layer 1: Wevion in-app RBAC

Implemented in apps/backend/src/services/creative-hub/creative-hub.helpers.ts:

  • getVisibleSessionIds(userId, teamId) — returns list of session IDs whose Creative Hub the current user can access

  • buildAllowedFolderIds(visibleSessionIds) — resolves to Drive folder IDs

  • File list / folder list endpoints filter by these allowed IDs

Role

Visibility within Wevion

super_admin

All sessions' folders + files

owner

All sessions' folders + files

admin

Own + folders explicitly shared with admin

manager

Own + explicit shares

mediabuyer

Own + explicit shares

finance

No Creative Hub access by default

viewer

Read-only on explicit shares

canViewTeam (super_admin / owner only) unlocks the Members switcher in the UI.

Layer 2: Google Drive permissions

Implemented via the Drive permissions API, called by creative-hub-sharing.route.ts:

  • role: 'writer' (read + edit) or 'reader' (read only)

  • type: 'user' (specific email), 'group' (Google Group), or 'anyone' (link-based)

  • Wevion currently uses role='writer' + type='user' by default

This layer controls who can open the file directly in Drive (outside Wevion UI). Wevion's Service Account is always the owner; everyone else's access is via these explicit shares.

How the two layers interact

Scenario

Wevion access

Drive access

You uploaded the file

✅ (own session)

Only via app (Service Account owns; not auto-shared with you in Drive)

Super_admin viewing teammate's file

✅ (canViewTeam)

❌ (not shared with their Drive)

Shared via ch-105 externally

Depends on Wevion role

✅ (Drive share writes via API)

Teammate in same workspace, no explicit share

❌ (Wevion blocks)

❌ (no Drive permission either)

The two layers are independent:

  • Wevion visibility ≠ Drive access

  • Sharing in Drive ≠ adding to Wevion view (Wevion still gates view)

Why two layers?

  • Wevion RBAC controls what teammates see inside Wevion — fast in-app gating without round-tripping to Drive

  • Drive permissions control external collaborators — gives non-Wevion users a way to access files without an account

Trying to merge them would either:

  • Force Drive-level enforcement for all Wevion views (slow + auth round-trip per render)

  • Force all sharing through Wevion (impossible for external non-Wevion users)

The two-layer model accepts the trade-off: a bit of mental overhead for admins, but clean separation of concerns.

Audit considerations

Audit log records actions on both layers:

Layer 1 actions

Layer 2 actions

creative_view, creative_team_folder_view

creative_share, creative_unshare

creative_upload, creative_delete

creative_drive_permission_change

Query /api/v1/audit-logs?resource_type=creative_* to see both layers' history.

Common scenarios

Scenario A: Teammate can't see a file you uploaded

  • They have mediabuyer role + no explicit share

  • Wevion RBAC blocks → expected behavior

  • Fix: add to shared team folder OR use ch-105 with their email (note: ch-105 goes to Drive, not in-app — for in-app visibility, use team folder workflow)

Scenario B: External user can't open Drive link

  • You shared via Wevion's UI (Wevion record exists)

  • But the underlying Drive permission API call may have failed

  • Fix: re-share via ch-105; check /api/v1/audit-logs?action=creative_share for status

Scenario C: Super_admin sees teammate folder but can't open file in Drive

  • Wevion canViewTeam allows in-app view

  • But Drive permission was never granted to super_admin's personal Drive

  • Fix: this is expected — Wevion fetches via Service Account on your behalf; if you need to open directly in Drive, ask the file owner to share with your Drive email via ch-105

Best practices

Treat Wevion + Drive layers separately

When sharing: ask "do I want this person to see it in Wevion, or in Drive, or both?". Answer drives whether you use team folder workflow vs explicit share.

Audit Drive shares periodically

External Drive shares accumulate. Quarterly: review /api/v1/audit-logs?action=creative_share to identify stale grants.

Lock down finance role

By default finance has no Creative Hub access. Don't grant explicitly unless needed. Creative IP isn't finance's concern.

Common mistakes

  • Expecting Wevion visibility = Drive access: they're independent

  • Sharing externally to give a teammate in-app view: wrong layer. Use team folder workflow.

  • Forgetting Wevion's Service Account is the file owner: removing the Service Account from a file = no one can access it including Wevion itself

Related