limited to languages; still can delete content element
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)
#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 !
#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.
#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
#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?