Blog
Build in Public
April 30, 202610 min

3 Access Levels for Sharing Without Giving Everything Away: TAMSIV's Permission Revamp

Marie invited Camille to the "Léa & Thomas Wedding" folder on Tuesday evening. She just wanted to show her the list of vendors and the guest organization. By Wednesday noon, Camille had modified the budget, deleted two tasks "by mistake," and renamed the folder. Not out of malice. Simply because sharing was binary: you're in or you're out, and when you're in, you can do anything.

This scenario comes up constantly as soon as a collaborative app grows. Granular access isn't a technical detail; it's what differentiates a tool you can lend to the whole family from a tool you hesitate to share. TAMSIV version 1.29 introduces three distinct access levels (read, write, full) that apply to each member of a share, on every task, memo, event, and folder. 1258 lines added, 824 deleted, six languages updated—a project we internally called "Phase A + B permissions refactor."

Key Points
  • Three clear access levels replace binary sharing: Read (view without modifying), Write (view and modify content), Full (modify, delete, manage assignments).
  • Each member of a shared folder receives a visible badge (gray eye, blue pencil, green shield) that makes access clear at a glance for everyone, not just the owner.
  • The "Hierarchy" and "Members" sections are now collapsible, the access tree is redesigned with continuous connectors, cards indented by depth, and an extended horizontal line per level.
  • The PermissionLevelPicker component centralizes selection: 186 lines, accessible modal, explicit descriptions in six languages, disabled state for non-editable roles.
  • An assignee's role is resolved within the folder's context (direct vs. external assignee), with roles.assigned and roles.external keys that prevent visual confusion.
Cinematic visualization of concentric layers of golden and amber keys, representing gradual access levels for collaborative sharing

Why does binary sharing no longer hold up once a family gets involved?

In most mainstream collaborative apps, access boils down to two states: you are a member, or you are not. When you invite someone, you automatically give them the right to do everything. Modify, delete, add participants, change dates, rename. This is the model for basic Trello boards, most Apple shared notes, and many shared grocery lists.

This model works as long as you share with only one trusted person, and as long as everyone has the same interest in respecting the content. As soon as you add a third party, or the dynamic changes, friction begins. Your spouse needs to modify the grocery list, but your mother-in-law, who's visiting for the weekend, just needs to see it. Your team can edit the client brief, but the client themselves should only read it. Your sister, who's planning her wedding with you, needs full control, but her sister-in-law, who helps occasionally, doesn't need to be able to delete the entire folder.

