User-defined fields

• Support by object
  • Database
  • json
  • List views
  • Detail
  • Other views – calendar, clips
• Technical implementation
  • Field definition
  • Fields management by server
  • Field management by client
  • Field operation in list

User defined fields have information stored in the object / table sysObjCustomAttrDef.

Each client has its own definition and there is not implemented way how to transfer fields between clients. However, export/import of data from this table is sufficient, it has no dependencies to anything else

Support by object

Object that supports user-defined fields, should has is set in the jsonc file and created column for them

Database

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

A field of the json type should be defined:

Currently no other name is supported (for speed and simplicity). In theory it is possible, but currently not implemented.

json

about→groups

"groups":[ "sysUAttrs", "sysUAttrLink" ]

• sysUAttrs – mark that objects supports user-defined fields
• sysUAttrLink – mark that object can be referenced by user-defined fields. The referenced object may but don’t have to support user-defined fields itself. The options are independent

Attributes

"userAttributes":{ "type":"userAttributes" }

There should a single attribute of the json type that is used to store user-defined fields. Currently only the name “userAttributes” is supported and that name cannot be used for anything else.

However, when needed it can support field of any name, but client application should be adapted for that

List views

"userAttributes":{}

List view should read userAttributes field to allow showing user fields

Field is automatically made invisible and values are loaded from that.

Server list load does not directly supports reading this attribute. Always is transported complete content and the client loads custom fields from json itself

Detail

"userAttrs":{ "type":"userAttributes"}

Detail should have block for user attributes. It can be only single block for all of them. By default the block is called userAttrs but the name is arbitrary; block should have type defined. Block should be placed to the tab in regular way. When block is placed, all user attributes are placed to it.

Other views – calendar, clips

There is currently no support for user-defined fields in theses views

Technical implementation

Field definition

Field definition is 100% common AyMINE object without any special modifications

Fields management by server

Definition of objects supporting the user-defined fields is processed during the object load – it stores group settings and information that object supports user fields – so that new object should be loaded.

Obviously, New user field definition does not require that module reload. However field definition is loaded by client during login / restart so that field changes are propagated after the restart.

Field management by client

Client application loads definition of the clients user field with application data (part of the object definition). They are placed to the viewAttrs by the fObjectManager (see function prepareView_manageUserAttr). It is placed every time when view is opened; they are never part of the object attributes.

Name of the fields is uA_fieldID – so they are currently not usable in any ts checks. If necessary they should get internal name field that could be used instead of ID.

Field operation in list

• Hide/Show – manage totally by client and does not influence that all data are loaded
• Right management – managed from the definition in the same way as ordinary fields
• Filter – supported client that creates special filter for column – text format is used, date or datetime fields are not yet supported,
• Sorting – supported using the json_value function – sorting is without index
• Link – supported both by client and server, client creates request to get uA_IDDesc field with linked object descriprion (field of the group: 'fieldUALink') and server creates requested field