Home > Release Notes

4.5.0

Release Date: May 2, 2008

Bug Fixes / Minor enhancement

• [01632] On Manager, when searching a decimal "1,000.00": it does not find it if user enters in "Search" field the input "1000" (whatever the current locale).

• [01633] On Manager, when searching a decimal "1,000.00": if current locale is French, it does not find the number if user enters in "Search" field the input "1 000" (the default display for french).

• [01634] On Manager, when searching a decimal "1,000.00": if current locale is English, it does not find it if user enters in "Search" field the following inputs: "1,000" or "000.00". It finds it is user enters "000,00" (the underlying locale is wrongly module's default locale, not session's one).

• [01635] On Manager, when searching a date "1997-10-07": if current locale is English, it does not find it if user enters in "Search" field the input: "1997-10". It finds it is user enters "10/1997" (the underlying locale is wrongly module's default locale, not session's one).

• [01636] The default format used for english dates is yyyy-MM-dd.

• [01637] On Manager, when it is used in Component mode, the first page has not the Locale expected.

• [01639] When ValueContext is obtained from a Procedure context, the following methods throw ShouldNotBeCalledException : ValueContext.formatOccurrence and ValueContext.displayOccurrence . At least these method's javadoc should specify this limitation.

• [01640] The method ValueContext.formatOccurrence has not the Locale as argument. This is correct when context is session-dependent (for example, in a UIBean ). But in other contexts (for example, in validation report) the locale used is module's default locale. This is a bit complicated for the developer, it would be more simple to format with XML Schema policy in the later case. Morevover, the method's javadoc should specify the behaviour.

• [01699] The creation of records through Data Services should return the Xpath predicate matching the primary key.

• [01705] Lock are not handled properly within UIServices . 

Additional relational database support

Support for Microsoft SQL Server 2005 (and further) as the database backend has been added.

Hierarchies (beta version)

Data can now be seen as a hierarchy. Hierarchies exploit directly existing relationships that are specified by underlying XML Schema document. They can be used either directly (prebuilt dimensions) or configured as views. A hierarchy is also able to mix recursive relationships and non-recursive relationships.

User interface rendering of each node in the hierarchy is based either on a small expression syntax (with XPath substitition) or on a Java implementation of a rendering interface. Default rendering for hierarchies can be specified at schema-level or it is specified by user at configuration level in EBX.Manager.

For more information, see:

• Manager documentation (use and configuration)

• Schema documentation (element defaultLabel )

• UILabelRendererForHierarchy javadoc.

Activation of hierarchies: In order to use this component, it must be enabled by means of the option "Enable hierarchy perspective" in Manager adaptation .

Known limitations:

• The following "relationships" are not yet exploited for configuring a hierarchy:

  • standard and extended enumerations,

  • osd:select elements,

  • inter-instance foreign keys ( osd:tableRef with container element defined).

• If a node is the result of a multi-occurrenced foreign key ( osd:tableRef inside an element with maxOccurs > 1 ), Move and Create actions are not allowed.

• If join tables have been used to build a hierarchy Level:

  • If a Move or Create action has been done, the tree does not expand properly to the concerned node.

  • If a Create is asked on a non-terminal recursive level, only a node creation of the same level is proposed.

• Search & view filters do not apply on hierarchies.

• Default perspectives should not be activated on complex datamodels.

Performance enhancements

It is henceforth possible to declare programmatic constraints' dependencies, so as to optimize incremental validation time.

The specification of local or explicit dependencies is useful when a large volume of data must be validated and/or the validation algorithm is particularly expensive. In other cases, the default unknown dependencies mode remains sufficient.

For more information, see ConstraintContext interface.

Data Services

Evolutions:

• [01699] The insert operation has been enhanced. Now it returns the XPath predicate of the primary keys of the inserted elements. It is useful when the primary key is an auto-increment.

• The select operation is now subjected to permissions. A user can only read records he has access to within the manager.

Permissions management

Disabled reason on actions permissions

A message has been added to explain why actions are disabled on homes, instances or tables. It generally gives clues to identify where updates, on permissions table, has to be performed in order to enabled the target action. This message appears when the mouse is over the target link or button.

Action permission resolution on tables

Resolution procedure for action permission on tables has been reviewed.

A table resolved action permission is then computed as follows:

• action permission defined on a table is its specific action permission if defined, or the default action permission defined for any instance's table;

• action permission resolved for the target table is:

  • the minimum of actions permissions defined for this table on all restricted profiles of the target user;

  • or the maximum of actions permissions defined for this table on all profiles of the target user, if no restriction is defined.

For more information, see also Resolution of permissions .

Home > Release Notes