Shared folders managed on the organisation's page; one folder, one organisation #7
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Decided against Relay's model (a folder holds one relayId; share modal blocks paths already shared): shared folders move onto each organisation's page, listing only its own; sharing a vault folder already mapped elsewhere is refused with a message naming the organisation (today it silently replaces the mapping). Legacy mappings claimed by no page are listed on the home pane for unmapping. Checkpoint: unit (mappingCovering, partition, share refusal, pagesKey), e2e (page shows Synced row; refusal leaves mappings unchanged), mutation checks, plugin installed.
Checkpoint, 14 Sep 2026 —
e769d2e. Relay read: a folder holds one relayId; the share modal blocks paths already on a relay; folders are managed on the relay's page. Shared folders now live on each organisation's page (per-server slot, partitionFolders reads only that organisation's mappings), the home entry counts folders synced, and sharing or mapping a path already covered — same, parent or child on a / boundary — is refused with the organisation named; legacy mappings no page can claim are listed under 'Folders needing attention'. Unit: mappingCovering, partition, share refusal, pagesKey with folder count, structure reaches the entries. E2e: page shows the Synced row, home has no Share control, a second share leaves mappings unchanged and shows the notice. Mutations caught (5). Plugin installed in both vaults.