Project

General

Profile

Actions

Task #45676

closed

Epic #55070: Workpackages

Epic #54851: WP: Workspaces IRRE & MM bugfixes

Story #54853: As a user I want to correctly create, modify, preview and publish IRRE & MM related workspace changes

Task #56376: Invalid relations of IRRE records in workspaces

Workspace references are not considered

Added by Oliver Hader about 11 years ago. Updated almost 10 years ago.

Status:
Rejected
Priority:
Must have
Assignee:
-
Category:
Extbase
Target version:
-
Start date:
2013-02-20
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
5.3
Tags:
ecs13ws
Complexity:
Sprint Focus:

Description

Workspace references for MM and IRRE records are not considered, since only the UID of the live record is considered (due to overlays).
Since this might(!) work in most cases for existing records that get modified in a workspace, it does not not for records that are newly created. In this case, the "live record" is a workspace placeholder without any data.

MM and IRRE always need to use the most specific UID in references, which is the versioned record in this case.


Related issues 3 (0 open3 closed)

Related to TYPO3 Core - Task #29278: Lost relations on copying IRRE children in workspacesRejected2011-08-26

Actions
Related to TYPO3 Core - Bug #38703: Publishing records with IRRE records -> lost relationRejected2012-07-06

Actions
Is duplicate of TYPO3 Core - Task #59107: Extbase behaviour concerning workspacesClosedOliver Hader2014-05-26

Actions
Actions #1

Updated by Thorsten Kahler about 11 years ago

A few questions/notes:

  • Did you add this issue here (project "Extbase") intentionally or by accident? This seems like a Core issue to me. Or is it just meant as reminder for a Core issue?
  • When you refer to IRRE you specifically refer to MM-enabled and symmetric IRRE relations? Values stored in comma-separated lists should AFAIK always point to live records.

I recently stumbled over an issue with MM_opposite_field and my impression was that the best (or only?) way to address all issues in this area would be to add versioning fields to MM tables.

Actions #2

Updated by Gerrit Code Review about 11 years ago

  • Status changed from New to Under Review

Patch set 2 for branch extbase_1-3 has been pushed to the review server.
It is available at https://review.typo3.org/18261

Actions #3

Updated by Timo Webler about 11 years ago

All relations must point to the live record. New placeholder are also live record.
For every live record, you must call "versionOL" functions.

See #37065 and #37209.

With #37065 enable fields filter all version records. So you can not select a version record for workspace preview.

Also see:

http://docs.typo3.org/typo3cms/TCAReference/Reference/Columns/Inline/Index.html:

Please note that IRRE does not fully work in conjunction with versioning. Only 1:n relationships are supported in workspaces (since TYPO3 4.5).

http://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/Workspaces/Index.html#workspaces-frontend-problems

Lookups and searching for records based on other fields than uid, pid or "enableFields" will never reflect workspace content since overlays happen to online records after they are selected.

Actions #4

Updated by Jo Hasenau about 11 years ago

So you seriously want to tell us that this bug can't be fixed because it has been documented before?!?

The fact that IRRE does not fully work in conjunction with versioning is exactly the problem we are going to fix with this patch.
Sad enough it has been documented, that this is a known(!) bug nobody seemed to care about before.

Since both, IRRE and Workspaces are functions of the core, we have to make sure they will work together.
Just telling people "You can't use it because IRRE does not work with workspaces!" can't be the solution.

Actions #5

Updated by Oliver Hader about 11 years ago

Hi Timo,

thanks for the links, especially the link to IRRE since I've written those lines on my own back then...
However, I don't get your suggestion here. Is it about to drop it completely since the documentation states that only 1:n relations are supported?

The second link to the documentation is the opposite of your suggestion. Other fields than the mentioned ones are not updated in new-placeholders and thus querying the "live-version" for those fields fails unless the shadow-fields are set. Therefore, only the specific workspace version contains the most relevant data.

New-placeholders are similar to live-records but not the same since they represent a new record on a particular workspace, thus these records have a t3ver_wsid not equal to 0.

Here's a scenario, why using always the live-version cannot work for MM relations:

In live workspace

  • tx_ext_parent with uid 1 has children
    • tx_ext_child with uid 1
    • tx_ext_child with uid 2

In "draft" workspace

The child records get reordered

  • tx_ext_parent with uid 2 (overlay to uid 1) has children
    • tx_ext_child with uid 4 (overlay to uid 2)
    • tx_ext_child with uid 3 (overlay to uid 1)

Result

Result in frontend still contains the old live-sorting unless records are published.
A similar behavior was recognized for tt_content in the backend page module - in this case the record sets need to be reordered with additional methods - see https://review.typo3.org/#/c/17497/

Conclusion

Since the whole workspaces topic is not easy and takes time, I suggest to have a live code-sprint (e.g. in Frankfurt at dkd office with Thorsten and you and other interested parties) to get those things done.

Best regards,
Oliver

Actions #6

Updated by Timo Webler about 11 years ago

+1 for a code-sprint.

We have some not yet reporting bugfixes for workspaces.

Things like saving relation or moving records.

Actions #7

Updated by Jo Hasenau about 11 years ago

So what about reporting them now and discussing your fixes in the appropriate bug reports here on forge?
If you already got these fixes, I don't see why we would need a code sprint for these tasks.

Actions #8

Updated by Timo Webler about 11 years ago

The right solution for mm relation are:

In live workspace

tx_ext_parent with uid 1 has children
tx_ext_child with uid 1
tx_ext_child with uid 2

In "draft" workspace

The child records get reordered

tx_ext_parent with uid 2 (overlay to uid 1) has children
tx_ext_child with uid 2
tx_ext_child with uid 1

After load child records do the overlay.

With #37209 and #37065 you doesn't has to filter out workspace records. This is no extbase bug.

If OK, I will modify the patch for this behaviour.

Actions #9

Updated by Anja Leichsenring almost 11 years ago

  • Target version changed from 4.5.24 to Extbase 1.3
Actions #10

Updated by Anja Leichsenring almost 11 years ago

  • Target version changed from Extbase 1.3 to Extbase 6.3
Actions #11

Updated by Anja Leichsenring almost 11 years ago

  • Target version changed from Extbase 6.3 to Extbase 6.2
Actions #12

Updated by Felix Oertel over 10 years ago

  • Tags set to ecs12ws
Actions #13

Updated by Felix Oertel over 10 years ago

  • Priority changed from Should have to Must have
  • Tags changed from ecs12ws to ecs13ws

Right resolving of relations in workspaces will be part of #ecs13ws.

Actions #14

Updated by Oliver Hader about 10 years ago

  • Parent task set to #54853
Actions #15

Updated by Oliver Hader about 10 years ago

  • Assignee deleted (Oliver Hader)
Actions #16

Updated by Oliver Hader about 10 years ago

  • Status changed from Under Review to Needs Feedback
Actions #17

Updated by Oliver Hader about 10 years ago

  • Project changed from 534 to TYPO3 Core
  • Category deleted (Extbase: Generic Persistence)
  • Target version deleted (Extbase 6.2)
Actions #18

Updated by Oliver Hader about 10 years ago

  • Category set to Extbase
Actions #19

Updated by Oliver Hader about 10 years ago

  • Status changed from Needs Feedback to On Hold
Actions #20

Updated by Oliver Hader about 10 years ago

  • Parent task changed from #54853 to #56376
  • PHP Version set to 5.3
  • TYPO3 Version set to 6.2
  • Is Regression set to No
Actions #21

Updated by Oliver Hader almost 10 years ago

  • Status changed from On Hold to Rejected

Since IRRE persistence has changed (always live/default, then overlay), issue #59107 holds the new approach concerning Extbase changes

Actions

Also available in: Atom PDF