Object Template Line

Are you looking for object line?

Object template line defines the behaviour of particular object line. It consists of list of behaviour rules, such as definition of calculations, validations, default values, lookups or autonumbers etc.

One object line can have assigned zero-or-more object template lines:

  • Zero - there is no need to have defined any behaviour for object line - typically optional fields without any calculation and default values.
  • One - there is need to have defined behaviour
  • More than one - there is need to have defined more than one behaviour. Each object template line belongs to one template, therefore admin has to add more templates for particular object

Default value

According to a Template it is possible to set a default value for every Object Line so when the new request is created the ObjectLine with default value is already populated with wanted content.

Variables can be set as a default value with placeholders. Addressing of general variable via string {Variable,Code} (same as for format of notification or printout.

Access Definition

For selected object line user is able to define access across whole aplication.

Definition of access for object and subgrid line - visibility and editabilty - is set at Templates.

Access definition is currently available for the following areas and should displayed in desired hierarchy:

  • Template Access: hierarchy Object name / Object template name
  • Template Access Owner: hierarchy Object name / Object template name
  • Template access view: hierarchy Object name / Object template name
  • Update Action access: hierarchy Object name / Object template name
  • Workflow Step access: hierarchy Workflow name / Role name / Request status name

Validation

Each object line should have a certain validation set. Validation should be assigned regarding the type of an object line, like “Number”, “Text field”, “Checkbox” etc.

Currently these types of validation can be set:

Mandatory Field is mandatory unconditionally
Optional Field is optional
Mandatory (Conditional) Field wil be mandatory if it meets a condition that has been set. E.g. idxxx isnotchecked (field will be mandatory if a certain checkbox is not checked). For Sub-grid you can use idxxx isempty or idxxx isnotempty
Disabled / Mandatory (Conditional) This type of validation works other way round than is expected. Field is disabled when the condition is met and gets mandatory when it doesn't meet the condition. _E.g. idxxx != 0 (field is disabled when idxxx != 0 and gets mandatory when value "0" is populated). For Sub-grid you can use idxxx isempty or idxxx isnotempty
Disabled / Optional (Conditional) Same as in Disabled / Mandatory case but field gets optional.
Hidden / Mandatory (Conditional) Works in the same way as in Disabled / Mandatory case. Field is hidden when the condition is met and gets mandatory when it doesn't meet the condition.
Hidden / Optional (Conditional) Works in the same way as in Disabled / Mandatory case. Field is hidden when the condition is met and gets optional when it doesn't meet the condition.
Extended Validation Extended validation allows admin define detailed validation, containing rules in which **situation** the field should be hidden, disabled or mandatory.
Validation is applied in cascade mode. In case all validations are defined, Xeelo checks first hidden validation. If it's **not met** , Xeelo checks disabled validation. If hidden and disabled are **not met,** then Xeelo checks finally mandatory validation.
If hidden validation is **not** defined, disabled and mandatory are applied. If hidden and disabled are not defined, the mandatory validation applies.

Substring function can be used in validation formula. The syntax is exactly the same like for client-calculation: substring(idXXX,start,length)

Example: Request detail is open. Field where conditional validation (hidden/mandatory (c)) is set doesn’t meet the condition which means that the field is displayed in the detail of a request and is mandatory. When it meets the condition it gets hidden.

For each type of Object Line - Object type there are slightly different possibilities of usage of validation and calculations.

Which validation or calculation is viable for object type is displayed in the following matrix:

Condition

Conditions that can be defined on object lines differ by object line types. IMPORTANT is to know that syntax that is gonna be used must correlate with the type of object line defined in the condition. Condition syntax, similar to SQL language, is a bit different for currently these object lines:

  • Checkbox
  • Number
  • Textbox
  • Combo-box
  • Datepicker
  • Timepicker
  1. Checkbox - only two conditions acquire for this type of object line (‘Yes’,‘No’):
    idxxx ischecked and idxxx isnotchecked where idxxx is id of the checkbox

  2. Number - with this type of object line, a lot of conditions can be defined - Basic mathematical comparisons:
    idxxx = 1,idxxx != 1, idxxx > 1, idxxx < 1, idxxx => 1, idxxx =< 1 where idxxx is id of a number

Note: Conditions can be combined with logical operators or, and: (idxxx = 1 and idxxx => 5 ).

  1. Textbox (1line, multiline, memo) - conditions defined for this object line are used for data type - string:
    idxxx like ‘ABC’, idxxx not like ‘ABC’ where idxxx is id of a textbox(memo)

Note 1: Conditions can be also combined with logical operators or, and.
Note 2: Now, you can use star symbol as whatever. For example: id123 like ‘car*’. The condition will be true if the object line id123 contains word which starts with car string.

  1. Combo-box - conditions for combo-box object lines can be used as the ones for textboxes or also the ones that are used for numbers. It depends on the value(bind) of the combo-box. If the combo-box(reference) is set like this:
    Value(Bind) - Name
    1 - ABC
    2 - DEF
    3 - GHI
    then it is possible to use conditions:
    idxxx = 1, idxxx > 1 etc. or idxxx like ‘1’, idxxx not like ‘1’
    But if combo-box(reference) is set like this:
    A - ABC
    B - DEF
    C - GHI
    then it is necessary to use conditions just for textboxes lines:
    idxxx like ‘A’, idxxx not like ‘A’

  2. Datepicker - datepickers are textboxes with a special format of date (dd-mm-yyyy). So if it is necessary to have a condition set to this object line then syntax is following:
    idxxx like ‘11-07-2017’, idxxx not like ‘11-07-2017’

  3. Timepicker - timepickers are also textboxes with a special format of time (hh:mm:ss):
    idxxx like ‘12:15:00’

Note 1: For textboxes - conditions can have either simple quotation marks or double quotation marks. Both work
Note 2: Conditions can be combined on one line. More precisely condition for textbox and for number and for checkbox etc. can be defined for one line:
idxxx like ‘CZ’ and idyyy => 200000 and idzzz ischecked

Note 3: Beware of double negation with string conditions regarding the same field. See explanation below:

  1. When you have a conditional validation e.g. “Disabled/Mandatory(cond.)” and the validation is set with logical operator AND: idxxx not like 'A' AND idxxx not like 'B' then following rule is valid:

    38

    You could say that field will be disabled every time as long as value ‘A’ or ‘B’ is populated.

  2. When you have a conditional validation e.g. “Disabled/Mandatory(cond.)” and the validation is set with logical operator OR: idxxx not like 'A' OR idxxx not like 'B' then following rule is valid:

    48

    You could say that field will be disabled every time no matter what you populate