Folder permission not inherited - unable to create subfolder

[kikru77]

Module version(s) affected

3.2.0

Description

After upgrading a website from 5.3 to 6.2 creating a sub-folder in a protected folder isn’t possible anymore.

The folder is protected with Only these groups (choose from list) (in this case Administrators) for ca view as well as for can edit. Within this folder are other folders with the Permissions (for both view and edit) Inherit from parent folder all marked with the locked folder symbol.
Trying to create a sub-folder within this folder doesn't work. The green "create" button does change to animated dots but then turns back to 'create' and didn't create the folder without an error message.

How to reproduce

On a new installation this works. So it has to do with the upgrade.

Possible Solution

No response

Additional Context

No response

Validations

• Check that there isn't already an issue that reports the same bug
• Double check that your reproduction steps work in a fresh installation of silverstripe/installer (with any code examples you've provided)

[NightJar]

Very similarly; I have just upgraded from 5 to 6 and am receiving reports that Administrators group (i.e. permission ADMIN) cannot create files. Replacing existing assets works, but no new uploads, to any folder. There are no special protections on most folders... though by default they all inherit from parent - so could be related.

[NightJar]

Setting the permission on the parent folder to something that isn't "inherit" seems to function as a workaround, but is obviously undesirable.

[NightJar]

CMS Admins have confirmed that changing the setting from "inherit" to any other option and then back to "inherit" again sees folder creation work as expected.
So this is definitely an upgrade issue - some change in how permissions are set up & inherited must be causing this.

[edwilde]

I dug into this and can confirm the root cause. It is a versioning-state problem rather than a permissions-config one, which is why toggling the inherit setting appears to fix it: the toggle re-saves the folder.

Root cause

Folders migrated from SilverStripe 3/4 can have File.Version = 0 and no File_Live row. Creating a child in a folder goes through Hierarchy::canCreate(), which calls $parent->canAddChildren(). That method refuses when $parent->isArchived() is true:

// framework: Hierarchy::canAddChildren()
if ($owner->hasExtension(Versioned::class) && $owner->isArchived()) {
    return false;
}

Versioned::isArchived() is id && !isOnDraft() && !isPublished(), and isOnDraft() is:

// versioned: Versioned::isOnDraft()
$draftVersion = static::get_versionnumber_by_stage($this->owner, Versioned::DRAFT, $id);
$isOnDraft = (bool) $draftVersion;

get_versionnumber_by_stage() returns the Version column, which is 0 for a legacy row. (bool) 0 is indistinguishable from "no row on this stage", so a folder that physically exists on the draft stage is classed as not-on-draft, therefore archived, therefore not allowed to have children added.

Because File::canCreate() runs the canCreate extension hooks (where the Hierarchy veto lives) before the FILE_EDIT_ALL / admin permission bypass, even administrators are refused, which matches the "Administrators cannot create files" reports here.

I reproduced it on a clean 6.2 install (framework 6.2.2, versioned 3.2.1, asset-admin 3.2.0): a protected parent with an inherit child, with the child seeded to Version = 0 and no live row. Folder::singleton()->canCreate($admin, ['Parent' => $child]) returns false while the child's own canView and canEdit still pass. Bumping the version off zero with any re-save restores creation.

Why the toggle workaround works

Setting a folder's permission to anything else and back re-saves it, which assigns a proper version number and creates the live row, and that un-archives it.

Where a fix might sit

A Version = 0 saved record arguably breaks the invariant that a versioned record has Version >= 1, so this may be better handled as a data repair or upgrade migration than as a change to isOnDraft() semantics, which a lot of code depends on. Flagging the trade-off rather than pushing a direction.

Stop-gap for affected sites

For anyone hit by this on an upgraded site who needs it resolved now, here is a small module with the repair: it finds folders with Version = 0 or no live row and re-saves them in a memory-safe, self-resuming queued job (dry-run by default). https://github.com/edwilde/silverstripe-legacy-versioned-repair

Related: #1691 surfaces the currently-silent create-folder failure as a proper error message.