Object view definition

Object views supported by the application framework

• Type of views
• View right control
  • uRight
  • view selection
  • single-object control
• Detail view
  • How to manage what fields are visible
• Application allows using object-defined colours for better user navigation.
  • How to set colours
• Make clip in the list
• Images in detail and clip

Type of views

Application designer defines several types of views

• List – list of several objects of the same type
• Detail – single object detail
• Calendar – definition of the calendar data that describes what data to show (not not the calendar design)
• ClipList – list of clips
• Clip – short view of a single object

View right control

There are three save modes to control the view visibility. Both are managed by server and client application cannot affect if used got data or not.

uRight

The common and most general way how to manages the view visibility is to join that with single or more system rights (aka uright). The view is available only if user has the system right assigned.
Since the uright is controlled before data loading, user cannot get data for the view even in case that fake client application would request the data.

view selection

The view under the selection could filter records that are accessible for user or not. This approach is necessary for list views where selection filters records to the list but is also usefull as the low-level access control for detail views.

Control based on the view is less flexible then control by object application method but probably more efficient because it does not require two objects loads from database.

single-object control

The application server could check if detail is visible or readonly for user or not using the default object right control or specific object-defined method

Default operation

Default control <object>.checkRightsInt is called to check user rights in to check the right to read object or update object.

Check rights to see the object

When object has defined global operation read with attribute "checkReadRights":true, the checkRightsInt method should confirm that user has right to read the object (operC::read).

"operations":{
   "read":{
      "checkReadRights":true
   }
}

Remember: The read-right is used only for object detail, not for list of objects, list of clips or single clip.

If user has right to list object or clip the list should select object using the list-controls.

Check rights to edit the object

When object has defined global operation update with atribute "checkUpdateRights":true, the right is controlled when application requests the lock to edit the object. Lock is not provided if checkRightsInt does not confirm operC::update right.

"operations":{
   "update":{
      "checkUpdateRights":true
   }
}

Using object-defined control

Object operation read is not required but when it is defined it could call the postOp.

Notes:

Using the read.preOp or read.postOp only for right checking is not recommended because it confuse the code. Use the default operation, of possible.

The preOp operation is intended to load or data that cannot be loaded by common methods (e.g. for calling a microservices or other application over the middleware).

The postOp is processed after the common data preparation and can modify or even delete some fields if they are no available to the user (e.g. contract price).

Function can use the data already loaded for view detail so that it might be the most efficient point where to check view rights, if they somehow depends on the object data only.

Detail view

Detail view definition is described in detail here.

How to manage what fields are visible

Pupose:
The purpose of field hiding is to show only relevant fields that user can use.

Warning:

Field visibility is controlled by client. It cannot be used to hide the data that user is not allowed to see.

Use data selection at the server view to limit what user can see or not

Type of the visibility controls

Each tab, box and field (view element) could have fields:

• readonly – view element is visible but it is read only. The read only mode is applied to all slave views regardless they have sign the their read only right management is independent on the master object.
• editable – negation of the read only. If both readonly and editable is used, system raises warning message and uses on the readonly.
• right – element is always visible for new object, but right is checked when object is already saved
• enabled – right is always controlled, even for new object. When both right and readonly is used, both should return true or other positive value (anything except false ) to make the field visible.

Warnings:
Be careful about the null / undefined value. E.g. the condition the might check if user is manager or responsible:

"enabled":"=[obj.isManager, obj.isResponsible].includes(user.ID)"

won't work correctly if both isManager and isResponsible is not always defined and one of the values is null. Use

"enabled":"=[obj.isManager??0, obj.isResponsible??0].includes(user.ID)"

and the control will be correct.

Application allows using object-defined colours for better user navigation.

Each page can change its background colour as well as the colour of the page tab in the tab line. The colour usage depends on the module settings.

The expected usage is to improve user orientation in the application when object could have colour defined by some major group which they relate to. Modules could uses their own colour for module pages, but keep in mind, that for fix colour are uses module-specific or even window-specific css/scss styles.

How to set colours

The colours are set by the object attribute bgColor. The attribute could be loaded from backend / database or calculated by the object method.

• Pages with object details as well as dashboard pages by default uses bgColor loaded from the dashboard object
  • Detail and list page change only the page tab colour (it cannot be chnaged by the object definition) and do not affects the page view; the window-specific style definition can change it.
  • Dashboard set the dashboard background colour to the defined colour but with the 50% opacity.
• Pages with objects lists uses bgColor from the object of the parent – typically areaItems list uses the colour from the area object.
• Clip lists and clips currently internally don't work with the background colour, but it can be utilised by the style definition.

Make clip in the list

For clip in the list, the should contain

• Special column of the type clip with fields:
  • view: name of the clip view that is used (could be calculated for each line)
  • selectAlt: what select is used when cliplist is visible
  • autoHide: list of columns that are never used together with the clip
• Special sections in the serverData Section:
  • selectClip – select command used when cliplist is used

Remember:

• List columns that contains sql command could not be used with the clip column – they shall be hidden (write them to the autoHide list)

Example:

"clipView":{ 
   "type":"clip",    // type that marks attribuet as column with clip
   "view":"=`${obj.systemObject}.clip.--listClipView`",  // name of the clip used in the detail (calculated)
   "selectAlt":"selectClip",   // name of the SQL select command (shall be written in the serverDate)
   "treeIndent":true,  // mark that column also contain tree icons for tree-structure of items
   // Colums that are hidden
   "autoHide":["name", "shortDesc", "systemObject", "firstName", "personRole", "areaName", "mark" ], 
},

Images in detail and clip

Detail view and clip view supports image instead of icon. In order to show image, the view definition should contain window definition section:

"window":{ 
   "image":"=`${obj.systemObject},${obj.crmSubjectID},photo`",
   "imageStyle": { "class":"leftFoto--personPhoto"} ...css style for picture
},