Repository navigation
fix(pending-actions): let operators resolve system-staged actions via --operator-wide - #3669
Merged
Merged
Conversation
… --operator-wide (#3668) accept/reject now forward --operator-wide, and execute() carries it across the Agents API hop as context.operator_wide. Still gated by can_manage(). CLI resolver is user:<id> so grantless kinds (event submissions) resolve. Co-Authored-By: Extra Chill Bot (AI) <bot@extrachill.com>
Co-Authored-By: Extra Chill Bot (AI) <bot@extrachill.com>
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.
Closes #3668.
Problem
A manage-level operator couldn't accept or reject a pending action staged with
created_by: 0, such as anonymousextrachill_event_submissionactions. It failed from the CLI and throughexecute()with "You do not have permission to resolve this pending action."Fix
PendingActionsCommand):accept/rejectnow forward--operator-wide(matchinglist/get/summary) and document<action_id>,--operator-wide, and--format.cli:<id>becomesuser:<id>.canResolveWithGrant()letsuser/signed_urlresolvers through, butcli:falls through to grant matching. Event submissions stage withresolver_grants => [], so even with the scope fixed, a CLI resolve would still be refused.context.resolution_transport = clistays for auditing.execute(): the Agents API resolver only forwardscontext, sooperator_widetravels ascontext.operator_wide.resolve_with_datamachine_handlers()maps it back into the scope input. It stays gated byPermissionHelper::can_manage()throughPendingActionScope::operator_wide_allowed(), so a non-manager setting the flag is still refused.Decision: a
created_by: 0action still needs explicit--operator-widefrom a logged-in user. Manage-level intent stays explicit, and the default caller scope is unchanged.Tests
tests/pending-action-resolver-contract-smoke.php: a pending-actions accept/reject can't resolve anonymous-staged actions: --operator-wide dropped in CLI and execute() #3668 regression matrix over ability and CLI, accept and reject, manager and non-manager, flag and no flag, and flag via top-level input or context. It passes with 74 assertions, and 6 of them fail without theinc/change. Refused resolutions leave the action pending and never call the handler.mainwith stale stubs (add_option,DAY_IN_SECONDS,apply_filters, and the drain claim source moving toScopedDrainService.php). They exit non-zero onmainand zero here.prefix-policy-audit.phpandpath-case-audit.phppass.Provenance
Code was produced by Homeboy cook
agent-task-be0ed4da-872d-49d1-9693-70e0178b2665. It was blocked only by an over-broadhomeboy review test data-machinegate: the lab worktree had novendor/, and that gate isn't what CI runs. Adoption then hit a controller conflict. I verified the work locally, committed it, and finalized outside Homeboy.🤖 AI-assisted: generated by a Homeboy cook (Pi) and reviewed and finalized by Extra Chill Bot.