Skip to content

Add a _canCancel function to improve granularity and allow roleAdminId to cancel the grant and revoke functions#6573

Open
Amxx wants to merge 1 commit into
OpenZeppelin:masterfrom
Amxx:access-manager/_canCancel
Open

Add a _canCancel function to improve granularity and allow roleAdminId to cancel the grant and revoke functions#6573
Amxx wants to merge 1 commit into
OpenZeppelin:masterfrom
Amxx:access-manager/_canCancel

Conversation

@Amxx

@Amxx Amxx commented Jun 1, 2026

Copy link
Copy Markdown
Collaborator

Fixes pM-01

PR Checklist

  • Tests
  • Documentation
  • Changeset entry (run npx changeset add)

@Amxx Amxx requested a review from ernestognw June 1, 2026 09:09
@Amxx Amxx requested a review from a team as a code owner June 1, 2026 09:09
@changeset-bot

changeset-bot Bot commented Jun 1, 2026

Copy link
Copy Markdown

⚠️ No Changeset found

Latest commit: dd060e8

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@coderabbitai

coderabbitai Bot commented Jun 1, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Walkthrough

This PR refactors the authorization logic in the cancel() function by extracting permission checks into a new internal _canCancel() helper. The cancel() function now delegates to this helper instead of performing inline authorization checks. The new _canCancel() function implements centralized logic that allows cancellation by the original caller, by admins, or by guardians of the target function's role, with special handling for calls targeting the AccessManager itself on admin-restricted functions.

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately describes the main change: introducing a _canCancel function to enhance access control granularity for canceling grant and revoke operations.
Description check ✅ Passed The description references the fix to pM-01 and mentions the _canCancel function implementation, relating it to the changeset.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
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 unit tests (beta)
  • Create PR with unit tests

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

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@contracts/access/manager/AccessManager.sol`:
- Around line 737-744: The inline comment above the cancellation check is
misleading: it says callers must be "guardian of the required role" but the code
uses hasRole(roleId, msgsender) (via _getAdminRestrictions and getRoleAdmin) to
check membership, not guardianship, and skips ADMIN_ROLE; update the comment in
AccessManager to accurately state that for calls targeting this contract the
code checks whether msgsender is a member of the admin role returned by
_getAdminRestrictions (and that ADMIN_ROLE is already checked/skipped) rather
than claiming it verifies guardian status.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: c4633ab5-456e-465f-b260-2850daca231f

📥 Commits

Reviewing files that changed from the base of the PR and between 74edc4b and dd060e8.

📒 Files selected for processing (1)
  • contracts/access/manager/AccessManager.sol

Comment on lines +737 to +744
// if the target of the call is this AccessManager and the call data matches an admin-restricted function, then the caller needs to be a guardian of the required role to cancel.
if (target == address(this)) {
(bool adminRestricted, uint64 roleId, ) = _getAdminRestrictions(data);
// Note: ADMIN_ROLE was already checked and can be skipped.
if (adminRestricted && roleId != ADMIN_ROLE) {
(bool inRole, ) = hasRole(roleId, msgsender);
return inRole;
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Comment does not match the actual logic.

The comment states "the caller needs to be a guardian of the required role to cancel", but the code checks role membership via hasRole(roleId, msgsender), not guardianship. For grantRole/revokeRole operations, roleId is getRoleAdmin(roleId) from _getAdminRestrictions, so this allows members of the admin role to cancel, which aligns with the PR objective but contradicts the comment.

📝 Suggested comment fix
-        // if the target of the call is this AccessManager and the call data matches an admin-restricted function, then the caller needs to be a guardian of the required role to cancel.
+        // if the target of the call is this AccessManager and the call data matches an admin-restricted function, then the caller needs to be a member of the required role to cancel.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@contracts/access/manager/AccessManager.sol` around lines 737 - 744, The
inline comment above the cancellation check is misleading: it says callers must
be "guardian of the required role" but the code uses hasRole(roleId, msgsender)
(via _getAdminRestrictions and getRoleAdmin) to check membership, not
guardianship, and skips ADMIN_ROLE; update the comment in AccessManager to
accurately state that for calls targeting this contract the code checks whether
msgsender is a member of the admin role returned by _getAdminRestrictions (and
that ADMIN_ROLE is already checked/skipped) rather than claiming it verifies
guardian status.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant