Documentation Center

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 XmlExtra 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

Report Configuration XML

  • Check that all resolutions exist
  • Check that all statuses 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 Xml which is automatically created and removed.

Changes in methods

Two methods with a metadata parameter
In the past the Settings methods were:
  • not accessible over web services
  • distributed over different classes
  • specific methods for each field
The methods are now grouped in the new Settings 2.5 web services and replaced by 2 methods which are every similar to the metadata calls in the other classes:
  • GetMetadata which can be used to retrieve all fields of the configuration object
  • SetMetadata3 which can be used to update all fields of the configuration object
Which information can be retrieved or updated?
FieldDescription
FMASTERLNGThe default language for the repository
FISHSYSTEMRESOLUTIONThe default resolution for the repository
FISHENABLEOUTOFDATEThis field indicates whether the out of date mechanism is enabled or not
FSTATECONFIGURATIONThe status (or workflow) configuration xml
FISHWRITEOBJPLUGINCFGThe plugin configuration xml
FISHCHANGETRACKERCONFIGThe change tracker configuration xml
FTRANSLATIONCONFIGURATIONThe translation configuration xml
FISHINBOXCONFIGURATIONThe inbox configuration xml
FISHREPORTCONFIGURATIONThe translation and workflow report configuration xml
...
Extending RetrieveFieldSetupByIshType for metadata bound fields
RetrieveFieldSetupByIshType returns per object type field information from the database (ismultivalue, ismandatory,...) combined with some extra business logic (allowonupdate, allowonsearch,...). Initially the RetrieveFieldSetupByIshType method returns types which are directly linked with the type in the database:
  • string which is limited to 1000 characters
  • longtext which can contain a big amount of text
  • datetime
  • number
  • ishreference indicating the field is referencing one or more other InfoShare objects. The referenced object can be another InfoShare object (e.g. a user) or a list of values (e.g. DRESOLUTION). The information is indicated in an extra ishreference element. For instance FAUTHOR is referencing objects of type ISHUser while FRESOLUTION contains values from the list of values DRESOLUTION.

Starting from Tridion Docs 14SP4 the type ishmetadatabinding is introduced which indicates that a field that is configured in the database as a string is actually linked via the metadatabinding element in the extension configuration with a taxonomy system (e.g. PoolParty) which is used to get the label and description of the identifier which is stored in the database. The sourceref attribute on the extra ishmetadatabinding element contains the handler (e.g. PoolPartyConnector) which is used to connect to the taxonomy system. Together with the new ishmetadatabinding type we also introduce a new allowonsmarttagging attribute indicating that smart tagging is supported or not by the handler.

Removing Xml Tags

With the introduction of the 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.5 the namespaces are only configured in the Plugin Configuration Xml and all code is redirected to find the namespaces there.

  • Xpaths for reusable objects
    • Reusable objects are no longer supported
  • Xpaths for the ExpandMaster option
    • The ExpandMaster option was available in some Web Services 1.0 calls.

      However, all methods from Web Services 1.0 must be replaced by Web Services 2.0 or Web Services 2.5 calls (see )