Bug #41802
closedPageTree-filter not working for Admins if admin has additional DB mounts
0%
Description
we recently updated our Typo3 4.6.4 instance to 4.7.1 without any big problems, only to realize soon that the PageTree-filter is not working for Admins.
If an Admin enters a UID or phrase into the filter no page gets found and all existing pages except the typo3-root page and another page on root-level are hidden in the PageTree.
As an Editor the PageTree-filter works just fine.
Downgrading typo3_src to 4.7.0 PageTree-filter works for both - Admin and Editor. Upgrading to 4.7.4 doesn't do anything for this issue.
I managed to determine the crucial code-snippet that is causing this behaviour:
l.228-240 in t3lib/tree/pagetree/class.t3lib_tree_pagetree_dataprovider.php of Patch Set1 (https://review.typo3.org/#/c/10376/):
if ($mountPoints != array(0)) { $isInsideMountPoints = FALSE; foreach ($rootline as $rootlineElement) { if (in_array(intval($rootlineElement['uid']), $mountPoints, TRUE)) { $isInsideMountPoints = TRUE; break; } } if (!$isInsideMountPoints) { continue; } }
If I remove this block from the code, the PageTree-Filter works just fine - for any user. On integrating it, PageTree-filter breaks for Admins.
I did not perform any altering of the mounting-configuration for the Admins on or after upgrading from 4.6.4 to 4.7.1, so maybe it is due to some old setting that these accounts are causing trouble with this mountpoint-routine?
Updated by Andre Lahmann about 12 years ago
After trying different mounting-settings I've found the cause for this behaviour: if an Admin has another mountpoint which does not contain the page with the uid being searched, the PageTree-filter breaks.
You can reproduce it very easily: create an Admin-account (e.g. test_admin), create an usergroup (e.g. test_group) that mounts a limited page-subset (=does not include some pages which are included in root). Now add test_admin to the usergroup test_group and perform a PageTree-search for a page that is NOT included in test_group's mountpoint. The result will be, that the page is not found although Admin-accounts always have the root-mountpoint.
If one adds the unmounted page-subset as another mountpoint to test_group (or create a new usergroup) the PageTree-filter works just fine, finding TWO matches (one in root, one in the extra-mountpoint).
I leave it to the typo3-dev-team what to do with this issue, it certainly is confusing and some sort of a bug, but it's not crucial. As for our typo3-instance I can fix our problem for now by reconfiguring the usergroups.
Updated by Mathias Schreiber almost 10 years ago
- Subject changed from PageTree-filter not working for Admins to PageTree-filter not working for Admins if admin has additional DB mounts
- Target version set to 7.4 (Backend)
- Is Regression set to No
Updated by Susanne Moog over 9 years ago
- Target version changed from 7.4 (Backend) to 7.5
Updated by Benni Mack about 9 years ago
- Target version changed from 7.5 to 7 LTS
Updated by Daniel Neugebauer almost 9 years ago
Looks like a duplicate has been reported and was solved in September with the release of 6.2.15:
2015-09-04 46a6bb8 #69063 [BUGFIX] Enable page tree filter for admin with mountpoints (Nicole Cordes)
Can anyone else confirm?
Updated by Riccardo De Contardi over 7 years ago
- Related to Bug #67698: active filtering mode added
Updated by Riccardo De Contardi over 7 years ago
- Status changed from New to Closed
I think I can safely close this issue: I tested it with 6.2.30, 7.6.16 and latest master (9.0.0-dev) and I was not able to reproduce it following the steps in comment 1.
If you think that this is the wrong decision or experience the issue again or think that a different test should be done, then please reopen it or open a new issue with a reference to this one. Thank you.