Client-defined object attributes

Clients can extends default object definition setting their own object attributes

Object attributes are object-independent, i.e. they can be defied for almost any object. However, developer of each object should enable the client-defined attributes:

How to allow client-defined attributes

Object that supports client-defined proprietary attributes should have defined attribute:

Object definition (JSONC):_

• "userAttributes":{ "type":"userAttributes" },

Database definition (SQL):

• userAttributes json null comment 'optional user attributes in the json format',

View definition – list (JSON):

• Attributue "userAttributes":{} shall be a single view attribue. Client-defined attributes are all automatically added to the list of attributes

View Definition – detail (JSON):

• Client-defined attributes are together in a single box. The box is placed in a common way:
• Setup box:
  • "userAttrs":{ "type":"userAttributes", "enabled":"obj.userAttributes" },
• Place the box to the right place at an object detail tab. Remember, that box is always created even when client doesn't have any attributes defined – it creates a gap for box on the tab
• User attributes might have their own tab (general tab with single box)

Reporting user attributes (PHP – PDF generator):

• User attributes should be located at the report defined by programmers
• All user attributes are placed to the report using single command:
  • $pat->fillSingle('userAttributes', sysObjCustomAttrDef::htmlObjClientAttributes($rep));

How the attributes are managed internally

As is obvious from the definition, all attributes are stored in a single database json-type attribute. SQL databae support searching in the field and even when not, there is simple json string that is searchable for string values. However, database support is more precise because it allows searching in a single specific field.

Searching from the application list defined by user is correctly transformed to the SQL search upon the json field.

Define where the field is used

Each client-defined field has defined conditions when it is available. The field conditions are controlled both for list and detail.

Example: Let's defined a field that is used only in a single area:

How application manages the client-defined attributes

List of attributes defined for each object are passed to the application with the object description. Application downloads data after the login.

• Server builds up the list of attributes in the method sysClient::getClientObjects (it calls method sysObjCustomAttrDef::getObjAttrDefList)
• Application has stored data about user attributes in the object description, field userAttrs (object with information about all attributes of the object)
• Method fObjectManager.prepareView_manageUserAttr complete list of general object attributes with additional client-defined list. However, method does not have knowledge about the object fields, so that it doesn't evaluate rights. Rights are inserted to the field and evaluated with all other fields.