#690 - Creating an app-owned GROUP silently provisions a SPACE for its members — mislabelled "Managed by the identity provider", Members 0 - Cordy/Cairn

Cordy commented

2026-09-23 10:20:53 +00:00

Owner

Found by the #656 QA pass, §2 admin scouting (v0.6.247, files-bao).

Steps

Administration → Users & access → Groups → New group qa656, members sharer1. The dialog says app groups are "usable in peering allow-lists and as an admin group". It does not mention spaces.
Administration → Spaces now lists qa656 · Managed by the identity provider · Members 0 · Size — · Active. The total went from 10 to 11 spaces.
As sharer1, /spaces now contains a qa656 space next to "sharer1 folder share". The pre-existing app group test5 (2 members) shows the same way: space test5 · Managed by the identity provider · 0.

Expected: either groups don't create spaces (they're share/peering/admin principals), or the New group dialog says it will provision a space, and the Spaces admin row labels it as app-owned ("Owned by nikola-test · app-managed", like app-owned-space) with its real member count.
Seen: a member-visible space appears as a side effect, attributed to the IdP, with a member count of 0 (qa656 has 1 and test5 has 2).

Related copy bugs on the same page:

"Sizes measured 7 hours ago ago." (the word is doubled)
The Members column shows 0 for every IdP-managed space, where the Groups tab shows — for directory groups. 0 claims "nobody". It should say "—" or "IdP".

Cleanup note: deleting app group qa656 at the end of #656 will show whether the space goes with it. I'll report that on #656.

Screenshot: 656-admin-spaces-bao.jpg

Found by the #656 QA pass, §2 admin scouting (v0.6.247, files-bao). **Steps** 1. Administration → Users & access → Groups → **New group** `qa656`, members `sharer1`. The dialog says app groups are "usable in peering allow-lists and as an admin group". It does not mention spaces. 2. Administration → **Spaces** now lists `qa656 · Managed by the identity provider · Members 0 · Size — · Active`. The total went from 10 to 11 spaces. 3. As **sharer1**, `/spaces` now contains a `qa656` space next to "sharer1 folder share". The pre-existing app group `test5` (2 members) shows the same way: space `test5 · Managed by the identity provider · 0`. **Expected:** either groups don't create spaces (they're share/peering/admin principals), or the New group dialog says it will provision a space, and the Spaces admin row labels it as app-owned ("Owned by nikola-test · app-managed", like `app-owned-space`) with its real member count. **Seen:** a member-visible space appears as a side effect, attributed to the IdP, with a member count of 0 (qa656 has 1 and test5 has 2). Related copy bugs on the same page: - "Sizes measured 7 hours ago **ago**." (the word is doubled) - The Members column shows `0` for every IdP-managed space, where the Groups tab shows `—` for directory groups. `0` claims "nobody". It should say "—" or "IdP". Cleanup note: deleting app group `qa656` at the end of #656 will show whether the space goes with it. I'll report that on #656. **Screenshot:** `656-admin-spaces-bao.jpg`

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

2026-09-23 10:20:53 +00:00

Cordy referenced this issue

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

