The concept for the Resource files differentiates between folders, which can be edited (those created only in JCR) and those, which can't. However, we've discovered there's a third type of folder we have to handle separately.

When I add a resource file under a non-editable folder (i.e. a folder from the filesystem or classpath), our current implementation also implicitly creates folders to map the existing folders also in the JCR origin. Such "masking JCR folders" can also be created explicitely - their characteristic is that they exist in JCR and that equally named folders with the same path exist in a read-only origin.

As a result, such masking JCR folders are currently marked as editable, which is probably wrong: a user shouldn't delete them and (in the future) not move or rename them (would result in very confusing behavior). However, having a "publish with sub items" actions on such folders could proof to be very handy.

Solutions I see are:

1. We treat masking JCR separately: they're not editable, but have a set of actions different from non-editable folders and which includes publish actions. UPD: after discussion it was also pinpointed that such folders should not be marked as editable in the resources app table (pen indicator).
2. We change the current implementation of how we store JCR resource files: we no longer implicitly create folders when adding a resource file, but store a "path" or similar alongside it.

I've set the severity of this issue to "critical" as we* should resolve this before the next release* of the Resource files app, as the current behavior will cause confusion and lead to questions.