Assigning File Set Permissions for a Group Programatically
Permalink
I've got a ton of file sets, pages, users and user groups to set up for a system I'm developing. I can set up user groups, set up users and assign them to the group, create a page and assign view permission for the group and I can create a file set for the group.
HOWEVER, I'm having trouble assigning the permissions for the group to be able to view files only. This is the chunk of code that is causing me the trouble:
The Administrators get their permissions assigned correctly (they get to do everything), the Editors group get their permissions assigned correctly (they get to do _some_ things), but the Company X user group picks up the same permissions that were assigned to the Editors user group (they should only get view permissions).
Can someone help me debug this, as I can't see what I've done wrong?
Another issue is that during testing, I kept deleting the test user/group/page/fileset I was adding, which works fine apart from the file set keeps accumulating permissions that were set on the previous test run, i.e. I get 'deleted group' showing up several times within the File Set permissions. With a new page, there is a function clearPagePermissions(), but the equivalent for a FileSet resetPermissions() doesn't seem to work as I expect it to. Perhaps this issue is related to the first issue (above)?
HOWEVER, I'm having trouble assigning the permissions for the group to be able to view files only. This is the chunk of code that is causing me the trouble:
// Add a new File Set $newFileSet = FileSet::createAndGetSet('Files for Company X', FileSet::TYPE_PUBLIC, $uID = false); // Add the permissions for the File Set $newFileSet->resetPermissions(); $newFileSet->acquireBaseFileSetPermissions(); $allFileSetPermissionKeys = PermissionKey::getList('file_set'); $allFileSetPermissionKeyHandles = array_map(function($permissionKey) { return $permissionKey->getPermissionKeyHandle(); }, $allFileSetPermissionKeys); // Administrators can do anything to the file set $newFileSet->assignPermissions(Group::getByName('Administrators'), $allFileSetPermissionKeyHandles); // Editors can do some things to the file set $newFileSet->assignPermissions(Group::getByName('Editors'), array( 'view_file_set_file', 'search_file_set',
Viewing 15 lines of 24 lines. View entire code block.
The Administrators get their permissions assigned correctly (they get to do everything), the Editors group get their permissions assigned correctly (they get to do _some_ things), but the Company X user group picks up the same permissions that were assigned to the Editors user group (they should only get view permissions).
Can someone help me debug this, as I can't see what I've done wrong?
Another issue is that during testing, I kept deleting the test user/group/page/fileset I was adding, which works fine apart from the file set keeps accumulating permissions that were set on the previous test run, i.e. I get 'deleted group' showing up several times within the File Set permissions. With a new page, there is a function clearPagePermissions(), but the equivalent for a FileSet resetPermissions() doesn't seem to work as I expect it to. Perhaps this issue is related to the first issue (above)?
Thanks for the advice. I'll give it a go and try and see what is happening.
Can someone help me with this? I have discovered that whenever I run the script, the default FileSet permissions (in System & Settings > File Permissions) have been updated to reflect the settings that I tried to apply to the new file set. So, each time I run it, the new user group I have created gets added on top of the permissions that are already there.
So, how do I apply specific permissions to a File Set programmatically without it affecting the default File Set permissions?
So, how do I apply specific permissions to a File Set programmatically without it affecting the default File Set permissions?
Did you ever figured this out? Is it a bug in the core you think?
As a side note, I always found it valuable to make snapshots of the database with the backup mechanism, when I knew it was in a good state, and restore to those checkpoints between tests. This helps you to rule out side-effects from test code.