QPR Knowledge Base

Things to Note When Using Base Models

Hide Navigation Pane

Things to Note When Using Base Models

Previous topic Next topic No expanding text in this topic  

Things to Note When Using Base Models

Previous topic Next topic JavaScript is required for expanding text Mail us feedback on this topic!  

Comments (...)

Base model usage has been improved so that editing the base model or any child models does not lock the other models using the same base model, i.e. it is possible to edit the base and child models concurrently. However, there are some things you should note:

 

If a base model is edited while a child model is open, the child model is updated the next time it is opened from the Server.
In the case both the base model and any of the child models are edited simultaneously, conflicts can occur due to possible deleted elements. In these cases a warning message is displayed and the models should be closed and reopened to make them "valid" again.
In the case a base model is deleted or its base model status is removed while a child model is being created (but not saved yet), a dialog asking whether to merge the base model elements into the child model is displayed when the child model is saved. After this the child model can be used as a regular Server model.
The "Use from base model" settings in a child model are loaded from the base model in the following cases:
New model is created based on a base model
An existing model is changed to use a base model and the base model forces read-only usage for element types.
If the child model has model-specific web publishing settings enabled, those settings are always used in dynamic web publishing. However, in the case the child model is not using model-specific web publishing settings and the base model is using them, the base model settings are used also in the child model except for web publishing settings set for individual model elements. In the case the child model contains custom element types, generic QPR Web Application Server settings are used for them. The generic QPR WAS settings are used also in the case neither the base model nor the child model are using model-specific web publishing settings. In addition, child models always use their own settings in static web publishing, i.e. web page export.

 

There are also two special cases when data loss can occur:

 

An element type was deleted from the base model and an element of this type was created to a child model. When the child model is saved, the element type is changed to an existing element type in the base model. This element type is either the default activity or subprocess type for process steps or first information/non-information connector type for connectors. When the element type is changed, all values of custom attributes are lost.
An element type was deleted from the base model and an existing element's type was changed to this type. In this case the element's original type is kept. All custom attribute values for this element are lost.

 

As regards View Settings, note the following:

 

When a model is changed to use a base model (i.e. the model's type is changed to child model), the model's view setting is considered to be a duplicate of the base model's view setting if the view setting has the same name and if it shows the same hierarchy. When such a duplicate view setting is found, the child model's view setting is deleted.

Comments (...)