Public status of nested folders inside unpublished folders

[ThomasKettner]

Affected version(s)

4.13

Description

As already discussed in Slack, I am tumbling about the process that new folders are set to "published" by default, when nested inside an unpublished folder. I am still not sure whether this is intentional, a bug, or never been thought about.

When protecting a folder I expect the whole content to be protected, no matter what type, by default. This includes files as well as folders. In our experience this is the main logical principle. Having unprotected folders nested in a protected folder should be possible as an exception (I do not see many reasons to do so) and not as a default process. Subfolders often need to be created in order to organize a growing number of files. It seems quite surprising when these are suddenly published.
To turn around this default process would increase security as well as usability. Editors do not need to be extra cautions when creating folders or content.
Same goes with automatically generated member folders. We have several cases where members upload content that should not be public by default. But every member folder created is automatically set to published.

Therefor I strongly advise to change this process in order to increase security.

[Hendrikhubl]

I agree with the points raised. It does make more sense for new folders to start off as private if they're inside a private folder. This would definitely help avoid any mix-ups with files and folders getting shown when they shouldn't be. Seems like a smart move to keep things safe and easy without being extra cautious.

[marcuslelle]

I support the issue.

I would not like to change the complete default behaviour since I know this would confuse a lot of current (power) users of Contao I guess.

To have the current situation improved I suggest to

• have the checkbox "public" checked when the folder has no parent
• have the checkbox "public" checked when the folder has a parent and the parent is public
• have the checkbox "public" unchecked when the folder has a parent and the parent is protected

All of the above is about the file manager.

@ThomasKettner also mentioned automatically generated member folders. I agree with him but cannot think of a simple rule here.

I also see the problem that checking only the parent folder is not enough when the path would be "files/protected/public/protected/new-subfolder" but I would consider that a known limitation.

[fritzmg]

When Contao 4 was released the default was that the "public" checkbox was not enabled. By popular demand this was changed, since users where used to folders being public by default - as was the case in Contao 3 and as is likely the most common use-case anyway.

I am against changing this behavior for protected folders for the following reason: if you have one or multiple back end user groups for editors, you will want to give them a file mount that is protected. Otherwise, if this is the only mount they receive, they will never be able to create a protected folder themselves. Because you cannot have a protected folder within a public one - only the other way around. If we implemented this change in general, this would basically restore the original behavior when Contao 4 was first released for these back end editors. They would have to specifically always enable the checkbox when they create a new folder within their file mount.

Of course you could create two file mounts per back end user group: one "public" one and one "protected" one. But in larger multidomain setups with multiple independent back end user groups I prefer to give just one file mount per user group where they can manage their content freely.

[ThomasKettner]

I can see your point @fritzmg
Still there would be an appropriate solution even for this one-folder-per-user strategy. We just need to protect the direct child folders. As soon as you have a public folder, all childs below could be set to public, too.

• user-root (unpublished)
  1 secure
  1.1 new folder (unpublished)
  2 published
  2.1 new folder (published)

[marcuslelle]

Thank you for your time, @fritzmg.

What do you think about the automatically generated user folders. Would that be a valid addition that those could be marked "protected", e. g. in the registration module.

[fritzmg]

Automatically generated user folders are never public (their parent can be of course) - or what exactly do you mean?

[marcuslelle]

Automatically generated user folders are never public (their parent can be of course) - or what exactly do you mean?

Ok. That is fine.

[fritzmg]

I can see your point @fritzmg
Still there would be an appropriate solution even for this one-folder-per-user strategy. We just need to protect the direct child folders. As soon as you have a public folder, all childs below could be set to public, too.

But that goes against why this was changed originally in the first place. Now you would have to explicitely set every new folder within user-root in your example to public.

[marcuslelle]

Hm. OK.
But this would be more secure by default.
But as you mentioned @fritzmg this was changed to public demand in the early Contao 4 days.

All I can say is that I would use a user-group1-public and user-group1-protected in the root of files, if I had several user groups with filemounts. This is a personal matter of course.