Community Budget Idea Report: ACL Improvements Phase

The fields inside these new tabs were arranged as follows, compared to TYPO3 version 12 and earlier:

To make the naming convention consistent, we have also decided to rename the Access Rights tab to Permissions in the backend user form. This also improves the distinction between the Access Rights and Access tabs (the latter concerns access options for a given record).

Together with all the changes mentioned above, we also added descriptions to some fields, explaining their behavior more clearly.

Help and Support From

• Rachel Foucard
• Riccardo De Contardi
• Georg Ringer, Michael Telgkamp
• Garvin Hicking
• Guido Schmechel
• Manuel Selbach
• Thomas Hohn
• Andreas Kienast
• Christian Kuhn
• Torben Hansen
• Stefan Bürk
• Oliver Bartsch
• Oliver Klee
• Christian Wolff
• Mathias Brodala
• Mathias Bolt Lesniak.

Related Patches:

• [TASK] Reorganize backend group form sections inside tabs
• [TASK] Add description to allowed_languages field
• [TASK] Change labels of sections in the access rights configuration form

Allow Filtering of Permission Lists

Splitting the backend user group form fields into more tabs reduced scrolling within a single tab. However, the various permission lists could still be very long, making it difficult to find items of interest. To address this issue, we decided to extend the standard Select Checkbox element (used to render most of the lists inside the backend user group form) with a new configuration option that enables a filter field above such an element.

You can enable a filter for an element with the renderType set to selectCheckBox by setting the showFilter option to true in the Table Configuration Array (TCA). For example:

'my_custom_field' => [
    'label' => 'My custom field',
    'config' => [
        'type' => 'select',
        'renderType' => 'selectCheckBox',
        'showFilter' => true,
        'items' => [ ... ],
        'size' => 10,
        autoSizeMax' => 50,
    ],
],

The scope of the filter is limited to the current field. So, if you have multiple fields rendered with this filter enabled, only the current field’s item list will show filtered items. If no items match the filter phrase, the user will see a dedicated information message. If the field renders its items in multiple separate groups, all of those groups will be filtered. Please take a look at these examples:

To render the informational message when no items match the filter criteria, we introduced a new web component called Alert. The new component can be reused in other parts of the TYPO3 codebase. Currently, such alerts are rendered by duplicating HTML code. I have also suggested that the TYPO3 Core Team unify other components/elements with similar structures and styling, such as Notification, Infobox (Callout), and Flash Message.

Help and Support From

• Andreas Kienast
• Oliver Bartsch
• Simon Schaufelberger
• Garvin Hicking.

Related Patches

• [FEATURE] Add an option to render filter input above the selectCheckBox field
• [FEATURE] Introduce Alert web component

Change Table Restrictions UI to Combine Read and Write Permissions

Moving forward with the planned improvements, we started to simplify the configuration of read and write permissions for database tables. Previously, these permissions were managed through two separate fields: Tables (listing) and Tables (modify). This task went through several iterations of changes and improvements before it was accepted by the core mergers. Let me describe this process in more detail.

Before our work started, a related patch had already been merged. It combined the two fields into a single palette, rendering them side-by-side. We changed it even further, to render as a combined view where it is possible to manage both read and write permissions for database tables.

Our approach was to create a dedicated render type for the select field that renders the tables_modify field and hides the tables_select field. The new view for the tables_modify field contains two columns of checkboxes. The checkboxes in the first column grants read permissions and those in the second column grants write permissions. This may sound simple, but there were three concerns:

• Should we check and disable the read permission checkbox when the corresponding write checkbox is checked?
• Should we use three checkboxes or radio buttons to represent three states of permissions (none, read, and write)?
• How do we best organize these form fields to fulfill the accessibility team's requirements?

In the meantime, other core changes were merged that also related to tables with checkboxes and their controls (Toggle all, Revert selection, etc.), so we had to adapt the code to those changes as well.

At one stage, it looked like we had the whole patch shaped up, with positive reviews and pretty much ready to merge. Then, after more reviews, the decision was made to change the implementation to use a dedicated TCA type, rather than a new render type for the select field. This would make the patch a solid basis for future changes, where table read and write permissions could be handled by a single JSON field in the database. So we modified the code again. We had a lot of feedback and code improvements from Oliver Bartsch and Ayke Halder. Finally, when we were close to the end of the quarter, we had a solid, nicely working solution.

The new view allowed setting the read and write permissions for selected tables. The behavior of the checkboxes was as follows:

• If you check the Read checkbox, it will be checked.
• If you check the Write checkbox while the corresponding Read checkbox is checked, both will be checked.
• If you check the Write checkbox while the corresponding Read checkbox is not checked, both will be checked.
• If both the Read and Write checkboxes are checked, and you uncheck the Write checkbox, it will be unchecked while the Read checkbox remains checked.
• If both the Read and Write checkboxes are checked, and you uncheck the Read checkbox, both checkboxes will be unchecked.

However, the team wanted to make it even better, more user-friendly, and accessibility compliant. With help from the Core developers, the checkboxes were replaced by radio buttons. The UI version that made its way into the TYPO3 core looks like this:

