This is the second post about the issue occurring when using Workplact XT entry template with ICN. We’ve seen that there is an inheritance problem in this post, we will now see that there is a problem of File Types filters. This issue needs to be addressed if you want to use the second work around of the former issue.
Symptom
You’ve created Entry Templates in Workplace XT, and also created a few File Type Categories gathering several MIME Types. You’ve used these Entry Templates by associating them on a folder to use them when adding document. You restricted them by File Type Category. For example ET 1 is only for Images (File Type Images gathering image/png, image/jpeg, …), ET 2 is only for office documents, and ET3 is for every king of document. That looks a little bit like that in Workplace XT:
Problem is that in ICN, this does not work. You always get the generic entry template (in my case misc doc, or no Entry Template if they all have restrictions on the File Type Categories.
If you look in a sub-folders of the folder on which you did the association in Workplace XT, you can see something like that:
Here is the problem, ICN does not understand the file type. This makes sense because actually in the Workplace XT Entry Template association (which is an xml annotation on the folder), the File Type are stored as ID only, and the Workplace XT keeps the File Type Categories definitions in its Site Preferences document. Therefore ICN has no way to know that h16vy is actually the Images File Type filter in ICN, even the name can be different so how could it know!
How to fix that
You have to ways to fixing this.
Basic way
The first one is more like a workaround. You can redo all associations you’ve done in Workplace XT in ICN, on the exact same folders, using the Workplace XT Entry Template but this time using the ICN File Type filters. This is a lot of work but it will work. Or you can automatize that by writing a tool converting all annotation of MIME Type application/x-filenet-folderprefs-templates (xml content) to an ICN one (application/x-icn-folderprefs-template an json content). Obviously this tool will have to know the mapping WPXT File Type Category ID –> ICN File Type filter name (there is no ID in ICN, the ID is the name, which actually creates another problem). The tool should transform something like this:
<object key="folderPreference" version="1.0">
<list key="folderTemplates">
<object key="folderTemplate">
<setting key="templateObjectStoreName">TARGETOS</setting>
<setting key="templateVersionSeriesId">{E9986DA5-1082-4B73-B7A3-C9B996962F4E}</setting>
<array key="fileTypes">
<value>i0dwzm4z</value>
</array>
</object>
<object key="folderTemplate">
<setting key="templateObjectStoreName">TARGETOS</setting>
<setting key="templateVersionSeriesId">{5E26863D-5E46-40E4-AC3A-698192FBD473}</setting>
<array key="fileTypes"/>
</object>
<object key="folderTemplate">
<setting key="templateObjectStoreName">TARGETOS</setting>
<setting key="templateVersionSeriesId">{63F142DB-8B6F-4163-B58B-69E7E3B9817D}</setting>
<array key="fileTypes">
<value>i0cpw1e7</value>
</array>
</object>
</list>
</object>
to something like that:
[
{
"currentFolderAsParent":true,
"fileTypes":["IBM Art Files"],
"type":"document",
"entryTemplateVsId":"{63F142DB-8B6F-4163-B58B-69E7E3B9817D}"
},
{
"currentFolderAsParent":true,
"fileTypes":["IBM DITA"],
"type":"document",
"entryTemplateVsId":"{E9986DA5-1082-4B73-B7A3-C9B996962F4E}"
},{
"currentFolderAsParent":true,
"fileTypes":[],
"type":"document",
"entryTemplateVsId":"{5E26863D-5E46-40E4-AC3A-698192FBD473}"
}
]
Smart way
The second way is more complex to implement but a lot more flexible and smart. The idea is to make ICN aware of the WPXT File Type Categories via a plugin sending the mapping to the client when it first connects. Then the plugin injects some code into the client so every times it retrieves a Entry Template association, it maps the unknown file type ID to an ICN equivalent. That’s more work but then it will instantly work for all existing associations and also for all future associations made in Workplace XT!
Here is briefly how to implement that. First you need to create a new plugin, the most complex part will be the Configuration Pane if you want it to be “smart” and fetch all Workplace XT File Type Categories by itself. It has to know the Object Store where is the WPXT Site Preferences Document, then fetch it and parse it. Then it offer you to map to an ICN File Type filter, and tries to do it automatically if name are the same. Here is what it looks for my plugin:
You can also make it dumb and dirty :), and just use one text field and fill it with
id1=File Type In ICN 1;id2=File Type In ICN 2;id3=File Type In ICN 3
The admin would have to open the Site preferences document of Workplace XT to know the ID and ICN Settings to know the File Type in ICN but that’s so much quicker to implement 🙂
Then you need to inject that on the client so it can map File Type Categories when retrieving Entry Template Association, this is how I did that:
require(["dojo/_base/declare",
"dojo/_base/lang",
"dojo/aspect",
"ecm/model/Request"], function (
declare,
lang,
aspect,
Request
) {
/**
* Use this function to add any global JavaScript methods your plug-in requires.
*/
var signalFileTypeFixPlugin = null;
var _injectFileTypes = function (fileTypesArray) {
// Build a hashmap for all file types
var fileTypes = {}, k, curfileType;
for (k = 0; k < fileTypesArray.length; k++) {
curfileType = fileTypesArray[k];
fileTypes[curfileType.id] = curfileType.name;
}
// aspect the retrieve template to change the file type
aspect.before(ecm.model.Repository.prototype, "_retrieveEntryTemplatesCompleted", function (response) {
var i, j, fileType;
for (i = 0; i < response.datastore.items.length; i++) {
var entryTemplateJSON = response.datastore.items[i];
for (j = 0; j < entryTemplateJSON.fileTypes.length; j++) {
fileType = entryTemplateJSON.fileTypes[j];
if (fileTypes[fileType]) {
entryTemplateJSON.fileTypes[j] = fileTypes[fileType];
}
}
}
});
// Execute this method only on the first login or we will have several aspects
if (signalFileTypeFixPlugin) {
signalFileTypeFixPlugin.remove();
}
};
var fileTypePluginDeployed = function () {
var i;
for (i = 0; i < ecm.model.desktop._plugins.length; i++) {
if (ecm.model.desktop._plugins[i].id == "FileTypeFixPlugin") {
return true;
}
}
return false;
};
// Retrieve plugin configuration from the server and store it
var _fetchFileTypes = function () {
if (fileTypePluginDeployed() && ecm.model.desktop.id != 'admin') {
Request.invokePluginService("FileTypeFixPlugin", "FetchWPXTFileTypesService", {
requestCompleteCallback: function (response) {
if (response.filetypes) {
// Here we can inject the File Types in the desktop config
_injectFileTypes(response.filetypes);
} else {
console.log("Error when retrieving File Type in the FileTypeFixPlugin");
}
}
});
}
};
// Function called on the onLogin even from desktop
var _onLogin = function (repository) {
_fetchFileTypes();
};
if (ecm.model.desktop.connected) {
// recycleBinPath not retrieve yet
_fetchFileTypes();
} else {
// dojo/on won't work because desktop does not fire events,
// let use aspect to call our method at the end of the dektop.onLogin
signalFileTypeFixPlugin = aspect.after(ecm.model.desktop, "onLogin", _onLogin);
}
});
I chose to use the _retrieveEntryTemplatesCompleted function of the repository, since it’s called once per folder then entry templates are cached. That’s a minimal overwork for the client.
As you can see, I implemented a service which basically only returns the mapping set in the plugin configuration panel, which is stored in the plugin configuration. It does not fetch them from Workplace XT every times of course.
Here is a video illustrating the fix:
