Skip to content

test(token): cover multi-role assignment to a single address - #825

Closed
davidugorji wants to merge 1 commit into
BCPathway:mainfrom
davidugorji:test/759-multi-role-assignment
Closed

test(token): cover multi-role assignment to a single address#825
davidugorji wants to merge 1 commit into
BCPathway:mainfrom
davidugorji:test/759-multi-role-assignment

Conversation

@davidugorji

Copy link
Copy Markdown
Contributor

Adds integration coverage for one address holding several roles at once, exercised through the token contract rather than asserted at the storage layer alone.

Role membership is a single per-address bitmask under AdminKey::RoleMask, so granting a second role is a bitwise OR onto the existing mask. The tests grant Minter | Pauser to one address and then execute a real mint and a real pause from it.

Covers: both roles held simultaneously in one mask entry; mint + pause + verified transfer halt + unpause from that address; exercising one role not disturbing the other; clearing one bit leaving the other enforced; single-role addresses unable to exercise the other role; per-address isolation; and a no-role address able to do neither.

Verification: 7/7 new tests pass, full token suite green (46 + 7 + 6, no regressions), cargo fmt --all -- --check and cargo clippy --all-targets --all-features -- -D warnings both clean.

Note: PR #643 covers related ground via fuzz tests in contracts/admin/src/fuzz_roles.rs (issue #484). This is a token-level integration test in a separate file, so the two do not conflict.

Closes #759

@drips-wave

drips-wave Bot commented Aug 26, 2026

Copy link
Copy Markdown

@davidugorji Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

Adds integration coverage for one address holding several roles at once,
exercised through the token contract rather than asserted at the storage
layer alone.

Role membership is a single per-address bitmask under AdminKey::RoleMask,
so granting a second role is a bitwise OR onto the existing mask. The
tests grant Minter | Pauser to one address and then execute a real mint
and a real pause from it, which is the behaviour the bitmask layout is
supposed to make possible.

Coverage:

- both roles are held simultaneously and share one mask entry, while
  never-granted roles stay absent
- the address mints, pauses, is confirmed to have actually halted
  transfers, and unpauses
- exercising one role does not consume or disturb the other
- clearing one bit leaves the other role held and enforced, and the
  cleared role is genuinely rejected
- an address holding only one of the two roles cannot exercise the other
- assignments are isolated per address and do not leak to a bystander
- an address with no roles can neither mint nor pause

The setup writes the RoleMask entry directly, matching how grant_role
persists a combined assignment, so the tests exercise the bitmask path
rather than the superseded per-role legacy keys.

Closes BCPathway#759
@davidugorji
davidugorji force-pushed the test/759-multi-role-assignment branch from c433faa to 0a4600c Compare August 26, 2026 15:24
@davidugorji

Copy link
Copy Markdown
Contributor Author

Superseded by #829, which bundles all four issues (#699, #700, #701, #759) into a single PR. Closing in favour of that one.

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.

[Testing] Integration: Multi-role assignment to single address

1 participant