Working with Business Object Files

Checking in a file allows other users to access a file that might not otherwise be accessible. The policy definition that governs an object can designate when specified persons, groups, and roles have access to an object. When an object is accessible, any files that are checked into that object are also accessible. If a group has read access to an object, they also have read access to any files checked into the object. If the policy definition for an object includes enforced locking, no check-in for that object is allowed until the lock is released, regardless if the file being checked in will replace the checked-out file which initiated the lock or not.

When working with checked in files, keep in mind that the copy you check in will not change if you edit your own personal copy. While you maintain the original, any edits that you make to that file will not automatically appear in 3DSpace. The only way to have those changes visible to other users is to check in the new version.

Checking in files is controlled by the Checkin Businessobject command. For more information, see MQL Command Reference: businessobject Command.

After a file is checked in, it can be modified by other users who have editing access (if the object is not locked). When a business object file is checked out, a copy is made and placed in the location specified. This copy does not affect the Collaboration and Approvals copy. That file is still available to other users. However, now you have your own personal copy to work on.

In some situations, a person might be denied editing access but allowed checkout privilege. This means the user cannot modify the Collaboration and Approvals copy, but can obtain a personal copy for viewing and editing. This ensures that the original copy remains intact. For example, a fax template is checked in, and each user can check out the template file, fill in individual information, and fax it. These users cannot edit the template and check in an updated version, as long as the permissions are correctly set.

The 3DEXPERIENCE platform handles the transfer of large files (that is, files larger than 2 gb) for checkin or checkout in exactly the same way they handle smaller files. However, the larger a file is, the longer it takes to check it in. For HTML/JSP-based applications, including the 3DEXPERIENCEapps and custom programs, large file checkins must be targeted for an FCS-enabled store/location (see File Collaboration Server Installation for setup information.)

It is recommended that you enable both FCS for all implementations, even if you do not foresee working with files larger than 2 gigabytes.

A business object can be locked to prevent other users from editing the files it contains. Even if the policy allows the other user to edit it, a lock prevents file edit access to everyone except the person who applied the lock.

Locking a business object protects the object's contents during editing. When an object is opened for editing, it is automatically locked to prevent other users from checking in or deleting files. A lock on an object prohibits access to the files it contains, but still allows the object to be manipulated in other ways. If a user has the proper access privileges, that users can view and edit attribute values and connections of the object and change its state.

If the checkout and edit are separate actions, the object should be manually locked. Without a lock, two people might change an object's file at the same time. With a lock, only the person who locked the object manually is allowed to check files into the object. As with an automatic lock, other users can view attributes, navigate the relationships, and even checkout an object's file. But, they cannot change the contents by checking in or deleting a file without unlocking the object.

It is possible for a locked object to be unlocked by a user with unlock access. For example, a manager might need to unlock an object locked by an employee who is out sick. For more information, see User Access.

If another user has unlock privileges and decides to take advantage of them, the person who established the lock will be notified via IconMail that the lock has been removed and by which user. This should alert the lock originator to check with the unlocker (or the history file) before checking the file back in to be sure that another version of the same file (with the same name and format) has not been checked in, potentially losing all edits made by the unlocker.

If the object is governed by a policy which uses enforced locking, the object must be locked for files to be checked in. Users must remember to lock an object upon checkout if they intend to checkin changes, since the separate lock command will be disabled when locking is enforced.