Extending Field/Header Groups Defined in Base

Learn to extend header groups configured in base.

Header groups are used to organize different types of headers - predefined, standard headers (e.g. Search, Expand, Tree) and custom special headers. When a header is referenced, a header group is configured in which it should be searched for. First, a suitable group is found in the hierarchy of the designer configurations and verticals. Then, a header with the matching name / type is searched for in that group.

In Aurea.CRM a new feature was implemented that allows an on-demand extension of header groups in child configurations.

This has been possible before in the same vertical, it is now even possible to switch from Base to a different vertical. Below is the detailed explanation of this logic:

• If a header group A is defined in the Base vertical of some configuration X, it is not possible to extend it in a specific vertical. One can make a copy of it in a specific vertical, however this copy is fully independent from the Base's A and won't inherit the headers. There are technical reasons for it in the way update.CRM web handles configurations and verticals - once a header group is found in a particular vertical, Base is no longer looked at, so one can not extend it horizontally.
• In a sub-configuration Y of X, in the Base vertical, one can add/override headers to the header group A, thereby logically extending it. These headers are still a part of the original header group A but is only visible in the configuration Y.
• Additionally, one can add/override headers to the header group A in the sub-configuration Y in another (e.g. BB) vertical. As soon as he does that, an extension of the group A is created in the BB vertical. An extension is a header group with a special flag (called extendsparent in the DB table) that can be used to define vertical-specific headers while still inheriting those from the X's Base. As a result, in the vertical BB of Y, headers defined both in X's Base and Y's Base is available in addition to those created specifically for Y's BB. This is also reflected in the copy operation - if one decides to copy the header group into Y's BB, all the inherited headers is merged and cloned so that the copy can be worked with independently. Such a copy no longer inherits anything.
• An important property of the extension is that it extends the parent configuration (although it is used for extending a header group in Base), so if we were to create a copy of A in the X's BB, this takes precedence and the extension created in Y's BB only inherits headers from that one. In general, an extension always refers to a header group found in the nearest parent configuration, where first the current and then the Base vertical is searched through. Similarly, to the on-demand extension done when the first header is created that requires the extension, the extension is deleted automatically as soon as all the headers it contained (except for those that are inherited, of course) are deleted. Thus, the extension only lives until it becomes superfluous.