test(e2e): assert the RENDERED icon per grant type (10.6), and the email invitation (10.4) - #2316
Merged
rubenvdlinde merged 1 commit intoAug 4, 2026
Conversation
…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.
Contributor
Quality Report — ConductionNL/openregister @
|
| 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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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-iconand the assertion fails. The row text renderssharedWith, 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:
:iswith 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()reportsTYPE_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
emailgrant · 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