[dhrupo]

Fixes #88

wp role create <role-key> <role-name> --clone=<role> grants every capability of the source role, including the ones the source role explicitly denies:

$ wp cap add author spectate --grant=false
$ wp role create reporter Reporter --clone=author
$ wp cap list reporter --show-grant
upload_files,true
edit_posts,true
edit_published_posts,true
publish_posts,true
read,true
level_2,true
level_1,true
level_0,true
delete_posts,true
delete_published_posts,true
spectate,true

create() keeps only array_keys( $role_obj->capabilities ) and then calls add_cap( $cap ) for each key. add_cap() defaults $grant to true, so a denied capability on the source role becomes a granted one on the clone.

create() now passes the source role's full capabilities array, with its grant values, to add_role( $role_key, $role_name, $capabilities ) and drops the add_cap() loop. The success messages and the order of the cloned capabilities stay the same. Creating a role without --clone still passes an empty array, which is the add_role() default.

Testing

Adds a scenario to features/roles.feature, after "Cloning a role". It denies spectate on author, clones author into reporter, and checks that wp cap list reporter --show-grant lists spectate,false and still lists upload_files,true.

• Without the fix, the scenario fails because wp cap list reporter --show-grant lists spectate,true (WordPress 7.1.4, MySQL 8.4).
• With the fix, features/roles.feature (5 scenarios) and features/cap.feature (1 scenario) pass on WordPress 7.1.4, MySQL 8.4.
• PHPCS passes on src/Role_Command.php. The linter, Gherkin lint and PHPStan pass.

AI assistance: I used Claude Code to find this and write the change; I reviewed and ran everything myself.

Summary by CodeRabbit

• Bug Fixes
  • Cloned roles now retain both allowed and explicitly denied capabilities. For example, a cloned role can continue to grant file uploads while denying spectating. This keeps the cloned role’s permissions consistent with the source role.

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

Role cloning now passes the source role’s full capability map to add_role(). A feature scenario checks that the clone preserves a denied spectate capability and a granted upload_files capability.

Changes: Role cloning

Layer / File(s)	Summary
Pass and verify cloned capability grants src/Role_Command.php, features/roles.feature	create() passes the source role’s full capability map to add_role(). The new scenario checks that the cloned role denies spectate and grants upload_files.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Medium

Suggested reviewers: danielbachhuber, swissspidy, ernilambar

Merge Risk: Minimal · up to a1f58

The cloning change and its feature scenario address preservation of denied capabilities. No merge-blocking issue is identified.

Pre-merge checks: 5

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title "Keep denied capabilities when cloning a role" matches the main change. The raw summary says Role_Command::create() now passes the source role's full capabilities map to add_role() when --cl…
Linked Issues check		Issue #88 requires that wp role create --clone keep the source role's grant values, so a capability denied on the source stays denied on the clone (expected spectate,false). Code evidence at head…
Out of Scope Changes check		The whole-PR diff against the merge base changes two files: - src/Role_Command.php: the create() clone path only. It is the fix that #88 requests. - features/roles.feature: one new scenario, "Cl…
Docstring Coverage		Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentat…

Full details: Title check

Explanation

The title "Keep denied capabilities when cloning a role" matches the main change. The raw summary says Role_Command::create() now passes the source role's full capabilities map to add_role() when --clone is used, instead of adding each capability as granted. The linked issue #88 asks that clones keep denied capabilities such as spectate, and the added feature scenario checks this behavior. The title is specific and concise, and it names the behavior the change fixes.

Full details: Linked Issues check

Explanation

Issue #88 requires that wp role create --clone keep the source role's grant values, so a capability denied on the source stays denied on the clone (expected spectate,false).

Code evidence at head (src/Role_Command.php, create()):

• $capabilities now holds the source role's full capabilities map ($capabilities = $role_obj->capabilities;), not array_keys() of it.
• The map is passed to add_role( $role_key, $role_name, $capabilities ). WordPress stores this array as given, so false grant values are kept.
• The per-capability add_cap() loop, which defaulted $grant to true, is removed.
• Without --clone, $capabilities is array(), so the default path is unchanged. The missing-source error and the success messages are unchanged.

Test evidence at head (features/roles.feature, scenario "Cloning a role keeps denied capabilities denied"): it runs wp cap add author spectate --grant=false, clones author into reporter, and checks that wp cap list reporter --show-grant contains spectate,false and upload_files,true, and does not contain spectate,true. This matches the reproduction in #88.

Limitation: I could not read the text diff of features/roles.feature because the changed blobs were missing from the checkout. I read the file at head instead. The test runs claimed in the PR description were not verified by this review.

Full details: Out of Scope Changes check

Explanation

The whole-PR diff against the merge base changes two files:

• src/Role_Command.php: the create() clone path only. It is the fix that #88 requests.
• features/roles.feature: one new scenario, "Cloning a role keeps denied capabilities denied". It is the regression test for #88.

The existing scenarios in the feature file are unchanged, and the existing "Cloning a role" success message still matches the new code path. No unrelated changes were found in the reviewed content.

Limitation: the feature-file diff could not be read directly. The scenario presence and the rest of the file were confirmed by reading the file at head. The +22/-0 change size from the summary is consistent with a single added scenario.

Full details: Docstring Coverage

Explanation

Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 1 functions across 1 files. (1 skipped: 1 unsupported.)

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn

Recent review info

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: de26e8cd-d5cd-4d08-b32a-964560f5aee6

Commits

Reviewing files that changed from the base of the PR and between cef6d14 and a1f5893.

Files selected for processing: 2

• features/roles.feature
• src/Role_Command.php

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

[github-actions]

Hello! 👋

Thanks for opening this pull request! Please check out our contributing guidelines. We appreciate you taking the initiative to contribute to this project.

Contributing isn't limited to just code. We encourage you to contribute in the way that best fits your abilities, by writing tutorials, giving a demo at your local meetup, helping other users with their support questions, or revising our documentation.

Here are some useful Composer commands to get you started:

• composer install: Install dependencies.
• composer test: Run the full test suite.
• composer phpcs: Check for code style violations.
• composer phpcbf: Automatically fix code style violations.
• composer phpunit: Run unit tests.
• composer behat: Run behavior-driven tests.

To run a single Behat test, you can use the following command:

# Run all tests in a single file
composer behat features/some-feature.feature

# Run only a specific scenario (where 123 is the line number of the "Scenario:" title)
composer behat features/some-feature.feature:123

You can find a list of all available Behat steps in our handbook.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!