Skip to content
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

Chrome: Hide Sidebar Panels if the user don't have the right capabilities #2585

Merged
merged 2 commits into from
Sep 6, 2017

Conversation

youknowriad
Copy link
Contributor

If the user doesn't have the "publish_posts" capability (a contributor), several panel sidebars should be hidden.

In this PR I'm hiding the "pending" toggle, the "schedule" panel and the post visibility is not editable. (similar to the current editor)

@youknowriad youknowriad added the General Interface Parts of the UI which don't fall neatly under other labels. label Aug 29, 2017
@youknowriad youknowriad self-assigned this Aug 29, 2017
@youknowriad youknowriad requested a review from aduth August 29, 2017 09:45
@codecov
Copy link

codecov bot commented Aug 29, 2017

Codecov Report

Merging #2585 into master will increase coverage by 1.21%.
The diff coverage is 63.33%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2585      +/-   ##
==========================================
+ Coverage   31.42%   32.63%   +1.21%     
==========================================
  Files         177      178       +1     
  Lines        5407     5531     +124     
  Branches      946      959      +13     
==========================================
+ Hits         1699     1805     +106     
- Misses       3135     3150      +15     
- Partials      573      576       +3
Impacted Files Coverage Δ
editor/sidebar/post-status/index.js 0% <0%> (ø) ⬆️
editor/sidebar/post-author/index.js 85% <100%> (ø) ⬆️
editor/sidebar/post-pending-status/index.js 58.33% <58.33%> (ø)
editor/sidebar/post-visibility/index.js 46.15% <83.33%> (+46.15%) ⬆️
editor/sidebar/post-schedule/index.js 65% <83.33%> (+65%) ⬆️
blocks/library/latest-posts/index.js 7.4% <0%> (-2.6%) ⬇️
editor/sidebar/post-schedule/clock.js 0% <0%> (ø) ⬆️
blocks/api/registration.js 100% <0%> (ø) ⬆️
...ebar/post-taxonomies/hierarchical-term-selector.js 0% <0%> (ø) ⬆️
... and 8 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5885233...40accca. Read the comment docs.

@youknowriad youknowriad requested review from mtias and ellatrix August 31, 2017 10:07
@youknowriad youknowriad force-pushed the fix/panels-visibility branch from 5b6569b to 6e56d7b Compare August 31, 2017 10:09
Copy link
Member

@aduth aduth left a comment

Choose a reason for hiding this comment

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

Nice 👍

One issue, which I expect is present on master, is that the author dropdown does not show (correctly) for contributor role, but only because it attempts to make the API request for users and fails. Up to you if you'd like to address that here or separately.

@youknowriad
Copy link
Contributor Author

One issue, which I expect is present on master, is that the author dropdown does not show (correctly) for contributor role

Do you mean, instead of relying on the available users, we should rely on the capabilities?

@youknowriad
Copy link
Contributor Author

youknowriad commented Sep 4, 2017

@aduth I went ahead and updated to add the capability check. but the API request is still being fetched, because it's declared on the same withAPIData HoC. I don't know if we want to create another inner component just to avoid this failing request. An alternative could be to pass the dataProps to the mapPropsToData callback, this way we could decide to include an API call depending on the previous result of another API call. This could be something to try separately;

@youknowriad youknowriad merged commit 1251c92 into master Sep 6, 2017
@youknowriad youknowriad deleted the fix/panels-visibility branch September 6, 2017 08:10
@aduth
Copy link
Member

aduth commented Sep 6, 2017

Yeah, either of those seem worth exploring. There should ideally be no 403 requests issued if we know they can be avoided.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
General Interface Parts of the UI which don't fall neatly under other labels.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants