Documentum : freeze, checkin, checkout, lock,…

Hello,

Just a post concerning the freeze, unfreeze mechanism of documentum which allows to mark an object and, optionally, its components (if the object is a virtual document), as unchangeable.

There is also the lock/unlock mechanism which places a database lock on an object.

FREEZE DOCUMENT
The content server modifies these following attributes of the object when freezing an object :
• r_immutable_flag to true : This attribute indicates that the object is unchangeable.
• r_frozen_flag to true : This attribute indicates that the object is unchangeable because it was specifically frozen.
• i_vstamp incemented.
• r_modify_date, r_modifier.

+ API : freeze,session,object_id[,freeze_components]
+ DFC : IDfSysObject.freeze()

Document before freeze:
Document after freeze:
It is not possible to freeze a frozen document:

UNFREEZE DOCUMENT
The content server modifies these following attributes of the object when freezing an object :
• r_immutable_flag to false: This attribute indicates that the object is unchangeable. Note that if the object has been versioned, unfreezing the object does not unset this attribute; it remains set to T.
• r_frozen_flag to false: This attribute indicates that the object is unchangeable because it was specifically frozen.
• i_vstamp incemented.
• r_modify_date, r_modifier.

+ API : unfreeze,session,object_id[,thaw_components]
+ DFC : IDfSysObject.unfreeze()

Document before unfreeze:
Document after freeze:
It is not possible to unfreeze a not frozen document:
ACTIONS on FROZEN DOCUMENT
TEST : DELETE/DESTROY a frozen document
DQL/API myadminuser : Delete/destroy of frozen document is impossible.

TEST : UPDATE a frozen document
DQL/API myadminuser : Update of frozen document is impossible.

TEST : CHECKOUT a frozen document
DQL/API myadminuser : CHECKOUT of frozen document is possible. The CHECKOUT action sets the attributes r_lock_owner, r_lock_date, r_lock_machine, i_vstamp. The attributes r_modify_date and r_modifier are not modified.

TEST : CHECKOUT/CHECKIN a frozen document
DQL/API myadminuser : CHECKOUT/CHECKIN of frozen document is possible.
Before CHECKOUT / CHECKIN After CHECKOUT After CHECKIN : the document is still FROZEN After CHECKIN : NEW VERSION UNFROZEN of document after CHECKOUT / CHECKIN : 090xxxxxxxxxxxxxx69

LOCK/UNLOCK DOCUMENT
It is possible to place a database lock on an object (lock) and remove this intention lock without saving any changes that may have been made to the locked object (unlock).

The lock and unlock mechanism don’t modify any attribute of document:
The UPDATE of a database LOCKED document is possible:

Unlock (i.e., Cancel Checkout) of an Object
It is possible to cancel checkout (Unlock) on the document which is locked by another user. The above api command to unlock the document which is checked out by another user, to execute the command the user must have minimum of Administrator access.
When a user makes a checkout on a sysobject (opens to edit), Documentum automatically applies a lock on the object, preventing other users from modifying it. Only the lock owner or a superuser can unlock the object by making a checkin or cancel the checkout. As sometimes users forget to unlock documents, you might need to do this as a superuser.
You can unlock an object in 2 ways:
The last argument is a boolean flag specifying if a mail notification will be sent to the lock owner.


IMPORTANT POINT :
+ We have remark that during a checkin on a document having no aspect, if the checkin includes the attachment of new aspect and the set of DATE attributes THEN there is an unexpected error related to a BUG in the DFS or DFC layer of Documentum. “Bad attribute name aspect_huo.my_start_date for document/object.”.

+ In fact, there is no attachment of the aspect despite the presence of {r_aspect_name =; aspect_huo} and this causes an error {[DM_API_E_BADATTRNAME] error: “Bad attribute name ‘aspect_huo.my_start_date’ for document / object.”}

+ This error only occurs with DATE attributes (eg: “aspect_huo.my_start_date” / “aspect_huo.my_end_date” of aspect “aspect_huo”).

+ The problem never arises if the aspect is already associated with the document.

+ SOLUTION: The solution found is during a CHECKIN to:
o delete the “[ASPECT] .DATE” fields from the list of PROPERTIES to update with CHECKIN,
o do the CHECKIN without the “[ASPECT] .DATE” fields,
o do an UPDATE (if the current user has WRITE permission) or do an automatic CHECKOUT / CHECKIN to update only the “[ASPECT] .DATE” fields,

Here, an example of CHECKOUT/CHECKIN followed by UPDATE in API:

Best regards,


Huseyin OZVEREN