TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692018-12-27T13:53:30ZTYPO3 Forge
Redmine TYPO3 Core - Feature #87300 (New): Limit amount of concurrent user sessions for same userhttp://forge.typo3.org/issues/873002018-12-27T13:53:30ZOliver Haderoliver.hader@typo3.org
<p>TYPO3 allows to use multiple sessions per user which is a feature on the one hand, but could also be a security risk on the other. In order to enhance the scenario it should be possible to limit the amount of concurrent user sessions per user (or disable concurrent logins at all).</p>
<p>Behavior either can be configured for the whole system or (optionally) per user.</p> TYPO3 Core - Bug #86231 (New): Distinguish between free-mode localization and chained translationhttp://forge.typo3.org/issues/862312018-09-12T08:51:28ZOliver Haderoliver.hader@typo3.org
<p>Based on my note <a class="external" href="https://forge.typo3.org/issues/86141#note-5">https://forge.typo3.org/issues/86141#note-5</a> when analyzing the behavior</p>
<a name="TLDR"></a>
<h2 >TL;DR<a href="#TLDR" class="wiki-anchor">¶</a></h2>
<p>When skimming over the examples below, focus and compare the values in <code>l10n_parent</code> and realize that <code>l10n_source</code> is <strong>optional</strong>.</p>
<a name="Usage"></a>
<h2 >Usage<a href="#Usage" class="wiki-anchor">¶</a></h2>
<p>Localizations can be created using the graphical backend interface (e.g. page module) or by invoking direct commands to DataHandler [1]. Thus even if the page module is only valid for <code>tt_content</code> records, it does not prevent records from being translated or localized explicitly. That's why this analysis used <code>element</code> instead of <code>tt_conent</code> a pointer to a database table holding relevant records.</p>
<a name="Terminology"></a>
<h2 >Terminology<a href="#Terminology" class="wiki-anchor">¶</a></h2>
<a name="Connected-Mode"></a>
<h3 >Connected Mode<a href="#Connected-Mode" class="wiki-anchor">¶</a></h3>
<p>When translating elements, each element is bound to it's relative ancestor. This results into a chain (that can be used for language fallbacks etc.).<br />The following example illustrates that, <code>l10n_parent</code> always points to the initial record in default language, <code>l10n_source</code> points to it's relative translation ancestor - that's the record a new translation is based on. All records are connected in a chain.</p>
<pre>
+ element:1 - English (Default) - language:0, l10n_parent=0, l10n_source=0
+ element:2 - French Translation - language:1, l10n_parent=1, l10n_source=1
+ element:3 - Franco-Canadian Translation - language:2, l10n_parent=1, l10n_source=2
</pre>
<a name="Free-Mode"></a>
<h3 >Free Mode<a href="#Free-Mode" class="wiki-anchor">¶</a></h3>
<p>When localizing elements in free-mode, the previously mentioned translation chain is broken up, thus "free-mode localizaion elements" are in a specific language, but are not related to any relative ancestor and thus are idependent. The following example uses <code>element:3</code> as "free-mode localization", <code>l10n_parent</code> is set to <code>0</code>, but <code>l10n_source</code> still points to it's relative localization ancestor (just as information, not as a strict relation in like a "composition" [2] would have been).</p>
<pre>
+ element:1 - English (Default) - language:0, l10n_parent=0, l10n_source=0
+ element:2 - French Translation - language:1, l10n_parent=1, l10n_source=1
+ element:3 - Franco-Canadian Translation - language:2, l10n_parent=0, l10n_source=2
</pre>
<a name="The-Challenge"></a>
<h2 >The Challenge<a href="#The-Challenge" class="wiki-anchor">¶</a></h2>
<a name="Translation-from-existing-localization"></a>
<h3 >Translation from existing localization<a href="#Translation-from-existing-localization" class="wiki-anchor">¶</a></h3>
<p>It is possible, to create a new localization directly, that does not have a record in default language - or as alternative start a translation based on a "free-mode localization element".<br />The example shows, that the "English (Default)" record is now missing - the translation chain should(!) start with "French Translation" as first chain link. Since no record in default language s involved <code>l10n_parent</code> stay empty with <code>0</code>, only <code>l10n_source</code> point to their according relative ancestor records.</p>
<pre>
+ element:2 - French Translation - language:1, l10n_parent=0, l10n_source=1 # <- translation chain or free-mode localization?!
+ element:3 - Franco-Canadian Translation - language:2, l10n_parent=0, l10n_source=2 # <- translation chain or free-mode localization?!
</pre>
<p>When comparing the "Franco-Canadian Translation" here to the one shown in the "Free Mode" section, it cannot be distinguished anymore, whether the record is part of a "translation chain" or has been created as "free-mode localization".</p>
<a name="The-information-in-l10n_source-is-not-mandatory"></a>
<h3 >The information in <code>l10n_source</code> is not mandatory<a href="#The-information-in-l10n_source-is-not-mandatory" class="wiki-anchor">¶</a></h3>
<p>Besides that, the information stored in the <code>l10n_source</code> field is optional and has to be configured in the control section of <code>$TCA</code> using the <code>translationSource</code> property. Thus, that information might not be available at all. The following examples show persisted results without having the <code>l10n_source</code> information.</p>
<a name="Connected-Mode-without-l10n_source"></a>
<h4 >Connected Mode without <code>l10n_source</code><a href="#Connected-Mode-without-l10n_source" class="wiki-anchor">¶</a></h4>
<pre>
+ element:1 - English (Default) - language:0, l10n_parent=0
+ element:2 - French Translation - language:1, l10n_parent=1 # <- part of a translation chain, which one?!
+ element:3 - Franco-Canadian Translation - language:2, l10n_parent=1 # <- part of a translation chain, which one?!
</pre>
<p>It is not possible anymore to determine at all, whether a record is part of a translation chain - since the relative ancestor is missing.</p>
<a name="Free-Mode-without-l10n_source"></a>
<h4 >Free Mode without <code>l10n_source</code><a href="#Free-Mode-without-l10n_source" class="wiki-anchor">¶</a></h4>
<pre>
+ element:1 - English (Default) - language:0, l10n_parent=0
+ element:2 - French Translation - language:1, l10n_parent=1 # <- part of a translation chain, which one?!
+ element:3 - Franco-Canadian Translation - language:2, l10n_parent=0 # <- translation chain or free-mode localization?!
</pre>
<p>It is (like in section "Translation from existing localization") not possible to distinguish between "connected translations" and "free-mode localizations".</p>
<a name="References"></a>
<h2 >References<a href="#References" class="wiki-anchor">¶</a></h2>
<p>[1]: DataHandler commands "localize" and "copyToLanguage": <a class="external" href="https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/Typo3CoreEngine/Database/Index.html#command-keywords-and-values">https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/Typo3CoreEngine/Database/Index.html#command-keywords-and-values</a><br />[2]: Association, Aggregation, Composition in UML: <a class="external" href="https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-aggregation-vs-composition/">https://www.visual-paradigm.com/guide/uml-unified-modeling-language/uml-aggregation-vs-composition/</a></p> TYPO3 Core - Task #85640 (New): Use context object in database restrictionshttp://forge.typo3.org/issues/856402018-07-25T10:46:41ZOliver Haderoliver.hader@typo3.org
In order to apply the existing <code>Context</code> object, its aspects need to be applied when executing queries using DBAL. This has possibly an impact on
<ul>
<li>Extbase QuerySettings (has to be checked)</li>
<li>QueryBuilder and applying restrictions</li>
</ul>
<p>By using and adapter, the <code>Context</code> object can be upgraded to be a <code>ContextBasedRestrictionContainer</code> which implements <code>QueryRestrictionContainerInterface</code> which keeps a local reference to the originating <code>Context</code> object in order to retrieve its aspects.</p> TYPO3 Core - Epic #84920 (New): Provide generic context based data retrieval APIhttp://forge.typo3.org/issues/849202018-05-03T14:50:35ZOliver Haderoliver.hader@typo3.org
<p>In order to avoid the requirement of specific knowledge of TYPO3 persistence behavior, such as localization or workspaces, a generic API to retrieve data shall be provided.</p>
The functional relies on these base parameters:
<ul>
<li>context (language, workspace)</li>
<li>permissions (pages, tables, fields, ..., context permissions)</li>
<li>optional behavior (language fallback, individual handling)</li>
</ul>
Basic functionality:
<ul>
<li>retrieve specific entities for the given base parameters (e.g. languages & workspaces resolved automatically)</li>
<li>retrieve any relational entities (children) for the given base parameters (not caring whether 1:n inline or m:n group/db has been defined)</li>
</ul>
Extended functionality:
<ul>
<li>retrieve data based on individual/custom query (fields, constraints, sorting)</li>
<li>retrieve data based on GraphQL query</li>
</ul> TYPO3 Core - Epic #84918 (New): Streamline Permission Layerhttp://forge.typo3.org/issues/849182018-05-03T14:41:43ZOliver Haderoliver.hader@typo3.org
<p>Concerning data handling and persistence, basically only the backend context is considered (in DataHandler, PageLayoutView et al). General permission handling in Extbase and other frontend related implementation is only implemented on the visibility of pages and frontend user groups.</p>
<p>In order to overcome these differences. Permission handling has to be generalized and used in affected components.<br />For instance as an impact, DataHandler does not rely on a BackendUserAuthentication (BE_USER) instance anymore, but on a generic Permission definition that can be used in backend and frontend context.</p> TYPO3 Core - Story #84917 (New): Make use of schema definition & relationship layerhttp://forge.typo3.org/issues/849172018-05-03T14:36:29ZOliver Haderoliver.hader@typo3.org
<ul>
<li>DataHandler, RelationHandler, DataMapProcessor</li>
<li>Extbase DataMapFactory, Storage Backend</li>
<li>FormEngine DataProviders, Containers</li>
<li>RootlineUtility</li>
</ul>
<p>... and more ...</p> TYPO3 Core - Story #84916 (New): Provide generic entity relationship modelhttp://forge.typo3.org/issues/849162018-05-03T14:30:00ZOliver Haderoliver.hader@typo3.org
<p>Expected goal</p>
<pre>
$contentSchemaDefinition = (new SomeService)->getSchemaDefinition('tt_content');
$fileReferenceSchemaDefinition = (new SomeService)->getSchemaDefinition('sys_file_reference');
var_dump($contentSchemaDefinition->getProperty('media')->getRelations());
var_dump($fileReferenceSchemaDefinition->getProperty('uid_foreign')->getRelations());
</pre>
<p>might output something like</p>
<pre>
# relations for tt_content.media
+ ActiveRelation: schemaName "sys_file_reference"
</pre>
<pre>
# relations for sys_file_reference.uid_foreign
+ PassiveRelation: schemaName "tt_content", propertyName: "image"
+ PassiveRelation: schemaName "tt_content", propertyName: "media"
+ PassiveRelation: schemaName "tt_content", propertyName: "assets"
</pre>
<p>Currently the "opposite usage" for relations is not explicitly known. In order to enhance look ups this information should be cached along with the plain schema definition (e.g. TCA).</p> TYPO3 Core - Story #84915 (New): Provide generic entity schema definitionhttp://forge.typo3.org/issues/849152018-05-03T14:19:06ZOliver Haderoliver.hader@typo3.org
<p>Expected goal</p>
<pre>
$factory = new TcaSchemaDefinitionFactory($GLOBALS['TCA']);
$schemaDefinition = $factory->buildForTable('tt_content');
$service = new SchemaDefinitionService();
$mediaProperty = $schemaDefinition->getProperty('media');
$service->isRelational(mediaProperty);
if ($service->getRelationType($mediaProperty) === Relation::TYPE_ONE_TO_MANY_COMPOSITION)) { ... }
</pre>
<p>The API above can still change. Besides that Extbase <code>DataMapFactory</code> could be considered as foundation as well.</p> TYPO3 Core - Epic #84914 (New): Streamline entity configuration layerhttp://forge.typo3.org/issues/849142018-05-03T14:08:35ZOliver Haderoliver.hader@typo3.org
<p>Entity configuration in TYPO3 is done by using TCA (table configuration array). Currently the interpretation of e.g. "what is a 1:n composition (IRRE)" is spread over multiple locations - most importantly to mention are DataHandler, Extbase and FormEngine - but there are much more.</p>
<p>In order to avoid individual (and possible) different interpretation of entity definitions and features and generic configuration shall be introduce to provide access to the the semantics of TCA and FlexForm data structures.</p> TYPO3 Core - Bug #81552 (New): Disable creating new inline child records if allowLanguageSynchron...http://forge.typo3.org/issues/815522017-06-12T13:14:29ZOliver Haderoliver.hader@typo3.org
<p><img src="http://forge.typo3.org/attachments/download/32533/81552.png" alt="" loading="lazy" /><br /><img src="http://forge.typo3.org/attachments/download/32538/81552_2.png" alt="" loading="lazy" /></p>
<p>If allowLanguageSynchronization is active for inline child elements, the "create new" buttons and any other interaction shall be disabled for localized parent records - since these child records. Otherwise there's the possibility to create inconsistent and non-synchronized scenarios.</p> TYPO3 Core - Feature #79105 (New): Extend workspace notification channelshttp://forge.typo3.org/issues/791052016-12-29T13:15:10ZOliver Haderoliver.hader@typo3.org
<p>Currently workspaces only supports sending out notifications via mail, however it would be great if this can be enhanced to push notifications to any other service, like e.g. Slack, IRC. This feature is about providing to possibility to have a custom API for attaching new notification services.</p> TYPO3 Core - Bug #78849 (New): Show logged records of DatabaseWriter in ext:beloghttp://forge.typo3.org/issues/788492016-12-01T12:33:34ZOliver Haderoliver.hader@typo3.org
<p>Log entries that have been persisted using the logging-framework are not visualized in ext:belog.<br />The reason is, that the logging-framework uses different field names for the sys_log table that are not considered.</p> TYPO3 Core - Task #69966 (New): Integrate localization and fallback resolving in PlainDataResolverhttp://forge.typo3.org/issues/699662015-09-19T10:53:29ZOliver Haderoliver.hader@typo3.org
<p>PlainDataResolver is targeted to resolve relations based on a given context (workspaces, localization). The currently implementation is used only for workspaces in the TYPO3 backend. However, the resolving pipe should consider localization and localization fallbacks as well.</p> TYPO3 Core - Feature #65720 (New): Add workspace element filter settingshttp://forge.typo3.org/issues/657202015-03-13T14:55:48ZOliver Haderoliver.hader@typo3.org
<p>The workspace configuration is extended by an element filter setting that allows to define record visibility in the workspace module per stage. This way, it can be defined, that either workspace owner, members or editors/creators of a particular record are allowed to see elements in the module - depending on the setting for the element's workspace stage.</p> TYPO3 Core - Feature #33747 (New): Implement usort() and moveItemAt() in AbstractRecordCollectionhttp://forge.typo3.org/issues/337472012-02-07T21:22:01ZOliver Haderoliver.hader@typo3.org
<p>Current situation:</p>
<pre>
public function usort($callbackFunction) {
// TODO: Implement usort() method with TCEforms in mind
throw new RuntimeException('This method is not yet supported.', 1322545589);
}
public function moveItemAt($currentPosition, $newPosition = 0) {
// TODO: Implement usort() method with TCEforms in mind
throw new RuntimeException('This method is not yet supported.', 1322545626);
}
</pre>