SdcController cleanup tasks

Thanks for the review!

• I think everybody would agree all of the things you listed should happen eventually.
• But they should not be required to happen now.

We need to be able to iterate quickly, without accumulating enormous MRs like we tend to do in Drupal core. In Drupal core this makes sense because it's already a consistent whole, but that's not yet true for Experience Builder.
In other words: for XB, we intentionally want to avoid the "every commit must be perfect" strategy that Drupal core uses.

I acknowledge this means outside participation is more difficult: what is in a "ready for detailed review" state vs "slapped together, don't bother to review" state? So I think that is the challenge we should solve rather than disallowing imperfect/incomplete MRs to be reviewed.

So I propose to introduce a way to convey this. Ideas:

1. an impossible to miss
   

   // ⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
   // ⚠️ 🔨🧹  This file is an early iteration. Do not review in detail yet.   🧹🔨 ⚠️
   // ⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
   

   at the top of the file

2. Issues like the one you created here make for excellent Novice tasks! 😊 So it's not like this is a wasted effort at all. Perhaps we should even intentionally call this out, by adding comments like // @todo Novice: inject service, // @todo Novice: introduce new permission, et cetera?
3. introduce src-rough (back end) and ui/src-rough (front end) directories
4. … something else?

Started adopting #4.1: https://git.drupalcode.org/project/experience_builder/-/merge_requests/2... 🤠

I'm going to update the issue summary to outline, to make this a great issue to sprint on at DrupalCon Barcelona :)

Nobody picked this up during DrupalCon. Narrowing scope. Removing dead routes should happen in 📌 Lift all methods out of `SdcController` into separate invokable services-as-controllers Needs work .

Still relevant!

Discussed this in detail with @lauriii. Converting this to a meta issue instead.

Refinements:

• Added: (as in: XB Component config entities)
• Put on hold, see issue summary for details.
• Put on hold, see issue summary for details.

is a persona that did not exist until now. It's the in the Drupal CMS personas → .

Closed 📌 Gate editing global regions behind 'administer blocks' permission in the UI Active in favor of this issue.

Updating XB's docs per #12: https://git.drupalcode.org/project/experience_builder/-/merge_requests/828

(This updates the docs that 📌 [PP-1] Diagram tying the product requirements + decisions together Postponed introduced.)

wim leers → credited lauriii → .

Oversights in 📌 Provide granular permissions for pages Active clarified by @lauriii. 👍

Another important oversight spotted while refining the issue summary for #3508694: #3508694-14: Permissions for XB config entity types → , asked @lauriii to confirm.

Outline of remaining plan.

📌 Add access control for "code components" and "asset libraries", special case: instantiated code components must be accessible to *all* Active is in 🥳

Hide parts of UI current user cannot access instead of always showing everything

is unblocked!

wim leers → credited penyaskito → .

Added 🐛 ContentCreatorVisibleXbConfigEntityAccessControlHandler's `view` access must refuse access to disabled config entities Active — great find, @penyaskito!

wim leers → credited tedbow → .

Added 🐛 ApiLayoutController::buildPreviewRenderable unnecessarily call \ClientDataToEntityConverter::converts causing errors Active , found by @tedbow.