On-demand Opus browser QA pass: full feature matrix + UI consistency audit + admin dashboard + one-time OpenCloud comparison (supersedes #642) #656

Cordy commented

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

Author

Owner

Cleanup follow-up: deleting app group qa656 (after revoking its one grant, see #687) removed the qa656 space from sharer1's /spaces. So the space's lifetime is tied to the group. But Administration → Spaces still lists qa656 and still counts 11 spaces afterwards. The admin list is either cached (it already says "Sizes measured … ago ago") or keeps orphaned entries.

Cleanup follow-up: deleting app group `qa656` (after revoking its one grant, see #687) **removed the `qa656` space from sharer1's `/spaces`**. So the space's lifetime is tied to the group. But Administration → Spaces still lists `qa656` and still counts 11 spaces afterwards. The admin list is either cached (it already says "Sizes measured … ago ago") or keeps orphaned entries.

Cordy referenced this issue

2026-09-23 10:42:14 +00:00

On-demand Opus browser QA pass: full feature matrix + UI consistency audit + admin dashboard + one-time OpenCloud comparison (supersedes #642) #656

Cordy referenced this issue from a commit

2026-09-23 18:33:37 +00:00

RED: QA batch 2 pins - admin/departed correctness (#686 #687 #688 #689 #690 #658 #657)

Cordy referenced this issue from a commit

2026-09-23 18:35:48 +00:00

GREEN splice: QA batch 2 admin/departed correctness (#686 #687 #688 #689 #690 #658 #657)

Cordy referenced this issue from a commit

2026-09-23 18:36:22 +00:00

one-shot: QA batch 2 red-green (#686 #687 #688 #689 #690 #658 #657)

forgejo-actions referenced this issue from a commit

2026-09-23 18:36:52 +00:00

QA batch 2 - admin and departed-owner correctness (#686 #687 #688 #689 #690 #658 #657)

Cordy referenced this issue

2026-09-23 18:41:32 +00:00

QA batch 2 - admin and departed-owner correctness (v0.6.249) #698

Cordy commented

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

Author

Owner

v0.6.249 ships the honesty half of this issue: the "ago ago" doubling is fixed, managed space rows show "—" instead of a false member count of 0, and the New-group dialog now says that members also see a shared space with the group's name under /spaces.

Still open here — the structural question. Root cause confirmed: the storage scope layer synthesizes /spaces/<group> from auth.User.Groups, and app-owned group memberships are merged into u.Groups (they have to be, for share-grant resolution). So every app group becomes a functional member-visible space as a side effect, and the admin inventory labels it "Managed by the identity provider" because the union sees an ownerless directory.

Two ways to close this out, and it's a product call:

Exclude app groups from the space synthesis — scope driver gets an exclusion set (app-group names) wired at boot; app groups stay pure share/peering/admin principals. Clean, matches the #550 framing, but removes a behaviour someone could be relying on.
Embrace it — keep the spaces, but the spaces inventory labels them as app-group spaces with their real member count (cross-referencing the group store), not as IdP-managed.

Say which and I'll cut the slice. The QA cleanup (deleting qa656) will also show whether the space disappears with the group.

v0.6.249 ships the honesty half of this issue: the "ago ago" doubling is fixed, managed space rows show "—" instead of a false member count of 0, and the New-group dialog now says that members also see a shared space with the group's name under /spaces. **Still open here — the structural question.** Root cause confirmed: the storage scope layer synthesizes `/spaces/<group>` from `auth.User.Groups`, and app-owned group memberships are merged into `u.Groups` (they have to be, for share-grant resolution). So every app group becomes a functional member-visible space as a side effect, and the admin inventory labels it "Managed by the identity provider" because the union sees an ownerless directory. Two ways to close this out, and it's a product call: 1. **Exclude app groups from the space synthesis** — scope driver gets an exclusion set (app-group names) wired at boot; app groups stay pure share/peering/admin principals. Clean, matches the #550 framing, but removes a behaviour someone could be relying on. 2. **Embrace it** — keep the spaces, but the spaces inventory labels them as app-group spaces with their real member count (cross-referencing the group store), not as IdP-managed. Say which and I'll cut the slice. The QA cleanup (deleting `qa656`) will also show whether the space disappears with the group.

Cordy referenced this issue

2026-09-23 18:45:17 +00:00

QA re-verification run: confirm the fixes for the #656 findings (post-fix pass for Opus) #697

Cordy referenced this issue

2026-09-23 22:11:23 +00:00

QA re-verification run: confirm the fixes for the #656 findings (post-fix pass for Opus) #697

Cordy commented

2026-09-23 23:30:42 +00:00

Author

Owner

actually, i propose a new idea, which touches the UI of the app-owned groups creation dialog, we add a checkbox there "create a space for this group", giving also the possibility to name it if the box is checked, prefilling the textbox for the name with the groups name + space, e.g. "team A space". So the user can decide at the creation of a group, "do i want a space with it or not"

Cordy referenced this issue

2026-09-24 00:52:12 +00:00

QA re-verification run: confirm the fixes for the #656 findings (post-fix pass for Opus) #697

Cordy commented

2026-09-24 00:52:29 +00:00

Author

Owner

Decision heard: opt-in space at group creation — a checkbox in the New-group dialog, with a name field prefilled <group name> space when checked. Mockup delivered to Nikola (interactive HTML, canon-styled: two dialog states plus the Spaces-admin row preview).

What the mockup encodes, for the eventual slice:

Default unchecked — and that ends the silent side-effect: the scope driver stops synthesizing /spaces/<group> from app-group memberships (option 1 mechanics under the hood). An unchecked group is purely a sharing/peering/admin principal, matching the dialog's own lede.
Checked reveals "Space name", prefilled <group> space; the prefill tracks the group-name field until the space name is edited by hand, then detaches. The created space is a real provisioned app-owned space (decoupled from the group's name — synthesis by name can't support custom names anyway).
Spaces admin lists it honestly: team-a space · Owned by <creator> · group team-a · Members 2 · App-managed · Active — never "Managed by the identity provider", never a fake count.
Proposed keys ×4: guSpaceOpt, guSpaceName, guSpaceHintOn, guSpaceHintOff.

Two open questions flagged on the mockup before implementation:

Group deletion — delete the space with the group (today's observed behaviour), or keep it and hand it to the owner? Proposal: the group-delete confirm (fact-row canon) states the space's fate explicitly and offers both.
Existing synthesized spaces (e.g. test5) — migrate to provisioned app-owned spaces on upgrade, or drop them and let admins re-opt-in per group?

Also still pending here from the earlier comment: the stale qa656 row in the Spaces admin inventory (orphaned entry or cache) — that cleanup rides the implementation slice.

Decision heard: **opt-in space at group creation** — a checkbox in the New-group dialog, with a name field prefilled `<group name> space` when checked. Mockup delivered to Nikola (interactive HTML, canon-styled: two dialog states plus the Spaces-admin row preview). What the mockup encodes, for the eventual slice: - **Default unchecked** — and that ends the silent side-effect: the scope driver stops synthesizing `/spaces/<group>` from app-group memberships (option 1 mechanics under the hood). An unchecked group is purely a sharing/peering/admin principal, matching the dialog's own lede. - **Checked** reveals "Space name", prefilled `<group> space`; the prefill tracks the group-name field until the space name is edited by hand, then detaches. The created space is a real provisioned app-owned space (decoupled from the group's name — synthesis by name can't support custom names anyway). - **Spaces admin** lists it honestly: `team-a space · Owned by <creator> · group team-a · Members 2 · App-managed · Active` — never "Managed by the identity provider", never a fake count. - Proposed keys ×4: `guSpaceOpt`, `guSpaceName`, `guSpaceHintOn`, `guSpaceHintOff`. Two open questions flagged on the mockup before implementation: 1. **Group deletion** — delete the space with the group (today's observed behaviour), or keep it and hand it to the owner? Proposal: the group-delete confirm (fact-row canon) states the space's fate explicitly and offers both. 2. **Existing synthesized spaces** (e.g. `test5`) — migrate to provisioned app-owned spaces on upgrade, or drop them and let admins re-opt-in per group? Also still pending here from the earlier comment: the stale `qa656` row in the Spaces admin inventory (orphaned entry or cache) — that cleanup rides the implementation slice.

Cordy referenced this issue from a commit

2026-09-24 01:33:39 +00:00

scout(#690): exact UI anchors for gadddlg/gdeldlg/renderer/main wiring

Cordy referenced this issue from a commit

2026-09-24 01:33:52 +00:00

test(#690): RED - spacestore group link (SetGroup/FindByGroup)

Cordy referenced this issue from a commit

2026-09-24 01:34:11 +00:00

test(#690): RED - scope group exclusion (app groups stop synthesizing spaces)

Cordy referenced this issue from a commit

2026-09-24 01:34:52 +00:00

test(#690): RED - opt-in group space (create, mirror, delete fate, inventory link)