This repository contains the OS2mo manager script for updating managers in MO.
Managers are updated based on data imported from SD-Løn prior to running this integration, i.e. the code does not make any calls to SD while running, but instead only updates managers based on the data already found in MO.
The code has the following responsibilities:
- Create any missing manager level classes in MO based on configurations provided by environment variables.
- Terminate managers with no active engagement in the org unit where they are set as manager.
- Assign new managers to org units based on info in special child org units with name ending in "_leder".
This section describes how the code logic operates when the application is triggered.
- All current manager roles are checked to verify the employee has an active engagement in the organisation unit they are placed. If not: manager role get terminated (manager roles end date set to today).
- For every organisation unit (org-unit) with
name
ending in_leder
and name NOT prepended withØ_
:- Get all employees with association to
_leder
unit. - Check each employee has an active engagement in parent org-unit. If more than
one employee with association in
_leder
org-unit, check which employee has the latestengagement from
date. The one with latest engagement date becomes manager in parent org-unit. - The manger roles
manager_level
is based on the org-unit level in which the manager role is assigned: - If the parent org-unit has
_led-adm
in its name, the manager will also become manager of this org-units parent org-unit (Notice: Manager level is based on org-unit level from the highest ranking org-unit). In the above illustration, manager fetched from_leder
unit becomes manager in not only "Byudvikling" but also "Borgmesterens Afdeling" as "Byudvikling is marked as anled-adm
unit. Manager level is then based on org-unit level from "Borgmesterens Afdeling". - Once a manager has been selected based on above criteria, associations for all
other employees in
_leder
unit are terminated. Leaving just one association in_leder
unit.
- Get all employees with association to
The follow environment variables can be used to configure the application:
TODO: some of the settings can possibly be retrieved from MO automatically instead of being set via the environment...
MO_URL
: Base URL for MOCLIENT_ID
: Keycloak client IDCLIENT_SECRET
: Keycloak client secret corresponding to the Keycloak clientROOT_UUID
: UUID of the root organisation unit. Instance dependant.MANAGER_TYPE_UUID
: Default UUID forManager type
. Instance dependant.RESPONSIBILITY_UUID
: Default UUID forManager type
. Instance dependant.MANAGER_LEVEL_MAPPING
: Dict withorg-unit level UUID
classes as keys andmanager level UUID
as values. Used to map fromorg_unit_level
tomanager_level
.
To start the container using docker-compose
:
$ docker-compose up -d
After the container is up and running, the script can be run manually by
triggering a FastAPI
endpoint:
- By using the GUI at:
http://localhost:8000/docs
and triggering/trigger/all
. - Calling the endpoint from terminal:
$ curl -X 'POST' 'http://localhost:8000/trigger/all'
As it checks and updates managers you will get a lot of output in docker logs
,
especially if you have opted for debug
information from logs.
Once the script has finished the last lines will look like this:
sd_managerscript_1 | 2022-12-09 10:38.30 [info ] Filter Managers
sd_managerscript_1 | 2022-12-09 10:38.30 [info ] Updating Managers
sd_managerscript_1 | 2022-12-09 10:38.30 [info ] Updating managers complete!
- Clone the repository:
git clone git@git.magenta.dk:rammearkitektur/os2mo-manager-sync.git
- Install all dependencies:
poetry install
- Set up pre-commit:
poetry run pre-commit install
You use poetry
and pytest
to run the tests:
poetry run pytest
You can also run specific files
poetry run pytest tests/<test_folder>/<test_file.py>
and even use filtering with -k
poetry run pytest -k "Manager"
You can use the flags -vx
where v
prints the test & x
makes the test stop if any tests fails (Verbose, X-fail)
Test data have been prepared for local development. Using the test data requires a running OS2mo instance locally as well as the standard test data from Kolding, which is included in OS2mo repository.
Before using this integration locally you need to clone and run the OS2MO
container from OS2MO repo:
Once cloned you can start main OS2MO
container using:
docker-compose up --build -d
You can now inject test data from this repository by changing folder to where this repository is located locally. Then run the following command:
poetry run python tests/test_data/inject_test_data.py "603f1c82-d012-4d04-9382-dbe659c533fb"
UUID passed as an parameter is required password
Sending and fetching data to/from OS2MO
is done using a GraphQL
client imported from Ra-clients
repos here
- Leder units have to be NY-levels - currently failing for Afdelings-niveauer
- If there is no active engagement in OU and employee currently is manager the manager will be terminated per todays date (and not when the engagement ended)
Magenta ApS https://magenta.dk
This project uses: MPL-2.0
This project uses REUSE for licensing. All licenses can be found in the LICENSES folder of the project.