Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | Last revision Both sides next revision | ||
devel:documentation:identities:dev:contractual-relationship [2019/01/02 11:40] tomiskar [Prime contract position] |
devel:documentation:identities:dev:contractual-relationship [2019/02/05 09:47] tomiskar |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ===== Contractual relationship (CR) ===== | ||
+ | {{tag> | ||
+ | |||
+ | They define the link between the identity and the tree structure. In the application, | ||
+ | |||
+ | The CR plays a significant, | ||
+ | |||
+ | Another intended functional feature is that when the CR ceases to exist / is invalidated, | ||
+ | |||
+ | Through CR, users are searched in the elements agenda of the tree structure / organizational structure, who are " | ||
+ | |||
+ | ==== Prime contract position ==== | ||
+ | |||
+ | CR can be flagged as " | ||
+ | - main | ||
+ | - valid (valid by from-till and not disabled) | ||
+ | - with working position with default tree type | ||
+ | - with working position with any tree type | ||
+ | - with undefined valid from | ||
+ | - other with lowest valid from | ||
+ | ==== Search managers by CR ==== | ||
+ | |||
+ | Managers could be found: | ||
+ | * through tree structers - identity with CR on tree node above. | ||
+ | * through the direct relation on CR - guarantees. | ||
+ | |||
+ | Searching managers and subordines could by overriden in custom module by implementing '' | ||
+ | |||
+ | ==== CR state, validity ==== | ||
+ | |||
+ | When CR validity ends, then all roles assigned to given CR is removed. Its not possible to assign roles to invalid contracts. | ||
+ | Invalid contract is defined by: | ||
+ | * '' | ||
+ | * and '' | ||
+ | * '' | ||
+ | * '' | ||
+ | * otherwise is contract validity controlled only by '' | ||
+ | === HR processes === | ||
+ | |||
+ | [[..: | ||
+ | |||
+ | * When contract is invalid, then all assigned roles for this contract are removed (automatic and manually assigned roles too) by configured [[..: | ||
+ | * When the last contract is removed or all contracts are invalid or excluded, then identity is disabled by configured [[..: | ||
+ | |||
+ | This automatic processes can be configured two ways, by: | ||
+ | * [[..: | ||
+ | * [[..: | ||
+ | |||
+ | Choosing the way is configurable - processor can be [[..: | ||
+ | |||
+ | ===== Other contract positions ===== | ||
+ | |||
+ | Other positions can be configured for the contract. Other contract positions are used just for assigning of automatic roles by the tree structure. Filtering and evaluating managers and subordinates are not supported by other contract positions. | ||
+ | |||
+ | ===== Tree structures indexing ===== | ||
+ | |||
+ | To make queries in an efficient manner, a separate library on the tree structure has been created [[https:// | ||
+ | * the possibility to ask about the children of any element of the tree with one query (all the children in the downward direction) | ||
+ | * the possibility to ask about all the parents of any element of the tree with one question | ||
+ | |||
+ | The documentation and an an example of getting involved in the project can be found [[https:// | ||
+ | |||
+ | Searching through index is linked to: | ||
+ | * Searching identities according to the organizational structure (through CR) | ||
+ | * Display of the identity position in the organizational structure | ||
+ | |||
+ | To rebuild the index, the task '' | ||
+ | |||
+ | ===== Automatically assigned roles ===== | ||
+ | {{tag> | ||
+ | |||
+ | Roles assigned based on their placement in the organizational structure. | ||
+ | Every identity in CzechIdM has an imlicit relation (~CR), which is tied to a component of the organizational structure. | ||
+ | ==== Linking a role to the organizational structure ==== | ||
+ | |||
+ | Everyone with permission to edit a role assign this role to a component of any organizational structure. The assigning/ | ||
+ | |||
+ | === Displaying information about automatically assigned roles === | ||
+ | |||
+ | Displaying of information about the roles linked to the organizational structure will occur at least at the following places: | ||
+ | |||
+ | * In the structure component detail, there will be a list of role which have been assigned to it | ||
+ | * With each role, a list of structure components (the whole path in the tree), for which this role is used for automatic assignment to the user, will be displayed. | ||
+ | * With each user, there will be the information in the list of assigned roles that he has been given the role automatically. | ||
+ | |||
+ | === Heredity of assigned roles === | ||
+ | |||
+ | If the role is assigned to an organizational structure component, the following behaviour may occur: | ||
+ | |||
+ | < | ||
+ | A | ||
+ | | | ||
+ | B | ||
+ | / \ | ||
+ | C D | ||
+ | / \ | ||
+ | E F | ||
+ | </ | ||
+ | |||
+ | * The role is assigned to a user who is linked precisely to this specific organizational structure component | ||
+ | * If the role is linked to " | ||
+ | * The role is assigned to all users who are linked to this organizational structure component and to the whole subtree (from the root to the leaves) | ||
+ | * Heredity exists in the whole subtree without depth restrictions | ||
+ | * If the role is linked to " | ||
+ | * The role is assigned to all users who are linked to this structural organization component and to all the managers (i.e. from the node to the root). | ||
+ | * This behaviour enables assigning according to the scenario "the manager has everything which the subordinate does". Therefore, by linking the role to " | ||
+ | * There is at least one customer where this is used | ||
+ | * We are not going to implement this now, but it is mentioned here because of potential consideration of possibilities on if and how we could solve this | ||
+ | |||
+ | === Audit === | ||
+ | |||
+ | All changes in assigning roles to the organizational structure will be audited. The minimum indicated in the audit log will be: | ||
+ | |||
+ | * Information that a change in roles has been made based on an application of an automatic rule and which one | ||
+ | * References to the process from which the change has emerged in order to identify that it has occurred within synchronization or saving from the web... | ||
+ | ==== Change of user's roles ==== | ||
+ | |||
+ | An update (adding and removing) of automatically assigned roles within an identity occurs at least in the following cases: | ||
+ | |||
+ | * When a change in the organizational placement is saved. | ||
+ | * A relation (or relations) of an identity is linked to the organizational structure. If a role (or roles) is assigned to a component in the organizational structure, the user should receive these roles automatically. | ||
+ | * When a change is saved in the " | ||
+ | * If the role is linked to an organizational structure component, it is necessary to recalculate the roles on identities which are linked by a relation to the given organization structure component | ||
+ | * Automatic assigning of roles to the user does not require an approval and is realized immediately. | ||
+ | ==== Implementation details ==== | ||
+ | * Configuration and assigning of automatic roles is implemented according to the description above | ||
+ | * Approving of the configuration of automatic roles (adding, removing) is configurable, | ||
+ | * Editing of an automatic role is not implemented => the algorithm "drop and create" | ||
+ | * Approving of the assigning of a role to an identity according to the configuration of the automatic role is not implemented - it depends on the currently developed functionality of role queries - will be implemented eventually. | ||
+ | * audit track will be implemented in the future | ||
+ | * If an automatic role is deleted, all assigned roles following this role are deleted. | ||
+ | * If a new automatic role is added, it is assigned to all the current identities with an existing CR, which should get the role. The realization is carried out via a Long running task. | ||
+ | * For roles becoming effective at a future time, the account management will be performed when the validity is met. | ||
+ | * Working with CR validity: | ||
+ | * When changing the contract validity, the changes are projected in the validity of automatically assigned roles | ||
+ | * Automatic roles with future validity are ready for contracts | ||
+ | * Automatic roles are not assigned to invalid contracts (in the past or disabled). When changing the validity to the past, the roles are removed directly by event processor. Removing of expired roles and roles with expired contracts is carried out by the Long running tasks ('' | ||
+ | * Recalculating of automatic roles when changing the tree structures (moving the components) have not been addressed yet (coming soon). |