fix(frontend): surface Cancel button for non-admin operators with cancel-* (closes #158)

[cristim]

Summary

• Replaces the user.role === 'admin' check in canCancelPendingRow (history.ts) with the same canAccess predicate pattern used by canApproveRIExchangeRow in riexchange.ts (PR feat(ri-exchange): symmetric session-auth approve path (closes #300) #590): canAccess('admin', '*') || canAccess('cancel-any', 'purchases') || (canAccess('cancel-own', 'purchases') && row.created_by_user_id === user.id).
• Removes the deferred-work caveat block that was tracking this gap.
• Adds history-cancel-permissions.test.ts covering admin / cancel-any / cancel-own-own-row / cancel-own-other-row / no-permission / anonymous matrix (6 new tests).

Test plan

• cd frontend && npx tsc --noEmit -- no type errors
• npx jest -- 2148 tests pass, 0 failures
• history-cancel-permissions.test.ts -- 6 new tests all green
• history-cancel-button.test.ts -- 8 existing tests still green (no regression)
• Verify: non-admin user with cancel-any:purchases permission sees Cancel button on all pending rows
• Verify: non-admin user with only cancel-own:purchases sees Cancel only on their own rows
• Verify: user with no cancel permission sees no Cancel buttons

Summary by CodeRabbit

• Tests

  • Updated user permission test fixtures for cancel and approve button scenarios
  • Added comprehensive test suite validating History cancel button permission authorization across admin, cancel-any, cancel-own, and anonymous user contexts

• Refactor

  • Refined History action permission evaluation to utilize the effective permissions model

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 699becf2-5972-4998-bda3-6909821bfb3e

📥 Commits

Reviewing files that changed from the base of the PR and between 6943207 and a36c266.

📒 Files selected for processing (4)

• frontend/src/__tests__/history-approve-button.test.ts
• frontend/src/__tests__/history-cancel-button.test.ts
• frontend/src/__tests__/history-cancel-permissions.test.ts
• frontend/src/history.ts

---

📝 Walkthrough

Walkthrough

This PR adds permission-gating to the History inline Cancel button using a granular role-based access control model. The canCancelPendingRow function is updated to honor three permission levels (admin, cancel-any, cancel-own), and comprehensive new test coverage validates all permission scenarios. Existing test fixtures are updated to populate the effectivePermissions array required by the new authorization logic.

Changes

Cancel Button Permission-Gating Authorization

Layer / File(s)	Summary
Cancel button authorization implementation frontend/src/history.ts	Imports canAccess and updates canCancelPendingRow to grant cancellation when canAccess('admin','*'), canAccess('cancel-any','purchases'), or (canAccess('cancel-own','purchases') and created_by_user_id matches current user).
Permission-gating test matrix frontend/src/__tests__/history-cancel-permissions.test.ts	New test suite mocks history dependencies and verifies cancel button visibility across six scenarios: admin, cancel-any, cancel-own (own rows), cancel-own (other rows), no permission, and anonymous. Includes helpers for permission setup and row construction.
Existing test fixture updates frontend/src/__tests__/history-approve-button.test.ts, frontend/src/__tests__/history-cancel-button.test.ts	Regular-user fixtures updated to include effectivePermissions entries for purchase-related permissions (approve-own, cancel-own, retry-own) and history view permission.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• LeanerCloud/CUDly#145: Introduces the History inline Cancel RBAC (cancel-any/cancel-own) and corresponding cancel UI tests that align with this PR's authorization updates.
• LeanerCloud/CUDly#299: Introduces approve RBAC and history authorization model that this PR extends with cancel-specific permission checks using canAccess.

Poem

A rabbit hops through permissions neat,
Cancel buttons now gate with repeats—
Admin sweeps all, cancel-any too,
Cancel-own sees what they create, it's true! 🐰✨

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately reflects the main change: enabling the Cancel button for non-admin users with cancel permissions, directly addressing issue #158.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/158-wave11

---

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

[cristim]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

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.

[cristim]

@coderabbitai full review

[coderabbitai]

✅ Actions performed

Full review triggered.

[cristim]

Rebased on feat/multicloud-web-frontend to clear the merge conflict.

Conflict shape: frontend/src/history.ts import block + canCancelPendingRow body collided with the post-#917 base where canAccess shipped alongside isAdmin. Kept both imports because canApprovePendingRow and canRetryFailedRow (out of scope of #158) still call isAdmin(); the cancel-row predicate now uses the canAccess('admin', '*') || canAccess('cancel-any', 'purchases') || (canAccess('cancel-own', 'purchases') && created_by === user.id) shape from the original PR.

Test-fixture follow-up from the rebase: post-#917 canAccess only honors user.effectivePermissions (no role-string fallback). Updated the existing REG_USER fixture in history-cancel-button.test.ts and history-approve-button.test.ts to carry the default-user effective permission set (cancel-own / approve-own / retry-own / view-history on purchases); the new history-cancel-permissions.test.ts mocks the entire permissions module so it also exports isAdmin (else renderApprovalQueue throws on the isAdmin() call inside canApprovePendingRow and short-circuits the cancel-render assertions).

Full suite: 2228 passed / 0 failed / 1 skipped. tsc clean. Pre-commit clean.

No new CR findings to address (the prior CR pass was rate-limited and the re-trigger from 2026-05-30 produced no inline comments).

@coderabbitai full review

[coderabbitai]

@cristim: Triggering the full review. Thanks for the detailed rebase notes — the conflict shape and fixture follow-up are clear.

One housekeeping note: the long-term memory entry from PR #145 (learning ID a71448ae-56fd-47bd-963d-236b72987d83) recorded that adding cancel-any:purchases support to canCancelPendingRow was explicitly deferred and deemed out of scope. This PR implements exactly that deferred work, so the learning is now stale. Would you like me to remove it?

---

⛔ Learnings removed

Learnt from: cristim
Repo: LeanerCloud/CUDly PR: 145
File: frontend/src/history.ts:291-322
Timestamp: 2026-04-27T21:45:03.476Z
Learning: In `frontend/src/history.ts`, `canCancelPendingRow` intentionally does NOT mirror the backend `authorizeSessionCancel` for non-admin users holding `cancel-any:purchases`. This is a deliberate UX trade-off: no default role grants `cancel-any` (it is reserved for future operator roles), so the practical impact is zero today. Adding the check would require a `/me/permissions` round-trip and extending the `User` type to carry permissions — deemed out of scope. The backend `authorizeSessionCancel` in `internal/api/handler_purchases.go` remains the security boundary. If an operator role with `cancel-any:purchases` is introduced in the future, `canCancelPendingRow` and the `User` type should be extended accordingly.

---

🧠 Learnings used

Learnt from: cristim
Repo: LeanerCloud/CUDly PR: 0
File: :0-0
Timestamp: 2026-05-05T15:44:54.463Z
Learning: In the LeanerCloud/CUDly repository, when a CodeRabbit review flags something as "outside-diff" that was already implemented in an earlier commit of the same PR, it is likely a stale-snapshot artifact where the review diff was generated against a pre-fix view. The inline comment convention `(CR pass on PR #<number> Finding N)` is used by the maintainer (cristim) to mark lines that were changed in direct response to a prior CodeRabbit review pass.

---

Learnt from: cristim
Repo: LeanerCloud/CUDly PR: 145
File: frontend/src/history.ts:291-322
Timestamp: 2026-04-27T21:45:03.476Z
Learning: In `frontend/src/history.ts`, `canCancelPendingRow` intentionally does NOT mirror the backend `authorizeSessionCancel` for non-admin users holding `cancel-any:purchases`. This is a deliberate UX trade-off: no default role grants `cancel-any` (it is reserved for future operator roles), so the practical impact is zero today. Adding the check would require a `/me/permissions` round-trip and extending the `User` type to carry permissions — deemed out of scope. The backend `authorizeSessionCancel` in `internal/api/handler_purchases.go` remains the security boundary. If an operator role with `cancel-any:purchases` is introduced in the future, `canCancelPendingRow` and the `User` type should be extended accordingly.

✅ Action performed

Full review finished.