I had to refactor this article because it didn’t make as much sense as now in my mind when I first wrote it. This is now split in two with a main post being this one. Hopefully it will be more understandable for everyone!
You have associated an entry template to a folder, or the ObjectStore itself. You tried to add a document into a subfolders, but your entry template never appears in the selection list of entry templates. If you go into the properties of the subfolders to see if the entry templates are correctly inherited, you can see either an empty list, or it says there are inherited entry templates but the File Types are really strange and error is displayed. Here are what you see and what you were expecting to see.
Here is a video describing the problem, so you can understand better.
Well this is because Entry Templates have been associated to folders being between the folder you are trying to add to, and the folder you did the association of Entry Template in IBM Content Navigator.
Indeed when you are adding a document, ICN looks for Entry Template associated on the folder, if there is none, it do the same on its parent, and so on until the root folder, the Object Store. Of course it stops as soon as it find one. The problem is that it looks for both Workplace XT association (application/x-filenet-folderprefs-templates), and ICN associations (application/x-icn-folderprefs-templates). If both exist on a same folderm of course it uses its own. But problems occurre when a folder in the middle has a Workplace XT ET association, then ICN stops there and uses this association instead of the one you made in ICN on a top folder.
That would be perfectly acceptable if we could see the association made in Workplace XT correctly. But truth is we can’t, and that’s make things confusing for the users because he can’t see there is a WPXT association on a middle folder, and doesn’t understand why the association is not correctly inherited. On the folder having the WPXT association, the list is empty, and we can actually see the association on sub-folder of this folder, but usually all buggy because of the File Type issu, which is another problem discussed in another post.
How to fix it
There is three possible workarounds for this issue.
First one might not be convenient to do, and time consuming, but at least it works. It you remake all entry templates associations you have done in Workplace XT in ICN, in the exact same folder each time, the ICN associations are predominant and will be used instead of the Workplace XT ones. So everything will work. So just look into the Workplace XT where associations are done, and do the same one in ICN. You can use the Workplace XT entry template it doesn’t matter, and it actually works great. The only think not working is when ICN tries to use the association made in Workplace XT, but using Workplace XT entry templates in an ICN associations works fine. you can also make a tool converting the Workplace XT association (this is actually a xml annotation) to a ICN association (and this one is a json annotation). It will just have to know the mapping between WPXT File Type Categories and ICN File Type filters. Ask me if you need more information on this.
The second one is to actually do no association in ICN, and do all of them in Workplace XT. That way you won;t have this problem. This is the solution we choose in our platform. However you will then have the File Type issue, since ICN does not understand the File Types Categories used in the WPXT association. If you fix this, see the other post, then you’ll have a platform fully working.
The last one is converting all Workplace XT Entry Template to ICN Entry Template, then redoing all association in ICN the same way you’ve done them in Workplace XT, or you can use the same tool as in workaround 1, definitely shut down the Workplace XT and delete all annotation of MIME Type application/x-filenet-folderprefs-templates on all folder. That would actually be a good thing done 😀