opengeos/GeoLibre PR #1534 — Access control and share management — PR #1534
opengeos/GeoLibre · pull request #1534 ·
Transcript
PlainEnglish
Let's walk through pull request 1534 — a feature that brings access control and share management to GeoLibre's project sharing system.
PlainEnglish
We're pursuing two main goals here. First, adding fine-grained access controls — roles, expiry dates, and password protection for shares. Second, giving users a way to manage their active shares and revoke them when needed. Along the way, we'll add supporting utilities, extend our type definitions, localize the new UI, and expand test coverage. And we're preserving the existing share API surface, so nothing breaks.
PlainEnglish
The existing share system was simple — you could share a project, but every link had full access and lived forever. There was no way to limit what recipients could do, no expiry, no passwords, and no way to revoke a link once you'd sent it. This PR brings the sharing feature up to speed with sophisticated collaboration workflows. Now users can choose whether someone can only view, leave comments, or fully edit. They can set links to expire after a day, a week, or a month. They can password-protect shares. And they can see all their active shares and revoke any of them.
Architecture
Let's see where the changes landed. The bulk of the work is in share-geolibre dot t s, which gets three new API functions — fetch project shares, revoke share, and verify share password — plus new type definitions for roles and expiry. The share project dialog gains a two-tab interface with dropdowns for role, expiry, and a password field, plus a manage tab that lists active shares with revoke buttons. Project-url dot t s picks up a helper to parse role query parameters for deep links. We've added i18n strings for all the new UI, and we've expanded test coverage to match.
Architecture
Here are the three new API functions in share-geolibre. Fetch project shares retrieves the list of active shares for the authenticated user — it's what powers the manage tab. Revoke share sends a DELETE request to remove a share by id, treating a 404 as success since the share is already gone. And verify share password authenticates access to a password-protected share by posting the password to the share's access endpoint and returning the decrypted project content and the role. Together, these give the frontend everything it needs to list, revoke, and unlock shares.
Architecture
Now let's look at the UI changes. The original share dialog had a single visibility dropdown. We've expanded it into a two-column grid with three controls. The role dropdown lets users choose view only, can comment, or can edit. The expiry dropdown offers never expires, twenty-four hours, seven days, or thirty days. And below that, there's a password input field for optional password protection. All three are optional — if you leave them blank, you get the defaults. But now users have the knobs they need to tailor each share.
Architecture
The dialog now has two tabs — new share and active shares. The manage tab shows a badge with the count of active shares. When you switch to it, we fetch the list of shares and display each one with its visibility, role, a lock icon if it has a password, and the expiry date if one's set. Each share gets two buttons — copy to grab the link and revoke to delete it. The revoke button disables itself while the deletion's in flight so users can't double-click. Once a share's revoked, it's filtered out of the list immediately.
Architecture
On the type side, we've added two new union types — share role with view, comment, and edit, and share expiry with never, twenty-four h, seven d, and thirty d. We've introduced an active share interface to represent a share in the manage list, carrying its id, url, visibility, role, expiry, and password flag. And we've extended share upload result with those same new fields so the create flow can return the metadata for the share we just made. These extensions ripple through the request and response parsing, making sure every layer knows about the new attributes.
PlainEnglish
So what's the codebase look like now? Users can create shares with fine-grained roles — view-only, comment, or full edit. They can set links to expire after a day, a week, or a month. They can password-protect shares for an extra security layer. They can view all their active shares in one place, complete with metadata badges showing visibility, role, password status, and expiry. They can revoke any share instantly. And they can deep-link to shares with a pre-set role using query parameters. The sharing feature is now robust enough for real collaboration workflows.
CodeQuality
One thing to keep an eye on. The revoke error state is shared and displayed globally in the manage tab. If two revoke operations fail sequentially, the error from the second will replace the first. A user attempting to revoke multiple shares in rapid succession might see confusing or stale error messages. It's not a blocker — the operations still work independently — but if you're debugging a support ticket about error messages disappearing or changing unexpectedly, this is the spot to look.
PlainEnglish
And that's the pull request. A focused expansion of project sharing that brings access roles, expiry options, password protection, and a manage-and-revoke interface to the table. The role parsing lives in project-url, the new API functions live in share-geolibre, and the manage tab renders starting at line four twenty-seven in the share project dialog. Thanks for walking through it with me.
How this was made
Lenzon read opengeos/GeoLibre at pull request #1534 and generated this walkthrough automatically. The narration above is the transcript of what it says.
Explain a pull request from your own repo
Point Lenzon at a repo or a pull request and get a narrated walkthrough like this one.
Try it