JR45934: SUPERFLUOUS BINDINGS ON THE VERTICAL SECTION CAUSES DUPLICATED TABLES WHEN DROPPING A VARIABLE OF TYPE LIST INTO SECTION

Version 8.0.1 Fix Pack 2 for the IBM Business Process Manager products
Version 8.5.0 Fix Pack 1 for the IBM Business Process Manager products

APAR status

• Closed as fixed if next.

Error description

• When dropping a variable of type List into a Vertical Section, a
  table is created, and unnecessary binding is setting on the
  Vertical Section. But because the table itself handles the
  repeating nature of the data, so the vertical section should
  not have any binding set on it.
  

Local fix

• Clear the binding on the vertical section that is holding the
  table.
  

Problem summary

• When a user drops a list-typed variable into an unbound section
  in the coach view canvas, and a table is created, the editor
  also binds the section to the list variable item.  The end
  result is that at runtime, multiple tables exist with the same
  content (table number equals the number of rows in each table).
  
  USER AFFECTED:
  Business Process Manager Advanced, Standard and Express Coach
  authors dropping a list-typed variable into an unbound section
  in the coach view canvas, which in turn creates a table.
  
  PROBLEM DETAILED DESCRIPTION:
  This issue is certainly caused by superfluous bindings on the
  vertical sections, and it is a small issue with the editor.
   When dropping a variable of type list into the section, a table
  is created.  The table itself handles the repeating nature of
  the data, so the vertical section should not have any binding
  set on it.  There are other cases where it is desirable to set
  the binding on the vertical section.  For example, if you create
  a section, then drop BO01List.currentItem into it, then ideally
  the vertical section gets set to the repeating data, BO01List[],
  and the proper controls are created and bound for the data
  within currentItem, such as a text box for
  BO01List.currentItem.String1.  This behaviour is indeed working
  properly.  The issue is that this logic is bleeding to cases
  where it is not needed.
  
  PROBLEM CONCLUSION:
  The fix is to detect when a table will be created, and avoid
  setting the binding on the section containing the new table.
  
  FIX AVAILABILITY:
  Fix for V8 is planned for next cumulative maintenance
  deliverable and release.
  

Problem conclusion

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels

• R801 PSN

     UP