Summary of Changes

The issue with the SQL field is that it can be risky when none super admins can edit it and define the SQL query setting. This query will be then executed on every article edit or view access. Like that it will be possible to define update queries which can be abused to grant super admin privileges to none super admins.

This PR changes the behavior of the SQL field, that only Super Admins can create it. Additionally it sets the "Edit" permission for all none Super Admin groups to deny. Means the super admin must explicitly allow none super admin groups to edit the field. This is done the way, that the "Public" group has the deny flag, where all (except the super admin) groups will inherit from.

I would like to thank @yvesh and @SniperSister for their help on that.

Testing Instructions

1. Create a new SQL custom field as none super admin.
2. Create a new SQL field as super admin.
3. Create a new SQL field as super admin and set the Administrator Group to "Allow".

Expected result

1. An error is shown and the field is not saved.
2. The "Public" group must have the "Deny" flag set for the edit permission. All other groups must inherit that flag and it should not being allowed to edit the field. A warning is shown that the permissions got updated automatically.
3. The Administrator group should have the Allow permission.

Actual result

1. No erro is shown. The field got created.
2. No warning is shown. The field got created and the permissions not automatically adjusted.
3. The Administrator group should have the Allow permission.

Documentation Changes Required

For the SQL custom field the behavior must be explained in the documentation.