Bug #19274

Editors can´t undelete records in history

Added by Andreas Heling about 13 years ago. Updated about 11 years ago.

Should have
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


When an editor tryes to undelete a record in the history, the record will be deleted for a second time. The log give following informations: "Attempt to delete record without delete-permissions. [ERROR: Record could not be fetched.]"

I found the reason for this. In class.t3lib_userauthgroup.php function recordEditAccessInternals() is a call to the function t3lib_BEfunc::getRecord(). If the record, the editor tries to recover is deleted=1 the function will return NULL and the record won´t be recovered.
(issue imported from #M9270)


typo3_bug_9270.patch (2.66 KB) typo3_bug_9270.patch Administrator Admin, 2008-11-11 11:02
9270_editorsUndelete.patch (1.91 KB) 9270_editorsUndelete.patch Administrator Admin, 2009-06-15 06:35
9270_trunk.patch (2.24 KB) 9270_trunk.patch Administrator Admin, 2009-08-21 13:32
9270_4-2_branch.patch (2.25 KB) 9270_4-2_branch.patch Administrator Admin, 2009-08-21 13:33
9270_4-1_branch.patch (2.19 KB) 9270_4-1_branch.patch Administrator Admin, 2009-08-21 13:34

Related issues

Related to TYPO3 Core - Bug #27309: permanently deleting impossible for non admin be_usersClosed2011-06-08


Updated by Christian Hernmarck almost 13 years ago

also in 4.2.2

Would be nice to fix - or don't offer to recover deleted content to editors...


Updated by Christian Hernmarck almost 13 years ago

I have a fix but don't know if it has any other effects...:

in class.t3lib_userauthgroup.php function recordEditAccessInternals(), add a "false" as fifth parameter to the getRecord function call - to prevent hiding the deleted records.
Only admins do not use this check... so all other editors have the same problem.

I don't know if this releases other problems... so please help testing...

function recordEditAccessInternals($table,$idOrRow,$newRecord=FALSE) {
global $TCA;

if (isset($TCA[$table]))        {
// Always return true for Admin users.
if ($this->isAdmin()) return TRUE;
// Fetching the record if the $idOrRow variable was not an array on input:
if (!is_array($idOrRow)) {
// $idOrRow = t3lib_BEfunc::getRecord($table, $idOrRow);
$idOrRow = t3lib_BEfunc::getRecord($table, $idOrRow, '*', '', false);
if (!is_array($idOrRow)) {
$this->errorMsg = 'ERROR: Record could not be fetched.';
return FALSE;



Updated by Christian Hernmarck almost 13 years ago

I have more infos:

in class.t3lib_tcemain.php where the function "recordEditAccessInternals" is called - there seems to be some small "unclarity" ...

line 3966 (in 4.2.2):

function undeleteRecord($table,$uid)    {

ok, and the following:

 * Deleting/Undeleting a record
 * This function may not be used to delete pages-records unless the underlying records are already deleted
 * Deletes a record regardless of versioning state (live or offline, doesn't matter, the uid decides)
 * If both $noRecordCheck and $forceHardDelete are set it could even delete a "deleted"-flagged record!
 * @param       string          Table name
 * @param       integer         Record UID
 * @param       boolean         Flag: If $noRecordCheck is set, then the function does not check permission to delete record
 * @param       boolean         If TRUE, the "deleted" flag is ignored if applicable for record and the record is deleted COMPLETELY!
 * @param       boolean         If TRUE, the "deleted" flag is set to 0 again and thus, the item is undeleted.
 * @return      void
function deleteRecord($table,$uid, $noRecordCheck=FALSE, $forceHardDelete=FALSE,$undeleteRecord=FALSE) {
global $TCA;
// Checking if there is anything else disallowing deleting the record by checking if editing is allowed
$mayEditAccess = $this->BE_USER->recordEditAccessInternals($table,$uid);

so for undelete, the Flag "noRecordCheck" is set (true) but ignored for the first check "$mayEditAccess=...".
Best solution in my eyes: new parameter for "recordEditAccessInternals" if deleted records should be included in check or not.
Otherwise: in my 2nd comment (24922) the solution always checks also for deleted records - or if we ignore the check because of "$noRecordCheck" then everyone can undelete elements even if he's not allowed to edit the record.

I'd like to see some feedback because I don't know about the typo3 internal ways...

Would be fine to fix this - maybe today?



Updated by Christian Hernmarck almost 13 years ago


the 2 lines in class.t3lib_tcemain.php (function deleteRecord) do not appear in 4.0.9 - so, they were introduced in 4.1.x somewehre:

// Checking if there is anything disallowing edit
$mayEditAccess = $this->BE_USER->recordEditAccessInternals($table,$uid);

Therefore the error may appear only in Typo3 4.1.x and 4.2.x -nobody out there who can give a comment what would be best?



Updated by Christian Hernmarck almost 13 years ago

Also appears in 4.2.3

further information: bug was introduced with the bugfixing of bug #15114 (http://bugs.typo3.org/view.php?id=1678).



Updated by Christian Hernmarck almost 13 years ago

I made a patch, could others please test. Thanx


Updated by Uwe Schmelzer over 12 years ago

The bug also appears in 4.2.6.

Thanks for the patch Christian!
Patching didn't work for me, so I've included your suggestions manually.

The updated files
are enclosed in the zip file

Greetz uwe


Updated by Christian Hernmarck over 12 years ago

More infos...
this bug was introduced apparently in v 4.1.4 (dec. 2007) and since then normal editors cannot undelete records (I wonder why so few people noticed this)...
It seems that also in 4.3.0alpha3 this bug still exist.


Updated by Christian Hernmarck over 12 years ago

Also with the new extension "recycler" it's not possible for a normal editor (without admin-rights) to undelete deleted content elements.
This is in the protocol:
"Attempt to delete record without delete-permissions. [ERROR: Record could not be fetched.]"


Updated by Philipp Gampe over 12 years ago

It would be really nice to get this fix into Typo3 4.3 before released


Updated by Rupert Germann about 12 years ago

attached 3 new patches for trunk, 4-2 and 4-1


Updated by Rupert Germann about 12 years ago

FYI committed to:
trunk rev 5960
TYPO3_4-2 rev 5961
TYPO3_4-1 rev 5962

Also available in: Atom PDF