Establishing a makeversion Action using the xmp:ModifyDate Field

Using the xmp:ModifyDate Field to trigger makeversion

Some Adobe applications update the value of the xmp:ModifyDate Field each time a file is saved, potentially making this Field, by way of example, a convenient trigger for the makeversion Action. (You can, however, trigger the makeversion Action in other ways.) With xmp:ModifyDate being a DATE Field, the Any Change option one would like to set for it in its Trigger Set wouldn’t typically be available; however, Xinet, ships a moddatetotext script inside the /usr/etc/webnative/actions/makeversion directory on Unix systems and the C:\Program Files\Xinet\WebNative\Bin\actions\makeversion on Windows systems. Execute the script in the makeversion directory and it will convert the xmp:ModifyDate Field to a TEXT field.

Note: The Solr index must be rebuilt if the moddatetotext script is executed. To rebuild the Solr index, open the Database > Admin > Searching tab, click Disable Solr Services, and then restart the Solr index by clicking Create Solr DB.

You can verify that xmp:ModifyDate is now a TEXT Field by checking the Xinet ADMINISTRATION view. Note that the Field will save information into an XMP packet.

1.	Add the xmp:ModifyDate to a Template, making sure the Field can be edited.

2.	Set up a Permission Set for the Template. (Xinet recommends that you make the Field invisible in the Permission Set, as this is likely to be less confusing for those editing files.)

3.	Assign the Template and Permission Set to Xinet users who will be editing the files on AFP volumes. Each user must use the same login name as a system user as he or she does as a Xinet user. The users do not have to have published Xinet volumes.

Only files saved by these users will create file versions.

If you want all users to create versions of files whether or not they have a matching Xinet login, assign the Template and Permission Set to the Default user. This will allow any AFP user, including guest, to use versioning.

4.	Configure a Setting for the makeversion Action, using the Database, Actions, New Setting. The page allows you to set five arguments which are logically related to one another by OR. If you leave any argument blank, Xinet will ignore that restriction. The arguments include:

• Suffix include list
You may identify files in an active path for which versions will be made when a file is saved by file name suffix, such as jpg tif psd indd ai, for example. (If using more than one suffix, separate items in your list by blank spaces.) If you leave the field blank, saving any file that writes XMP data to the correct Field will create a version.

• Filetype include list
You may identify files for which versions will be made by their filetype, for example IDd6 8BPS PDF. (If using more than one filetype, separate items in your list by blank spaces.) See filetype(4) and /usr/adm/appletalk/filetype for details about how Xinet identifies files in this manner.

• Max. versions allowed
Allows you to specify the maximum number of versions of a file that will be kept. When the file system exceeds the maximum number allowed, the oldest version will be erased. Be careful if you change this setting at some point to a smaller number, you may erase some older versions.

• Min. Time (in seconds) between versions per user and file
Allows you to suppress the making of a version when a file is saved multiple times in quick succession by a given user while editing. This will reduce the number of versions saved when operators habitually Save files in rapid succession. If the Field remains empty, no delay time between versions will be enforced.

• Required string in filename
Allows you to enforce the saving of versions by the appearance of the designated string in the name of the file being saved. For example, if you want to keep versions of all files that contain the string draft, you would add draft in the Field. If the Field remains empty, no filename filter will be used.

5.	Establish a Trigger Set to run the makeversion Action. It should look similar to Using Trigger Sets provides details.

Note that like any Trigger Set, an Active Path must be established before Xinet will save versions.

6.	Enable version control for Xinet users by enabling the User Volume option, Show Versions, found on the Volumes/Users, User Volumes, Edit Volume page. Creating versions of assets displays an example of the interface they will use.

About file versions

What happens when a user saves a file when the makeversion Action is triggered?

1.	When a user saves a file in the makeversion Action’s Active Path, if it doesn’t already exist, the Action will create a Versions subdirectory within the directory where the asset dwells. If a Versions subdirectory already exists, it will use it.

Changing the name of the folder where versions will be kept

Normally, Xinet uses a folder named Versions to store versions of files; but, you can change the name to another name if you would like by following these steps. (If you do not do this, Xinet will continue assuming a folder named Versions.)

1.	Create a file called versions.conf in the following location:

Unix: /var/adm/webnative/
Windows: C:\Program Files\Xinet\WebNative\Admin\

2.	Add the new name (as a single line entry) where you would like versions of files to be kept to the versions.conf file.

3.	Create a new record in the searchenginesettings table, as shown in the example below, that establishes another name for Versions. In this example, the folder will be called Saved: