Security Restrictions? Application restrictions? What’s the difference?

Body

You may need to add restrictions to new or existing Maximo attributes, for example, making them required, read only or hidden.  Let’s describe the different ways you can do this from either Application Designer or with attribute restrictions in the Security Groups application. These restrictions can be either conditional or non-conditional.

What is the difference? Application Designer configurations are always for one application. Configurations that use data restrictions can apply to all applications that use the object or attribute or to one specific application. At the attribute level, data restrictions can be created to make records hidden, read-only, or required. Because these data restrictions exist at the data-level, the restrictions apply to any user interface element or application that uses an object or attribute.

To better explain the difference between the two types of restrictions, consider the following scenario:

A system administrator wants to make the serial number required on the ASSET business object.  As mentioned earlier this can be done from Application Designer as well as through data restrictions.  Which should be used?  Read on…

Application Designer Restrictions

This is best used when the desired outcome is to require that a serial number be registered for each Asset record when using the Assets application.  This type of restriction is associated with the presentation business object for assets and is therefore only enforced in the Assets application (in this case).

Generally this will only be applicable to attributes entered/updated through the application’s presentation (the screen), and the restriction is enforced at the time of saving the record.  Because background processing by Maximo can set and fetch data in business objects outside of the presentation object, a shortcoming can exist that a restriction created in the presentation may not be enforced for the same object when processed by Maximo’s business logic.  So in the example above, the ‘requiredness’ of the serial number for the asset object may not be enforced when the system updates/creates/modifies an Asset via background processing such as changing the status of an Asset.  If the user desires to have the serial number be required (for a set of users) in ALL uses of the Asset object, they should consider an attribute restriction.

Attribute restriction:

Attribute restrictions are essentially security restrictions enforced at the data level.  They will work for all the instances of the object regardless of being instantiated through the presentation (application UI), or via background process (such as an action, or via integration).
Data restrictions always supersede application configurations in the Application Designer application. For example, if an attribute has a data restriction that makes it required or read-only, the Application Designer will not be able to override this and allow for the optional entry of the attribute or allow the attribute to be editable in the case of it being set to read-only. The flow of restrictions on an attribute starts with database configuration, meaning at the table and attribute level, then data restriction which is similar but enforced at a security group level, and then Application Designer application, which is only at the application’s UI presentation level.