TYPO3 Core

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.

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.

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.

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

+1 for a code-sprint.

We have some not yet reporting bugfixes for workspaces.

Things like saving relation or moving records.

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.

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.