ContentCreatorVisibleXbConfigEntityAccessControlHandler bypasses admin permissions for view

Nice find!

Indicates missing test coverage though 😅

📌 Add access control for "code components" and "asset libraries", special case: instantiated code components must be accessible to *all* Active added this.

Does this duplicate 🐛 XbConfigEntityHttpApiTest Active or just would have been found by it.

🐛 XbConfigEntityHttpApiTest Active is in. That makes it easier to adjust the tests here, which should then nicely visualize what exactly has changed.

I'll work on this if Matt doesn't beat me to it.

wim leers → credited mayur-sose → .

The same bug was just reported by @mayur-sose at #3509333-9: [PP-1] After an error it’s possible to get trapped in an unrecoverable error state → .

We will benefit from having a Functional test, but tbh the unit test showed the misunderstanding (even in the test name).

@wim.leers That's a different error not affected by this. Will comment there.

Exposing code components even when disabled if we have access means that we also will expose unpublished asset libraries.

Which showed us that our openapi schema for the assets listing was wrong, and untested.

(I don't think this needs extra test coverage as we had a) unit test, b) XbConfigEntityHttpApiTest functional test already)

AFAICT this is updating the wrong access control handler, because the issue summary is a bit inaccurate.

And given I probed 🐛 After an error it’s possible to get trapped in an unrecoverable error state Active that 🐛 After an error it’s possible to get trapped in an unrecoverable error state Active is not related to permissions but client-side navigation, I'm not sure what needs to be done here then.

Can we add steps to reproduce to the IS?

Updated/expanded the MR with our actual test expectations for assets and patterns.