Symphony.

I've got two sections connected with a selectbox link field: the main section is visible, the child section is hidden. While I – as a developer – am able to access the hidden section via the relationship link in the interface, authors will see a 403 forbidden page.

Is this intended behaviour? If so: why?

This issue seems to be limited to the index view of the hidden section: authors are allowed to access the edit page (if they guess the correct URL).

I can't see any code in the content.publish.php page that does any kind of redirecting based on author type. Do you have an extension enabled that might be doing this?

EDIT: michael-e just beat me to it, cross-linked from the Author Roles thread suggesting this might be the culprit.

This still happens when I uninstall Author Roles.

Have you tried to replicate the issue on a vanilla install?

All I can find is where the hidden column is used to build the navigation here. If visible is always yes does the 403 still occur? Perhaps that flag is used somewhere else.

If visible is always yes does the 403 still occur?

No, in this case everything is fine.

Have you tried to replicate the issue on a vanilla install?

No, I haven't. Will do that next week.

Aha it's in Administrationpage::canAccessPage() and looks intentional.

If it's intentional: how are authors supposed to edit entries attached via SBL.

No idea. I only say it's intentional because it looks like there is logic there to specifically catch this, but unfortunately no comment to describe under what circumstance this is desired behaviour.

It definitely used to work back in much earlier versions (rev5), so now this behaviour does feel like a bug.

To add another voice, I agree that this current behavior is undesirable.

I'd really like to know why this has been implemented.

It looks like it was introduced with documentation changes for AdministrationPage class. But i am not sure if it is a bad thing. It depends on how You see hiding sections: is it a kind of permissions setup or is it just a makeup for menu?

If it is about permissions, then i think it should also prevent authors from editing entries.

If it is just to clean up administration menu, then i think it should not be there :).

In my eyes, it makes the concept of hidden sections completely useless. If hiding is about content protection, section associations with hidden sections should not be shown to authors.

Symphony doesn't provide a real rights management out of the box, so I think this is better left to extensions like Author Roles.

Symphony doesn't provide a real rights management out of the box, so I think this is better left to extensions like Author Roles.

I agree. I have always viewed hiding sections as a way to de-clutter the navigation.

The current implementation makes a poor assumption. It is a bug. If it were not a bug, it would hide the section, keep authors from adding new orphan entries into that section, and allow entries to be added with an association to a parent section via the select box link's table view.

I can't reproduce the issue that Nils has mentioned, has anyone else been able to?

Two sections, Test A, Test B. Test A has a text input and textarea, Test B has a textarea and SBL to Test A's text input. All fields are shown on the publish index. Test A has been set to be hidden via the section editor. Clicking on the related 'entry' from the SBL allows the user to edit the entry in Test A.

The only oddity that springs up here is that after you edit the related entry (in the hidden section) clicking View Entries will take the Author to a 403 page because the index is denied. That was the result of changes linked by ahwayakchih. I'm not attached to them, so happy to remove, which seems to be the general vibe here...

Looks like this is still a problem.

My feeling is that the hiding is presentational only. This functionality would have been added to the core when the Section Link field was conceived (predecessor of the SBL), as a way to hide an "Images" or "Comments" section where entries could only be created by following the journey from a parent article-type entry first. It enforces that user journey.

So I think the behaviour should that checkbox...

Hide this section from the back-end menu

Should do just that, and nothing more. Presentational only.

Can someone add this to the tracker, I'll revert the 2.2 behaviour in the 2.3 release. Thanks!

Fixed in this commit