Docman, handling multiple files as a block

We have something made over 15 years ago, just for you :)

You should read up on the topic “Extended EDM File” in the end-user documentation. The link below will not work for you directly, but I think you will know how to replace the “root” and make it work :)

http://docweb.corpnet.ifsworld.com/ifsdoc/Apps10/documentation/en/CreateAndMaintainDocument/AboutExtendedEDMFile.htm?StandAlone=true

Let me know if that document explains things in enough detail or if we should make it better.

Note: This functionality is not available in Aurena, yet. It’s “fringe”/seldom used functionality, and if people do not use it we would like to get rid of it, but we still have the option to implement support for it in Aurena (using the Aurena Agent, not possible without it). It works great in IEE though.

Thanks Mathias,

This is the functionality that we need. Unfortunately, the extra files most have the same name. In this case (above), they names have extras (.cutinfo, .thumbnail).  

I tried to get around this with new file extensions “CUTINFO.XML, THUMBNAIL.BMP”, but that is not allowed.

Unless you relax the requirements to the file names and implement it in Aurena , I think we have to abandon that solution.

A solution that I think could work, is to make 1 doc revision with all files in a structure. Here:

When the document is check-out, all the files in the structure goes to a new folder.

Right now we are looking into making that functionality ourselves, but it is an unpleasant amount of code. 

Somebody pleased talk us out of it.

Ah, what a pity… :’(

But yes, using a document structure might work too. Available in IEE but not yet in Aurena. Like the functionality mentioned above, it has very few users. It can be added but it is a substantial amount of work.

I guess you thought of the possibility to zip the files, right? Actually, a macro should be able to unzip when you edit the document and then zip it back again when you check in. Yeah, I think that should work.

Yes, I did consider making zip-files, but that would make the archive less flexible and un-searchable. And macros do not work on multiple files.

I did not know that file structures are not working in Aurena. Do you consider not porting it?    

We will probably add support for working with structure documents in Aurena if customers need it.

Would you like to elaborate on your first two paragraphs? Do you use content search to find the kind of files you mentioned here? With “archive” do you mean “Docman”? When you say macros does not work on multiple files, did you mean they do not execute if you select multiple document revisions in Docman and execute some file operation? If so, why/when do you do this? (it’s good for us to learn how customers use this)

Thanks!

Sure,

With Archive I mean docman. 

We need to able to search for the original file name. If the file is hidden inside a zip, we cannot do something like this:

select doc_no from edm_file where user_file_name = '124490.dxf'

If the files are in the zip, they will also have the same properties. E.g. approval. Probably not relevant in this case, but I am not sure.

In the case above, we need to check-out all 4 files. IFS will try to open them also. We do not want that. Only the the cur-file. I tried to fix that with a macro (if class_name=’x’ then exit sub). That is working fine, when you only have one file selected. On multiple selections, it is not working. We will then have to check-out the files one by one. Too tedious.

At this point I gave up trying to solve it with macros.

The solution considered now:

• Fire an event when a new revision is created.
• If class_name=’x’, move the file to the structure of a “master-revision” for the relevant part. 
• When a revision containing a structure is check out, IFS can save the files instead of open them.
• Locate the cur-file in explorer and open it.

• When a revision containing a structure is check out, IFS can save the files instead of open them.

Above, you mean the user will select the “Open Folder” option of the View/Edit Document Structure dialog, right?

I still think you should consider zip files… :) Is the search that important? Can’t the same data be put in some other field, or even in the zip file name even?

The solution of using a custom event seems to be clever and all, but one custom event after the other will take you down the custom event/trigger rabbit hole… :)

Another options, also “clever”, might be to have a macro rename the files such that the “extended EDM file” support works. Then another macro, when editing or viewing would rename them back after they are opened. The question is where to store the file names in the meantime though… Perhaps, and now things becomes even more “clever”, the macro could create a new file, a pure metadata file that contains information about the other files. This will also be checked in. The macro that is used when checking out can then read this file, and rename the other files. Heck, the macro could even create two more fake files that keep the basename part of the renamed files, for your search requirement.

Okay, I better stop now before I get too clever for my own good… :)

Above, you mean the user will select the “Open Folder” option of the View/Edit Document Structure dialog, right?

Yes, unfortunately the folder is not deleted when the files are checked-in.

I still think you should consider zip files… :) Is the search that important? Can’t the same data be put in some other field, or even in the zip file name even?

Search is important. Saving the data somewhere else. I do not like it. We then have to sync that with what is actually in the zip, forever.

Another options, also “clever”, might be to have a macro rename the files such that the “extended EDM file” support works. Then another macro, when editing or viewing would rename them back after they are opened.

This could work, and we do not have to remember the original names. We know that. Add CutInfor for the xml file…

Of course, this is only relevant if “extended EDM file” does not goes to graveyard with IEE.

I might have a look at it during the weekend.

We very much appreciate your help  .

Yes, unfortunately the folder is not deleted when the files are checked-in

Hmm… Cannot remember why now. It’s probably because we did not want risk deleting anything by mistake. However, you can safely remove these folders if they are empty I guess.

Of course, this is only relevant if “extended EDM file” does not goes to graveyard with IEE.

Yeah. Well, we do support view copies in Aurena already so adding support for checking in “other files” should not be hard. But it of course adds to the overall complexity and complexity adds to the bug count, eventually, so we would like to know this is used if we should add it to Aurena.

