FileNet P8 Platform, Version 5.2.1

Property modification access

To be able to edit a property, a user generally needs Write access to the property. However, Content Platform Engine provides an optional way to add another layer to the required access rights to modify custom properties. System administrators can do this by configuring the Modification Access of property templates. (Because this feature depends on a system property called Modification Access Required, the acronym for modification access behavior is MAR.)

Remember: Property modification access behavior is a feature primarily intended for the IBM® Enterprise Records application, especially in connection with markings. It is available for use by non-records management applications that need granular control over user ability to modify properties.

About MARs: The property sheets of all property templates have a Modification Access page that contains a list of access rights. By default, these access rights for all property templates are unselected. If left unselected, then the property template has no modification access behavior and "normal" property security applies. However, if you select one or more access rights, properties based on the property template will have different security than normal, as described below.

Normal property security (no modification access)

Custom properties are all based on property templates. In the Administration Console for Content Platform Engine Property Templates node are listed the property templates that have been added to the object store. The property template's own ACL, contained in its property sheet's Security page, controls who can access the property template. Default security on property templates is one of the decisions made by the Object Store Wizard: object store administrators have Full Control, and object store users have View all Properties and Read Permissions. You could change these default assignments, but only if there is a clear reason to do so.

Security on a property that has been added to a class and then placed on an instance of the class is governed not by the security of the property template, but by its object's security. The initial state of the security for any object is created from the default instance permissions defined via its class and thereafter edited through the Security tab of the object's property sheet. For example, the Default Instance Security of a document class is copied onto a new document, and it is this security that governs access to the document's properties.

However, keep in mind that property templates have a Settability setting that can be configured so that the properties based on them will be read-only, read/write, settable only on create, or settable only on checkin. These settings take precedence over any permissions granted by the object's security. In other words, a property marked read-only is not modifiable even if the user is granted the Modify all properties access right on the document.

There are two property-related access rights that appear on the ACLs of all securable objects:

View all properties: whether the user can see the object's properties.
Modify all properties: whether the user can modify the values assigned to the properties (taking into account any settability restrictions on modifying the property).

Example of property security

In this graphic showing normal property security, the property template's settability is Read/Write which carries to the property when it is added to the document class and onto the document. The document's ACL grants Alice permission to see and modify all properties, while Bob can see all properties but cannot modify them. Therefore, Alice could change the value of Property A (and any of the other readable or writable properties contained by the document), while Bob can see Property A (and all others) but cannot change its value.

Property security if modification access has been configured

By setting a property's Modification Access Required property, you can establish another layer of access permissions that affects who can modify the property. You can use the MAR to specify that certain properties can be modified only by users with a specified set of rights, as opposed to the "normal" condition in which users need only the Modify all properties access right to the object.

Example of property security with the delete permission set

In this graphic, Property Template A has a MAR in which the Delete permission is set. Property A has been added to the document. The ACL on the document permits Alice to delete the document while it prevents Bob from deleting the document. Therefore Alice can modify Property A and Bob cannot (assuming the property is settable).

Remember: Administration Console for Content Platform Engine does not collect the property modification access settings in a single view or page.

As mentioned above, if you do not specify any values, meaning that all the access rights on the Modification Access page are left unselected, then there is no MAR behavior and normal property security applies. A property template's Modification Access settings are settable only on create and therefore cannot be changed later on.

Exceptions to the normal access requirements

As described above, setting or modifying a property generally requires Write access to the object to which the property belongs. A different right is required for the following actions:

To modify Permissions, SecurityPolicy, or SecurityParent, a user requires WriteAcl access.
To modify the Owner property, a user requires WriteOwner access.