• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (6)

1 Patrick van der Horst commented Permalink

Great post on extending the basic functionality. What is the impact on the performance of this change?

2 jos.olminkhof commented Permalink

Hi Patrick, <div>&nbsp;</div> Thanks for your feedback. To answer your question: <br /> It's not a severe impact. Compare it to an in-basket being filled with work items, which you can model with the Content Capacity Planner (SCouT) tool. <br /> A search for related cases is performed each time you select a work item in the in-basket, so it depends also on how the user uses the system. <div>&nbsp;</div> Hope this helps. <div>&nbsp;</div> Regards/groeten, <br /> Jos. <br />

3 Dave_Ward commented Permalink

Hi Jos. Really interesting post. I've done a little bit of playing with Split Cases / Related Cases and wanted to post my finding here... <br /> 1. Create Parent Case #1 <br /> 2. Create Child Case #1 (Split from Parent Case #1) <br /> 3. Create Child Case #2 (Split from Parent Case #1) <br /> 4. Create Sub-Child Case #1 (Split from Child Case #1) <div>&nbsp;</div> Hierarchically this would give the following case relationship <br /> - Parent #1 <br /> &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;- Child #1 <br /> &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;- Sub-Child #1 <br /> &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;- Child #2 <div>&nbsp;</div> Using the Related Case REST API, you see the following behaviour <br /> - Parent #1&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;--&gt; Sees direct children (Child #1 &amp; Child #2). Does not see grandchild (Sub-Child #1) <br /> &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;- Child #1&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;--&gt; Sees parent (Parent #1) and child (Sub-Child #1). Does not see sibling (Child #2) <br /> &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;- Sub-Child #1&#160;&#160;&#160;&#160;--&gt; Sees parent (Child #1). Does not see grandparent (Parent #1) <br /> &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;- Child #2&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;--&gt; Sees parent (Parent #1). Does not see sibling (Child #2) <div>&nbsp;</div> Is this the sort of behaviour you would expect to see (with only direct relationships being reported)? <br /> Do you know any way to report on extended relationships so you can see sibling cases <div>&nbsp;</div> Thanks, <div>&nbsp;</div> Dave <br />

4 jos.olminkhof commented Permalink

Hi Dave, <br /> Thanks for your analysis and comments. I asked one of the development manager ([Dev]) to respond: <br /> - Parent #1                          --&gt; Sees direct children (Child #1 &amp; Child #2). Does not see grandchild (Sub-Child #1) <br /> [Dev] This is what I'd expect since what he calls Parent #1 is actually just a peer case to child 1 and child 2. Sub-child 1 is just a peer case to child 1. <br />         - Child #1                    --&gt; Sees parent (Parent #1) and child (Sub-Child #1). Does not see sibling (Child #2) <br /> [Dev] Again, this is expected. Child 2 is actually a peer to Parent 1. It has no relationship to child 1. <br />                 - Sub-Child #1    --&gt; Sees parent (Child #1). Does not see grandparent (Parent #1) <br /> [Dev] Same logic as above. <br />         - Child #2                    --&gt; Sees parent (Parent #1). Does not see sibling (Child #2) <br /> [Dev] Same logic as above.

5 EdwardBrutus commented Permalink

NOTE: the IE8 xmlhttp object does not appear to support the "overrideMimeType" method in the following line (above):

 
<===
xmlhttp.overrideMimeType("application/json");
===>
 
The resulting runtime error on IE8 can be avoided as follows:
 
<===
if (dojo.isIE && (dojo.isIE > 8)) {
xmlhttp.overrideMimeType("application/json");
}
===>
 
I don't see any immediate problem resulting from this when I test on IE8, but there may be something I am missing.
 
In any case, I have seen two IE8 customers encounter this issue so far.
 

6 jos.olminkhof commented Permalink

Thanks Edward for figuring that out. The msdn.microsoft.com site indeed suggests that you can skip such line: <br /> "Configure your web server to send the right HTTP content type header with the right charset parameter, then you don't need any override on the client."

Add a Comment Add a Comment