Task #54948
closed
Epic #58282: Workspaces Workpackage #2
Story #58284: Bug fixes & Behaviour
swap workspace won't reset t3ver_wsid
Added by Michael Voehringer over 10 years ago. Updated about 4 years ago.
0%
Description
This is an followup problem to #37065 and change set a81a5816cf94ed873978d85dad25f6a3b7823b74. This patch introduced an new check to the t3ver_wsid (line 1102). But this field is not always set to the right workspace.
For example if you create new content in the workspace and the choose the mass action "swap", TYPO3 will not set the t3ver_wsid to 0. See attached screenshots for the db status.
The result is: In live version everything looks good, but all the swapped content disappears in the workspace preview.
Files
| before_swap.png (57.4 KB) before_swap.png | tt_content before swap | Michael Voehringer, 2014-01-13 14:55 | |
| after_swap.png (53.9 KB) after_swap.png | tt_content after swap | Michael Voehringer, 2014-01-13 14:55 | |
| v6.2.3-before.png (28.4 KB) v6.2.3-before.png | Michael Voehringer, 2014-06-10 15:37 | ||
| v6.2.3-after-swap.png (28.1 KB) v6.2.3-after-swap.png | Michael Voehringer, 2014-06-10 15:37 |
Updated by Oliver Hader about 10 years ago
- Status changed from New to Needs Feedback
Thanks for your report. However, the change you mentioned (frontend preview) does not seem to be related to the problem of not setting/modifying "t3ver_wsid" in the backend.
Besides that, the records in the screenshots you provided do not look like having been processed at all with a swap/publish command in the backend.
I've been working on functional test cases the last few weeks for workspaces - thus, your scenario could be part of those tests as well - especially the edge cases are interesting here.
So, can you please give some more information what you did and maybe which warning/errors have been shown (see Admin Log in the backend as well).
Does the problem occur only in TYPO3 4.5 or can you reproduce that in the current master (TYPO3 6.2 LTS development) as well?
Thanks in advance for your feedback!
Updated by Oliver Hader almost 10 years ago
Short reminder on this feedback request. Thanks in advance!
Updated by Michael Voehringer almost 10 years ago
- File v6.2.3-before.png v6.2.3-before.png added
- File v6.2.3-after-swap.png v6.2.3-after-swap.png added
Hi Oliver,
i now tested this issue on an clean (Intropackage) 4.5.34 and on the latest 6.2.3 and still can reproduce this error. I found this issue because we use the "Swap content" of the workspace module a lot and after updating to an T3 Version which includes change set a81a5816cf94ed873978d85dad25f6a3b7823b74 a lot of duplicate Content-Element appeared in the frontend. In the change T3 introduce an an new condition which checks the t3ver_wsid.
Here is what i did:
1.) Install T3
2.) Create workspace
3.) Create new page in the workspace 
4.) Go to the Workspace module and choose "Mass action"->SWAP.
5.) after you swap the versions in the DB the t3ver_wsid is still 1 
Please let me know if i can help you with this issue.
Updated by Oliver Hader almost 10 years ago
- Parent task changed from #54853 to #58284
Updated by Oliver Hader almost 10 years ago
Alright & thanks, I moved the issue to the current workpackage and will have a look soon (with some functional tests for that scenario)
Updated by Oliver Hader almost 10 years ago
- TYPO3 Version changed from 4.5 to 6.2
By looking to the SQL data, it looks correct since "swapping" just switches live versions with workspace versions. For the "publish" task (one-way) the t3ver_* fields are cleared...
However, the "swap" action is still missing in the functional test cases, there's currently only "modify", "publish" (single record) and "publishAll" (whole workspace)
Updated by Michael Voehringer over 9 years ago
Hi Oliver,
ok, if the SQL data is correct then there must be an bug in the SQL-query. If you can have a look at the changeset form ticket #37065 ( https://forge.typo3.org/projects/typo3cms-core/repository/revisions/a81a5816cf94ed873978d85dad25f6a3b7823b74/diff/typo3/sysext/frontend/Classes/Page/PageRepository.php) on line 878 -880 there where an new condition added which filters out the swapped records when you are in an workspace.
Maybe we should change the title of this bug?
Updated by Alexander Opitz over 9 years ago
- Status changed from Needs Feedback to New
Updated by 
Updated by Oliver Hader over 8 years ago
- Assignee set to Oliver Hader
- Target version changed from 7.5 to 7 LTS
- Complexity set to medium
Updated by Riccardo De Contardi about 4 years ago
- Status changed from New to Needs Feedback
is the issue still reproducible on version 10.x? I tried the following test on 10.4.0-dev:
Prerequisites¶
- a workspace "draft" (mine has ID=1)
Test procedure¶
1) LIVE workspace > create a content element on the page, type: Header, headline: "THIS IS TEST 54948 IN LIVE" (ID=275)
2) Switch to "Draft" Workspace and edit the element, change it to "THIS IS TEST 54948 CHANGED IN WS", save
The result on database is:
| UID | PID | Header | t3_origuid | t3ver_oid | t3ver_wsid | t3ver_state | t3ver_stage | t3ver_count | t3ver_tstamp | t3ver_move_id |
|---|---|---|---|---|---|---|---|---|---|---|
| 275 | 269 | THIS IS TEST 54948 IN LIVE | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 276 | -1 | THIS IS TEST 54948 CHANGED IN WS | 275 | 275 | 1 | 0 | 0 | 0 | 0 | 0 |
3) Go to workspace module > select the content element > choose selection action > swap
| UID | PID | Header | t3_origuid | t3ver_oid | t3ver_wsid | t3ver_state | t3ver_stage | t3ver_count | t3ver_tstamp | t3ver_move_id |
|---|---|---|---|---|---|---|---|---|---|---|
| 275 | 269 | THIS IS TEST 54948 CHANGED IN WS | 275 | 0 | 0 | 0 | 0 | 0 | 1583189782 | 0 |
| 276 | -1 | THIS IS TEST 54948 IN LIVE | 0 | 275 | 1 | 0 | 0 | 1 | 1583189782 | 0 |
After the swapping, in the preview, the content element is visible and it has the correct label (THIS IS TEST 54948 IN LIVE)
Is everything correct?
P.s. I have a doubt about the swapping of * t3_origuid* value, it seems strange that it has been swapped.
Updated by Benni Mack about 4 years ago
- Status changed from Needs Feedback to Closed
We've actually reworked this exact change in TYPO3 v10, so I consider this issue solved. Let me know if there is still something to do, so I will re-open the ticket.