Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Published by Scroll Versions from space TDDM and version 1

Introduction

Relationships are defined means of determining a user's relationship to other users in the system. In a nutshell, it resolves common types of relations between users, such as managers and appraisers. In the current implementation, relationships are defined on the system level, and are not modifiable.

How

...

relationships work

A relationship can process any developer defined input. Different kinds of input can be specified, such as user IDs, job assignment IDs, course IDs et ceteraetc.

The output for a resolved relationship will always be is an array of unique user IDs however. The user IDs are determined by relationship resolver, which are classes that define what can be inputted, and then process that input to determine the users that relate to the inputdata transfer objects (DTOs). Each DTO is intended to contain the user_id of a resolved user, the source of the user (default is an internal user record), and any extra metadata information associated with the resolved user. A DTO gives plugins implementing relationship functionality more flexibility - in the case of performance activities within Totara Perform it means we can return users outside of the system who do not have a user record.

Each relationship can potentially have many resolver as required, although their inputs must be compatible. For example, there could exist a relationship 'supervisor' which contains both 'manager' and 'appraiser' resolvers, which would both accept user ID and/or job assignment ID as inputs. It could not additionally contain a 'seminar' resolver, because that would require a seminar ID (unless the seminar resolver accepted either user ID and/or job assignment ID as input).

Each relationship is an individual record in the totara_core_relationship table. Relationship resolvers are extensible classes that can be defined on a per-plugin basis. Each relationship record can have many relationship resolvers associated with it. The link between resolvers and relationships are stored in the totara_core_relationship_resolver table.

Usage

Relationships extend entity models, and are loaded from the database like any other entity. A relationship can be created by passing in an array of at least one resolver. The compatibility of resolvers is checked before creation.

...

Code Block
languagephp
$relationship_collection = new \totara_core\relationship\helpers\relationship_collection_manager([
    $manager_relationship_id,
    $appraiser_relationship_id,
    $temporary_manager_relationship_id,
]); // Pass in array of relationship instances or their IDs

$user_one_reports_to = $relationship_collection->get_users(['job_assignment_id' => 1]);
$user_two_reports_to = $relationship_collection->get_users(['user_id' => 2]);
$user_three_reports_to = $relationship_collection->get_users(['job_assignment_id' => 3]);

...

If you want to get a list of relationships to use or display, you can use the relationship_provider class.

Code Block
languagephp
// Get all relationships.
$relationship_provider = new relationship_provider();
$relationship_provider->get();

// Get all relationships that are compatible with the mod_perform plugin and support a user_id input.
$relationship_provider = new relationship_provider();
$relationship_provider
    ->filter_by_component('mod_perform', true)
    ->get_compatible_relationships(['user_id']);

Existing relationships

For the moment, relationships are defined on a system level. There are currently 3 several usable relationship resolvers , which were created for usage within performance activities, but can easily be used elsewhere anywhere across the system.

  • Subject Accepts only user_id as input, and just returns the input without processing (\totara_core\relationship\resolvers\subject - Accepts only ) 
  • Manager: Accepts user_id and/or job_assignment_id as input, and just returns the input without processing.Manager - returns the manager(s) for the user/job assignment (\totara_job\relationship\resolvers\manager - )
  • Manager's manager: Accepts user_id and/or job_assignment_id as input, returns the manager of the user's manager(s) for the user/job assignment Appraiser - (\totara_job\relationship\resolvers\appraiser - Accepts managers_manager)
  • Appraiser: Accepts user_id and/or job_assignment_id as input, returns the appraiser(s) for the user/job assignment (\totara_job\relationship\resolvers\appraiser)

Each of these resolvers have a corresponding relationship , so there exists 3 relationships currentlyrecord too.

Potential

...

future functionality

The current implementation was made with the intention of allowing user defined relationships (created by admins via UI). This could allow admins to customise what users are displayed/used in certain areas, and could allow functionality such as allowing admins to create custom team member dashboards for certain users/user groups.