Only users with "edit" operation access to code components can see previews with auto-saved code components

"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.

This title is very misleading 😅😬

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

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 currently the same as if they have permission to use XB's page builder at all), 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 #3529924: Add access check for using Experience Builder at all: if >=1 content entity type with an XB field can be created or edited. 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 #3508694: Permissions for XB config entity types, 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 #3529924: Add access check for using Experience Builder at all: if >=1 content entity type with an XB field can be created or edited. 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 #3529924: Add access check for using Experience Builder at all: if >=1 content entity type with an XB field can be created or edited.'s lands.

#3529924: Add access check for using Experience Builder at all: if >=1 content entity type with an XB field can be created or edited. 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? 🤞