Add permission for "Use Experience Builder"

Post-poned on ✨ Allow working with a new (unsaved) entity Active

🤔 Shouldn't this be the other way around, i.e. this before #3529836? Because of:

Should this permission apply to every XB route?

Devil's advocate: why this permission? Only for #3529836? It's not one of the permissions @lauriii prescribed?

I doubted to be honest. But without #3529836 this will be hard to write tests for, while #3529836 can still use 'access administration pages' as we are doing now.

Why a new permission? Because we could use "Create Pages (for Page content entities)", but we might have XB enabled for other content entities and a user might not have permission to create pages but to edit e.g. articles. And I'm assuming here that the XB UI will be able to create any enabled XB content type from blank.

An alternative is another route access check that checks if I have permissions for any XB-enabled content.

An alternative is another route access check that checks if I have permissions for any XB-enabled content.

This will be probably the solution we will go for, so changed the title + IS

wim leers → credited effulgentsia → .

I think we have an alternative solution for #4 over at #3529836-7: Enable starting with an empty XB UI (so without first having to create an entity with a component tree) → 😊

I'm pretty sure @lauriii specifically wanted to AVOID this kind of permission.

So then this is the generalization of #3529836-7: Enable starting with an empty XB UI (so without first having to create an entity with a component tree) → , for much later!

@penyaskito's work at 📌 Provide the client with permissions flags for create content Active inspired me and made me realize a connection: the \Drupal\Core\Entity\EntityFieldManagerInterface::getFieldMapByFieldType()-based logic he wrote for \Drupal\experience_builder\Controller\ExperienceBuilderController::getContentEntityCreateOperations() is what ✨ Allow working with a new (unsaved) entity Active needs as the long-term solution, rather than the pragmatic interim linked in #7.

Combine the pattern of #3529895 with the logic in ComponentTreeEditAccessCheck (from 📌 [PP-1] Update `experience_builder.(experience_builder|api.layout.get) routes` to respect content entity update/field edit access of edited XB field Active ), and I think we have a solution!

Response for /xb/api/v0/config/component when accessing as not just the anonymous user, but also an authenticated user that for example can only edit Media entities, but not Pages nor article nodes:

{
  "errors": [
    "Requires >=1 content entity type with an XB field that can be created or edited."
  ]
}

@Wim at #8: This is exactly what I was envisioning in #3452581-54: [META] XB Permissions → !!!

Hah! 😄 Great minds … 🥸

penyaskito → credited larowlan → .

Note that while reviewing 🐛 Entity saved with autosaved data is not respected Active , I noticed this MR should also update

experience_builder.api.content.list:
  path: '/xb/api/v0/content/{entity_type}'
  defaults:
    _controller: 'Drupal\experience_builder\Controller\ApiContentControllers::list'
  requirements:
    _permission: 'edit xb_page'
  methods: [GET]
  options:
    _format: 'json'

Because

    _permission: 'edit xb_page'

makes no sense — it was a useful interim step, but what this issue is doing is more appropriate :)

Discussed with @effulgentsia and @penyaskito — @effulgentsia agrees this should be beta-blocking.

Assuming the last failure is a cypress random failure, which I'm retrying, this should be ready for review.

Maybe I'm missing something, but these changes don't quite make sense to me? 😅

Needs reroll after 🐛 PHPUnit Next Major tests failing Active 🙏

working on the reroll

Reroll done.

@penyaskito is working to address https://git.drupalcode.org/project/experience_builder/-/merge_requests/1... 👍

Fixed logic.

          // Grant access if the current user can:
          // 1. create such a content entity (and set the XB field)
          // 2. edit such a content entity (and update the XB field)
          // 3. edit code components, as there might a "component developer role"

There is one cypress test that requires the permission to pass, but I can't reproduce locally (but test fails locally too).

Looks good to me, found one minor nit and self-addressed it.

Just triaged #3533461 and found it to be blocked on this: #3533461-5: [PP-1] Only users with "edit" operation access to code components can see previews with auto-saved code components → .

Found only one problem: half a dozen remaining occurrences of the access administration pages permission. Refactored them all away. Was trivial thanks to the infrastructure (and examples!) in this MR 😊👍

Got navigation.cy.js to green — it had previously implicitly (and inappropriately) been relying on the access administration pages permission, simply to use /admin/config as the "last visited URL" for the "Exit XB" functionality.

Merging at last… 🚢🥳