File Tracker download directory regression

Using Workplace XT, we were able to keep the folder hierarchy of a Document within the Object Store when downloading it with the File Tracker applet. That means, if your document’s path was /Folder/SubFolder/Document.xml, and your FileTracker folder on the client was C:\FileNet\Work, then you would get your document downloaded as C:\FileNet\Work\ObjectStoreName\Folder\SubFolder\Document.xml.

That’s no longer true with ICN. Everything goes into your download folder, C:\FileNet\Work in the previous example, without creating any sub-directories. This is especially an issue if you download a lot of document and want to edit them, this folder becomes a mess, and if a lot of documents are called the same in your Object Store, then you will have conflicts.

Officially, this is because this functionality is now covered by the Sync and Share feature, which uses a client agent on Windows platform, and is embedded in mobile applications. However this does not cover Unix platforms, and does not allow using Entry Templates, which can be a requirement for your platform. That’s why we will see how to make it work in ICN anyway.

How to fix that


Here what I did to work around that. I’m not saying this is the most gracious solution, but it is not too intrusive and quite “easy” to implement. The idea is just to aspect the Check Out Dialog to, so when ICN shows it, you can concatenate the path of the item within the Object Store to the already set download path, which should be the download folder for the File Tracker. Then just let the ICN File Tracker applet do its job, within the folder you provided instead of the default folder.

This work-around is implemented in 3 steps;

  • Concatenate the path in the Check out dialog
  • Create the folder to accommodate the ICN File Tracker applet
  • Get rid of the warnings from our applet
Concatenate the path in the Check Out dialog

In your plug-in, for instance the main JavaScript file, aspect the show function of the Check Out dialog and concatenate the path of your item:

// Adding fix to keep folder hierarchy on Check Out
aspect.after(CheckoutDialog.prototype, "show", function (repository, documentInfoArray, callback, items) {
    if (items && items.length > 0) {
        var itemPath = Utils.toFSPath(items[0], false);
        var fileTrackerHome = this._fileInput.get("value");
        this._fileInput.set("value", fileTrackerHome + itemPath);
    }
}, true);

The toFSPath function just use the item.getPath() to build a / or \ separate path depending on the client platform. Result should looks like that:

ICN_FileTrackerFix

This is the first step of the work-around. But that won’t work because the ICN File Tracker applet is not able to create folders since now everything goes in the same folder. You have to provide an existing folder, that we will create automatically. Another way could be using the Workplace XT File Tracker applet, which is already implemented and signed and can create folder, but I haven’t tried it yet so I won’t comment it for now.

Create the folder to accommodate the ICN File Tracker applet

There aren’t a lot of ways to modify the client File System with the W3C FileSystem API beging quite dead (Java/Flash/ActiveX/Silverlight). We are going to use a Java applet since they are already used in ICN. Our applet will have only one method, which creates a folder on the client if it doesn’t exist yet, or do nothing if it does. The code, really basic, is the following:

public boolean createDirs(final String path) {
    return (Boolean) AccessController.doPrivileged(new PrivilegedAction<Object>() {
        public Object run() {
            File theDir = new File(path);
            if (!theDir.exists()) {
                return theDir.mkdirs();
            }
            return true;
        }
    });
}

As you may have noticed, we have to use an AccessController even if the applet will be signed, because this method will be called via JavaScript. Don’t forget to sign this applet. See my post on how to use an applet in ICN to embed that nicely in your code. Then use it in your JavaScript code. Your code should now be:

// Adding fix to keep folder hierarchy on Check Out
aspect.after(CheckoutDialog.prototype, "show", function (repository, documentInfoArray, callback, items) {
    if (items && items.length > 0) {
        var itemPath = RecycleBinUtils.toWinPath(items[0], false);
        var fileTrackerHome = this._fileInput.get("value");
        this._fileInput.set("value", fileTrackerHome + itemPath);
        MyApplet.createDirs(fileTrackerHome + itemPath);
    }
}, true);
Get rid of the warning from our applet

Everything should work at this point except you have some annoying warnings because of your signed applet. This is because Java now requires to have signed applet signed with certificate trusted by a CA (Certificate Authority), for instance Comodo, DigitCert, VeriSign and so on. You have to pay them of course. If you can afford it that’s great. If you can’t, another solution would be to add your self-signed certificate you used to sign the applet, to the keystore of the JRE used by the client’t browser. Of course it would have to be done on all clients, but can be automatized with the following command:

REM This is how to trust the certificate, it needs to be done on all user workstations
REN the JAVA must be the one used by the browser
set JAVA_HOME=C:\Program Files (x86)\Java71\jre
"%JAVA_HOME%\bin\keytool" -importcert -keystore "%JAVA_HOME%\lib\security\cacerts" -alias myalias -file mycert.cer -storepass changeit

And you will have to export your certificate from the keystore you used to sign the applet with the following command:

REM export the certificate again from the keystore
keytool -exportcert -keystore mykeystore.keystore -alias myalias -file mycert.cer

That’s it. At this point you should have something working, when the Check Out dialog is shown, the document path within the repository will be added and the folder created. Don’t worry, the ICN File Tracker applet is able to find the documents in sub-folders too, so that will work when checking in back the document. Of course, if the user cancels, the folder won’t be deleted but folders stay when user check in anyway so it doesn’t make any difference.

Leave a Reply