I wonder if we could/should extend this functionality in some way. The reason we require the basename to be the same is of course that it is the only way we know which files to pick, without requiring even more basic data/rules and without asking the user. But perhaps we should ask the user, in this case, like we do for checking of structure documents… Thoughts?

But perhaps we should ask the user, in this case, like we do for checking of structure documents… Thoughts?

I think it has to be automated. The users don't know what these files do. If they forget to check in a file, it breaks. But they are used to working with folders. Maybe check in all the files in a folder to 1 document revision and connect a master file extension to the doc class?

I have tried the extended EDM file function and I got it to work, but there is a problem.

I have to register cur, xml, bmp files with new document types. Then I cannot use them as “Originals”. That is not acceptable for xml and bmp- files. How do I solve that? 

Hmm… I was going to say that you can check them is as originals as well, because we can do that for file types that we set as VIEW. But now that I tested it seems like we stop the user from checking in “other” file types. I have a vague memory of having discussed or at least been thinking about this scenario at some time, but I don’t know if we/I came to any conclusion. It would be interesting to open up for supporting checking in these “other” file types as originals, when the user wants to, and see what happens. Perhaps it will work beautifully or perhaps there will be some nasty side effect we could not think about, forcing us to roll back the change. The file handling in Docman is… tricky, sometimes, because of all the features that we provide, and it’s easy to break something unrelated when we fix something seemingly simple…

Sorry, but this does not seem to be a good option for you, as it works now. You could try filing a case and we could have a look at it, but I make no promises that we can fix it. After all, we need to protect the functionality we designed this for, as the first priority.

Also, if we fixed this, would you use it? You suggested above that you cannot require the files to have the same basename, still, you did an experiment. So, which is it? :)

I actually have it running using macros. Here is the procedure and the last small issues at the bottom.

Create 2 document class actions (checkin and checkout)

Create the 2 macros:

Checkin code:

Public Sub run()

stDocClass = ScriptValues.Item("DOCUMENT_CLASS").Value

if (stDocClass="ZUND") then

  stFileName = ClientScriptValues.Item("LOCAL_FILE_1").Value
  stPath =   ClientScriptValues.Item("CHECK_OUT_PATH").Value

  set objFso = CreateObject("Scripting.FileSystemObject")

  set objBaseFile = objFso.GetFile(stFileName) 

  stBaseName = GetFilenameWithoutExtension(objBaseFile.Name)

  'Rename XML file  
  stXmlName =  stPath & stBaseName & ".XML" 
  stXmlNewName =  stBaseName & ".CutInfo.XML"
  
  set objXmlFile = objFso.GetFile(stXmlName)
  objXmlFile.Name = stXmlNewName    

  'Rename BMP file
  stBmpName = stPath & stBaseName & ".BMP"
  stBmpNewName =  stBaseName & ".Thumbnail.BMP"

  set objBmpFile = objFso.GetFile(stBmpName)
  objBmpFile.Name = stBmpNewName    

end if

 End Sub

Checkout code:

Public Sub run()

stDocClass = ScriptValues.Item("DOCUMENT_CLASS").Value

if (stDocClass="ZUND") then

  stFileName = ClientScriptValues.Item("LOCAL_FILE_1").Value
  stPath =   ClientScriptValues.Item("CHECK_IN_PATH").Value

  set objFso = CreateObject("Scripting.FileSystemObject")

  set objBaseFile = objFso.GetFile(stFileName) 

  stBaseName = GetFilenameWithoutExtension(objBaseFile.Name)

  'Rename XML file
  stXmlName = stPath & stBaseName & ".CutInfo.XML"
  stXmlNewName =  stBaseName & ".XML"  
  
  set objXmlFile = objFso.GetFile(stXmlName)
  objXmlFile.Name = stXmlNewName    

  'Rename BMP file
  stBmpName = stPath & stBaseName & ".Thumbnail.BMP"
  stBmpNewName =  stBaseName & ".BMP"

  set objBmpFile = objFso.GetFile(stBmpName)
  objBmpFile.Name = stBmpNewName    

end if

 End Sub

Helper function:

Function GetFilenameWithoutExtension(ByVal FileName)
  Dim Result, i
  Result = FileName
  i = InStrRev(FileName, ".")
  If ( i > 0 ) Then
    Result = Mid(FileName, 1, i - 1)
  End If
  GetFilenameWithoutExtension = Result
End Function

Add class management:

Now we cannot checkin bmp-files. We do not have any in the system right now, but one day it sure comes back and kick us.

It is not working in Aurena, but Mathias will fix that before the release of IFS 11. Right?

I cannot figure out how to disable the macro popup if I checkin a dxf-fil to another class than “Zund”.

  How is that done?

It is not working in Aurena, but Mathias will fix that before the release of IFS 11. Right?

We cannot make any such promises at this time, I’m afraid. Especially not here. If you file a support case about this, we can discuss there.

I cannot figure out how to disable the macro popup if I checkin a dxf-fil to another class that “Zund”.

The only way to disable the macro popup is by adding configuration in Document Class Process Action, for all classes where it should be disabled (so you need to think about what classes users might want to check in the type of files the macro is connected to), by using the RunIfOnlyOne option. While on the topic of Aurena, we decided that, most probably, no user today wants to see that popup, so we have not added it back there. In the scenario where more than one macro is available, we will execute the first one we find.