The absence of access levels forces a painful binary choice: either you over-invest guests (and risk a loved one unintentionally modifying something), or you under-invest (and the person can't do anything useful, so they give up). This is exactly the friction that pushes people back to WhatsApp screenshots and scattered mental load across ten different tools.

What are the three access levels in TAMSIV?

The redesign introduces three distinct levels, each with its icon, color, and description, accessible via a unified selector throughout the app.

Read (gray eye)

The member sees all content but cannot modify anything. They can comment, react with emojis, receive folder notifications, but not create new tasks, modify dates, or change assignments. This is the perfect level for a loved one you're keeping informed, a client you're consulting, a parent who wants to follow the organization without risking touching anything.

Write (blue pencil)

The member can view and modify existing content. They can create new tasks, modify memos, add photos, move an event. But they cannot delete what they didn't create themselves, nor manage others' assignments. This is the common collaboration mode, used when working together on the same project.

Full (green shield)

The member has the same rights as the owner with one exception: they cannot dissolve the entire share. They can modify, delete, manage assignments, invite new members, and change others' access levels. This is the "co-organizer" mode, perfect for a spouse, a partner, a parent to whom you want to delegate everything without transferring ownership of the folder.

The three levels are represented by a consistent visual selector: icon + color + label, with an explanatory bubble on tap. The selector is called PermissionLevelPicker, it lives in frontend/src/components/common/ and is used wherever an access level needs to be displayed or modified. This component's uniqueness ensures that a Read member on the "Wedding" folder visually recognizes themselves as Read on the "Book Venue" task, without reinterpretation.

How to see who has what access in a shared folder?

The second major part of the redesign concerns the screen that lists members. Previously, you saw a flat list of avatars with first names. Now, each member is accompanied by a colored access badge, and the list is sorted by level (Full at the top, then Write, then Read). At a glance, the owner sees who can do what.

The "Hierarchy" and "Members" sections of a task, memo, or event's details are now collapsible. You tap the header, the chevron rotates, and the section folds or unfolds. On screens with many members or deep hierarchies, this changes everything for readability.

The access tree itself has been redesigned. Before, it was a flat list with two or three approximate indentations. Now, each depth level has its own cell, its own extended horizontal line, its own continuous tree-connectors that draw the hierarchy like a real tree. When a folder is nested within another, and a task is nested within the child folder, the tree makes the inheritance chain visual, not verbal.

How does permission inheritance work through the hierarchy?

TAMSIV allows nesting folders up to six levels deep. If you give someone Write access to a parent folder, they automatically inherit Write access to all sub-folders and their content. This is the default behavior, and it's what's expected in 80% of cases.

However, the new architecture also allows overriding an access level locally. A Write member on the parent folder can be limited to Read on a specific sub-folder, because that sub-folder contains sensitive information. The override is explicit (a specific badge appears in the tree), and it is displayed in the context of the parent folder to remain traceable.

This inheritance with override is technically complex. It relies on PostgreSQL's Row Level Security policies, extended by 31 RLS policies that calculate a user's effective level on a given item by traversing the tree. The result is calculated on the database side, not the client side, which prevents permission drifts and frontend exploits.

Why did this refactor affect 15 files and 6 languages?

Permissions are a transversal concept. They live in the details of a task (who can modify?), in the list of members of a folder (who sees what?), in the sharing selector (who do I give access to?), in the assignment screen (who can be assigned?), in the access tree (how is inheritance calculated?). Touching permissions means touching the backbone of collaboration.

The refactor involved 15 modified frontend files, including the main ones: AssigneesModal.tsx (130 lines added, managing an assignee's role in their folder), GroupMembersModal.tsx (62 lines added, access badges), GroupHierarchySection.tsx (346 lines refactored, redesigned tree), TaskAccessTree.tsx (24 lines adjusted, integrating the badge into the group branch), and the new PermissionLevelPicker.tsx component (186 lines, reusable modal).

On the i18n side, new keys access.read/write/readWrite/full, access.readDescription/writeDescription/fullDescription, access.permissionLevel, roles.assigned/external were added to the six language files (FR, EN, DE, ES, IT, PT). Translation went through our OpenRouter automatic script with human review for nuances. A bad label for "Total" in German or "Write" in Italian can be enough to lose all readability of the feature.

What family and professional uses does granularity unlock?

What changes in real life isn't the code. It's the usage scenarios that become possible without workarounds.

A family with a teenager. You give Full access to your spouse on the "Home" folder, Write access to your 15-year-old so they can check off their own tasks without risking deleting the whole family's, and Read access to grandparents visiting for the weekend who just want to know if they need to bring bread.

A freelancer with a client. You share the "Client X Website" folder with your client in Read mode (they see progress, they comment), with your subcontractor in Write mode (they modify content without being able to unassign you), and with your partner in Full mode (they can manage everything if you go on vacation).

An association or PTA. You give Full access to the board (3 people), Write access to active volunteers (15 people), and Read access to parents who want to follow the organization of the school fair without risking accidentally modifying the schedule.

A multi-person wedding. You give Full access to your spouse and the main witness, Write access to the four bridesmaids helping with specific aspects, and Read access to parents and in-laws who want to follow guests and the D-Day schedule without risking breaking everything.

Frequently Asked Questions

Can the folder owner change members' access levels after invitation?

Yes. From the folder's "Members" screen, the owner (and any Full member) can modify anyone's access level at any time, without re-inviting. The change is applied in real-time on all devices via Supabase Realtime; the affected member sees their level change in the app without having to log in again.

What happens if I give Read access to someone who previously had Full access?

Past contributions (tasks created, photos uploaded, comments) remain in the folder. The person only loses the ability to modify or delete them. They continue to see all content, but editing buttons disappear on the interface side, and server-side requests are rejected by RLS policies if someone tries to bypass via a direct request.

Can I give someone Full access to a sub-folder without giving them Full access to the parent folder?

No, inheritance goes down but not up. If you want someone to have Full access to a sub-folder, they must have at least Read access to the parent (otherwise, they won't be able to navigate to the sub-folder). You can, however, do the opposite: give Full access to the parent and downgrade to Write or Read on a specific sub-folder to protect a sensitive part.

Do access levels also apply to attachments and comments?

Yes. A Read member can view attachments but not upload them. They can read comments but can still write them and react with emojis (commenting is a non-destructive form of contribution, open to all levels). RLS policies are consistently applied across the six tables involved: tasks, memos, events, attachments, comments, reactions.

How does migration work for folders created before 1.29?

All existing members have been migrated to the Full level (which corresponds to the behavior before the refactor). No user action is required. If you want to take advantage of granularity on an existing folder, simply open the Members screen and adjust each person's level. The modification is instant, without invitation rejection or data loss.

And you, have you ever given someone too much access on a shared app?

If you're reading this article, it's probably because you've experienced this scenario at least once. You added a loved one to a folder or project, and a few days later, you discovered that the person had modified, deleted, or reorganized something you cared about. Not out of malice. Simply because the app didn't allow you to say "you can look, but don't touch."

TAMSIV version 1.29 solves this dilemma in two taps. You invite, you choose the level, you can modify it at any time. Sharing becomes a slider, not a switch. And that might be what gives you the courage to open your folders to a wider circle than the two people you used to invite.

Download TAMSIV for free on the Play Store and test the new access levels starting with version 1.29.