Areas with special purpose

Areas defined with special purpose is the principal model of the UI encapsulation

• What means "special-purpose" business area
• Definition of the special purpose
• User interface definition
  • Special-purpose areas

What means "special-purpose" business area

Business areas itself supports encapsulation of the objects but they do not define any special functionality. The functionality is defined by two completely distinctive ways:

• Descendant (object inheritance) e.g. Projects, Methodologies etc.
• Special-areas (interface definition) e.g. Location management area or HR management

Definition of the special purpose

The modules that defines special-purpose area should define module-settings for assignment the purpose to the client-defined area. The linkage between area and module-defined purpose is defined by the module itself and managed in the module administration.

List of areas with special interface is loaded to the application as a part of the module application initialisation data.
Areas of the special purpose are linked with processes and other objects. The special-purpuse process areas are described in the chapter here.

User interface definition

Modules creates special-area user interface by business area extension. The extension changes the area board and fulfil new menu items, functions and dashboard items.

An example presents how HR module defined HR extension for Human-resource department:

// ******************************  Extension – special-purpose Business Area  ******************************
// All personalist data are managed from the area defined in the settings – this extension add finance settings to the selected area 
"tskArea":{
   // Main page extension for hr module.
   "extParameters":{ "uright":"hr@HRPersonnel"  },
   "about":{"langModules":[ "hr/langs/@/hrCommon"]  },
   "views":{ 
      // Dashboard: add access to the personal items
      "dashboards":{ "default":{
      "menu":{ 
         "menuItems":{ 
            "Staffers":{ 
               "enabled":"=obj.tskAreaID == user.mParam('hr').hrArea ",
               "icon":"hrManagement", "a":"form.hrStaffer.list.hrPersonnel", "order":"CA" 
            },
            "mHRCompanyStructure":{  "uright":["hr@HRPersonnel" ], "icon":"company",
               "enabled":"=obj.tskAreaID == user.mParam('hr').hrArea ",
               "menuItems":{
                  "mHRStContract":{ "icon":"areaproject", "a":"form.hrStContract.list.default" }
            }  }
      }  }
   }  } 
   } // end of views
},  // end of frmAymine extension

Let's mention linkage between the UI definition and the module settings. The command user.mParam('hr').hrArea provides data from HR module initialisation. The complete condition: "enabled":"=obj.tskAreaID == user.mParam('hr').hrArea ", provides initial control and adds the UI definition on to the area defined in HR module administration.

Special-purpose areas

Example:

• Human resource data are available only in single special-purpose HR area.
• Helpdesk areas for internal or client helpdesk are also special-purpose

Special-purpose areas:

• Have self-defined list of functions
• They have typically self-defined dashboard
• They are not listed in the list of common areas on the main dashboard

/** Add sytem tag to the list of area info icons 
*  
* @param int $tskAreaID – if of the area to update
* @param string $tag – the tag identification
* @param bool $removeOthers = false – when true, icon is removed from all other areas
*   – set to true in case that area could be only one
*
* * systemTags is a list of marks that inform about special area settings, like that the area is set as a personal-management area
* * Adds icon only if not yet exists in the list
* * Max lenght of the field is 250 chars so that it should be enought
* * Icons are comma separated like any multi-enum field
* 
* Note: actually not used. Specific areas are market directly by modules in the clip extention
* 
* __Special behaviour of the tags:__
* * selfAcc_    -- tags starting with this prefix marks areas that has self-managed access. 
*                Actually makes sense for areas with access buttons on the top-menu line or from some other buttons.
*                Those areas are not listed in list of areas
*                _Warning:_ Done use selfAcc_ without some area-specific mark with module prefix (selfAcc_hrHR – for HR management)
*/
tskArea::addSystemTags(int $tskAreaID, string $tag, bool $removeOthers = false): void;


/** Remove the task from the list – opposite from addSystemTag
 * @param int|null $tskAreaID 
*  – when set, only defined area is updated
*  – when no set, field is removed from all client areas
* @param string $tag – the tag identification
* 
*/
tskArea::removeSystemTags(int|null $tskAreaID, string $tag): void;