ACL improvements

TYPO3 Association Community Budget Ideas 2024 Q1
1

by Łukasz Uznański

What is your idea about?
"We aim to improve the Access Control List (ACL) by introducing predefined user groups as a standard feature. During the installation of TYPO3, users will have the option to select these predefined user groups, a feature that will also be available when adding a new site.

Subsequently, we plan to implement a notification system that alerts administrators when the permissions list is expanded, suggesting potential adjustments.

As a third measure our focus will shift to developing a more intuitive and user-friendly interface for the creation and management of user groups, enhancing the current system’s usability."

What do you want to achieve by the end of Q1 2024?
"We aim to include predefined user groups as a default option during the installation process and when creating new sites. Additionally, we would like to implement a notification system designed to alert administrators efficiently.

Goals for Q1

  • Predefined user groups for new TYPO3 instance
  • Add option to add predefined user groups during installation
  • Add command for generating user groups
  • Predefined access control settings
  • Backend module with notification system for administrators (e.g when new field is added to table that is used in ACL).
  • Additional documentation for best practices in creating access groups (also placed in backend module)
  • Extension will be published on github in FriendsOfTYPO3 namespace as public repository"

What is the potential impact of your idea for the overall goal?
"By including predefined user groups during TYPO3 installation and site creation, the process becomes more streamlined and efficient. This feature reduces the initial setup time and complexity, making it more accessible, especially for new users or less technically inclined administrators. This feature would guide users towards more consistent standards of configuring user groups.

The introduction of a notification system for permissions significantly improves security and management oversight. Administrators can respond more promptly to changes, ensuring that user access remains appropriate and secure.

Developing a more intuitive and user-friendly interface for managing user groups directly impacts the ease of use. This improvement will make the system more approachable and easier to navigate, reducing potential errors and increasing efficiency in user management.

In summary, the implementation of these ideas will not only streamline and secure the TYPO3 user management process but also enhance the overall user experience."

Which budget do you need for your idea?
7.500 Euro

3 Likes
2

I would love to see a scope-reduced version of this budget idea - essentially a split into multiple parts:

  • One part for the predefined groups and predefined ACL presets.
  • One part for the embedded documentation and best-practice.
  • One part for the command-line based interface to group creation.
  • One part for the mentioned notification feature.

Packaging this as an “all or nothing” with a rather big budget ask does not seem like a good approach, given that the idea is perfectly divisible into smaller scopes, some of which imho would/should have much higher priority than others.

1 Like
3

How does this work together with the current efforts of deployable permissions in the Core?

1 Like
4

What do you mean? I know that there is third-party extension that covers this area. Could you send some urls?

5

I think that those parts are a bit intertwined, our approach was to start with the simplest feature and build on top of it more complex solution. E.g. predefined groups & ACL presets would point us towards best practices and documentation, documentation could help us in developing better CLI tool. I agree that notification system feature could be done in later time, but those three should be in one package, as they feed of each other, to make better functionality altogether.

6

Still sounds to me like these are fully iterative things; A allows for B which allows for C which allows for D etc. and each of those parts would be viable without the next parts (truly iterative).

For example, for me, having predefined groups and ACL presets is much, much more important than having a CLI tool and embedded documentation - and the base feature itself would be fully useful also without those other things added to it. I would +1 a budget that wants to do the presets without a second thought, but I hesitate to +1 a budget that wants to do it all (implied: or not do any of it). Had these been split I would have given the first item absolute top priority over any other budgets, but having it all pooled together like this I’d give it middle priority at best.

7

Thank you for your insight. We discussed your thoughts internally and agree that we should focus only on a part of our original scope, which is to define best practices of ACL presets. We propose to achieve this in three phases:

Phase 1: Research & analysis

  • Conduct a review of the current state of ACL in TYPO3.
  • Undertake research on common use cases, focusing on those most applicable across a variety of websites.
  • Research how to adapt ACL for websites of various sizes: small, medium, and large.
  • Explore interactions with core extensions (e.g., workspaces, import/export, etc.).

The outcome of this phase will be a technical document outlining best practices for the most used scenarios, including a plan for implementation.

Phase 2: Feedback loop with core & community

  • Engage with the core team and the wider community to gather feedback on our proposals.

After gathering feedback, we will proceed with the implementation of a PoC.

Phase 3: Implementation

  • Proceed with the implementation of the proposed solution.

Final outcome

  • Technical document with best practices for ACL
  • Implementation of presets in form of patch to the core
8

That seems like a really good decision!

9

We at OpenGemeenten have an extension which does similar stuff. All of our own extensions provide yaml files for access control. Each yaml file represents a group and the yaml file defines how the group is stored in the database (be_groups). At deployment all yaml files are read by the order of the extension packages, depending on your composer requirements. This way it makes it possible to override default settings from extension packages in the final site package extension. Groups which have been added automatically by a yaml file cannot be edited in the TYPO3 backend. Our extension keeps everything in sync with each and every deployment. Groups are added, deleted or changed if needed. Bacause we are storing everything in the database at the end, everything is still compatible with the TYPO3 core.

The yaml file for the core content element “Text & Media” (contentType_coreTextmedia.yaml) at our company looks like the following:

description: |
  Permission to edit the content type "textmedia (Text & Media)".

  Includes the group "tables_modify_coreFileReference" for the "assets" field.
explicitAllowDeny:
  tt_content:
    CType:
      textmedia: true
nonExcludeFields:
  tt_content:
    assets: true
    imageborder: true
    imagecols: true
    imageorient: true
subgroups:
  tables_modify_coreFileReference: true

(Yes, we limit the fields for our clients, so you are missing fields in this yaml file for this CE)

In a site package we also provide the roles like _role_editor.yaml where everything is gathered for this specific role. In the backend we add one group manually (__Editor) which will get this role, a page access group, a database mount group and file mount group.

If you need some more insight, please let me know. Maybe our extension can help you in any way.

10

Hi,

@patrick thanks for you input. We will definitely look into this.

11

Hi,

I would like to share with you draft of documentation with proposed user groups and approach. This is result of research. I open this document for suggestions, so you can comment directly in this document. We would like to propose it as a part of documentation later on.

Please share your insights!

12

Super interesting document. At current university project, we using a structure and concept similar.
image
First a be_group can either

  • Grant access to a sitetree and corresponding mount/files
  • Grant access as a role (Editor) for a specific purpose (news, content editor, etc)

A be_user is then giving a access combination consiting of access and editor role

image
image1314×274 5.54 KB

And when they login, they do choose what role on what site they will be working as, and the backend displays that.

Ping me if the idea, concept or implementation is of interest in this process :ok_hand:

13

@sorenmalling thanks! That’s something to consider, for sure.

Additionally, I would like to announce that core patch related to this ACL budget idea, which allows you to install predefined groups, just got merged!

You can check it here https://review.typo3.org/c/Packages/TYPO3.CMS/+/83087

2 Likes
14

I’ve shared that feature with the others on the project, and I can see a great way to deploy access groups and presets without a editable user interface :ok_hand:

I’m excited to see where this goes towards next. I will adopt the deployment of access groups to my own project right away :partying_face: