Users with lesser permissions cannot preview a page

"view" as the entity operation makes sense, but I think if we do that, we need to also make sure that the access handler uses a permission like "view unpublished" or "view latest version" (see Content Moderation for reference) if the entity is the one that's in auto-save.

The problematic entities were config entities which don't support revisions. Not the actual entity being edited itself. I don't know if this effects regular conponen config for SDCs

Flagging for tests. There must be existing tests that have missing coverage.

This title is very misleading 😅😬

This was introduced in 📌 Code Components should render with their auto-saved state(if any) when rendered in the XB UI Active .

So I went to investigate how we agreed this was supposed to work: when should code components load their auto-saved vs live CSS+JS code? 🕵️

I wrote ~4 months ago at #3500386-35: Code Components should render with their auto-saved state (if any) when rendered in the XB UI → :

should not only only apply to that route, but also only to users who have sufficient permissions: if they lack the administer code components permission, they should not be able to see draft (auto-saved) states of edited code components.
I think that can become a third MR here.

Which @effulgentsia disagreed with at #3500386-38: Code Components should render with their auto-saved state (if any) when rendered in the XB UI → :

I don't think that's correct. If they have permission to use the code component within XB's page builder (if we don't yet have granular permissions for this, this is ), then they should see what their component instance looks like in their content, using the draft state of the JS and CSS.

The underline (added by me) is what 📌 Add permission for "Use Experience Builder" Active is about to land! 🥳

We then agreed at #3500386-39: Code Components should render with their auto-saved state (if any) when rendered in the XB UI → to do this in 📌 Add access control for "code components" and "asset libraries", special case: instantiated code components must be accessible to *all* Active , but we never did — or rather: in #3508694 we did change the route requirement for the routes discussed here like so:

  requirements:
    _permission: 'administer code components'
    _xb_http_eligible_config_entity: 'TRUE'
    _entity_access: 'xb_config_entity.edit'

So … once 📌 Add access control for "code components" and "asset libraries", special case: instantiated code components must be accessible to *all* Active lands, this should become trivial to support :)

Pushed solution. Test coverage should be trivial to add in \Drupal\Tests\experience_builder\Functional\AssetLibraryAttachmentTest::test().

Note that the MR will fail until 📌 Add permission for "Use Experience Builder" Active 's lands.

📌 Add permission for "Use Experience Builder" Active just landed 🥳

Test-only CI job failed 👍

Reviewing in-depth…

See https://git.drupalcode.org/project/experience_builder/-/merge_requests/1... — now you can review to see if it all makes (hopefully MUCH) more sense? 🤞

Automatically closed - issue fixed for 2 weeks with no activity.