First of all, sorry if I seemed a bit childish. But recently I saw a similar topic like this post and it seemed like the only option I have left.
Both SPR I mentioned above relate to an inconsistency of notesdocument.CopyItems and notesdocument.CopyAllItems method when copying a rich text item that has more than one document links in it. I am submitting the PMR for the former while the latter has been there by the time I found out about the problem. See my previous post here (http://www-10.lotus.com/ldd/nd6forum.nsf/ShowMyTopicsAllFlatweb/4de2a87db4542181852574580026f79a?OpenDocument)
The rich text item(s) seemed to be copied correctly (attachments, text font and layout), but when trying to open the copied document link, only one would point to the correct document. The rest of the document link will open the wrong document. It doesn’t matter where the document link point to , only one of them would work correctly after copied.
What horrified me is that there is no workaround for this issue. (IBM support has confirm it and I can’t think of any non complicated ones). So far we have about 5 daily report application that summarized documents using those methods and I am rather hard pressed to find the alternative.
So my question is does anyone else out there experienced these problem since the IBM support personnel just called me saying that they cannot include the SPR on the next version since there is not enough customer reporting these issues (I believe he said there are only 3 at the moment).
I am not saying that the issue is severe (or not severe), I just find it hard to believe that hardly anyone use the two method. Oh and by the way, the support person said that even R8 experienced these too (but I can’t verify this since I don’t have R8 on my environment).
Regards
Tinus Riyanto
Subject: RE: SPR ASBE7FQ3ZP & KWEL4ZLN6R, need more customer reporting these issues
I agree it’s inconvenient and I would like to see it fixed.
Realistically, even if you get a lot of people to sign on to your cause, you’re not going to see a fix until there’s a release of code, and depending on the size (and degree of caution) of your organization, it could take a good while longer before the fixed code is available for you to use. So, meanwhile, can we talk about workarounds?
If you would describe your requirements, perhaps we could come up with a different way to do what you’re trying to do.
Subject: UPDATE re: SPR ASBE7FQ3ZP & KWEL4ZLN6R
I tried to reproduce your problem in 8.0.2 and could not. So it has perhaps already been fixed in that version. The language team say they didn’t look at this particular issue, but they did a lot of work around doclinks and may have fixed it as a side effect.
Meanwhile, if I can suggest a workaround, it’s possible to use a NotesRichTextNavigator to iterate thru the doclinks in the original and copied rich text, “side by side” so to speak, and copy the properties of each original doclink into the copied doclink. I didn’t try that because I don’t have a version of the code handy that has this problem, but it seems like it should work.
Subject: Thanks Andre … more info as you requested
I understand that it will take the next version of 7.x to solve these issues and I can live with that, even if 7.0.4 is scheduled for 2009. What made me mad is the answer that they will not solve this problem because …
I would elaborate on our daily report scenario. Basically each report came from the lowest section where each responsible section head would fill the report for their section. Since this is all done in the same time period in the morning, to avoid save conflict or document locking we decided to make each section report a separate document.
Then each section report would be summarized into one document (either by scheduled agent or action button). This is where the CopyAllItems method come to play. So one viable workaround would be to manually scan all the seciton report document and copy their items using other method (though I can’t figure out what method we can use for this other that CopyItem) or just copied it using copyAllItems and somehow “fixed” the doclink afterwards.
On a side note, I just skimmed through designer help for NotesRichTextNavigator. It might do the trick but I can’t say for sure until I tested it. I will post my result here so at least there would be a documented workaround if it is indeed viable.
Regards
Tinus Riyanto
ADDED on 08 July 2008
Finally managed to try Andre’s idea and found that it doesn’t work. Even after replacing all the summary doc link property (ServerHint, DBReplicaID, ViewUNID, DocUNID) some doclink still point to the wrong document. I really suspect the issue lies on $Link, but have no idea on how to override its content
Subject: A little revision
Got a bit more time to investigate. Apparently The two method would fail if it is used to combine two or more document together and those document have link in them. I suspect this is due to an incorrect append to the $Link value
In my case above, as long as only one section report have document links, the summary would be generated correctly (since there would only be one $Link to copy and create)
Regards
Tinus Riyanto