[Bug]: Copy link button in Active Shares does not show copied/checkmark feedback or View link

[tapiamcclung]

Before you start

• I searched the existing issues and did not find a duplicate.
• This is a bug report, not a usage question (questions belong in Discussions).

What happened?

In the Share Project dialog, the Active Shares / current shares list has a Copy link button that successfully copies the project URL to the clipboard, but provides no visual feedback that the copy succeeded.

This is inconsistent with the copy button shown immediately after creating a new share, which changes from the Copy icon to a Check icon after the clipboard operation succeeds and the possibility to open the share.

Steps to reproduce

Open a GeoLibre project.
Open Project → Share.
Create/share a project.

In the resulting share view, click Copy — the icon changes to a checkmark, providing confirmation that the URL was copied. The Open button gives access to the shared project.

Close/reopen the Share Project dialog and view the existing/active shares.

Click Copy on one of the existing shares.
Click on View

Expected behavior

The Copy button for an existing/active share should provide the same visual feedback as the Copy button shown immediately after creating a share.

For example:

Copy icon before clicking.

Checkmark after a successful clipboard write.

Return to the Copy icon after a short delay.

And let the user open the shared project from here too. The "View" text is possibly related to permissions, but this is inconsistent too, because I created the project with an "Edit" access role.

How are you running GeoLibre?

Self-hosted web deployment

Operating system and browser

No response

Sample data

No response

Screenshots or logs

Screen-Recording-2026-10-02-at-1-38-32-p-m.mp4

Screen-Recording-2026-10-02-at-1-41-04-p-m.mp4

[deniial00]

Reproduced in the web build (headless Chromium, local dev build, mocked /api/shares):

• The Copy button on an Active Shares row never changes to a checkmark. It always renders the Copy icon, while the post-create Copy button swaps on a copied flag.
• Each row has only Copy and Revoke, with no Open action.

Fix in #2806: per-row checkmark for 2s after a successful clipboard write, and an Open button on each row (same projectUrl as the post-create Open).

The "View" label is not changed. The client shows "View" when /api/shares returns no role or an unknown one, and shows "Edit" when the server returns role: "edit". I only tested mocked responses, so I can't say what your server returns. Could you check the raw /api/shares JSON for your Edit share and tell me what its role field is? If it is missing or not edit, the problem is on the server side.

Update: this is the Active Shares list. The "View" you clicked next to Copy is the role label, not a button, which is why nothing happened.

[tapiamcclung]

Thanks for the fix.
For the label, running curl -i \ -X POST -H "Authorization: Bearer xxxxx" https://<server>/api/shares returns (using what is mentioned on #2803 )

{
  "shares": [
    {
      "id": "ef3fc8f8-009b-4eed-a873-304e4e946db2",
      "username": "rtm",
      "slug": "test",
      "title": "Test",
      "description": "",
      "visibility": "public",
      "organization": null,
      "groupIds": [],
      "thumbnailUrl": null,
      "views": 0,
      "forkCount": 0,
      "versionCount": 1,
      "featured": false,
      "deleteProtected": false,
      "createdAt": "2026-10-02T19:35:57.704034Z",
      "updatedAt": "2026-10-02T19:35:57.704034Z",
      "tags": [],
      "rawJsonUrl": "https://<server>/rtm/test.geolibre.json",
      "projectUrl": "https://<server>/rtm/test",
      "viewerUrl": "https://<server>/?project=https%3A%2F%2F<server>%2Frtm%2Ftest.geolibre.json",
      "canEdit": true
    }
  ],
  "limit": 24,
  "offset": 0,
  "total": 1
}```

I am not getting a `role` field. Could it be the `"canEdit": true` one?

[deniial00]

Thanks, that payload explains it.

Your nginx rule maps /api/shares to /api/projects and renames projects to shares, so the client receives project objects, not share objects. Those carry canEdit, which says whether you (the caller) may edit the project. It is not the access level a link gives visitors, so GeoLibre does not use it as the role. No role is sent, and the client falls back to "View" for every row. That label is a fallback, not what was stored for your share.

As far as I can tell from #2803, the server has no /api/shares route and no link roles, expiry or passwords yet; implementing them in geolibre_server_api is planned there but is not available yet. The nginx alias cannot supply a role. Until the real endpoint exists, the role label on your shares will read "View" whatever role you picked.

#2806 fixes the other two points: a checkmark after copying on Active Shares rows, and an Open button on each row. Once the real /api/shares endpoint is deployed and nginx points at it, the role will come from the server and the label will be right. I did not map canEdit to the role, because that would show "Edit" on every share you own.

[tapiamcclung]

Exactly, GeoLibre expects GET /api/shares, while the self-hosted backend exposes GET /api/projects so I had to include that rule to fiddle around with it. The actual route not existing on geolibre_server_api explains it.
Thanks!