TYPO3 Core

Ah, this behaviour has a condition:

- you have to have selected a page with FE-group protection
- if incl-subpages or not, both cases are equal

I found a hard relationship:

- The FE-group set in the inner-panel is locked on the FE-group that is defined in the access-properties of the page.

There is an additional even worst effect of the lock:

- you have a tree beginning with FE-group protection and you made it "incl. Subpages"
- you don't apply access-restriction to any of the childs
- you access one of the non-protected childs

What happens is that the admin-panel entirely turns off! Not only that you are still allowed to run an FE-simulation, no you are also allowed to edit those entries through the adminpanel, and you get stripped off of both possabilities.

It's even going so far as that this happens:

1: not protected
 `-- 2: fe-protected (group A), no extendTo
     `-- 3: fe-protected (group B which is subgroup of A), with extendTo
         `-- 4: not protected

• login into BE
• switch to Web->View
• look at '2', fe-group in adminPanel switches to A
• look at '4'

What happens is that 'Group A'-simulation stays in effect and will erase all elements which would just be visible to 'Group B'.

If you visit in order '2' -> '3' -> '4' you manually do the switch to 'Group B' and all is fine ('4' shows all it's content).

Solution: I guess recursive resolution of sub-group inclusion into gr_list will make this behave more stable, even if it doesn't solve most of the other issues.

On condition detected:

The adminPanel will disapear on '4' only if you have the "preview" panel collapsed. You can collapse it while on the page and it will vanish and (depending on the setup) will never appear again (for example if you have a db mountpoint on '4').

Additional bugs:

1: not protected
 `-- 2: fe-protected (group A), no extendTo
     `-- 3: not protected (but BE-user page)

• login into BE
• switch to Web->View
• look at '1', deactivate fe-group simulation
• look at '3'

What happens is that '2' appears to act as if of type extentTo and we will be thrown down to '1' (which in my case has the login-form), instead of simply showing '3' (not applying any fe-access checking at all).

11194_sliced_rootline_with_extendTo.diff:

The patch will establish rootline-truncation only for 'extendTo'-cases. In other cases it will slice out the protected portions out of the rootline.

This solves the bug mentioned in comment #0029289 above.