New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

`wp user remove-cap` incorrectly returns success status when attempting to remove cap inherited from a role #97

Closed
johnbillion opened this Issue Oct 6, 2017 · 5 comments

Comments

4 participants
@johnbillion
Contributor

johnbillion commented Oct 6, 2017

Given a user with a role of Editor, running wp user remove-cap publish_posts <user> will incorrectly show a success message stating that the capability has been removed.

Attempting to remove any capability which is not directly assigned to the user (most capabilities are inherited from the user's role) will incorrectly result in a success message.

@danielbachhuber danielbachhuber added the bug label Oct 6, 2017

@danielbachhuber

This comment has been minimized.

Show comment
Hide comment
@danielbachhuber

danielbachhuber Oct 6, 2017

Member

Thanks for the report, @johnbillion. What would your expected behavior (and message) be in this case?

Member

danielbachhuber commented Oct 6, 2017

Thanks for the report, @johnbillion. What would your expected behavior (and message) be in this case?

@johnbillion

This comment has been minimized.

Show comment
Hide comment
@johnbillion

johnbillion Oct 6, 2017

Contributor

I think the expected behaviour in this case is to return an error. The best way to phrase it might be to say that the capability cannot be removed from the user because it's inherited from the user's role.

Contributor

johnbillion commented Oct 6, 2017

I think the expected behaviour in this case is to return an error. The best way to phrase it might be to say that the capability cannot be removed from the user because it's inherited from the user's role.

@johnbillion

This comment has been minimized.

Show comment
Hide comment
@johnbillion

johnbillion Oct 6, 2017

Contributor

Alternatively: This could add the capability with a value of false, which explicitly denies the capability for the user, overriding their role (AFAIK, I'll need to triple check this). Or that could result in even more unexpected behaviour. Could be an option via a flag, eg --force-deny?

Contributor

johnbillion commented Oct 6, 2017

Alternatively: This could add the capability with a value of false, which explicitly denies the capability for the user, overriding their role (AFAIK, I'll need to triple check this). Or that could result in even more unexpected behaviour. Could be an option via a flag, eg --force-deny?

@danielbachhuber

This comment has been minimized.

Show comment
Hide comment
@danielbachhuber

danielbachhuber Dec 4, 2017

Member

I think it makes more sense to return an error here, instead of introducing new behavior.

Member

danielbachhuber commented Dec 4, 2017

I think it makes more sense to return an error here, instead of introducing new behavior.

@schlessera

This comment has been minimized.

Show comment
Hide comment
@schlessera

schlessera Dec 5, 2017

Member

I agree, an error makes more sense. Adding a wp user override-cap is still an option for the second proposed behavior.

Member

schlessera commented Dec 5, 2017

I agree, an error makes more sense. Adding a wp user override-cap is still an option for the second proposed behavior.

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