fix(ui): correct the perspectives hint, and name one team state one way - #284
Merged
Merged
Conversation
Found while writing the Teams documentation, by checking a claim rather than copying it across. The hint said perspectives are "resolved from the affected releases, which only vulnerability events carry: with perspectives set, release and approval events match nothing". Every part of that is wrong. ReleaseChangeHookImpl stamps ReleaseNotificationSupport.buildAffectedReleases onto RELEASE_CREATED, RELEASE_LIFECYCLE_CHANGED and RELEASE_BOM_DIFF; ApprovalEventNotifierImpl does the same for APPROVAL_REQUESTED and APPROVAL_RESOLVED; and that helper copies the component's perspectives onto each AffectedRelease. A perspective-scoped route matches those event types perfectly well. This mattered beyond the wording. The same claim is why the perspectives control was a candidate to be hidden alongside the minimum-severity one in this PR, and it was cited in the review as an unexplained inconsistency. The inconsistency is real but the direction is the opposite of what it looked like: severity IS inapplicable outside the two vuln event types (no producer resolves one), so hiding it is right; perspectives apply everywhere, so hiding them would have removed a working feature on the strength of a false comment. The deferral note added earlier in this PR is replaced by the finding. What an operator actually needs to know is what the gate requires -- a component that belongs to the perspective -- so that is what the hint now says. The identical claim survives in perspectiveGateMatches' javadoc in rearm-saas and is tracked on the board (t20260812-121545-31450); it is a comment-only fix in the other repo, not folded in here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> ReARM-Agent: a7dbfd07-7512-451d-8883-2e047dff3a50 ReARM-Agentic-Session: 3b26cb26-2a38-4ed6-811b-d008781071f1
…" everywhere The Layer 2 review of the docs PR found three pickers naming the same team state three ways: the route-target picker said "(deactivated)", the owner and assignment-rule pickers say "(archived)", and the Teams tab itself calls the action Archive and toasts "Team archived". The status stored underneath is INACTIVE in all three. Nothing was broken, which is exactly why it survived -- but an operator reading "deactivated" in one picker and "archived" in the next has no way to know they are the same state, and the documentation being written for this feature had to either pick one and be wrong somewhere or name all three. Aligned on "archived", the verb the feature's own control uses. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> ReARM-Agent: a7dbfd07-7512-451d-8883-2e047dff3a50 ReARM-Agentic-Session: 3b26cb26-2a38-4ed6-811b-d008781071f1
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
2 participants
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.
Two commits that were meant to be part of #282 but landed on the branch after it
merged -- the same way two commits missed #281 earlier. Cherry-picked onto main
unchanged.
1. The perspectives hint states the opposite of what the code does.
It says perspectives are "resolved from the affected releases, which only
vulnerability events carry: with perspectives set, release and approval events
match nothing". Every part of that is wrong.
ReleaseChangeHookImplstampsbuildAffectedReleaseson RELEASE_CREATED, RELEASE_LIFECYCLE_CHANGED andRELEASE_BOM_DIFF;
ApprovalEventNotifierImpldoes the same for both approvalevents; and that helper copies the component's perspectives onto each entry. A
perspective-scoped route matches those event types perfectly well -- what it
needs is a component that belongs to the perspective, which is what the hint now
says.
This matters beyond the wording: the same false claim was the stated reason to
consider hiding the perspectives control alongside the minimum-severity one.
Severity really is inapplicable outside the two vuln event types; perspectives
are not, and hiding them would have removed a working feature on the strength of
a wrong comment.
Docs #283 already documents the corrected behaviour, so until this lands the
product and the documentation contradict each other.
2. One word for one state. Three pickers named the same team state three
ways:
(deactivated)on route targets,(archived)on the owner andassignment-rule pickers, with
INACTIVEstored underneath and an Archiveaction producing it. Nothing was broken, which is why it survived -- but an
operator reading "deactivated" in one picker and "archived" in the next has no
way to know they are the same state. Aligned on the verb the feature's own
control uses.
The identical false claim also survives in
perspectiveGateMatches' javadoc inrearm-saas; it is comment-only and tracked on the board
(
t20260812-121545-31450).Validation: 147 unit tests pass, build clean, added lines plain ASCII.