Technical Blog Post
Abstract
What's up with ... ObjectStore permissions?
Body
The ObjectStore object itself has an access control list (ACL), just like most objects within it. Its permissions differ from those other sorts of objects in two ways.
First, there are very few different possibilities for access rights on the ObjectStore object. Most (but not all) of them control the right to perform basic CRUD (create, retrieve, update, delete) operations on objects within the ObjectStore. For example, there is AccessRight.CONNECT which serves as a sort of overall gateway to control who can retrieve any objects from within that ObjectStore.
Second, permissions from the ObjectStore object are not inheritable to any objects contained within that ObjectStore. This is a common misunderstanding because admin tool security dialogs allow you to create an access control entry (ACE) for the ObjectStore object that it says is applicable to "this object and all children". If you were the pedantic type, you could try to make the case that that's literally true, but there actually are no security inheritance children for the ObjectStore object. Things contained within an ObjectStore are not children of that ObjectStore for security inheritance purposes.
Let's look at an example of these two factors together. If a user does not have AccessRight.REMOVE_OBJECTS on the ObjectStore object, then they will not be able to delete an object within that ObjectStore no matter how liberal their rights are on the object they wish to delete. On the other hand, if they do have AccessRight.REMOVE_OBJECTS on the ObjectStore object, that means they can delete objects within it if they also have the usual deletion rights on that object.
[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSCTJ4","label":"IBM Case Manager"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
UID
ibm11281814