Enforce Clause for the Add Policy Command

This clause is optional and can be used to prevent one user from overwriting changes to a file made by another user.

When an object is governed by a policy that has enforce locking turned on, the only time a user can check in files that replace existing files is when both of these situations exist:

  • The object is locked.
  • The user performing the checkin is the locker.

To ensure that the person who locked the object is the person who checked out the file, enforce locking disables the manual lock function. The only way to lock an object that is governed by a policy that enforces locking is by locking it when checking out the file (for example: checkout bus OBJECTID lock;).

When checking in files that do not replace existing files (for example, if you check files into a format that contains no files or you append files), as long as the object is unlocked, you can check in new files. When an object is locked, no files can be checked into the object until the lock is released, even if the file does not replace the checked-out file that initiated the lock. This means that attempts to open for editing, as well as checkin, will fail. Files can be checked out of a locked object and also opened for viewing.

Enforce locking ensures that when a user checks out a file and locks the object, signifying that the user intends to edit the file, no other user can check in a file and overwrite the files the original user is working on. When the original user checks the file back in, the user should unlock the object.

Be aware that the manual unlock command (unlock businessobject OBJECTID;) is available for users who have unlock access, but users should avoid using the command for objects that have enforce locking. For example, suppose Janet checks out a file and locks the object with the intention of editing the file and checking it back in. Steve, who has unlock access, decides he needs to check in an additional file for the object so he unlocks the object manually. When Janet attempts to check in her edited file, replacing the original with her updated file, the system won’t allow her to because the object isn’t locked. To check in the file, Janet has several options:

  • She can check in the edited file in such a way that it won’t replace existing files; for example, change the name of the edited file and append it or delete the original file and check in the edited file
  • She can check out the original file again and lock the object, taking care not to replace the edited file on her hard drive with the older file she is checking out, and then check in the edited file

For more information, see MQL Concepts: Access Privilege Definitions.

A user would end up in a situation similar to the one described above if the user forgets to lock the object when checking out a file for editing. When the user attempts to check in the edited file, the system won’t allow the checkin because the object is unlocked (or possibly locked by another user who checked out the file after the first user).

For example, to enforce locking on the Proposals policy:

add policy "Proposals"
   description "Process for generating, reviewing, and releasing proposals"
   type Proposal, Plan
   format ASCII, "BestWord", Drawing
   defaultformat "BestWord"
   enforce;

The not enforce clause is available when modifying policies to turn the feature off.