Organizations: members, roles, an organization visibility level, and a public-sharing policy

[giswqs]

Summary

Add an organization tier to share.geolibre.app: members, member roles, an organization visibility level between unlisted and public, and an admin policy for whether members may publish publicly.

Why

Sharing today is single-owner. ShareVisibility is public | unlisted | private, and a project belongs to exactly one username. There is no way to express the most ordinary institutional situation: this map is for my lab / my department / my class, and nobody outside it.

The two workarounds both fail. unlisted means "anyone with the URL", which is not a boundary anyone can defend to a data steward. private means "only me", which defeats the purpose of sharing.

The second gap is the guardrail. Any signed-in user can set a project public today. For an institution putting GeoLibre in front of students or staff, "a member cannot accidentally publish to the open internet" is usually a precondition for adoption, not a nice-to-have.

Proposal

1. Organizations

• An organization has a slug, a display name, and members. A user may belong to more than one.
• Member roles at the org level: Administrator (manage members, settings, and any org content), Publisher (create and share content), Member (create own content, share within the org), Viewer (open shared content only).
• Projects can be owned by an organization rather than an individual, so someone leaving does not orphan the team's work.

2. A new visibility level

Extend ShareVisibility to private | organization | unlisted | public, where organization means "any signed-in member of the owning org". This is additive to the existing enum, so share-geolibre.ts, ShareProjectDialog.tsx, and the gallery's visibility filter all extend rather than change shape.

fetchMyProjects grows a sibling: list what my organization has shared with me, which is what the Project Gallery should open on for a member of an org.

3. Org settings that act as a ceiling

Enforced server-side, not offered as a suggestion:

• Members may share publicly: yes / publishers only / no.
• Default visibility for new projects (so the safe choice is the default, and public is always deliberate).
• Optionally, a default org content category taxonomy for browse.

When a policy forbids it, the Share dialog should show public as disabled with the reason ("your organization does not allow public sharing"), not hide it — a missing option reads as a bug.

Scope notes

• Almost all of the work is on share.geolibre.app: data model, membership, invitations, and enforcement on both the write path (POST /api/projects) and the read path (GET /api/projects, raw .geolibre.json).
• Depends on real sign-in (OAuth issue) — org membership is meaningless without an identity to attach it to.
• Groups (a separate issue) are the finer-grained cut inside an org and should reuse the same role vocabulary rather than inventing a second one.
• Keep individual accounts fully functional with no org. The overwhelming majority of users have no organization and must not be asked to create one.

Effort

Wishlist — this is a platform feature, not an app change.

---

Part of #1665 (access control umbrella).