Managing FOLDER versions [LATEST]
Hello!
At our company the Agile Smartrule for Attachments “Copy Files to Rev – File Folders” is set to “Reference” which means “Agile uses the existing file folder and creates a new reference to it on the item’s new pending revision Attachments tab.” (from the Agile 9.3.4 Administrators guide).
We have run into a situation where, when more than one user has done multiple checkouts/checkins of a file on the same filefolder on a pending revision of an object, that Agile returns an “Insufficient Privilege” error when the user attempts to submit the new revision of the object with a folder VERSION that they have not created themselves.
An Administrator/Change Analyst can then go in an manually select the Folder Version and they can route the change. However, we have seen examples where the Change Analyst has selected [LATEST] instead of a specific number.
This associates the latest folder version with this revision – also after the revision has been approved and a new revision updates the folder version! This is a huge compliance issue.
First action is of course to ensure that those who can change it, never select [LATEST], but at a system level I need to ensure that this gets corrected.
The admin guide elaborates a lot on Attachments and Folders, but I have not been able to find a section that addresses this.
My initial questions:
1. What privilege determines weather a user can modify folder verions? (it looks like we have only assigned modify privileges to the admin, but I know change analysts can also change it)
2. Is it possible to remove the option to manually select [LATEST] ?
Thanks so much for all your expertise here!
Rune
edit: I found the attached document on Oracle Support, but it would be changing the basic handling of FileFolders in Agile, which is only a partial workaround, but not a solution to the issue.
It would appear that to fix this, when a file that is shared between more than 1 revision is checked out, it must first have a new FILES record created and assigned to the current revision that it is linked to. This would then leave everything else alone, but make sure you have a “new” copy to work with. What appears to be happening is that since the file is “shared” (basically the entire file structure is just linked to multiple revisions), when you check it out, it shows up on all revisions as checked out (that is what the attached document indicated). Since it is a shared file, yes, that (kind of) makes sense. And then it leads to your issue.
The main reason to use the “Reference” setting on the “Copy Files to Rev” smart rule is to save on vault storage (you don’t create a new version of all attachments when you create a new revision). And it is probably intended only for attachments that most likely won’t change (like external or standards documents). But if you have drawings or other attachments that will change for each revision, you are probably better off using the “Copy” or “Copy with Warning” options. That way every revision will at most have it’s own copy of each attachment, and there shouldn’t be issues with how Agile handles things.
Thanks a lot for your input Kevin. I can see the logic behind some of it. We will be changing the “Copy Files to rev” smartrule to Copy.
It still puzzles me that the system has the option for “LATEST” in the user interface. It makes sense at a system level (like a $latestrev association) but not for a user to be able to select it.
Thanks again,
Rune