Groups

Reusable membership sets inside an organization. Add a group to an ACL once, every group member gets the grant — and gain or lose it as the group changes.

A group is a named set of org members. Sweetdocs lets you grant a group permission to a library, folder, or document — and every member of that group inherits the grant. Adding someone to the group later automatically extends the grant; removing them strips it.

Groups are the scaling mechanism for org permissions. With ~10 members you can grant per-person; with ~50 you want to grant per-team.

How groups are modeled

In the database:

• groups — id, org_id, name
• group_members — group_id, user_id (composite primary key)

A user can be in any number of groups inside a given org. Groups are scoped to one org — you can’t share a group across orgs.

Creating a group

Only org Owners and Admins can create or delete groups. Members can see groups they belong to in the org page’s groups section, but they can’t create new ones.

Granting access with groups

Once a group exists, you can add it to the ACL of any:

• Library (whole org library shared with the group)
• Folder (everyone in the group gets access to that folder and its descendants)
• Document (single-doc grant — less common at the group level)

In the Share dialog, the principal type is either user or group. Picking a group from the people-picker sets principal_type = 'group' and the group’s UUID as principal_id in the acl_entries row.

The permissions resolver walks both user-direct ACL entries and group-membership-derived entries, and takes the highest level across both.

Group ACL entries vs. direct ACL entries

Both are first-class in acl_entries:

So a single user could have a direct Read grant on a folder and also be in a group with Write on the same folder — the resolver returns Write, the higher of the two.

Examples

A few common patterns:

Changing membership

Adding or removing a user from a group is instantaneous — the next permissions resolve (which runs on every read and write in the app and DB) sees the new membership and applies it. There’s no caching, no propagation delay.

In particular: removing someone from a group immediately revokes any access that flowed through that group. The next request they make to a resource they only had via the group will return “access denied.”

Deleting a group

Org Owners and Admins can delete a group. Deletion:

• Removes the groups row
• Cascades to delete every group_members row (the users themselves are untouched)
• Cascades to delete every acl_entries row that pointed at the group as principal
• Loses the audit trail of who was in the group when (consider exporting first if you need it)

This is destructive — every grant that depended on the group’s membership disappears at once.

What’s not in v1