There’ve been a few observations that the index agents do not start up in running mode after restarting the Windows Server. And since we’re talking about Windows OS, there’re a lot of security patches by the days and weeks, hence, a weekly or monthly restart is inevitable.
WIth this, it is better to always check at DA to ensure that the index agents are started up and running after rebooting the Windows Server.
If the default_acl attribute in the dm_server_config object is set to “1 – folder”, new objects (e.g., subfolders, documents, etc) will inherit the parent’s permission set. For copied objects, they will also inherit the same permission set, since effectively new objects are created in the folder. However, for moved objects, their original permission set are carried over to their new destination folder.
This effectively posed a security loophole. To avoid this, a job could be scheduled to apply the permission set to a folder and its contents routinely.
There’s however another challenge imposed here. Checked out documents. Documents that are checked out cannot be applied with the “new” permission set. They had to be checked in or cancelled checked out inorder for the application to be successful.
One possible approach would be to write the DQL such that, it will only update an object’s ACL if it its not the same as the new ACL and only if its r_lock_owner is null or empty.
Folders are not affected, since folders cannot be checked out.
I’d a recent need to do some DFC programming related to permission set. It makes sense to write an ACL helper class for reusability.
Common useful methods are: isACLExist, getACL, createACL and updateACL
The method getACL returns an IDfACL object if it exists. If it doesn’t, NULL is returned.
The isACLExist method calls the getACL method and do a NULL check. If it is NULL, the ACL doesn’t exist, and vice-versa.
The createACL method will create a new persistent object of type “dm_acl”. To grant accessor to the permission set, the IDfACL.grant method is used. After creation, the IDfACL.save method is invoked to save the object.
The updateACL method will check if an ACL exists. If it does, it will do the necessary updates and lastly saves it.
I tried to use DQL to delete ACLs, but unfortunately it doesn’t work. So in the end I had to resort to use API to delete it. Naturally I would have done this:
delete from dm_acl objects where object_name = ‘my custom acl’;
But since it hit an error, I have to get the r_object_id:
select r_object_id from dm_acl objects where object_name = ‘my custom acl’;
And run the API command: