+6
Hi,
Br
Linda
+30
It's not a bug. It's a ... design quirk that has been there for 20+ years (I don't even remember why it was done), probably to work around the scenario where we check in a document that has a file type we also have set up for use as view copy. There is only one file, but with two pointers. Also, in this scenario, we cannot have one version of the PDF (in this case) as the original and one as the view copy, since they point to the same file.
+6
But why do we get both pointers when we check in with Document Revision client and only one pointer when we check in with Create Documents? This is depending on the client doing the check in?
If this is old stuff -- Why cannot this be handled so that the result is: 1. always one pointer or 2. always two pointers?
It is confusing that it sometimes are two pointers and sometimes is one pointer to the same file. 😊
Br
Linda
+30
Looks like a bug in Create Documents.
+5
It works fine with only one original file in file reference, so why do we need 2?
We do not experience any difference if the pdf has 2 or 1 pointer in File Ref. So could we get rid of one of them?
If we have only one original file in File.Ref and then create a new revision, we get 2 lines in File Ref. as expected.
But do we really need 2?
+30
It works fine with only one original file in file reference, so why do we need 2?
I may look like it works fine, but we would need to test a large number of combinations of settings and operations to know for sure.
We do not experience any difference if the pdf has 2 or 1 pointer in File Ref. So could we get rid of one of them?
See above.
I would like to get rid of this quirk too, but it was added by someone deliberately many years ago and probably quite a bit of code relies on this being like it always have been. Changing this is not something we do at the snap of the fingers. It’s risky business.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
