Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Section
titleDefault 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 

In-Document Link
anchorHealth Service
to false. In the configuration to check the use of dynamic values at run-time the defaults are used per default (see
Static Document Link
documentDynamic 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:

Code Block
{
  "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.

Note Box

The default configuration is only checking on projectdoc macros. If you are using macros of third-party apps as property values, you need to add those to your configuration when running the

In-Document Link
anchorHealth Service
.

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 

Static Document Link
documentName 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):

NameDescription
IsDynamicNoMatterWhat

If the parameter is specified with any non-empty value, then the macro is considered to be dynamic and must not be used as a property value.

This check is also used for macros that are not considered dynamic per se, but should nevertheless not be used as a property value.

This is used for macros that should never be used as property values.

AllowModeOnly

If the mode is allow, then no property is actually considered to be a dynamic value.

This is for backward compatibility. These macros should usually not be allowed, but may be allowed for the allow mode.

ModeSpecificControls

If there are proper controls on the value, then the value is not considered dynamic, even if it basically is.

So an author may check if the use of the macro is actually an issue in this context and if not use the proper control to allow its use. Which control is allowed to make a macro pass as property value is defined by the mode selected by the administration.

Why can the use of the macro be no problem in some cases? If the search is using values from a delegate space and these values are never changing, then the use may be okay. This includes that if the value actually does change or the projectdoc caches are cleared, then proper measurements need to be taken to update the caches (for instance run a refresh on the delegate space first).


...