Introduction
This document is about the future of “system management” of single TYPO3 instances - a mixture of various backend modules and what is currently known as “install tool”.
The main goal is to introduce a clear distinction between “TYPO3 system management”, “site administration” and “installation process”.
This topic has been started during the TYPO3 User Experience Week 2017 and is currently aligned on and followed by core team members and other contributors: Susi Moog, Benni Mack, Oliver Hader, Mona Muzaffar, Marco Christian Krenn, Christian Kuhn, Philipp Hamid.
Current situation
With the rewrite of the install tool for version TYPO3 v6.2, the install tool has been made an independent application with relatively little dependencies always works, even if the backend breaks down after upgrades. It is an important anchor of the system, enabling install tool administrators to revive the system even if conflicting extensions break other parts of the system.
Apart from that, most functionality from the “old” install tool has been adopted and not too much changed with the “functionality scope” of the install tool. The install tool currently provides:
- System Maintenance - eg. lowlevel “cache clearing”, processed file cleanup, typo3temp cleanup, ...
- System settings administration - All configuration, Preset handling, ...
- Upgrade helpers - Core updater, TCA migration checker, Change documentation, …
- Environment analysis - phpinfo, system check, folder structure, image calculation tests, …
Furthermore, some backend modules which are not part of the install tool provide functionality which change main system configuration (write TYPO3_CONF_VARS / LocalConfiguration / PackageStates / …) - obvious examples are the “Extension configuration” within the extension manager and the “Languages” module that handle system languages. Various other modules exist on this level which show, but don’t manipulate system configuration - for instance the “Reports” module and the “Configuration” module. “DB check” is a mixture of both.
The overall state of this is dissatisfying: It is not clear which parts belongs where in the system, the distinction between “Admin tools” and “System” in the main module looks arbitrary, new administrators don’t understand why certain functionality is located at the one or the other place. The need for an “install tool password” does not help and adds additional headaches organizing the password communication within developer groups maintaining an instance. Additionally, the install tool already provides two distinct applications in itself: The “step installer” and the “tool”.
Solution
The current mixture of system level administration tasks at various places in the backend and install tool should be disentangled, have a clear distinction and access rights management:
Split install tool into two applications: An installer which only takes care of “first installation” and can be removed after initial installation has been completed. It can be extracted to an own extension (or stays as “install” and the other part is extracted to a different extension name) for now, but could later evolve to for instance a .phar based installer or similar.
The other part of the current “install tool” evolves to a “system management” module that has all functionality which changes the “system” level of an instance: Everything that changes LocalConfiguration, PackageStates, l10n, main file / folder structure and required low level server infrastructure.
The “system management” application is integrated into the TYPO3 backend main module - A current WIP patch brings 4 modules “Maintenance”, “Settings”, “Upgrade” and “Environment” within the “System” main module. Current “System” module is renamed to “Admin tools” and vice versa. The current menu of the install tool (“All configuration” and friends) vanishes. The “system management” application is thus seamlessly integrated into the TYPO3 backend and brings the same look and feel. The “standalone” version of the system management application looks like the backend, just without all the other modules (and some color indicator or similar).
The install tool password falls. A new role “system management” for backend admin users is introduced: A LocalConfiguration setting “SYS/SystemManagementUsers” or similar contains a list of backend users who can access system management. This list can be administered only from within the system management itself.
Logged in backend administrators who are also system managers do see the system management main module entries and can use them without further login, directly. Admins not in this list don’t see the menu points.
The standalone version of the system management (not from within backend application) allows user/password based login as an admin user who has the system management role.
The installer is split from “system management” recovery - the recovery checks db and be_user table and communicates a shell based solution on how users could regain access to the system management if needed (similar to the current “forgot install tool password but based on be_users).
We end up with a clean separation of concerns and different user levels in the backend:
Editors / editor groups for content administration - no change here
Backend admins: Set up instance, manage site, has access to tree root node, sys_domain, sys_language, scheduler, show (!, not change) system configuration, CRUD other BE admins, can not set a be_user as system maintainer.
System maintainer: Extension configuration and management, environment, manage LocalConfiguration settings, BE language setup, system maintainer management, recovery.
A clean distinction between system maintenance and “rest of the system / backend” also gives us a significant security advantage: The system management application should have no other code dependency than to the “core” extension in the end, and no other core extension should have a dependency to the system management application. Thus, the “system management” does NOT need to exist on live systems if deployments are set up correctly. Not existing code has no security issues 
The ongoing efforts on the “git split of core extensions” plays into our hands here.
Organizational
Topic Initiator: Susi Moog, Benni Mack, Oliver Hader, Mona Muzaffar, Marco Christian Krenn, Christian Kuhn, Philipp Hamid
Topic Mentor: Christian Kuhn
