Permissions for XB Page content entities: edit/delete/create, reuse core's `access content` for viewing

Per @lauriii, we're actually indeed going to skip ownership permissions as indicated as a maybe (We can decide to skip any/own and ignore ownership permissions.). @lauriii specifically listed these 4:

1. View Pages (view xb_page)
2. Edit Pages (edit xb_page)
3. Delete Pages (delete xb_page)
4. Create Pages (create xb_page)

AFAICT this means @lauriii also intends us to remove HEAD's administer xb_page permission.

@lauriii to confirm

1. Am I extrapolating correctly that you think permissions should be as simple as possible, and hence we should refactor away the administer xb_page permission in this issue?
   Impact: either a "catch-all" admin permission for the Page content entity type or not. Having such an admin permission brings some mental model complexity.
2. Do we indeed want to add View Pages (view xb_page) instead of relying on access content? That permission used to be Node-specific, but has since been kind of generalized:
   

   # Note that the 'access content' permission is moved to the Node section of the
   # permission form when the Node module is enabled.
   access content:
     title: 'View published content'
   

   — system.permissions.yml
   Impact: an additional permission must be enabled for XB's landing pages to be viewable by anonymous users; the access content permission is already typically assigned because it us used for: viewing nodes, viewing public:// files, file upload progress, and more.

Am I extrapolating correctly that you think permissions should be as simple as possible, and hence we should refactor away the administer xb_page permission in this issue?

Yes, we should keep the permissions as simple as we can at this point. We can keep adding more permissions as we add more functionality. We should avoid adding permissions which we don't have a clear use case for since they are pretty hard to remove later on.

I noticed that the administer xb_page permission isn't used for anything at the moment, and I also couldn't think of anything that we should move behind that permission at the moment. We will have to introduce this permission later, once we have page entity specific configurations in the UI.

Do we indeed want to add View Pages (view xb_page) instead of relying on access content? That permission used to be Node-specific, but has since been kind of generalized:

I agree that we should rely on the generic access content permission. I simply did not know that #2892821: Core modules check node module's "access content" permission for displaying things that have nothing to do with nodes had happened because the permission is still listed under Node. 🤯

Perfect, incorporated 👍

Note: this means the Page content entity type will NOT use the node module's access content.

I think this is wrong in issue summary as we are using it, but it's provided by the system module.

You're right — I failed to remove this in #11 — my bad! 😅

Otherwise users will need to have edit, create, and delete instead of one permission.
[…] Removing this makes the granular permissions more complicated.

I don't see how granting all 3 permissions is more complicated than granting a single "administer" permission? In fact, this is one of those things where Drupal's been historically misleading, because it has no way of conveying to the site administrator that "administer" really means "edit+create+delete".

You wrote it's "normal", but I'd argue it's a Drupalism that is not worth perpetuating? 😅

IOW: I agree with @lauriii's preference for both the simplicity (no "administer" permission) and the explicitness.

We're not providing upgrade paths for XB currently, so it'd be fine to change this without an upgrade path.

We're not providing upgrade paths for XB currently, so it'd be fine to change this without an upgrade path.

Indeed. While XB is in alpha, we don't provide this.

I think I've finished the new permissions, replace administer xb_page by access content , create xb_page , edit xb_page and delete xb_page.

What I've done is adapt the permissions and review the tests that were already done, by maybe is something else needed to do.

Nice!
Some of my comments need @Wim confirmation, but there are some actionable already.

Nice to see this moving forward! 😄

Some tests are failing

🏓 Another review round. Found a number of problems, including changes that belong on #3516432: Update all XB routes to respect content entity update/field edit access of edited XB field and #3494915: Support entity-level + field-level access checking in auto-save — i.e. in `experience_builder.api.api.(layout.post|auto-save.post)`.

@lauriii clarified his stance on the collection_permission and how that should change. This needs to be reflected in the issue summary.

🏓

As the owner of the Page content entity type, I'd like @mglaman to explicitly approve 😊

Thank you @isholgueras for pushing this over the finish line! 👏 🎉