Provide granular permissions for pages

Our team has an upcoming ticket for this.

Per @lauriii, we're actually indeed going to skip ownership permissions as indicated as a maybe (). @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?
2. Do we indeed want to add 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
   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. 🤯

We should keep administer pages and follow normal permission patterns. Otherwise users will need to have edit, create, and delete instead of one permission.

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.

It is. It is the edit/create/delete permission. Removing this makes the granular permissions more complicated. Someone may want authors to have full permissions whereas some may only want create/edit but no delete.

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.

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.

+1 I'm okay with removing administer, we just need an upgrade path for adjusting on existing sites. Or are we going to just let end users handle that if they've decided to long-term run XB?

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