Core

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!

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.

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)