sharer2 is a "departed owner" (frozen) yet still offered as a share recipient and listed as an active directory account #686

New issue

Closed

opened 2026-09-23 10:17:23 +00:00 by Cordy · 0 comments

Cordy commented

2026-09-23 10:17:23 +00:00

Owner

Found by the #656 QA pass, §2 admin scouting (v0.6.247, files-bao). Read-only: sharer2 is a real account, so nothing was acted on.

Three surfaces disagree about the same account:

Administration → Sharing → Departed owners (badge 1): "1 FROZEN OWNER — Shares whose creator no longer resolves… sharer2 · 0 items · 1 public link · /home/sharer2/README.md · Transfer ownership / Revoke all".
Administration → Users & access → Accounts → Directory accounts: sharer2 is listed as USER, last sign-in 2026-09-21 23:11, with a "Make admin" action. There is no departed or frozen marker.
The share panel's people search: GET /api/v1/recipients?q=sh (and ?q=sharer2) → {"kind":"user","name":"sharer2"}, so sharer2 is offered as a normal share target.

Expected: one truth. If sharer2 "no longer resolves" (the departed detection), the directory list should mark them as departed, and the recipient search should not offer them (or should label them). Otherwise new grants go to an account whose existing shares are frozen. If sharer2 does resolve, the Departed owners entry is a false positive and the frozen public link is wrongly stopped.

Seen: the departed tab freezes sharer2's public link, while everything else treats sharer2 as live.

I couldn't tell from the UI which side is right: the IdP lookup vs the "seen at sign-in" cache. Worth checking the resolution path the departed sweep uses against the one the recipients endpoint uses.

Screenshots: 656-admin-users-accounts-bao.jpg (the directory list continues below the fold); the Departed owners pane is captured in the Sharing set of the §2 screenshots.

Found by the #656 QA pass, §2 admin scouting (v0.6.247, files-bao). Read-only: sharer2 is a real account, so nothing was acted on. **Three surfaces disagree about the same account:** 1. Administration → Sharing → **Departed owners** (badge 1): "1 FROZEN OWNER — Shares whose creator no longer resolves… **sharer2** · 0 items · 1 public link · /home/sharer2/README.md · Transfer ownership / Revoke all". 2. Administration → Users & access → Accounts → **Directory accounts**: sharer2 is listed as `USER`, last sign-in 2026-09-21 23:11, with a "Make admin" action. There is no departed or frozen marker. 3. The share panel's people search: `GET /api/v1/recipients?q=sh` (and `?q=sharer2`) → `{"kind":"user","name":"sharer2"}`, so sharer2 is offered as a normal share target. **Expected:** one truth. If sharer2 "no longer resolves" (the departed detection), the directory list should mark them as departed, and the recipient search should not offer them (or should label them). Otherwise new grants go to an account whose existing shares are frozen. If sharer2 *does* resolve, the Departed owners entry is a false positive and the frozen public link is wrongly stopped. **Seen:** the departed tab freezes sharer2's public link, while everything else treats sharer2 as live. I couldn't tell from the UI which side is right: the IdP lookup vs the "seen at sign-in" cache. Worth checking the resolution path the departed sweep uses against the one the recipients endpoint uses. **Screenshots:** `656-admin-users-accounts-bao.jpg` (the directory list continues below the fold); the Departed owners pane is captured in the Sharing set of the §2 screenshots.