Bug #93714
open
Editors can't (recursively) restore records from Recycler
0%
Description
As an admin you are able to restore page records with Recycler, as an editor you can't.
The following needs to be true, which is the default configuration:$GLOBALS['TYPO3_CONF_VARS']['BE']['lockBeUserToDBmounts'] = true;
The problem is the Recycler is checking the page access for the backend user, unsetting $GLOBALS['TCA']['pages']['ctrl']['delete'] temporarily to get the deleted pages. This does not work. The rootline is calculated using BackendUtility::BEgetRootLine() with the deleted page as a starting point for the calculation. BackendUtility::BEgetRootLine() and BackendUtility::getPageForRootline() are using runtime cache. The runtime cache in BackendUtility::getPageForRootline() is being filled with a query statement (including deleted restriction) before checking the page access AND before unsetting $GLOBALS['TCA']['pages']['ctrl']['delete'] . The same statement is used within the Recycler (including deleted restriction) which will always make the deleted page inaccessible.
To track this bug down follow:
TYPO3\CMS\Recycler\Domain\Model\DeletedRecords::checkRecordAccess()
TYPO3\CMS\Recycler\Utility\RecyclerUtility::checkAccess()
TYPO3\CMS\Core\Authentication\BackendUserAuthentication::calcPerms()
TYPO3\CMS\Core\Authentication\BackendUserAuthentication::isInWebMount()
TYPO3\CMS\Backend\Utility\BackendUtility::BEgetRootLine()
TYPO3\CMS\Backend\Utility\BackendUtility::getPageForRootline()
Updated by Patrick Broens over 3 years ago
How to reproduce:
- Make a root page
- Switch to an editor which proper access
- Make a subpage of this root page
- Delete the subpage
- Make a content element in the root page
- Delete the content element
- Go to the Recycler module and click the root page
- The subpage is not in the list to restore
The deleted content element is needed to reproduce, since this will store the query statement ('getPageForRootlineStatement-' . $statementCacheIdent) in the runtime cache before the access to the deleted pages is calculated.
In my case deleted tt_content records were fetched before page records.
Updated by Dennis Prinse about 3 years ago
- Subject changed from Editors can't restore page records in Recycler to Editors can't (recursively) restore records from Recycler
As far as I could see during debugging this issue, restoring pages does work for non-admin users, however restoring records recursively does not work properly.
If one goes to the recycler, choose the page they want to restore and select Recover content and subpages recursively only the selected page and its subpages are recovered, but not the records that are stored in the deleted pages.
I tried adjusting the BackendUtility::getRecord() call at RecyclerUtility.php#L64 to the code below
BackendUtility::getRecord('pages', $calcPRec['pid'])BackendUtility::getRecord('pages', $calcPRec['pid'], '*', '', false)
Without this adjustment, the DeletedRestriction will be added to the query, which leads to the problem that the page from which the records have to be restored can not be found because it is still marked as deleted. This results in null as return value. Inside the BackendUserAuthentication::calcPerms(), the check below returns Permission::NOTHING and records other than pages are not restored.
if (!$this->isInWebMount($row)) {
return Permission::NOTHING;
}
The adjustment to leave out the DeletedRestriction does fix that $row in the snippet above is not null, so theoretically the records should be recovered. However, when calculating the rootline inside BackendUtility::BEgetRootLine(), self::getPageForRootline() will be executed, again with the deleted constraints active resulting in an empty (false) query result. This causes permissions to be calculated as Permission::NOTHING.
As far as I could test this bug is aleady there since at least TYPO3 v8 and is still there in TYPO3 v11, so it is not limited to TYPO3 v10 only.