This documentation is not applicable to VLF-ONE
You can add instance level security to the Framework by modifying the IIP avCheckInstanceAuth. For example if we take the employees business object in the demonstration system, the same user can be authorized to different commands depending on the employee selected. This can be used to strengthen security or to make the Framework security conform to your site's standards. It can also be used to alter the behavior of filters or command handlers for particular users and particular business object instances.
The IIP routine receives an identifier for the business object and an identifier for the command (In both cases the identifier is the user object name / type parameter which can be viewed on the identification tab sheet for the business object or command), the user profile, and the identifying keys for the business object instance.
(A special case is if avCheckInstanceAuth is invoked by a filter. In this case no identifier for the command is specified).
See the source of UF_SYSTM, method avCheckInstanceAuth, for details.
The IIP routine could be changed to do something like FETCH a security record for this user profile, business object, command, and business object instance. Based on this security record it can return OK or ER.
The IIP routine returns a result as OK or ER. When the Framework is run in a mode other than design, the Framework will evaluate the IIP routine for each business object instance, and automatically display or hide the commands appropriate to that business object instance and user.
The security of the avCheckInstanceAuth IIP routine is additive with the Framework security - If the Framework's security says that the user is not authorized to the object (application/business object/command reference), OR the IIP routine says that the user is not authorized to the command for that instance of the business object, the command won't be displayed for that user.
If you want to, you can access avCheckInstanceAuth from the code in your filters and command handlers, and alter their behavior based on the returned "additional information parameter".
When you invoke avCheckInstanceAuth from a filter you are validating the instance of the business object (for any command). Based on the return code and the additional information parameter the filter could decide (for example) which of the data selected from the database should get added to the instance list.
When you invoke avCheckInstanceAuth from a command handler you are validating a command reference (a Framework/application/business object - command combination) for a particular business object instance. For the command to be available for this business object instance, the IIP routine must have returned OK for this command reference and business object instance, but it could also return the additional information parameter. The command handler could use this parameter to allow (instance by instance) some users to edit all fields while restricting other users to work with a reduced set of fields, or view only access.