Consider optionally applying AND logic to restrictions by region?

Thanks for asking about this.

Per the documentation at https://www.drupal.org/docs/contributed-modules/layout-builder-restricti... → , the design of the module is to allow for global block restrictions to be set, along with restrictions by region:

Once the per-layout restrictions have been saved, they will work in conjunction with any global block restrictions you have set for the entity. For example, if you restricted the "Basic block" globally, it will be restricted on all layouts, regardless of what further restrictions you may have set for a specific layout or region in a layout. In contrast, a block restriction that is specific to a given layout or layout region will not affect other layouts or regions.

Looking at the precise language of what you're asking for: an ability to set restrictions **per layout** (i.e., not global, and not per region), I'm hesitant to add this middle-layer due to the UI and coding complexity. Would the global defaults in conjunction with region restrictions be sufficient for your usage?

Hey Mark! Thanks for the follow-up. I took about 2ish hours this afternoon to proof of concept this.

I've uploaded a very aggressive patch that should at give an approximate UX for my feature proposal. To be clear, this is a 100% "rip and tear, get it done" patch that should just be used as a reference.

I'd be all for a global setting for this, for what it's worth too!

To give a bit more context, I'm looking to provide restrictions...

1. Per content type
2. Per layout type
3. Per region

to provide a very contextually aware and tightly controlled set of blocks to be used in any given context. This is primarily to help us focus on providing guaranteed accessibility -- baked in -- without having to rely on content editor governance. In a way, site builders / designers wouldn't even have to write up content guidelines if the only things that folks can add in any given context "simply work" there and jive with the overall design and content strategy.

Let's try this patch -- inadvertently broke some tests.

Same restrictions, wrong label that the test was expecting -- let's persist the label, eh?

Hi Luke!

Thanks for following up with this. Before going further, I want to reiterate two statements I made earlier:

I'm hesitant to add this middle-layer due to the UI and coding complexity

So, before working on the code for further proofs-of-concept, let's think about this more. Given that developers can quite easily add custom restrictions on a per-layout basis (see our documentation at https://www.drupal.org/docs/contributed-modules/layout-builder-restricti... → ), I'm hesitant to make this part of the UI of the module. I'm not convinced that the UI is the right way to tackle what I consider a "middle-layer" edge case.

Once the per-layout restrictions have been saved, they will work in conjunction with any global block restrictions you have set for the entity.

Based on this, I'm not sure what you mean with "I'd be all for a global setting for this." Can you clarify.

Changing the issue status on this to "Postponed (maintainer needs more info)," based on the previous comment. To summarize:

1. Global restrictions should already work in conjunction with region-specific restrictions. Why is another layer of restrictions by layout needed?
2. Does the community agree that a programmatic way to achieve restrictions as proposed in this issue, and as documented in https://www.drupal.org/docs/contributed-modules/layout-builder-restricti... → , is sufficient?

Hey Mark, sorry, I've been on vacation.

Regarding #1, the current per region functionality only works if the layout regions are known at compile time. That isn't the case for any layout plugin types that use PHP to dynamically define regions. For such layout types, the all regions method is the only way to target dynamically defined regions.

In our particular case, we have an "intro" region plus a dynamic number of subordinates tabs and/or accordions, as a concrete example.

I can't really speak to #2, as our usage of layout builder is quite atypical, requiring deeply nested, infinitely configurable, interactive UI elements. One might argue that deeply nested interactive UI elements is not a recommended UX pattern, but unfortunately, we're not able to influence requirements in our team dynamic.

If this use case isn't a candidate for inclusion in the module proper, I wouldn't be opposed to drafting up a parallel/add-on module for it. I simply can't justify writing custom restriction plugin types for our layout stack when it would be more reusable and intuitive to lightly tweak some pre-existing, and battle-tested logic instead.

Cheers