Bug #78630
closed
explicitAllow not respected in 7.6.12
Added by Rainer Becker about 8 years ago.
Updated about 8 years ago.
Description
After the update from 7.6.11 to 7.6.12 in new content wizard and cType dropdwon there are entries which are not allowed for the current BE user (new content wizard and ctypes are filled by custom function, which worked as expected until I updated).
are filled by custom function
What do you mean by that, can you please elaborate a bit?
For the cType field I use a custom itemsProcFunc that gets the possible cTypes for my installation. The NewContentWizardItems are filled in by using the wizardItemsHook.
But even when disabling these functions NewContentWizard and cType-DropDown show Contenttypes, that are not allowed for the current BE user group. In TYPO3 7.6.11 this did work.
- Status changed from New to Needs Feedback
I just tried that on two of our live instances and I can't see any problem here.
Additionally I'm not aware of any changes in this area after inspecting the git logs.
Hi Rainer,
could you please post the configuration of your CType field. You can get this configuration from Configuration -> $GLOBALS['TCA'] (Table configuration array) -> tt_content -> columns -> CType -> config.
This is the tca config of CType:
CType
config
authMode = explicitAllow
authMode_enforce = strict
default = textmedia
items
0
1
...
25
itemsProcFunc = Rocket54\R54Rocks\Hook\TcaArrayItemsProcessor->processCTypeItems
renderType = selectSingle
type = select
label = LLL:EXT:lang/locallang_general.xlf:LGL.type
Regardless items are shown in 7.6.12, which are not allowed by user group configuration.
I just tested that again with latest 7.6. I fail to reproduce that.
I even tried with gridelements (which has a itemsProcFunc as well) and it worked too.
Your setup looks the same as mine so far.
Can git bisect the issue on a testsystem, so we can find out the offending commit for you?
What would the bisect procedure look like?
- You link your website to TYPO3 git-sources.
- You start with git bisect
- You mark the current commit as "bad"
- You reset the branch to the last known working commit and mark it as "good"
- bisect checks out the next commit for you
- you test if it works again, if so "git bisect good" otherwise "git bisect bad"
- repeat the last to steps until git tells you which commit is the broken one
- "git bisect reset"
It seems that I misunderstood/overlooked something - the manual for TCA / select / authMode states:
The authentication modes will work only with values that are statically present in the "items" configuration. Any values added from foreign tables, file folder or by user processing will not be configurable and the evaluation of such values is not guaranteed for!
Since my itemprocfunction adds new values to the list there will be no select items filtering by user rights out of the box. Sorry for not rtfm - please close this isssue.
Thank you for the bisect hint - now I know that bisect exists, how to use it and how cool it is!
- Status changed from Needs Feedback to Closed
Closing this ticket as requested by the author.
Also available in: Atom
PDF