Summary
An sso.email address that two accounts already answer for is counted both as
"already has an account" and as "cannot be created", so the summary describes one
address twice, in two contradictory ways.
Detail
_roster_address_is_held treats an ambiguous address as held and returns a warning
(deliberately — a roster is keyed by email and cannot be rekeyed by username, so
raising would abort an apply over an address that needs no action). The address
therefore lands in both UserCreationPlan.existing and UserCreationPlan.warnings.
_unmakeable_accounts (quiltx/tools/catalog/acl.py:306-310) then counts the whole
warnings list:
if not plan.warnings:
return ""
return f" and {len(plan.warnings)} cannot be created"With one ambiguous address and nothing else to do, the summary reads:
No accounts to create: 1 roster address(es) already have one and 1 cannot be created.
Both halves are about the same address, and they say opposite things.
Impact
Cosmetic. The per-address warning printed immediately afterwards is accurate and
explains the situation, and no creation decision is affected. It is noted because the
summary line is output about an irreversible operation, where a reader counting
addresses should be able to trust the arithmetic.
Proposed fix
Distinguish "cannot be created" from "needs nothing done, but is worth reporting".
UserCreationPlan.warnings currently carries both. Either split it into two tuples,
or have _unmakeable_accounts count only warnings whose address is absent from
plan.existing.
Splitting is probably cleaner: the ambiguous-but-held case, the missing-role case and
the truncated-username-collision case are three different outcomes sharing one field.
Notes
Introduced by #106 (PR #107); flagged during that work as outside the fix list.
Independent of the other follow-ups.
Summary
An
sso.emailaddress that two accounts already answer for is counted both as"already has an account" and as "cannot be created", so the summary describes one
address twice, in two contradictory ways.
Detail
_roster_address_is_heldtreats an ambiguous address as held and returns a warning(deliberately — a roster is keyed by email and cannot be rekeyed by username, so
raising would abort an apply over an address that needs no action). The address
therefore lands in both
UserCreationPlan.existingandUserCreationPlan.warnings._unmakeable_accounts(quiltx/tools/catalog/acl.py:306-310) then counts the wholewarnings list:
With one ambiguous address and nothing else to do, the summary reads:
Both halves are about the same address, and they say opposite things.
Impact
Cosmetic. The per-address warning printed immediately afterwards is accurate and
explains the situation, and no creation decision is affected. It is noted because the
summary line is output about an irreversible operation, where a reader counting
addresses should be able to trust the arithmetic.
Proposed fix
Distinguish "cannot be created" from "needs nothing done, but is worth reporting".
UserCreationPlan.warningscurrently carries both. Either split it into two tuples,or have
_unmakeable_accountscount only warnings whose address is absent fromplan.existing.Splitting is probably cleaner: the ambiguous-but-held case, the missing-role case and
the truncated-username-collision case are three different outcomes sharing one field.
Notes
Introduced by #106 (PR #107); flagged during that work as outside the fix list.
Independent of the other follow-ups.