Adding your own object security validation
In Windows applications you can add your own layer of object security on top of the Framework security by modifying the IIP method avCheckAuth. This can be used to make the Framework security conform to your site's standards. It can also be used to alter the behaviour of filters or command handlers for particular users.
The IIP routine receives an identifier for the object (This is the user object name / type parameter which can be viewed on the identification tab sheet for the object) and the user profile.
A special case is when the object being validated is a command reference (a command for a particular Framework or application or business object) the IIP receives the user profile, an identifier for the Framework/application/business object, and an identifier for the command. (The identifier is the user object name / type parameter).
See the source of UF_SYSTM, method avCheckAuth, for details.
The IIP routine could be changed to do something like FETCH a security record for this user and object from a file containing authorization data.
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 object, and automatically display it or hide it as appropriate.
The security of the IIP routine is additive with the Framework security - If the Framework's security says that the user is not authorized to the object, OR the IIP routine says that the user is not authorized to the object, the object won't be displayed for that user.
If you want to, you can access avCheckAuth from the code in your filters and command handlers, and alter their behaviour based on the returned "additional information parameter".
When you invoke avCheckAuth from a filter you are validating the business object. For the business object to have been visible in the first place, the IIP routine must have returned OK for that business object, but it could also return the additional information parameter. The filter could use this to decide whether to restrict filter options for particular users.
When you invoke avCheckAuth from a command handler you are validating a command reference (a Framework/application/business object - command combination). For the command to be available for the Framework/application/business object, the IIP routine must have returned OK for this command reference, but it could also return the additional information parameter. The command handler could use this parameter to allow some users to edit all fields while restricting other users to work with a reduced set of fields, or to view only access.
One point to remember when writing an avCheckAuth routine is that if your users connect to a server, they will not be connected to the server at the time their authority to the Framework or servers are evaluated. However they will be connected at the time their authority to applications, business objects and commands are evaluated.