Bug #15114

limited to languages; still can delete content element

Added by Cathomen Claudio about 15 years ago. Updated over 12 years ago.

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


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


If I limit a be_user to a certain language, the user doees not have the possibility to edit, unhide etc. content from unallowed languages. BUT he can still delete the whole content element, even ones wich are in unallowed languages.

(issue imported from #M1678)

0001678-lang_limit_del.patch View (899 Bytes) Administrator Admin, 2006-08-04 01:34

0001678-lang_limit_move.patch View (873 Bytes) Administrator Admin, 2006-08-04 01:34

bug_1678_4.1.1.diff View (1.58 KB) Administrator Admin, 2007-07-02 18:34

bug_1678_V2_4_1.diff View (21 KB) Administrator Admin, 2007-11-21 16:01

bug_6682_trunk_v2.diff View (1.72 KB) Administrator Admin, 2007-11-21 16:02

bug_1678_V2_trunk.diff View (16 KB) Administrator Admin, 2007-11-28 16:15

Related issues

Related to TYPO3 Core - Feature #14953: In Extended view it should also be possible to disable icons for deletion, cut, copy and others... Closed 2005-08-30
Related to TYPO3 Core - Bug #16572: Limit to Languages doesn't restrict editing of "alternative page language records" Closed 2006-09-18
Related to TYPO3 Core - Bug #17819: Page and info module ignore "Limit to language" Closed 2007-11-20


#1 Updated by Christian Welzel about 15 years ago

There is also a problem with creation of new content elements.
i have 5 languages on my page and for every language a be-user account for the translator. every translator is restricted to the default language and his own.
But when the user selects "page"->the page->"languages"->default language, he can see all languages and even has the buttons to copy std-content from default language to an language he has no rights for. if he does this, the new content element is not inserted to this (wrong) language, but into the default-language.
this is clearly a bug.

by the way: an backend user should not be able to see the languages, he has no rights for !

#2 Updated by Sebastian Kurfuerst about 15 years ago

it would be great if you could supply a T3X file to test this problem. This would make solving it a lot easier. Thanks :-) Sebastian

#3 Updated by Christian Welzel almost 15 years ago

I send my .t3d file to Sebastian per private Mail.

#4 Updated by Sebastian Kurfuerst almost 15 years ago

I dug a bit deeper into the problem.
The main issue is that TCEmain doesn't check if the user has rights for this language when creating new content elements (process_datamap). There, the check for $BE_USER->recordEditAccessInternals(...) or $BE_USER->checkLanguageAccess is missing in the section where new CEs are created.
The other issue (deletes and moves are possible) lies in process_cmdmap. There, no permission checking for limited languages is done whatsoever.
I am not sure how to fully fix these issues in a consistent and clean manner, but I will have a look into it.
Greets, Sebastian

#5 Updated by Andreas Gaufer about 14 years ago

I guess no one is realy working on this right? I'll try to start working on this if noone replys the next few days.

#6 Updated by Andreas Gaufer about 14 years ago

Here are two patches that try to solve this bug

They are tested with 4.0.1 and make the dissallowed edit and delete
produce a exeption as suspected. No extra side effect tests where done.

It may be even nicer to use extra conditional blocks to produce a more
percise error message. But this would add another ident which is bad

#7 Updated by Sebastian Kurfuerst about 14 years ago


#8 Updated by Dmitry Pikhno over 13 years ago

still see this problem in typo3 4.1beta3

#9 Updated by Christian Welzel over 13 years ago

This bug should be set to related to #16572.

#10 Updated by Helmut Hummel over 13 years ago

Added a single patchfile to use for TYPO3 4.1.1
It contains the changes suggested by Andreas Gaufer

#11 Updated by Basti Baumann over 13 years ago


with the last patch from Helmut editing, deleting and moving is not allowed, but a user can still create new entries in the default language.

#12 Updated by Benni Mack almost 13 years ago

Any progress on this one?

#13 Updated by Christian Zehaczek almost 13 years ago

Confirmed. The bug still occurs in 4.1.3 and as well 4.2.0alpha1.

An unprivilueged user still can:
- cut & paste
- move around
- delete
- resort (depends on record setup)

#14 Updated by Helmut Hummel almost 13 years ago

it's not true that adding new entries to the default language is possible (even without applied patch). But adding an entry to "all languages" works and these entries are placed in the default language column.

But it's really strange, that after moving a record which is "all languages" (sys_language_uid=-1), the language field is connverted to default language (sys_language_uid=0) :-/

What is this "all languages" all about anyway?

If you do not want your editors to add something to this "language" you can simply disable the item with user/group TS:

page.TCEFORM.tt_content.sys_language_uid.removeItems = -1,0

Hope this workaround helps others and someone finds the time to have a deeper look at this very important issue...

#15 Updated by Helmut Hummel almost 13 years ago

After reading the function checkLanguageAccess in class.t3lib_userauthgroup.php I come to the conclusion, that beeing able to add content elements to sys_language_uid=-1 is intentional, so setting page.TCEFORM. isn't a workaround but a straightforward solution.

Does anyone knows what sys_language_uid=-1 was(or is) used for?

#16 Updated by Christian Zehaczek almost 13 years ago

Hi Helmut,

as it says, you are able to add content that is shown up on ALL translations using "-1".

Just tried your latest patch on the 4.1.3, works great and solves all my mentioned issues above. Thank you.

#17 Updated by Benni Mack almost 13 years ago

so if the patch works, Helmut, do you want to send it to the core list?

#18 Updated by Helmut Hummel almost 13 years ago

I added two new patchfiles (simply cleanup and output specific error messages):

for 4_1 branch, since there were significant done changes done in trunk for moving records.

patch against current trunk

#19 Updated by Helmut Hummel almost 13 years ago

bug_6682_trunk_v2.diff has nothing to do with this bug and was uploaded by accident :-/ It should be deleted by an admin

#20 Updated by Basti Baumann almost 13 years ago

Is it possible to publish the whole and edited class.t3lib_tcemain.php? It would be easier for me (cause copy&paste won´t work for me).

#21 Updated by Benni Mack almost 13 years ago

Hey Basti, send me both files (before and after), I can create the patch for you this one time: mack (ad) xnos (dat) org

Also available in: Atom PDF