Skip to content

Transfer ownership of a shared project, and delete protection #1670

Description

@giswqs

Summary

Let the owner of a shared project transfer it to another account or to an organization, and let them mark a project delete-protected so it cannot be removed by accident.

Why

Two small gaps that cost real work when they bite.

Ownership is permanent. A shared project's URL is share.geolibre.app/<username>/<slug>, and the owner is fixed at upload. When a student graduates, a maintainer changes, or a personal project becomes a team's, the only option is for the new owner to re-upload — which changes the URL, breaking every embed, citation, and slide deck that pointed at the old one, and drops the view count, fork history, and version history.

Deletion is one click with no floor. A project that is embedded in a public site or cited in a paper has no way to say "this one is load-bearing". Delete protection is the standard answer, it is cheap, and it is the kind of thing people only wish for after the fact.

Proposal

1. Transfer ownership

  • From the project page and from the Project Gallery's "My projects" view: transfer to a username or to an organization the user administers.
  • The recipient must accept, so nobody can push content into someone else's account.
  • Keep the project id, view count, fork lineage, and version history. Redirect the old <username>/<slug> path to the new one permanently, so existing embeds keep working — the redirect is the entire point of doing this instead of re-uploading.
  • If the new owner already has that slug, ask for a new one at transfer time.

2. Delete protection

  • A per-project "prevent deletion" toggle, off by default.
  • With it on, delete returns a clear refusal that names the toggle. The owner turns it off and then deletes; two deliberate steps.
  • Show it in the gallery's own-projects list, so the protected ones are visible at a glance.

Scope notes

  • Server-side on share.geolibre.app, plus small UI in ProjectGalleryDialog.tsx and the project page.
  • The transfer-accept flow needs an identity to send the invitation to; sequence after sign-in.
  • Worth deciding at the same time what happens to a transferred project's visibility when the destination organization's sharing policy is stricter than the source's — clamping down is the safe answer.

Effort

Small to medium; mostly server-side plumbing with a modest UI surface.


Part of #1665 (access control umbrella).

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancement (small)Minor feature, small UI tweak, or text adjustment

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions