Hi Marianne,

Thanks for asking here.

There is currently no setting for controlling that. It would not be bad to have one but, surprisingly, this is the first time I hear about the idea :)

I suggest you file a an idea/request here on Community, if you have the possibility to do so.

You can probably fix this with a custom event with a custom event action connected to it. It would look for new file references where Document Type = VIEW, and check if the document was just made from an old one. If so, it can remove the file reference, and the file. If the file is stored in the database, otherwise it is messier... On the other hand, perhaps it will work just removing the file reference and keeping the file since the system will not know about it without the file reference... And, eventually, a new view copy will overwrite the wrong one in the repository.

If you trigger on the file reference tab you will get the dreaded "mutating table", but it can be overcome. Search for "mutating table" here on Community and you will find posts that discuss various solutions on how to avoid that.

Good luck!

/Mathias
 

Hi Marianne,

We just discussed exactly this issue a view days ago with our engineering department. I can support this requirement.

regards Johannes

Hi both

Thank you for your replies. I think a custom event is a good idea to solve this issue temporarily.

I will post this as an idea here in community, but also raise it as a standard bug to IFS support. I don’t think their is an reasonable logic behind the possibility to be able to Release a document revision with a view copy which is a copy of the previous revision and not a copy of the original file for current document revision. At least user should have a warning that it is a view copy connected to document revision which has to be deleted and replaced with a new one.

@Marianne 

There is a warning when you check in the original file after having edited it, if the view copy is older than the original. Did you know that? It is meant to avoid having an outdated view copy.

I think you will have no success in getting this changed in support, since it will not be accepted as a bug. This is a very old feature and am quite sure that there are existing customers relying on the current functionality.

In my view, the only solution here is to introduce a setting, either in the user interface or in basic data, (or both) so I think you should register that idea and leave it at that.

In the meantime, you can use a workaround like what I mentioned earlier.

@Mathias Dahl 

I can see that user getting a Warning message “View file does not exist, do you still want to Check in the Document”

This is a information message which is quite confusing for user. There is a view copy already attached to document revision and user will in most cases misunderstand the message and select Yes even though the pdf is a copy of previous revision and not current revision. 

Anyway.. we will create a event which will delete the view copy when creating a new document revision to avoid this 

That is actually a message for another scenario than the one I was thinking about. That comes because you have selected the “view copy required” option on the document title.

I realized however that the message I did think about comes at the wrong time for you, or for the wrong reasons. The message I was thinking about warns you when the view copy you are trying to check in is older than the original file. It does not help with your scenario though.

Another option would be to have a custom event action for when the document is approved. There you can check if the original file has been checked in more recently than the view file. If so, show an error to the user. Depending on where you keep your documents, the latter option might be easier to configure.

Good luck!