Two RBAC layers: Wevion in-app (getVisibleSessionIds(db, callerId, callerRole) — super_admin/admin see all, owner sees self+team, others see own) + Drive permissions API (external folder sharing, writer).

Google Drive RBAC

Wevion enforces two layers of RBAC for Creative Hub files: 1) Wevion in-app visibility via creative-hub.helpers.ts getVisibleSessionIds(db, callerId, callerRole) (super_admin / admin see all users; owner sees self + their team; every other role sees only their own), and 2) Google Drive permissions for external sharing via the Drive permissions API (role='writer', type='user', folder-level). Both layers are 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(db, callerId, callerRole) — returns the list of session IDs whose Creative Hub the current user can access
• Listing endpoints filter by these visible session IDs

There is no canViewTeam flag — the role decides visibility directly. The Members switcher appears for roles that can see more than their own folder (super_admin / admin / owner).

Layer 2: Google Drive permissions

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

• Wevion uses role='writer' (read + edit) + type='user' (specific email)
• The share is folder-level — it grants access to the user's whole Creative Hub folder, not a single file

This layer controls who can open the folder 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

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

Creative Hub actions are not written to the Wevion audit log — there is no creative_* audit action in the code (no creative_view, creative_upload, creative_share, etc.). To see current external grants, use GET /api/v1/creative-hub/shared-emails. The general audit log lives at /api/v1/audit-log and covers other lifecycle events, not Creative Hub.

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 (a sharing record exists)
• But the underlying Drive permission API call may have failed
• Fix: re-share via ch-105; check GET /api/v1/creative-hub/shared-emails for current grants

Scenario C: super_admin / admin sees another user's folder but can't open the file in Drive

• Wevion's role-based visibility allows the in-app view
• But no Drive permission was ever granted to your personal Drive
• Fix: this is expected — Wevion fetches via the Service Account on your behalf; if you need to open directly in Drive, ask the 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.

Review Drive shares periodically

External Drive shares accumulate. Periodically review GET /api/v1/creative-hub/shared-emails to identify stale grants and revoke them.

Remember non-privileged roles see only their own folder

Roles like finance, manager, mediabuyer, and viewer see only their own Creative Hub folder — they can't browse others' creatives unless a folder is explicitly shared with them via Drive.

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

FAQ

Why can a teammate see a file in Wevion but not open it in Google Drive?

Because Wevion enforces two independent RBAC layers. Layer 1 is Wevion in-app visibility via getVisibleSessionIds(db, callerId, callerRole) — for example a super_admin or admin sees all users' folders by role. Layer 2 is Google Drive permissions for opening files directly in Drive. Wevion fetches files via the Service Account on your behalf, so in-app view never implies a Drive-level share.

Which roles can see everyone's Creative Hub files?

super_admin and admin can see every user's folders and files. An owner sees their own plus their team members' folders. Every other role — manager, mediabuyer, finance, viewer — sees only their own folder. There is no canViewTeam flag; the role decides visibility directly, and the Members switcher shows for the roles that can see beyond their own folder.

How do I give a teammate in-app visibility to a file I uploaded?

Use the shared team folder workflow, not external sharing. If a mediabuyer teammate has no explicit share, Wevion's Layer 1 RBAC blocks their view — that is expected. Sharing via ch-105 writes a Google Drive permission (Layer 2) for direct Drive access, but it does not add the file to their in-app Wevion view.

What happens if the Service Account is removed from a file?

No one can access it, including Wevion itself, because Wevion's Service Account is always the file owner and fetches files on your behalf. Wevion shares files externally using the Drive permissions API with role='writer' and type='user' by default, but the Service Account must retain ownership for any access to work.

Related articles

• Creative permissions and access
• Share folder with external collaborators