Problem Description

When a user edits a document, only one document at a time is changed. Multiple users my edit multiple documents at the same time, but for the system most of the documents stay the same, only a number of them is altered.

A document may use values from other documents. This is the case if for example the Tags Property is referencing tags. It uses the name of the tag documents to render as values for the Tags Property. When a service document lists the systems it requires, then the service document uses the names and maybe further properties of the system documents, to render the values of its properties.

When only one document is changed, the property values of all other documents are calculated and readily available.

When all projectdoc documents are erased, they can be rebuilt from scratch, since all information is actually derived from Confluence pages. Some information architectures that seemed sound when used in the one-document-at-a-time context will now show if they can cope with the from-scratch context.

One issue may be with circular references as property values. References should be pointing in one direction. The projectdoc Toolbox will report circular references accordingly. Sometimes those circular reference first show up in the from-scratch scenario. That is because a value may be available from a existing document, but not if the document needs to be calculated.

Another issue are dynamic properties. This may be more dramatic than circular references. Users may experience dynamic property issues even in the one-document-at-a-time context. The property values of such documents may often be considered as as not up-to-date. 

Definition

The value of a dynamic property is dependent on the request-time.

Typically property values must be rendered at the time a page is stored and must not change due to external events.  A property may reference another property. If a referenced property changes, the document with the reference is informed and the property value is updated accordingly. Changes only happen when a document is stored. A dynamic value does not reference another property value, but builds result sets at request-time based on queries or fetches information from other resources then projectdoc documents. The update mechanism is not applied to dynamic values, therefore dynamic values represent the value at the time they where stored. This is most likely an out-of-date value.

However there are use cases, where dynamic property values can be a valid solution. But special considerations need to be made: the property should probably not be indexed (noindex) and always be rendered at request-time (in other words: not be cached, no-render-cache). Or it may not even be considered to be a property at all (no-property, available since version 6.0).

Modes

The mode to handle dynamic properties is defined by the administrator via the configuration screen Dynamic Property Value Handling.

The following modes are available with the projectdoc Toolbox with version 6.0.

Health Service

Administrators may check the current status of the projectdoc documents by the use of the REST service projectdoc-internal/1/health/find-dynamic-values.

The service allows to check spaces with different modes.

For version 6.0 of the projectdoc Toolbox the default mode is allow for compatibility reasons. For new users a value of strict or lenient is recommended.

With the parameters additional-dynamic-macros and use-default-configuration, administrators may test configurations in addition and without the default configuration.

Default Dynamic Value Configuration

The Default Dynamic Value Configuration Service (projectdoc-internal/1/health/default-dynamic-value-configuration) allows to retrieve the configuration that controls the default processing of property values. It is deactivated by setting the parameter use-default-configuration of the Health Service to false. In the configuration to check the use of dynamic values at run-time the defaults are used per default (see Dynamic Property Value Handling).

There are no parameters to this service. It returns a list of the dynamic macro checks. Each check is reported in the following format:

{
  "macroName": "<name-of-the-macro>",
  "paramChecks": [
    {
      "problematicParamName": "<name-of-a-macro-parameter",
      "specificDynamicValueCheck": {
        "id": "<identifier-of-the-type-of-check"
      }
    }
  ]
}

The listed macroName identifies the macro that is check. If a macro is not part of the returned list, it is not considered to be checked and is considered safe to use as a property value by default.

Some macros may be dynamic no matter what parameters are used. But some macros may be safe to use a property values, if and only if specific parameters or even specific parameter values are not used. For instance the Name List Macro is safe to use as property value only if there is no search configured. In case the macro is safe but for a set of parameters, then the name is listed under problematicParamName (one entry in paramChecks per parameter name). How the parameter value is checked is determined by the specificDynamicValueCheck. Currently there are these type of checks provided (identified by the value of the id property):

Health Logger

Administrators may use the health logger de.smartics.projectdoc.healthCheck.dynamicValues for more logging output.

See Logging for more information on loggers.

Resources

More information on this topic is available by the following resources.