Access Clause for the Add Person Command

This clause specifies the maximum amount of access a person will be allowed. When this clause is used, you can select from many different forms of access. Each access is used to control some aspect of a business object’s use. With each access, other than all and none, you can either grant the access or explicitly deny the access. You deny an access by entering not (or !) in front of the access in the command.

For more information, see Controlling Access and MQL Concepts: Policies.

Business objects are governed by a policy. The policy defines who has access and when. Depending on the business object’s state and the person involved, a user could have full, limited, or no access. Generally, the policy that governs the object restricts the access by role or group name. In some cases, that might mean that more access is granted than you might desire for a particular person.

If you want to prevent a person from ever having a form of access, you can do so by denying that access in the person’s definition. For example, assume you have a user who continually overrides the signature requirements for business objects. This can be done with an access clause such as:

add person George
   access all, notoverride;

Even if George is granted override access via a policy, the access will be denied.

Access can be assigned or denied using one of two methods:

  • all: The person has access to all functions except those listed.
    access all, notchangeowner, notcheckout, notdisconnect, notdelete,
   notdemote, notdisable, notenable, notoverride, notschedule
  • none: The person has access to only the functions listed.
    access none, checkin, connect, create, promote, lock, unlock, modify, read

The method you use will depend on whether most access will be permitted or denied. The default is None.

If the amount of access being permitted or denied is about the same, the method does not matter. However, when the amount of access being permitted or denied is heavily weighted toward one or the other, the method you choose can save you time (and typing!).

If the access clause is not included when defining a user “none” is assumed.

In native apps (MQL or Matrix), you cannot see the code in a hidden program unless you have "admin program" access. However, in a server environment this restriction does not apply. The reasoning is that you must be able to restrict end-users of rich clients from seeing "secret" programs, including those in which passwords are hidden. In a server environment:

  • App-level code needs to be able to use such secret information
  • Ordinary end-user are not supposed to have such direct access to MQL commands and so it should remain secure.