Actions
Epic #95904
openMake backend user and user groups deployable
Status:
Under Review
Priority:
Should have
Assignee:
-
Category:
-
Target version:
-
Start date:
2021-11-08
Due date:
% Done:
0%
Estimated time:
Sprint Focus:
Description
This issue was raised during the T3MC session "Zap the gremlins".
The issue has been discussed in April 2022 in the #typo3-cms-coredev channel (https://typo3.slack.com/archives/C03AM9R17/p1650369198186799). The following is the result of the discussion.
General requirements¶
- preferred format: YAML * core uses it already * can be commented
- definitions can be shipped with extensions
- the functionality can be compared with the handling of Site configuration * Site configuration (still) has implicit dependencies on UID values in `rootPageId` and `limitToPages` (for route enhancers) * replacing those UIDs by distinct / universally-unique seems to be a good way to go
- events should be provided * as with the Site configuration * allows extension authors to hang in there dynamically before / after the cache building
- overwriting / modification should be simple * it is a no-brainer to inherit the default "news editor" and remove some fields or add another backend module
- error handling * handle defined but missing relations to groups and mounts
User Groups¶
- groups should be understood as roles, e.g. "news editor"
- a role * includes corresponding permissions (= contains the access control) * should be assigned to a group (= collection of roles)
- a group * will be assigned to a user * contains the DB and file mounts
- be_groups needs an additional string identifier to avoid relying on autoincrement IDs
- we recommend a human readable string identifier which helps to handle those definitions
Problems to be discussed¶
- using string identifiers do not guarantee uniqueness -> having a UUID could solve the problem but causes additional work on datahandler (which considers everything not a UID to be a new record placeholder, if it starts with NEW)
Users¶
- handling of one or more user records
Problems to be discussed¶
- handling of sensitive data (passwordl, name, email address)
Handling user groups would solve a big problem and would be a huge improvement. The import and export of users is rather complex, the value small.
There are some solutions already out there:- https://packagist.org/packages/maxserv/yaml_configuration
- Benni Mack might have a PoC somewhere :)
Actions