gsteimer
commented
10 years ago @benallenallen @dgrumieaux - our hunch was correct. This is because of the addRendition call when the eSignature PDF is added. The DFC code was setting the keep parameter to true, when it should be false. I'll update the 2.1 tag and OC trunk.
If you checkin a x.0 to create y.1, the PDF rendition looks to be carried over to the new y.1 version. After DTS processes y.1, the object incorrectly has two PDF renditions.
This one is perhaps easier to show in pictures. In the scenario below, I have a CURRENT, LATEST, Effective 2.0 document.
The renditions of the 2.0 document look a little odd to me - there are two renditions, and they're both correct, but the set_file looks weird:
Looking at a different Draft document with PDF set from DTS, you can easily see from the set file that the rendition was created from DTS:
Getting back to my original doc... I checkout 2,0, modify the Word content and check it back in. After the checkin, but before DTS has a chance to render the doc, the renditions look like this:
2.0, CURRENT, Effective
2.1, LATEST, Draft
After DTS has a chance to render the document, the renditions look like this:
2.0, CURRENT, Effective
2.1, LATEST, Draft
As you can see - it looks like the odd rendition is carried over to the 2.1 when the checkin happens. At this point, I"m not sure if the issue is something in DTS, or our TBO code that runs when the 2.1 is created.