Bug #47126

Disable users which are restricted to only non default languages to handle page records

Added by Frank Frewer about 8 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Backend User Interface
Target version:
-
Start date:
2013-04-11
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
6.1
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

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.


Related issues

Related to TYPO3 Core - Feature #46017: Language switcher for pagetree in BackendNew2013-03-04

Actions
Related to TYPO3 Core - Bug #47144: Editor can always edit the default language of pagesClosed2013-04-11

Actions
#1

Updated by Gerrit Code Review about 8 years ago

  • Status changed from New to Under Review

Patch set 1 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/19802

#2

Updated by Gerrit Code Review about 8 years ago

Patch set 2 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/19802

#3

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.

#4

Updated by Gerrit Code Review about 8 years ago

Patch set 3 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/19802

#5

Updated by Frank Frewer about 8 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
#6

Updated by Gerrit Code Review about 8 years ago

  • Status changed from Resolved to Under Review

Patch set 1 for branch TYPO3_6-1 has been pushed to the review server.
It is available at https://review.typo3.org/21153

#7

Updated by Gerrit Code Review about 8 years ago

Patch set 1 for branch TYPO3_6-0 has been pushed to the review server.
It is available at https://review.typo3.org/21154

#8

Updated by Frank Frewer about 8 years ago

  • Status changed from Under Review to Resolved
#9

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!

#10

Updated by Benni Mack over 2 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF