SAK-51375 Content fix Edit Folder Permissions in sub-folder

[ottenhoff]

No description provided.

[ern]

Adrian we reviewed this in the core call and didn't quite understand the authz override, could you help clarify?

[adrianfish]

yep. The authz override specifies and authzgroup with permissions which lock any "child" authzgroup permissions where the overriding group has that permission set.

[ottenhoff]

what no one could understand on the core call: what is the use case for locking the permissions so that instructor cannot modify them? does this PR look correct to you?

[adrianfish]

Because top level folder permissions are supposed to dominate. I did it on purpose base on Sean Horner's description of the use case.

[ottenhoff]

Sorry this isn't making sense to me. The use case that we've supported for a dozen years is creating a sub-folder inside Resources that has increased permissions (e.g., students can add/edit files). That seems to no longer be possible.

I see Sean advocating for disabling checkboxes in https://sakaiproject.atlassian.net/browse/SAK-50984, but I think this hasn't been fully thought through.

The root of the problem seems to be that the sub-folder realm permissions are additive on top of the parent folder permissions? E.g., if top parent has content.delete for student role than it's impossible to remove that permission from a sub-folder?

[ottenhoff]

Sakai 23 has changed a lot after the permissions helper was removed and permissions web component replaced it.

Here is the way Sakai 22 works today:

1. The root Resources tool permissions are the base-level permissions.
2. sub-folder permissions inherit from the parent folder permissions and from the tool permissions.
3. You cannot remove permissions from a folder that are defined in (1) or (2). these are locked/disabled
4. if a permission is granted on a parent folder, there is no way to remove it on a sub-folder.

IDK, this isn't what i assumed. do you want more people to weight in?

[adrianfish]

I think we need to codify how this is supposed/expected to work so it probably makes sense for others to chime in. I'm worried that if I change things again somebody else will complain that I've broken it. You know how it goes.

[adrianfish]

It currently inherits from the top level folder alone I think, so the hierarchy is flattened under that folder. That seems wrong anyway - a folders permissions, as in 22, should inherit from its parent.

[adrianfish]

I thought it had gone all too well when I switched content to the web component ...

[ottenhoff]

i'm fine with implementing this exactly as it behaves on Sakai 22. but i think it's ultimately all wrong ;) but at least it would be consistent

[wilmahodges]

In my opinion, the expected behavior for Resources permissions is as follows: 1) When a new folder is created, it inherits the permissions of the parent folder by default. 2) However, if you go to the child folder and select Actions > Edit Folder Permissions, you should be able to remove or add permissions which override the inherited default for that folder and any subfolders within it. Each subfolder can likewise restrict/add permissions as needed if set individually.

This sort of behavior is consistent with what users expect in modern file management/sharing applications. For example, in Google Drive, you can share folders with different people at any level of the folder hierarchy. Subfolders inherit the sharing rules from the parent folder, but the sharing can be modified for any subfolder individually. (You get a message about it being easier to remove sharing on the parent folder, but it still lets you remove permissions from just the subfolder if you choose.)

That being said, in order to facilitate scenarios such as allowing folders to only be seen by certain groups, or hiding a folder from students so they don't see answer keys or test images, a better way to manage these use cases is by going to Actions > Edit Details for the resources folder (or file) and changing the Availability and Access settings to control whether or not students can view an item. Since Availability and Access handles the removal of permissions for most use cases, really the main reason to go to Edit Folder Permissions is to add permissions, such as allowing students to edit or delete files within a folder. I suspect this is where the idea of locking permissions at the parent folder came about. However, it is a bit confusing to have two different places where an instructor goes to manage folder and file permissions and access. Perhaps people are going to the wrong place to set up the sort of access restriction they want?

I've posted the above comment to the sakai-user list to see if others want to weigh in.

[adrianfish]

Boom! And Wilma has arrived on the scene. Finally, one of us knows what the heck's going on :)

[hornersa]

After 'verifying' the other related jira, I'm just now catching up to this. Will read more and come up to speed tomorrow. (Fwiw, my assertions in the test plan from the other jira are based on past behavior with the assumption that past behavior = "should". I'm open to a revised sense of "should".)

[hornersa]

To contextualize why and where I filed jiras related to this issue, I'll write those in the comments section of the jira corresponding with this PR. (I need to refer to other jiras and don't want those issue IDs muddying up github to jira conventions during merge, etc.)

[adrianfish]

@hornersa I'd just like to thank you for your attention to detail on issues such as this. You regularly seem to get involved in some complex corners of Sakai and your insight is appreciated.

[ottenhoff]

CC: @adrianfish and @hornersa

I made changes per core call.

• We live with locking from parent folders and deal with that separately.
• overrideRef must be immediate parent folder and not top-level folder
• No errors when editing new folder
• Escaping seems to work fine

[hornersa]

I've tested the patch locally and recorded the before-and-after in a screencast (SAK-51375-TestResults-PR-20250506.mp4) attached to the jira. Though I wasn't expecting the disabling of already granted permissions with this update, I'm definitely fine with it as it conforms mostly with Sakai 22 and earlier.

[ottenhoff]

Though I wasn't expecting the disabling of already granted permissions with this update,

Absolutely should not happen with latest code. This did happen with code from this morning. Please writeup what you are seeing if you are testing with latest code.

[hornersa]

The 'before' scenario is the master branch up to 3cfd7df (May 6, 2025). Then for the 'after' scenario, I shutdown Sakai, apply this PRs patch. Deploy content, then webapi, then webcomponent. Relaunch Sakai, and retest using a new course site. We create sites copied from site templates. Perhaps this might be where the difference lies, namely the disabled checkboxes.

I observe a similar difference between nightly 22.x and my local instance of 22.x.

[ottenhoff]

The 'before' scenario is the master branch up to 3cfd7df (May 6, 2025). Then for the 'after' scenario, I shutdown Sakai, apply this PRs patch. Deploy content, then webapi, then webcomponent. Relaunch Sakai, and retest using a new course site. We create sites copied from site templates. Perhaps this might be where the difference lies, namely the disabled checkboxes.

I can't replicate your testing. In a clean site:

1. Create folder A
2. Add one permission to Student role in folder A
3. Edit again and confirm I can remove that one permission (not locked)
4. Add folder B under folder A
5. Confirm that the permission added to folder A is locked/disabled
6. Add one permission to Student role in folder B
7. Confirm I can remove that one permission added to folder B (not locked/disabled)

[hornersa]

I can't replicate your testing. In a clean site:

1. Create folder A
2. Add one permission to Student role in folder A
3. Edit again and confirm I can remove that one permission (not locked)
4. Add folder B under folder A
5. Confirm that the permission added to folder A is locked/disabled
6. Add one permission to Student role in folder B
7. Confirm I can remove that one permission added to folder B (not locked/disabled)

Yes, the list of steps above all work in my local instance with this patch. It's just that the behavior demonstrated in the aforementioned screencast is also extant for me as well. (The 'why' may take some extra sleuthing.) All that said, I'm very much fine with the merging of this patch.

[wilmahodges]

Just a quick update... The T&L/UX group discussed the Resources permissions issue today on our call. The consensus was that, since there were no complaints about the behavior regarding folder permissions in 22, we should keep the same behavior as 22 for versions 23, 25, and future versions.

[ottenhoff]

Yes, the list of steps above all work in my local instance with this patch. It's just that the behavior demonstrated in the previous screencast is also extant for me as well. (The 'why' may take some extra sleuthing.) All that said, I'm very much fine with the merging of this patch.

Sorry, I'm generally not willing to sit through a screencast. Happy to discuss on the core call why, but I just don't find it works for my debugging flow.

[hornersa]

The following image depicts a new course site within my local context (copied from a template via the SOAP calls in webservices) with a patch from this PR deployed. All the granted permissions within Resources display as disabled checkboxes. Those not checked are checkable. Within this context, revoking 'Read resources' for students cannot be done via the Resources tool. That permission can be revoked however via Site Info > Tool Order and locking Resources. When this patch is not deployed, the disabled checkboxes depicted below are not disabled-- i.e., they can be unchecked.

[ottenhoff]

When this patch is not deployed, the disabled checkboxes depicted below are not disabled-- i.e., they can be unchecked.

Without this patch you can't edit the folder permissions on a sub-folder at all. You receive "You don't have permission to change permission settings."

[hornersa]

Without this patch you can't edit the folder permissions on a sub-folder at all. You receive "You don't have permission to change permission settings."

Correct. In my estimation, patch = goodness. There's just this other behavior that I'm reporting on that I assume from your comments that you're not observing. If you would like me to do a deep dive on 'why', I'll see what I can come up with, though currently I'm also trying to assess the state of the SCORM player for 23.x per a user request.

[ottenhoff]

All the granted permissions within Resources display as disabled checkboxes. Those not checked are checkable.

This is exactly how it works on 22 and 23-pre-webcomponent-helper, no? The goal here is to simply get this webcomponent helper working correctly and to restore previous behavior.

[hornersa]

This is exactly how it works on 22 and 23-pre-webcomponent-helper, no? The goal here is to simply get this webcomponent helper working correctly and to restore previous behavior.

I'm on the same page with you re the goals you are stating in the quote directly above. My other comments over the past day are in response to your earlier comment which implies that you find the behavior with the patch that I've observed and reported as unexpected.

When nightly master is rebuilt, I can test the merged patch incorporated there tomorrow.