TYPO3 Forge: Issueshttp://forge.typo3.org/http://forge.typo3.org/themes/typo3_forge/favicon/favicon.png?17058661692020-09-22T16:53:41ZTYPO3 Forge
Redmine TYPO3 Core - Bug #92372 (Needs Feedback): Duplicates when copying a page having moved elements in...http://forge.typo3.org/issues/923722020-09-22T16:53:41ZOliver Haderoliver.hader@typo3.org
<a name="Steps"></a>
<h2 >Steps<a href="#Steps" class="wiki-anchor">¶</a></h2>
<ul>
<li>in live
<ul>
<li>having a page</li>
<li>having three content elements A, B, C on that page</li>
<li>having page localization of that page</li>
<li>having all three content elements localized (in connected mode)</li>
</ul>
</li>
<li>in workspace
<ul>
<li>move content element A after B</li>
<li>copy that page as new sibling on same level</li>
</ul></li>
</ul>
<a name="Bugs"></a>
<h2 >Bugs<a href="#Bugs" class="wiki-anchor">¶</a></h2>
<ul>
<li>localized version of moved record (having move-placeholders in workspace) are duplicated
<ul>
<li>→ localized version of element A is show twice in backend</li>
<li>→ in the frontend there is just one record rendered, no duplicates</li>
</ul>
</li>
<li>copied content elements in that page are not reflecting the proper order
<ul>
<li>→ should be B, A, C</li>
<li>→ actually is A, B, C since order was taken from live workspace, move-placeholders were ignored when copying the page</li>
</ul></li>
</ul>
<p>Tests at <a class="external" href="https://github.com/TYPO3/TYPO3.CMS/blob/8457e82596fe232b7699fdd660dd18be8bb7c800/typo3/sysext/workspaces/Tests/Functional/DataHandling/Regular/Modify/DataSet/changeContentSortingAndCopyDraftPage.csv#L36">https://github.com/TYPO3/TYPO3.CMS/blob/8457e82596fe232b7699fdd660dd18be8bb7c800/typo3/sysext/workspaces/Tests/Functional/DataHandling/Regular/Modify/DataSet/changeContentSortingAndCopyDraftPage.csv#L36</a> (starting in line 36 with uids 335+) unfortunately contain this misbehaviour...</p> TYPO3 Core - Bug #89138 (Closed): Correctly retrieve workspace versionshttp://forge.typo3.org/issues/891382019-09-10T23:54:34ZOliver Haderoliver.hader@typo3.org
<ul>
<li>Clipboard now correctly resolves record localizations of a workspace</li>
<li>PageLayoutController new correctly determines sub-pages that are new in a particular workspace</li>
<li>SlugHelper & TypoScriptTemplateModuleController can be simplified by using WorkspaceRestriction directly</li>
<li>common function test scenario tree (based on YAML) is introduced for ext:backend in order to be used as structure for other tests</li>
<li>required testing framework changes support version and language variants and combination much better now</li>
</ul> TYPO3 Core - Bug #87995 (Closed): Cannot preview workspace changes in frontendhttp://forge.typo3.org/issues/879952019-03-25T10:54:48ZOliver Haderoliver.hader@typo3.org
<p>When previewing workspace changes in the frontend using split view (/typo3/index.php?route=%2Fworkspace%2Fpreview-control%2F&token=...&id=...) an exception is thrown.</p>
<pre>
#1518472189 TYPO3\CMS\Core\Error\Http\PageNotFoundException
Request parameters could not be validated (&cHash comparison failed)
</pre> TYPO3 Core - Bug #84985 (Closed): Published workspace record show in page treehttp://forge.typo3.org/issues/849852018-05-12T17:27:42ZOliver Haderoliver.hader@typo3.org
<a name="Steps-to-reproduce"></a>
<h3 >Steps to reproduce<a href="#Steps-to-reproduce" class="wiki-anchor">¶</a></h3>
<ul>
<li>switch to some workspace</li>
<li>change title of page & save</li>
<li>publish workspace version to live</li>
<li>reload page tree</li>
</ul>
<a name="Result"></a>
<h3 >Result<a href="#Result" class="wiki-anchor">¶</a></h3>
<ul>
<li>page tree shows modified value</li>
<li>page tree shows previous old version</li>
</ul>
<a name="Background"></a>
<h3 >Background<a href="#Background" class="wiki-anchor">¶</a></h3>
<p>When publishing workspace records, the previous old version is still persisted with <code>pid=-1</code> and <code>t3ver_wsid=0</code> - that's correct. However, these records are not not filtered in the page tree.</p>
<a name="Pointer"></a>
<h3 >Pointer<a href="#Pointer" class="wiki-anchor">¶</a></h3>
<p>Flaws in resolving records in <code>PageTreeRepository::fetchAllPages</code> and maybe in <code>BackendWorkspaceRestriction</code> usage...</p> TYPO3 Core - Bug #81950 (Closed): Resolve disabled sys_workspace.unpublish_timehttp://forge.typo3.org/issues/819502017-07-24T15:15:03ZOliver Haderoliver.hader@typo3.org
<p>The property <code>sys_workspace.unpublish_time</code> was hidden during TYPO3 4.5 development from being displayed with a remark that the feature would not be working (see <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: "Un-Publish:" should be hidden (Closed)" href="http://forge.typo3.org/issues/12333">#12333</a>). However, in version 8.7 and 9-dev the TCA property is still available and still handled in <code>AutoPublishService</code> - however, there's not possibility in the regular backend to define that field.</p>
<p>The workspace auto-publishing process was thought to automatically push a (temporary) version to live at a given time (publish), as well as reverting that back at some other date (unpublish). The wording of "publishing" is misleading here, since it actually should be a "swapping" process which allows to switch the live and version state of some element at any time.</p>
<p>Thus, now we can either remove the <code>unpublish</code> behavior completely (from TCA and <code>AutoPublishService</code>) or "enable" this feature again (adding it to TCA types again) & providing better description and documentation.</p> TYPO3 Core - Bug #80995 (Closed): Content of hidden page not shown in workspace previewhttp://forge.typo3.org/issues/809952017-04-25T01:12:48ZOliver Haderoliver.hader@typo3.org
<p>New pages in a workspace are created as hidden per default. If either the hidden page or enabled version (the new-placeholder still stays hidden) shall be previewed in the frontend, no content elements are shown.</p>
<p>Parts of previous TYPO3 CMS 7 behavior of PageRepository has been extracted to distinct query restriction interceptors. However, back then not any enable restrictions were not applied if workspaces version preview was active.</p> TYPO3 Core - Bug #80663 (Closed): Inline references are bound to versioned pagehttp://forge.typo3.org/issues/806632017-04-03T18:39:24ZOliver Haderoliver.hader@typo3.org
<p>When modifying inline child elements that belong to a page as parent record in a workspace, the pid values of these inline children are bound to the page version instead of the according counterpart (real record or placeholder) of the live workspace.</p> TYPO3 Core - Bug #79048 (Closed): Cannot interact with versions on all workspaces tabhttp://forge.typo3.org/issues/790482016-12-20T13:13:33ZOliver Haderoliver.hader@typo3.org
<p>Interacting with workspace versions using the "all workspaces" tab in the workspace module is not possible. The process tries to use the current workspace, which is in this case the virtual workspace with ID -98 - which of course does not exist.</p> TYPO3 Core - Bug #77375 (Closed): MM references are not transformed to versioned entitieshttp://forge.typo3.org/issues/773752016-08-03T12:38:20ZOliver Haderoliver.hader@typo3.org
Scenario:
<ul>
<li>using a workspace</li>
<li>using a MM intermediate table for relations</li>
<li>having versioned entities on both sides of the relation to be defined</li>
<li>however, the live uids of the entities are submitted to the data handler</li>
</ul>
Problem:
<ul>
<li>MM relation is created with the live uids on one side</li>
</ul>
Solution:
<ul>
<li>convert submitted relation uids to accordant version uids in workspace context</li>
</ul> TYPO3 Core - Bug #77374 (Closed): Opposite MM relation between both new entities not createdhttp://forge.typo3.org/issues/773742016-08-03T11:14:54ZOliver Haderoliver.hader@typo3.org
Scenario:
<ul>
<li>usage in a workspace</li>
<li>tt_content and sys_category records are created at the same time with defining an MM relation</li>
<li>sys_category.items (group/db field, with MM and opposite usage defined) is filled with accordant tt_content record</li>
</ul>
Problem:
<ul>
<li>the remap-stack in DataHandler does not consider references that are defined in a group/db field</li>
<li>thus, these kind of relations are just not set, since the opposite reference uid cannot be resolved</li>
</ul>
Solution:
<ul>
<li>process group/db relations with new record uids in remap-stack</li>
</ul> TYPO3 Core - Bug #73502 (Closed): Workspace Module continiously reloadinghttp://forge.typo3.org/issues/735022016-02-16T18:50:43ZOliver Haderoliver.hader@typo3.org
<p>Since <a class="changeset" title="[TASK] Use getAbsoluteWebPath instead of extRelPath In order to be more flexible for path resolv..." href="http://forge.typo3.org/projects/typo3cms-core/repository/1749/revisions/2f0a9521b343f757b543a9f8f2ac1ba9d06a69e2">2f0a9521b343f757b543a9f8f2ac1ba9d06a69e2</a> the workspace module is continiously reloading.</p> TYPO3 Core - Bug #73243 (Closed): Stage buttons shown in frontend without user being repsonsiblehttp://forge.typo3.org/issues/732432016-02-11T15:50:44ZOliver Haderoliver.hader@typo3.org
<p>The workspace preview in the frontend shows the buttons to the previous and next stage if the user is not responsible for the current stage. Clicking the button does not forward the records to the names stage however - this is caught by DataHandlerHook in EXT:version.</p> TYPO3 Core - Bug #72992 (Closed): No action icons in the workspace module anymorehttp://forge.typo3.org/issues/729922016-01-28T17:05:38ZOliver Haderoliver.hader@typo3.orgTYPO3 Core - Bug #72225 (Closed): Workspace page previews collide with generated preview linkshttp://forge.typo3.org/issues/722252015-12-14T22:53:45ZOliver Haderoliver.hader@typo3.org
<p>Workspace page previews collide with that configuration that might have been set by using a preview link containing a ADMCMD_prev command. The keyword "IGNORE" is introduced to actually ignore these configurations when viewing a page from the workspace module.</p> TYPO3 Core - Bug #70921 (Accepted): Really resolve meaning of FlexForm fields in version dependen...http://forge.typo3.org/issues/709212015-10-21T18:28:36ZOliver Haderoliver.hader@typo3.org