Difference between revisions of "Features/Status level dependencies"

From TempusServa wiki
Jump to navigation Jump to search
Line 2: Line 2:


Example:
Example:
   Say you had a management system containing employees. These employees have the following information: They have a CV, current working details, and last workday. If a given employees can be in a few different statuses then each of the fields might not make sense. If an employee is in the process of being hired, then they would not have any current work details or a specific last work day. If the employee were in the process of being fired, then their CV would not matter. This example illustrates how you might want to hide away certain record fields depending on which status the record currently is in. Status level dependencies are used to solve this problem.
   Say we have a hr-management system containing some employees who are assigned to projects. These employees are either currently working on a project or between projects. Or they might be in the process of being hired and would therefore not be a full employee yet. Depending on which of these states the employee is currently in, different information about them would be made available. If they were under consideration of being hired, we should see their application. If they were working on a project, we should see their work schedule. If they were between projects, we should see the end date of their last project. Each piece of information should only be made visible for the status in question, since they make no sense or are unimportant otherwise. Status level dependencies are used to manage this visibility.


== Guide ==
== Guide ==

Revision as of 13:29, 28 August 2023

What it is

Example:

 Say we have a hr-management system containing some employees who are assigned to projects. These employees are either currently working on a project or between projects. Or they might be in the process of being hired and would therefore not be a full employee yet. Depending on which of these states the employee is currently in, different information about them would be made available. If they were under consideration of being hired, we should see their application. If they were working on a project, we should see their work schedule. If they were between projects, we should see the end date of their last project. Each piece of information should only be made visible for the status in question, since they make no sense or are unimportant otherwise. Status level dependencies are used to manage this visibility.

Guide

Picture 1

Status levels are numerical categories that one or more statuses can belong to. Individual Fields in an Entity can be configured to depend on these levels such that they can be made inactive and hidden if the Entity record is not in a status with the correct level. For example can the dependency be set for all status levels above a certain value such that one or more Fields are only active and displayed for those levels. To see the status levels of an Entity's statuses, go to that Entity in the back-end and look in the column shown in picture 1.

Picture 2

To change a status's level, go to that status and edit it as shown in picture 2.

Picture 3
Picture 4

To set the dependency, toggle the advanced view of the Entity panel on as shown in picture 3 and go to the bottom as shown in picture 4.