Editors don't see Site Pages menu item

[malinajirka]

Expected behavior

User in Editor role can see and edit site pages.

Actual behavior

"Site Pages" menu item is not displayed for users in Editor role.

Steps to reproduce the behavior

1. Create a self-hosted site
2. Add a new user with Editor role
3. Log into the app using the self-hosted log in
4. Open My Site
5. Notice "Site Pages" menu item is missing

#3373718-zen

[davidlevinwork]

Hi
I would like to help with this issue..
Just to be sure - you want to create "Site Pages" menu as a new button in this page?

[malinajirka]

Hello @davidlevinwork! Your willingness to contribute is very much appreciated ;)!

The "Site Pages" button already exists and works as expected in most scenarios. However, it's not being shown on self-hosted sites when the user has "Editor" role. I think we'll need to modify this condition. hasCapabilityEditPages is always false for all self-hosted sites (the flag works only for .com sites). We'll need to somehow derive if the user has the required permission, but I'm not sure how (or if it's even feasible). This task will require some initial investigation before we implement the final solution - which will most probably be just a change in the condition.

Let us know if you want to look into it or if you'd rather pick a more implementation-focused task ;).

[malinajirka]

Few more notes about the issue:
The menu item is visible on iOS and the user can edit pages. However, it seems that the menu item is always shown on ios -> there aren't any conditions which would hide it (link).

1. We might want to try to access the site in "Contributor" role on iOS and check if the item is still visible and if the user can edit the page. They shouldn't be allowed to do that.
2. If they are not allowed to make changes as "Contributors", but they are allowed to make changes as "Editors", we can just copy the same logic from iOS to Android.

I haven't dived deeper into this issue, I'll leave it to whoever will pick up this task.

[designsimply]

Closed #13056 as a duplicate even though it was created first since this issue already has a bit more technical discussion and detail in the comments! /hat tip @reginabally ❤️

Note: it's also worth considering the FAB button, which should have an option to add a page if that is allowed by the role, i.e. for editors but not authors.

I tested whether or not I could see the Pages option while logged in from various roles (administrator, editor, author, contributor, subscriber) using WPAndroid 15.9-rc-1 and I found that the Pages option does not appear for the author, contributor, or subscriber roles which is the expected behavior.

I also found that I could access the option to create posts while logged in as either a contributor or a subscriber but an error displayed after trying to add a post as either of those roles (screenshots). A contributor should be able to create a post but it should default to pending status and not be published until it is approved. A subscriber should be read-only and not be allowed to create a post or a page.

See https://wordpress.org/support/article/roles-and-capabilities/ for more information about WordPress roles and capabilities.

[zwarm]

I researched this issue during maintenance rotation and discovered the following:

A recent iOS issue requested that iOS change their logic to match Android (implemented in this PR).

This issue suggests that Android check iOS and follow their implementation (prior to their change above).

It seems like we are at a crossroads as to which implementation should prevail, but for now both platforms behave the same way.

[antonis]

I researched this a bit as part of the maintenance rotation. The implementation has been refactored and now the logic for showing the page edit or create option resides mainly in the following two functions:

• hasFullAccessToContent
• buildPagesItemIfAvailable

In both cases the requirement is Admin access to the self hosted site.

It seems like we are at a crossroads as to which implementation should prevail, but for now both platforms behave the same way.

Given that the implementations are in sync and that getting the correct options for self-hosted sites might not be trivial/if feasible I was thinking that maybe we could drop this issue or remove it from the prioritised Maintenance week board.

@zwarm Since you also touched this recently do you agree with closing the issue?