Check in as Same Version?

Webtop lets you check in a document as the same (existing) version. However, when you do this the Content Server never sees a checkin call or event. Webtop simply sets the new file as content, updates any changed attributes, and saves the object. So a dm_save event occurs rather than dm_checkin.

It becomes more obvious if we look at the corresponding API call descriptions.

• checkin – creates a new version of an object in the repository and removes the lock from the previous version.
• save – writes the object to the repository without creating a new version of the object.

Both of these methods have an optional argument to retain lock on the resulting object (new version for checkin and existing version for save). This argument defaults to FALSE – the lock is gone after the operation.

So why do we care? Normally we don’t need to. However, if we turn notification on for a document we need to remember this difference between checkin and save. By default, notifications are sent only for checkin event occurrences. So we won’t get a notification if the document was “checked in as same version”.

Similarly, other behavior (such as auditing) tied to events may be affected.

Installing a DocApp multiple times

DocApps are used to package various elements for customization (such as custom Object Types, Lifecycles, etc.) so that they can be ported from one repository to another easily. It is usually not an issue when a DocApp is installed into a repository for the first time. Consider that a DocApp was developed in a DEV repository and then archived and installed into the QA repository. At this point the QA repository contains everything that was packaged in the DocApp.

Suppose that testing in QA exposes a problem with a lifecycle. We go back to DEV and fix the problem. Now, we archive the DocApp again and install it in QA. If we are using the default installation options on the DocApp, this will create a new version of the lifecycle! It is likely to lead to a problem.

A DocApp contains installation options and the options that address conflicts with existing duplicates are called Upgrade Options. Upgrade options include overwrite, version, overwrite if newer, and do not overwrite. Once you start looking at each item within the DocApp the choices may not be very difficult. The problem may arise if you decide to trust the default upgrade options.

In general (there are some exceptions), sysobjects have version as the default upgrade option. The tricky part is that lifecycles and workflow templates are also sysobjects. Usually, one doesn’t version lifecycles and workflow templates. However, default upgrade options will version lifecycles and workflow templates when the DocApp is installed again in a repository after the first time.

If you are creating a DocApp containing lifecycles and/or workflow templates the least you can do is to review the upgrade options for these objects. More often than not, this will be time well spent.