Skip to content

test(e2e): assert the RENDERED icon per grant type (10.6), and the email invitation (10.4) - #2316

Merged
rubenvdlinde merged 1 commit into
developmentfrom
test/e2e-rendered-icons-and-email-invite
Aug 4, 2026
Merged

test(e2e): assert the RENDERED icon per grant type (10.6), and the email invitation (10.4)#2316
rubenvdlinde merged 1 commit into
developmentfrom
test/e2e-rendered-icons-and-email-invite

Conversation

@rubenvdlinde

Copy link
Copy Markdown
Contributor

Task 10.6 — measured icons, and it fixes a weakness in my own group test

Every grant row's icon is now asserted from the DOM class the icon component emits — .account-icon, .account-group-icon, .email-icon, .link-variant-icon — one per grant type.

This is a real discriminator, not decoration. iconFor() dispatches on the type the server reported, so a user share named after a group renders .account-icon and the assertion fails. The row text renders sharedWith, which was the group's name under the broken behaviour too — I labelled it "sanity check only, NOT the discriminator" one commit ago, and this is the discriminator it was missing.

It also proves the icon resolved at all: :is with an unregistered name renders nothing rather than a fallback, so "no icon" and "wrong icon" are both caught, and neither is visible to a text assertion.

On the link row it is load-bearing for a second reason: a link row only exists because listGrants() reports TYPE_LINK (#2311), so this guards that fix from the outside.

Task 10.4 — the email invitation, as far as this instance can honestly take it

Proven: created through the UI · reported by the server as an email grant · listed (it was not, before #2311) · the token is followable by someone with no account · revoking in the UI returns 404 for that token.

Not proven, and stated rather than papered over: SMTP delivery. CI has no mail transport, and standing up a sink process would make this gate depend on it — a flaky gate is worse than a stated gap. The half that is proven is the security-relevant one: followable, and revocable after the mail has gone out, which is the whole reason the message carries no object data.

The test also asserts the component's error branch stays empty immediately after the click, so if the instance refuses the invitation outright the failure says that instead of a later selector timing out and implicating the UI.

tasks.md: 69 done, 13 open — the 13 each carrying their reason.

🤖 Generated with Claude Code

…ail invitation (10.4)

TASK 10.6 — every grant row's icon is now asserted from the DOM class the icon
component emits: `.account-icon`, `.account-group-icon`, `.email-icon`,
`.link-variant-icon`, one per grant type.

This is a real discriminator, not decoration, and it fixes a weakness I flagged
against my own group test one commit ago. `iconFor()` dispatches on the type the
SERVER reported, so a user share named after a group renders `.account-icon` and
the assertion fails — whereas the row TEXT renders `sharedWith`, which was the
group's name under the broken behaviour too and would have passed either way.

It also proves the icon resolved at all: `:is` with an unregistered name renders
NOTHING rather than a fallback, so "no icon" and "wrong icon" are both caught,
and neither is visible to a text assertion.

On the link row the icon is load-bearing for a second reason: a link row only
exists because listGrants() reports TYPE_LINK (or#2311), so this guards that fix
from the outside.

TASK 10.4 — the email invitation, as far as an instance with no mail transport
can honestly take it.

PROVEN: created through the UI; reported by the server as an `email` grant; LISTED
(it was not, before or#2311); the token is followable by someone with NO account;
revoking in the UI returns 404 for that token.

NOT PROVEN, and stated rather than papered over: SMTP delivery. CI has no mail
transport, and standing up a sink process would make this gate depend on it — a
flaky gate is worse than a stated gap. The security-relevant half is the one
proven: followable, and revocable AFTER the mail has gone out, which is the whole
reason the message carries no object data.

The test also asserts the component's error branch stays empty right after the
click, so if the instance refuses the invitation outright the failure says so
instead of a later selector timing out and implicating the UI.

tasks.md: 69 done, 13 open.
@github-actions

github-actions Bot commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

Quality Report — ConductionNL/openregister @ 3d30068

Check PHP Vue Security License Tests
lint
phpcs
phpmd
psalm
phpstan
phpmetrics
eslint
stylelint
build
composer ✅ 174/174
npm ✅ 713/713
PHPUnit
Newman
Playwright

Quality workflow — 2026-08-03 22:19 UTC

Download the full PDF report from the workflow artifacts.

@rubenvdlinde
rubenvdlinde merged commit 274d2ff into development Aug 4, 2026
29 checks passed
@rubenvdlinde
rubenvdlinde deleted the test/e2e-rendered-icons-and-email-invite branch August 4, 2026 05:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant