fix(home): show Cancel button for own scheduled purchases by cristim · Pull Request #1421 · LeanerCloud/cloud-commitments-cli

cristim · 2026-07-16T20:50:59Z

Summary

Standard users with cancel-own:purchases could not cancel their own upcoming purchases from the Home page "Upcoming Scheduled Purchases" widget even though the backend supports creator-scope cancel (closes ux(home): Standard user cannot cancel own scheduled purchases from Home page #1400)
Backend deletePlannedPurchase required delete:purchases as its entry gate; Standard users hold cancel-own:purchases (not delete:purchases), so the endpoint returned 403 for them
Frontend canCancelUpcomingPurchase gated on delete:purchases before allowing the creator-scope path, so Standard users never saw the Cancel button for their own rows

Changes

Backend (internal/api/handler_purchases.go)

requireDeleteOrCancelPurchasePermission: new entry-gate helper accepting delete:purchases, cancel-any:purchases, or cancel-own:purchases
authorizePlannedPurchaseCancel: new ownership-check function (replaces authorizeExecutionManagement in the delete path) that accepts update-any or cancel-any for full-scope and creator-match for creator-scope; cyclomatic complexity kept at 10

Frontend (frontend/src/dashboard.ts)

canCancelUpcomingPurchase: full-scope via admin:*/cancel-any/update-any; creator-scope via delete:purchases OR cancel-own:purchases + creator match; original ownership semantics for delete:purchases holders are preserved

Tests

Backend: TestHandler_deletePlannedPurchase_CancelOwn_Creator_Allowed, TestHandler_deletePlannedPurchase_CancelOwn_NonCreator_Rejected in handler_purchases_test.go
Backend: two cancel-own sub-tests in TestDeletePlannedPurchase_PermissionGate in router_660_permission_flips_test.go
Frontend: 4 new cases in dashboard-ownership-950.test.ts under "Dashboard upcoming-purchase cancel-own gating (issue ux(home): Standard user cannot cancel own scheduled purchases from Home page #1400)"

Test plan

Go build: go build ./... exit 0
Go vet: go vet ./... exit 0
Backend tests: go test ./internal/api/... 1665 passed, exit 0
gocyclo -over 10 on touched files: exit 0 (no new violations)
golangci-lint --new-from-rev=origin/main: 0 new issues
Frontend tests: 78 suites, 2567 passed, exit 0
Frontend build (webpack): exit 0
Manual: log in as Standard user, navigate to Home > Upcoming Scheduled Purchases, verify Cancel button appears on own rows and is absent on other users' rows

Standard users with cancel-own:purchases could not cancel their own upcoming purchases from the Home page widget because: 1. The backend deletePlannedPurchase handler required delete:purchases (a management verb) as its entry gate, which Standard users do not hold. Only cancel-own:purchases is in their default permission set. 2. The frontend canCancelUpcomingPurchase checked delete:purchases as a necessary gate before allowing the creator-scope path, so Standard users never saw the Cancel button even for rows they created. Backend: add requireDeleteOrCancelPurchasePermission (accepts delete:purchases, cancel-any:purchases, or cancel-own:purchases) and authorizePlannedPurchaseCancel (extends authorizeExecutionManagement to also accept cancel-any as a full-scope grant). deletePlannedPurchase now uses these in place of the old requirePermission + authorizeExecution- Management pair, keeping all existing behavior intact. Frontend: canCancelUpcomingPurchase now grants full-scope access to admin/cancel-any/update-any, and creator-scope access to delete:purchases OR cancel-own:purchases holders who match the row's created_by_user_id. The original ownership semantics for delete:purchases holders are preserved. Tests added: - backend: TestHandler_deletePlannedPurchase_CancelOwn_Creator_Allowed, TestHandler_deletePlannedPurchase_CancelOwn_NonCreator_Rejected (handler_purchases_test.go) - backend: two cancel-own sub-tests in TestDeletePlannedPurchase_ PermissionGate (router_660_permission_flips_test.go) - frontend: "Dashboard upcoming-purchase cancel-own gating (issue #1400)" describe block with 4 cases in dashboard-ownership-950.test.ts Closes #1400

cristim · 2026-07-16T20:51:06Z

@coderabbitai review

coderabbitai · 2026-07-16T20:51:12Z

✅ Action performed

Review finished.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

coderabbitai · 2026-07-16T20:51:13Z

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 41 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: a9601d72-853a-4917-8587-778b161e8a56

📥 Commits

Reviewing files that changed from the base of the PR and between f017cae and fcc40ee.

📒 Files selected for processing (5)

frontend/src/__tests__/dashboard-ownership-950.test.ts
frontend/src/dashboard.ts
internal/api/handler_purchases.go
internal/api/handler_purchases_test.go
internal/api/router_660_permission_flips_test.go

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch fix/1400-home-cancel-own-scheduled

_{Comment @coderabbitai help to get the list of available commands.}

cristim · 2026-07-16T21:31:44Z

Merged to main after independent adversarial review (verdict SHIP, fail-before/pass-after verified) + all CI green; closes #1400. Standard users can cancel their OWN scheduled purchases on the Home page (backend gate now accepts cancel-own with a server-side ownership check; non-owner 403).

… page (closes #1442) (#1443) canDisablePlan in plans.ts required delete:purchases, which Standard users do not hold. PR #1421 updated the backend (deletePlannedPurchase) and the Home-page widget (canCancelUpcomingPurchase) to accept cancel-own:purchases, but the Plans-page Disable-button gate was not updated. The creator's canManagePurchase was already true via canManageScheduledPurchase; only the verb check was wrong. Accept cancel-own:purchases and cancel-any:purchases alongside delete:purchases in canDisablePlan, mirroring the backend requireDeleteOrCancelPurchasePermission gate and the dashboard canCancelUpcomingPurchase logic from PR #1421. Regression tests added to plans-ownership-950.test.ts: - Creator with cancel-own (no delete) sees Disable on their own row - Non-creator with cancel-own does not see Disable (ownership gate holds) - Legacy NULL-creator row shows no Disable for cancel-own user - cancel-any creator also sees Disable (backend supports it)

…ion check (#1491) requireDeleteOrCancelPurchasePermission hand-rolled its own auth dispatch (admin API key -> session) and dropped the user-API-key branch that every other permission gate relies on via requirePermission/authorizeAPIKey. Scoped API-key automation clients presenting only an x-api-key header got a 401 "no authorization token provided" instead of being authorized against their key's granted verbs, even when the key held delete:purchases. Add requireAnyPermission/authorizeAPIKeyAny as the multi-verb counterparts to the existing requirePermission/authorizeAPIKey dispatch chain, and delegate requireDeleteOrCancelPurchasePermission to it so the delete/cancel gate cannot drift from the single-verb dispatch order used everywhere else. Also widen the verb set to include update-any so a custom group holding only that permission clears this entry gate before ownership is checked. Follow-up to #1421, which introduced the hand-rolled gate. Also updates a pre-existing sibling test (TestDeletePlannedPurchase_PermissionGate) whose mock set predates the update-any verb addition.

cristim added triaged Item has been triaged priority/p2 Backlog-worthy severity/medium Moderate harm urgency/this-sprint Within the current sprint impact/many Affects most users effort/s Hours type/bug Defect labels Jul 16, 2026

cristim merged commit 460daed into main Jul 16, 2026
20 checks passed

cristim deleted the fix/1400-home-cancel-own-scheduled branch July 16, 2026 21:31

This was referenced Jul 17, 2026

bug(rbac/plans): creator cannot manage own scheduled purchase created from Plans page #1442

Closed

fix(rbac/plans): let creator manage own scheduled purchase from Plans page (closes #1442) #1443

Merged

cristim mentioned this pull request Jul 22, 2026

fix(api): authorize API-key clients on delete/cancel purchase permission check #1491

Merged

7 tasks done

Navigation Menu

Repository navigation

fix(home): show Cancel button for own scheduled purchases - #1421

fix(home): show Cancel button for own scheduled purchases#1421
cristim merged 1 commit into
mainfrom
fix/1400-home-cancel-own-scheduled

cristim commented Jul 16, 2026

Uh oh!

cristim commented Jul 16, 2026

Uh oh!

coderabbitai Bot commented Jul 16, 2026 •

edited

Loading

Uh oh!

coderabbitai Bot commented Jul 16, 2026 •

edited

Loading

Review limit reached

Uh oh!

Uh oh!

cristim commented Jul 16, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

cristim commented Jul 16, 2026

Summary

Changes

Test plan

Uh oh!

cristim commented Jul 16, 2026

Uh oh!

coderabbitai Bot commented Jul 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

coderabbitai Bot commented Jul 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review limit reached

Uh oh!

Uh oh!

cristim commented Jul 16, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

coderabbitai Bot commented Jul 16, 2026 •

edited

Loading

coderabbitai Bot commented Jul 16, 2026 •

edited

Loading