Bug #89383
closed
Restoring deleted content element in workspace fails
100%
Description
When trying to restore a deleted content element in a workspace, database gets inconsistent.
Steps to reproduce:
- Switch to custom workspace
- Create a page
- Create a content element on the page
- Delete the content element
- Open History/Undo for that page
- Restore the deleted content element
- 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.
Updated by Christian Weiske about 5 years ago
- Related to Bug #21299: Can't restore a deleted page in draft workspace added
Updated by Christian Weiske about 5 years 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?
Updated by Benni Mack about 5 years 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).
Updated by Christian Weiske about 5 years ago
So DataHandler's "undelete" handling needs to be extended to support workspaces.
Updated by Christian Kuhn over 4 years ago
- Related to Bug #90679: "Restore record" does not restore record added
Updated by Gerrit Code Review almost 4 years ago
- Status changed from New to Under Review
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/67191
Updated by Gerrit Code Review almost 4 years ago
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/67191
Updated by Gerrit Code Review almost 4 years ago
Patch set 5 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/67191
Updated by Gerrit Code Review almost 4 years ago
Patch set 6 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/67191
Updated by Gerrit Code Review almost 4 years ago
Patch set 7 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/c/Packages/TYPO3.CMS/+/67191
Updated by Christian Kuhn almost 4 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset 5e7cad94c4395f87fc651a62e75bbf55c03d620c.
Updated by Benni Mack almost 4 years ago
- Status changed from Resolved to Closed