Bug #89383

Restoring deleted content element in workspace fails

Added by Christian Weiske 10 days ago. Updated 1 day ago.

Status:
New
Priority:
Should have
Assignee:
-
Category:
Workspaces
Target version:
-
Start date:
2019-10-09
Due date:
% Done:

0%

TYPO3 Version:
9
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

When trying to restore a deleted content element in a workspace, database gets inconsistent.

Steps to reproduce:

  1. Switch to custom workspace
  2. Create a page
  3. Create a content element on the page
  4. Delete the content element
  5. Open History/Undo for that page
  6. Restore the deleted content element
  7. Look at the page: The element is not visible

In database we have two records:

  • "INITIAL PLACEHOLDER": It has "deleted=0" after restoring
  • "First draft version": It has "deleted=1" after restoring

Before restoring, both had deleted=1.


Related issues

Related to TYPO3 Core - Bug #21299: Can't restore a deleted page in draft workspace Accepted 2009-10-19

History

#1 Updated by Christian Weiske 10 days ago

  • Related to Bug #21299: Can't restore a deleted page in draft workspace added

#2 Updated by Christian Weiske 9 days ago

A correct undo action would need to set "deleted=0" also on the workspace overlay record ("draft version').

The database inconsisteny causes further problems: When copying a page, previously not visible/existing elements appear on the copied page because copying uses the placeholder data. (Delete element in workspace and restore it - not visible and seemingly lost. Copy & paste the page, and the restored element is surprisingly visible again on the new page)


I'm not sure how to solve this. TYPO3\CMS\Backend\History\RecordHistory::performRollback() does the undo, but does not care about workspaces.
Should this method also take care of rolling back the workspace overlay record?
If not, which place would be better suited?

#3 Updated by Benni Mack 1 day ago

Thanks for your analysis. I agree that both records should be set to deleted=0.

Christian Weiske wrote:

A correct undo action would need to set "deleted=0" also on the workspace overlay record ("draft version').

The database inconsisteny causes further problems: When copying a page, previously not visible/existing elements appear on the copied page because copying uses the placeholder data. (Delete element in workspace and restore it - not visible and seemingly lost. Copy & paste the page, and the restored element is surprisingly visible again on the new page)


I'm not sure how to solve this. TYPO3\CMS\Backend\History\RecordHistory::performRollback() does the undo, but does not care about workspaces.
Should this method also take care of rolling back the workspace overlay record?
If not, which place would be better suited?

In the end, performRollback calls DataHandler which needs to be handled there (there is a "undelete" command for DataHandler, which seems to not be compatible with workspaces).

Also available in: Atom PDF