Add conditional logic to blocks field

[abel-sch]

I think it might be useful to be able to add logic on which blocks are available on the blocks field. Maybe only a user of a certain type of role is able to select a certain block, or you want to be able to select a 'page template' that enables a different set of blocks.

(Btw that admin.condition function doesn't do anything at all atm for v3alpha)

[DanRibbens]

I love this idea. I would call it filterBlocks and add it to the blocks field, though I could also see the point of setting it on the block itself. What do you think is the best choice?

Because admin.condition is something we use to hide indvidual fields, it feels like "condition" should be reserved for that. This feels more similar to how relationships have a filterOptions which does exactly what it would sound. For filterOptions we even have the validation logic involved to prevent savin with a filtered item.

To your point about certain users, that is more like access control which has other implications. In your scenario, what happens if an admin user creates a document that has a priveledged block, others can't access, but then the lesser priveledged user goes to edit the document? This can happen now with relationships and we leave the id even if you can't read the related document.

We'll look into v3 admin.condition, thanks!

[abel-sch]

Both setting the filterBlocks on the parent blocks field and the child block do make sense. However I think the block might be used in different places so the best way to know about the context would be from the parent field.

You are right, it is pretty much the same as the filterOptions for the relationships field. For consistency's sake, why wouldn't you can this filterOptions as it does exactly this but filters blocks instead of relations?

I didn't think the access control through, but treating this the same as relations sounds like a good choice. Isn't a blocks field just a relation with a block after all?

Thanks for the quick response!