Switch to first allowed type if default type is not allowed in element group

[dennisbohn]

Unfortunately, I broke my last pull request. So here is the second attempt.

Currently, the type field of a content element is set to "article" by default, which leads to an unknown option being displayed in the drop-down list of the type if you create it in an element group where the type "article" is not contained in "allowedTypes".

#[AsContentElement(category: 'custom', template:'content_element/element_group', nestedFragments: ['allowedTypes' => ['image']])]
class ImageGroupController extends AbstractContentElementController
{
    protected function getResponse(FragmentTemplate $template, ContentModel $model, Request $request): Response
    {
        return $template->getResponse();
    }
}

In this case, the added callback function automatically changes the value to the first supported type.

Furthermore the tl_content.php was modified to close the content element, if the user has no permission for the nested elements.

[dennisbohn]

I wonder why PHPStan gives an error. According to PHPStan, I am using the User class here, although I am using the BackendUser class. Can this be ignored or do I have to adjust something here?

It has no problems with BackendUser in tl_content.php.

[aschempp]

Thanks for the follow-up @dennisbohn! I have two issues here:

1. this fix is kinda duplicated by Added voter for content elements #7088. However, we recently discussed a voter should not decide on non-user permissions (nested elements), so I dunno what @contao/developers think here?
2. I dislike that the functionality is now split across multiple places (tl_content and the listener). Additionally, this will create an incorrect record and then modify it after, instead of making sure the correct data is saved to the database. Maybe this could be done using an options_callback or the widget_callback? 🤔

[leofeyer]

However, we recently discussed a voter should not decide on non-user permissions (nested elements), so I dunno what @contao/developers think here?

What do you mean? The pull request adds a listener, not a voter.

[aschempp]

I mean that my content-element access voter would fix this as well, but it would vote on the allowed nested elements.

[leofeyer]

Ah, that‘s a tricky one.

There is a user setting for allowed content elements, which per our definition is the responsibility of the security voters. But there is also the allowedTypes property that can be used to limit the types of elements in a set of nested fragments, which per our definition is not the responsibility of a security voter.

However, since both tl_user.elements and allowedTypes do the same thing, I think a security voter should be allowed to vote on both. @ausi WDYT?

[ausi]

However, since both tl_user.elements and allowedTypes do the same thing, I think a security voter should be allowed to vote on both. @ausi WDYT?

I don’t agree. For me the security voter should only handle the tl_user.elements part.

[m-vo]

If you think what an admin would experience, it's clear that the allowedTypes must be enforced outside the voter. ☺️

[leofeyer]

You are absolutely right.