Answered Editor User Group - View Published permission not working

I feel like this one haunts me.

Have created an Editors User Group:

One user so far in the group with Role: Editor - 10
Context Access:
mgr | Editor - 10 | Access Policy: AdminEditor (custom)
web | Member - 9999 | Load, List, View
Resource Group Access:
Editors | Member - 9999 | Load, List, View | web
Editors | Member - 9999 | Resource | mgr

Access Policy AdminEditor: (here are all the permissions related to resources given to this access policy)
edit_document | yes
new_document | yes
new_doc_in_root | yes
publish_document | yes
resource_duplicate | yes
resource_quick_create | yes
resource_quick_update | yes
resource_tree | yes
tree_show_resource_ids | yes
undelete_document | yes
unpublish_document | yes
view_document | yes
view_unpublished | yes

The editor user can view, edit, save, publish, unpublish resources in the manager. Just can't preview the unpublished resources, so I'm guessing this has something to do with a web context policy... but don't know what to change.

There are no resources in the Editors Resource Group - that group was made automatically when the Editors user group was created.

MODX 2.3.6 at MODX Cloud.

That all looks right to me. Did you flush all permissions and settings after setting it up?

A few times, and in fact I upgraded the site from 2.3.5 to 2.3.6 hoping that would help, but hasn't. Could it have something to do with roles? I just don't get roles, honestly.

Roles are almost meaningless in Revo. I give everyone but the super user the same role.

The point of roles is so that you can have different users in the same group who have different capabilities (policies). It's much easier and less complicated, imo, to just put the users in different groups so everyone in a given group has the same rights. Once you do that, roles become truly meaningless as long as all users meet the minimum role for each group they're in.

I think I may see what your problem is. Your AdminEditor Policy is missing load, list, and view. It those were there, I don't think you'd need the third Context Access ACL entry.

The ACL entry for the web context you wondered about is necessary. Without it, the users won't see any web-context resources in the tree in the Manager.