Cordy/Cairn

Fork 0

"My shares" headings show the full internal path, not the basename (#529 2/3 follow-up) #590

New issue

Closed

opened 2026-09-18 00:48:40 +00:00 by Cordy · 1 comment

Cordy commented

2026-09-18 00:48:40 +00:00

Owner

Found in the v0.6.213 live pass. Small, but it is a mismatch with the shipped PR's own stated behaviour.

What happens

Shares → My shares, with one grant on the folder moverini, renders the group heading as:

/home/nikola-test/moverini
  nikola-test2   Person   Can view   revoke

The heading is the full owner-qualified backend path.

What was specified

PR #583 says of pure:share-groups:

each group carries the basename for its heading

and share-groups.test.js has a passing case named "each group carries the basename for its heading". So either the pure function returns the basename and the view ignores it, or the view is handed the wrong field — worth checking which before editing, since the test is green and should stay meaningful.

The adjacent tab gets it right: Shared with me renders moverini with shared by nikola-test underneath, which is the intended treatment.

Why it is worth fixing rather than leaving

/home/nikola-test/ is the owner's own home prefix. On the My shares tab the viewer is the owner, so every heading repeats the same meaningless prefix, and a deep path pushes the part the user actually recognises off to the right. It also leaks the internal /home/<user>/ layout into a user-facing surface for no purpose — the same reasoning that made vpath server-supplied in #582 rather than rebuilt client-side.

Keep the full path available somewhere (title attribute, or the row's own detail) — two files with the same basename in different folders must still be distinguishable. The heading is the only thing changing.

Reproduce

Share anything with anyone.
Shares → My shares.

Found in the v0.6.213 live pass. Small, but it is a mismatch with the shipped PR's own stated behaviour. ## What happens Shares → **My shares**, with one grant on the folder `moverini`, renders the group heading as: ``` /home/nikola-test/moverini nikola-test2 Person Can view revoke ``` The heading is the full owner-qualified backend path. ## What was specified PR #583 says of `pure:share-groups`: > each group carries the basename for its heading and `share-groups.test.js` has a passing case named *"each group carries the basename for its heading"*. So either the pure function returns the basename and the view ignores it, or the view is handed the wrong field — worth checking which before editing, since the test is green and should stay meaningful. The adjacent tab gets it right: **Shared with me** renders `moverini` with `shared by nikola-test` underneath, which is the intended treatment. ## Why it is worth fixing rather than leaving `/home/nikola-test/` is the owner's own home prefix. On the **My shares** tab the viewer *is* the owner, so every heading repeats the same meaningless prefix, and a deep path pushes the part the user actually recognises off to the right. It also leaks the internal `/home/<user>/` layout into a user-facing surface for no purpose — the same reasoning that made `vpath` server-supplied in #582 rather than rebuilt client-side. Keep the full path available somewhere (title attribute, or the row's own detail) — two files with the same basename in different folders must still be distinguishable. The heading is the only thing changing. ## Reproduce 1. Share anything with anyone. 2. Shares → My shares.

Cordy added this to the v0.7 — Closed beta (dogfood + hardening) milestone

2026-09-18 00:48:40 +00:00

Cordy referenced this issue

2026-09-18 00:49:15 +00:00

Share panel: people and groups first, links split internal/public (#529, 2/3) #571

Cordy referenced this issue from a commit

2026-09-18 01:21:40 +00:00

chore: one-shot for the #590 fix (red then green on fix-590)

forgejo-actions referenced this issue from a commit

2026-09-18 01:23:34 +00:00

fix(#590): the My-shares heading is the basename the pure fn already carried

Cordy referenced this issue

2026-09-18 01:25:25 +00:00

fix(#590): the My-shares heading is the basename the pure fn already carried #592

Cordy referenced this issue from a commit

2026-09-18 01:30:57 +00:00

fix(#590): the My-shares heading is the basename the pure fn already carried (#592)

Cordy referenced this issue

2026-09-18 01:46:24 +00:00

docs: v0.6.214 changelog entry #594

Cordy commented

2026-09-18 02:01:33 +00:00

Author

Owner

Fixed in #592, shipped as v0.6.214, live on both dogfoods.

As the issue suspected: the pure function was right and the view ignored it — groupShares() carried both path and name, and sharesRenderMine() rendered g.path. The heading is now g.name with the full path kept as the heading's title, so two files sharing a basename in different folders stay distinguishable on hover.

web/test/shares-view.test.js now covers the wiring: it renders sharesRenderMine against a fake DOM and asserts the heading text, the title, and the two-folders-one-basename case. Red witnessed on the old rendering before the fix.

**Fixed in #592, shipped as v0.6.214, live on both dogfoods.** As the issue suspected: the pure function was right and the view ignored it — `groupShares()` carried both `path` and `name`, and `sharesRenderMine()` rendered `g.path`. The heading is now `g.name` with the full path kept as the heading's `title`, so two files sharing a basename in different folders stay distinguishable on hover. `web/test/shares-view.test.js` now covers the wiring: it renders `sharesRenderMine` against a fake DOM and asserts the heading text, the title, and the two-folders-one-basename case. Red witnessed on the old rendering before the fix.

Cordy closed this issue

2026-09-18 02:01:41 +00:00

Cordy referenced this issue

2026-09-18 02:02:14 +00:00

Share panel: people and groups first, links split internal/public (#529, 2/3) #571

Cordy referenced this issue

2026-09-18 10:24:55 +00:00

Share panel: people and groups first, links split internal/public (#529, 2/3) #571