Bug #17600

Overriding multilevel UC settings fails

Added by Michael Stucki over 5 years ago. Updated 17 days ago.

Status:Needs Feedback Start date:2007-09-13
Priority:Should have Due date:
Assignee:Michael Stucki % Done:

0%
Category:-
Target version:-
TYPO3 Version:4.1 Complexity:
PHP Version:4.3
Votes: 0

Description

It is possible to override UC settings using BE-USER-TSconfig:

  1. setup.override.disableTabInTextarea = 1
  2. => works fine

However, overriding multilevel properties will not work:

  1. setup.override.TSFE_adminConfig.display_top = 1
  2. => no effect

The reason for the problem is that the TSconfig output is processed like regular TSconfig and therefore, parent keys have trailing dots:

  1. ['TSFE_adminConfig.']['display_top']

However, the UC array does not know these keys and looks for this key in this example:

  1. ['TSFE_adminConfig']['display_top']

(issue imported from #M6337)

bug_6337.diff (2.4 kB) Administrator Admin, 2007-09-13 15:12

History

#1
Updated by Michael Stucki over 5 years ago

The attached patch solves the problem by stripping all trailing dots right before the exsting UC is merged with the TSconfig settings.

Additionally, it makes sure that the override routine is also called at these places:
- when making changes to any module ($this->uc['moduleData'])
- when storing the admin panel (e.g. closing the "edit" module)

This assures that override settings really can't be changed, so for example, the admin panel can be configured sticky and can't be closed.

#2
Updated by Michael Stucki over 5 years ago

How to test:

- enable the admin panel in the TS template
- set these properties for a BE user/group:

setup.override {
TSFE_adminConfig.display_top = 1
TSFE_adminConfig.display_cache = 1
TSFE_adminConfig.display_edit = 0
TSFE_adminConfig.display_info = 1
}

- Try opening the "edit" module
- Try closing the "info" module

#3
Updated by Michael Stucki over 5 years ago

NOTICE: Now that the feature is working it should of course be added to the TSconfig Documentation. The property was already there, it just didn't work...

#4
Updated by Alexander Opitz 17 days ago

  • Status changed from Accepted to Needs Feedback
  • Target version deleted (0)

The issue is very old, does this issue exists in newer versions of TYPO3 CMS (4.5 or 6.1)?

Also available in: Atom PDF