Changes to the class Settings 2.5
The new Settings class should be used for managing and retrieving information about the settings (e.g. Default language, Default resolution, Status Configuration Xml, Translation Management Configuration Xml,...)
Validation of configuration xmls
One of the major changes of the new Settings class is that the configuration xmls in the database should always be valid. In order to ensure this, the incoming xmls are validated, but we also update the xmls whenever a referenced value is updated/deleted. In the past the configuration xmls were checked and corrected upon retrieval
- What happens during an update of a configuration xml?
-
The validation of all configuration xmls starts with a schema validation. When the incoming xml is valid according to the schema, some extra checks are executed to validate the values which are used.
The following table gives an overview of those extra checks.Configuration Xml Extra checks Status Configuration XML
- Check that all statuses exist
- Check that all user roles exist
Translation Configuration XML
- Check that all languages exist
- Check that all resolutions exist
- Check that all user groups exist
- Check that the conditions are valid
Plugin Configuration XML
- Check that the conditions are valid
Inbox Configuration XML
- Check that all statuses exist
- Check that all user roles exist
- What happens when creating, updating or deleting a referenced value?
-
In order to keep the configuration xmls valid, some extra actions are required when a referenced value is updated or deleted.
For most values, these extra actions are limited to updating the label inside the configuration xml and blocking the delete of the value if the value is used in one of the configuration xmls.
However, for some of the values an extra element is added during creation and removed during deletion. For example:- When creating a new user role, an initial status placeholder is created. Of course, this initial status is removed again when that user role is deleted.
- Something similar happens during the creation of a new status. Each status has a status definition inside the
Status Configuration Xmlwhich is automatically created and removed.
Changes in methods
- Two methods with a metadata parameter
-
In the past the
Settingsmethods were:- not accessible over web services
- distributed over different classes
- specific methods for each field
The methods are now grouped in the newSettings 2.5web services and replaced by 2 methods which are every similar to the metadata calls in the other classes:GetMetadatawhich can be used to retrieve all fields of the configuration objectSetMetadata3which can be used to update all fields of the configuration object
Which information can be retrieved or updated?Field Description FMASTERLNG The default language for the repository FISHSYSTEMRESOLUTION The default resolution for the repository FISHENABLEOUTOFDATE This field indicates whether the out of date mechanism is enabled or not FSTATECONFIGURATION The status (or workflow) configuration xml FISHWRITEOBJPLUGINCFG The plugin configuration xml FISHCHANGETRACKERCONFIG The change tracker configuration xml FTRANSLATIONCONFIGURATION The translation configuration xml FINBOXCONFIGURATION The inbox configuration xml ...
Removing Xml Tags
Settings 2.5 web services, we have removed the Xml Tags configuration xml which was only used by non-DITA customers for the configuration of:
- Namespaces
The namespaces were not only configured on the Xml Tags but also on the
Plugin Configuration Xml.Starting with
Settings 2.5the namespaces are only configured in thePlugin Configuration Xmland all code is redirected to find the namespaces there.
- Xpaths for reusable objects
- Reusable objects are no longer supported
- Xpaths for the
ExpandMasteroptionThe
ExpandMasteroption was available in someWeb Services 1.0calls.However, all methods from
Web Services 1.0must be replaced byWeb Services 2.0orWeb Services 2.5calls (see Changes Web Services 1.0 versus 2.0)