Home > Release Notes

4.2.3 fix 002

Release Date : July 11, 2007

Bug Fixes

• [01495] Calling a Service by means of UIHttpManagerComponent API returns an illegal state exception.

4.2.3 fix 001

Release Date : July 10, 2007

Bug Fixes

• [01493] Service permissions can not be configured as UI does not display service names clearly.
• [01494] Table reference items (mdm:tableRef) should be displayed sorted by formatted label.

4.2.3

Release Date : July 6, 2007

Bug Fixes

• [01484] In compare UI: there is no conflict detection for content types permissions and header informations.
• [01486] Unability to define a uiBean for a multi occurrenced complex. The declared complex is used for all records as a whole but causes a ClassCastException. UIBean may apply for each single occurrence of the complex that could be hence repeated.
• [01487] Complex unbounded node can not be validated through webMethods Master Data Manager.
• [01482] In the compare UI, if node's path are too long, Microsoft Internet Explorer does not conform to the limit of the page for the differences table. Thus, user needs to scroll to see the button « mark as decided ».
• [01466] Only the owner (or administrator) of an adaptation should have access to the Activate/Inactivate button.
• [01491] When a table occurrence is created in the context of a user session, another user session that is already on a descendant of this table is not systematically notified of the new occurrence (the user must reselect the table for viewing the update).

Services on table occurrences : better accessibility and multiple selections

Services that are defined on occurrences are accessible directly on the table view. However, the user can still execute them from the occurrence view.

Services can also be declared as executable on any number of occurrences. The attribute activatedForPaths has evolved consequently with a new syntax (previous one is still supported for ascendant compatibility). The new syntax is the following:

If the path to the table is /root/myTable:

• /root/myTable activates the service on the table globally.
• /root/myTable{1} activates the service if one occurrence is selected.
• /root/myTable{2} activates the service if two occurrence are selected.
• /root/myTable{n} activates the service if exactly n occurrences are selected (n is a positive integer).
• /root/myTable{+} activates the service if one, two, ..., n occurrences are selected (unbounded selection).

For more details, see Schema Definition.

For accessing to the multiple selection, the service container API has now a new method :

ServiceContext.getSelectedOccurrences()

Permissions on services defined by users

Up to this version, permissions to execute services could be configured only through programmtic schema extensions. Permissions to execute a service are now also defined in the standard instance permissions ("Permissions" tab on an adaptation instance).

New API for accessing to permissions

A new class is added to the API, SessionPermissions. It is a facade for checking the various permissions to access to Master Data entities (branches, instances, table occurrences, individual nodes) and to perform actions on them.

Those permissions are resolved in the context of a current user session and they can be accessed through the following new method:

Session.getPermissions().

Comparisons

Up to this version, when a user compared two occurrences, he got all the details on terminal complex nodes, even values that were not different. The interface displays now only the values actually different

The API has a new method for comparing with full details under terminal nodes:

DifferenceHelper.compareOccurrences(..., showDetails)

Merge process locks branches

Merge process first locks the branches involved, so as to ensure merge consistency. This means that until the merge is finalized, nobody can update neither the source branch that is merged nor the target branch.

If a user begins a merge without finalizing it, it is still possible to unlock the branches manually. Only the user that initiated the merge, the owners of the branch or of an ancestor branch, or the administrator have the permission to unlock.

Merge process disables triggers

Merge process now systematically disables all the triggers, when the merge is finalized.

Archives management

Import process first locks the current branch, so as to ensure merge consistency.

The Manager "Archive" actions have been augmented with the following options:

• export without change set
• export Reference (always without change set)
• import without change set

Note: an import without change set involves a replace strategy. For example the content of a table is first deleted before the archive table content is added.

Trigger as guard

Triggers can be used for preventing the execution of the associated action (for example the modification of a table occurrence). This type of usage has been made more explicit by the declaration of throws OperationException in trigger methods handleBefore....

New behaviour for UI Components (mdm:uiBean)

From this version, when a complex node with maxOccurs > 1 has a mdm:uiBean declaration, the associated editor component will be instanciated for the corresponding List and also for each occurrence in the list.

In order to distinguish the whole List from one of its item, the developer can check current context path. For example:

public void addForEdit(UIResponseContext aContext);
{
  Step step = aContext.getPathInAdaptation().getLastStep();
  if (step.isIndexed())
  {
    int i = step.getIndex();
    // Editor applies to occurrence at index i
    .../...
  }
  else
  {
    // Editor applies to the list
    // Use the default behaviour for default list management
    aContext.addUIBestMatchingEditor(Path.SELF, "");
  }
}