Disable users which are restricted to only non default languages to handle page records
In case that an user is restricted to some language and is not allowed to see the default language the user see the disable/enable and the edit entries in the context menu of the page tree and is able to execute this actions. He also can edit the default page title directly in the page tree via double click.
This bug appears not only in 6.1 but also in 6.0, 4.7 and 4.5. I didn't test it in 4.6, but probably it's the same.
Updated by Frank Frewer about 8 years ago
This patch hides not only the disable/enable and the edit entries in context menu but also history/undo and the whole PageActions submenu with new, cut, copy, paste into, paste after and delete, because all of this actions enable the user to modify the page record.
Updated by Ernesto Baschny about 8 years ago
Although already merged, I don't think the merged commits are the right solution. They only (try to) fix the GUI leaving the whole permission system (TCEmain) untouched.
Currently the behavior of the permissions system (TCEmain and thus also all other components) is to use "checkLanguageAccess" only if the TCA for the table has a "languageField".
"pages" is not such a table, because there is "pages_language_overlay". So the current integrators solution to restrict a user not to be able to edit the "Original Language" is to remove the permissions for editing table "pages" and only allow "pages_language_overlay". See also #27794.
This is not what is being done in the patch, but instead you simply check for checkLanguageAccess.
Similar problem we have in the "List view", as the context menu provides more options (i.e. for content elements) than really permitted (see #19467). Permission check in TCEmain is more "aggressive" than in the GUI.
A solution to fix the GUI (context menu in page tree) would be to check if user has "edit permissions" on the "pages" table - just like TCEmain also does. But this is not what is being reported here, as there are other ways to get the "page edit" screen other than from the page tree.
As this is confusing for integrators in general, I would rather propose that someone thinks about a better approach on "language restriction permissions on pages" in the first place before fixing the GUI.
I am not sure yet if we should revert this merge, but I am currently pretty sure we should not backport that to 4.5.
Maybe in your research you find out different aspects than I did or you can prove me wrong as I have only touched the "surface" of the whole complex. Please let me know!