Under the hood, the read and write permissions are stored in the same two database columns as before, so no changes were made to how TYPO3 internally handles and checks permissions for the tables.

Help and Support From

• Ayke Halder
• Oliver Bartsch
• Christian Kuhn
• Georg Ringer
• Andreas Kienast
• Michael Telgkamp.

Related patches

• [FEATURE] Change table restrictions UI to combine read and write permissions

Allow Previewing Forms Based on Backend Group Permissions

After improving TYPO3’s permission management , we wanted to make it easier to preview how changes in group permissions affect the form layout for a particular backend user. Previously, it was necessary to assign the group to a backend user, switch to that user, and check what fields are rendered within the forms.

We decided to add a preview button to the header of the Allowed fields view. Clicking it will display a preview of a given record form based on the permissions of the edited backend group and its subgroups.

When the user clicks on the preview button, a new modal window will open with the form inside, previewing what fields will be visible to the backend user if the edited backend user group is assigned to them. Here is an example of the form preview for the Page record type:

Let me explain how it works in the background and what limitations we have.

When the user clicks the form preview button, a request is sent to the dedicated TYPO3 backend endpoint with all the edited group data (not only the selections from the exclude fields list, but the entire form). The group permissions are combined with the permissions of all subgroups currently assigned to the edited group and then assigned to a dummy backend user. This dummy user does not exist in the database and is temporarily assigned to $GLOBALS['BE_USER'], just to render the form and ensure that no additional user-specific settings interfere with the group permissions applied to this user. This way, we ensure that what is displayed in the form preview is limited to the edited backend group settings only.

Within the form, there are some limitations. The possibilities and rendering approach were the result of two calls with TYPO3 framework merger Oliver Bartsch. Oliver provided a lot of valuable feedback and suggestions regarding the form engine and TYPO3 internals. To avoid JavaScript errors, we decided to make the form non-interactive. This means that the rendered form preview does not handle events and dynamic components, such as those rendering trees using JavaScript code, will not be displayed. The field preview is very similar to what you see now when you set its readOnly option.

The consequence of having a non-interactive preview form is that you cannot change its type (like you do when changing a Page record’s type between Standard, Shortcut, Folder, etc.).

Having this capability is crucial, though. Different record types can have different lists of visible fields, and we want to be able to verify all of them. Another factor influencing field visibility is the TCA’s displayCond setting. This option allows defining when a field will be rendered (for example, if another field has a specific value set). To address these issues, there are dedicated controls above the form preview. These allow changing the record type and disabling the displayCond options for all fields.

To remain backward compatible and prevent these changes from breaking any custom extensions that provide custom form elements, the abstract form element now implements a renderPreview method. This method will render an information box when a field has no renderPreview method defined.

Help and Support From

• Christian Kuhn

Related Patches

• [FEATURE] Allow record fields permissions preview

Allow Assigning Users Directly to Backend Groups from Group Settings

When you have properly configured the backend user groups, the next step is usually to assign users to them. If there are hundreds of backend users that need to be updated, this process can be very time-consuming, as it requires editing each user and assigning them to selected groups.

To address this issue, you can now assign users to a group directly from the group edit form in the new Users Belonging to This Group section under the General tab of the group form. It displays a paginated list of users assigned to the group, as well as buttons to assign new users and remove existing ones. Under the hood, there were no breaking changes, and the process remains compatible with TYPO3’s traditional user group assignment.

Help and Support From

• Mogens Fiebrandt

Related Patches

• [FEATURE] Allow assigning users to groups in group editor

Merge the Access Module Into the Backend Users Module

The last change I would like to mention is related to the modules navigation, or the main TYPO3 menu. We have proposed a patch that replaces the Backend Users and Permissions (formerly known as Access) entries in the module menu with a single entry named Users and Permissions. It groups all the submodules related to managing backend users, backend groups, file mounts, and page permissions. We thought (and it was also mentioned a few times in the Q1 survey) that it would be better to have all the permissions-related settings in one place. Today, it can be easy to forget to set permissions for pages after configuring backend user groups.

Related Patches

• [TASK] Merge Permissions and Backend Users modules

Further ACL Improvements Planned

As I mentioned at the beginning of this article, we planned the work on ACL improvements in four parts. The first part was finished in Q1/2024 by providing documentation for best practices on how to manage permissions in TYPO3 and a command to generate default backend user groups. In Q2/2024, we focused on UI/UX improvements, and all those changes are described above.

Today we have more great news for you. The voting for Community Budget Ideas for Q3/2024 has already finished, and we have a green light to continue our work. This time, we plan to deliver functionality that will allow extension developers to define permission presets directly within their extensions. So stay tuned for more great news in the future.

Thanks and Acknowledgements 

We would like to thank all the great people who spent their time helping us with the features, providing constructive feedback, making reviews, and, in general, making these improvements possible. I tried to mention them all when summarizing each task, but if I mistakenly omitted someone, please forgive me.

We hope that you like what we have done and that these improvements will make ACL management in TYPO3 much easier, more performant, and more enjoyable for everyone.