TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692024-03-13T16:17:38ZTYPO3 Forge
Redmine TYPO3 Core - Task #103392 (Resolved): Add important RST for changed form framework markuphttp://forge.typo3.org/issues/1033922024-03-13T16:17:38ZOliver BartschTYPO3 Core - Task #103385 (Resolved): Add GeneralUtility::makeInstance to PHPStorm meta filehttp://forge.typo3.org/issues/1033852024-03-13T10:26:44ZOliver BartschTYPO3 Core - Task #103254 (Resolved): Trim bparams instead of using string replacehttp://forge.typo3.org/issues/1032542024-03-03T12:38:36ZOliver BartschTYPO3 Core - Task #103192 (Resolved): Use speaking array keys in changelog examplehttp://forge.typo3.org/issues/1031922024-02-23T20:54:33ZOliver BartschTYPO3 Core - Task #103183 (Resolved): Ensure symfony container usage when calling set() in testshttp://forge.typo3.org/issues/1031832024-02-23T09:36:04ZOliver BartschTYPO3 Core - Task #103089 (Resolved): Remove unused labels related to the old page treehttp://forge.typo3.org/issues/1030892024-02-09T10:25:18ZOliver BartschTYPO3 Core - Task #102985 (Closed): Make Indexed Search a CTypehttp://forge.typo3.org/issues/1029852024-01-29T17:25:34ZOliver BartschTYPO3 Core - Task #102845 (Closed): Remove pointless stdWrap testhttp://forge.typo3.org/issues/1028452024-01-17T14:02:24ZOliver BartschTYPO3 Core - Task #102801 (Closed): Clean up grid classeshttp://forge.typo3.org/issues/1028012024-01-09T13:22:22ZOliver BartschTYPO3 Core - Task #102791 (Closed): Declare EXT:core Event classes and properties readonlyhttp://forge.typo3.org/issues/1027912024-01-09T09:22:17ZOliver BartschTYPO3 Core - Task #102789 (Closed): Declare EXT:backend Event classes and properties readonlyhttp://forge.typo3.org/issues/1027892024-01-09T09:06:19ZOliver BartschTYPO3 Core - Task #102744 (Closed): Remove references to non existing wizard_rte routehttp://forge.typo3.org/issues/1027442024-01-03T10:54:39ZOliver BartschTYPO3 Core - Epic #101585 (New): Use AsEventListener for registrationhttp://forge.typo3.org/issues/1015852023-08-05T07:53:27ZOliver BartschTYPO3 Core - Epic #95904 (Under Review): Make backend user and user groups deployablehttp://forge.typo3.org/issues/959042021-11-08T11:15:51ZOliver Bartsch
<p>This issue was raised during the T3MC session "Zap the gremlins".</p>
<p>The issue has been discussed in April 2022 in the #typo3-cms-coredev channel (<a class="external" href="https://typo3.slack.com/archives/C03AM9R17/p1650369198186799">https://typo3.slack.com/archives/C03AM9R17/p1650369198186799</a>). The following is the result of the discussion.</p>
<a name="General-requirements"></a>
<h2 >General requirements<a href="#General-requirements" class="wiki-anchor">¶</a></h2>
<ul>
<li>preferred format: YAML
* core uses it already
* can be commented</li>
<li>definitions can be shipped with extensions</li>
<li>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</li>
<li>events should be provided
* as with the Site configuration
* allows extension authors to hang in there dynamically before / after the cache building</li>
<li>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</li>
<li>error handling
* handle defined but missing relations to groups and mounts</li>
</ul>
<a name="User-Groups"></a>
<h2 >User Groups<a href="#User-Groups" class="wiki-anchor">¶</a></h2>
<ul>
<li>groups should be understood as roles, e.g. "news editor" </li>
<li>a role
* includes corresponding permissions (= contains the access control)
* should be assigned to a group (= collection of roles)</li>
<li>a group
* will be assigned to a user
* contains the DB and file mounts</li>
<li>be_groups needs an additional string identifier to avoid relying on autoincrement IDs</li>
<li>we recommend a human readable string identifier which helps to handle those definitions</li>
</ul>
<a name="Problems-to-be-discussed"></a>
<h3 >Problems to be discussed<a href="#Problems-to-be-discussed" class="wiki-anchor">¶</a></h3>
<ul>
<li>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)</li>
</ul>
<a name="Users"></a>
<h2 >Users<a href="#Users" class="wiki-anchor">¶</a></h2>
<ul>
<li>handling of one or more user records</li>
</ul>
<a name="Problems-to-be-discussed-2"></a>
<h3 >Problems to be discussed<a href="#Problems-to-be-discussed-2" class="wiki-anchor">¶</a></h3>
<ul>
<li>handling of sensitive data (passwordl, name, email address)</li>
</ul>
<p>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.</p>
There are some <strong>solutions</strong> already out there:
<ul>
<li><a class="external" href="https://packagist.org/packages/maxserv/yaml_configuration">https://packagist.org/packages/maxserv/yaml_configuration</a></li>
<li>Benni Mack might have a PoC somewhere :)</li>
</ul> TYPO3 Core - Epic #93119 (Closed): Bootstrap v5 migrationhttp://forge.typo3.org/issues/931192020-12-20T11:11:35ZOliver Bartsch
<p>This epic deals with the integration of Bootstrap v5 and all corresponding followup tasks.</p>