Organization Model

The organization model answers where responsibility lives.

Layers

Tenant: the administrative space.
Organization unit type: an abstract type such as faculty, institute, committee, department, team, service desk, or legal entity.
Organization structure: a named way to look at the institution. Several structures may exist in parallel, for example employer hierarchy, academic structure, committees, memberships, or classifications.
Relation type: the permitted edge between units inside a structure.
Organization unit: a concrete department, office, committee, service desk, school, institute, or other unit.
Function: a named responsibility in an organization unit, such as clerk, reviewer, approver, committee secretary, intake desk, or resource manager.

Boundary With Identity And IDM

This module does not own login accounts, identity lifecycle, account linking, or identity-to-function assignments. govoplan-identity owns the identity/account directory. govoplan-idm records that an identity currently holds an organizational function and may constrain that link to one account.

Resolving accounts to identities, choosing candidate identities for an organization assignment, and importing those mappings from external directories belongs to govoplan-idm, not to organizations.

Boundary With Access

An IDM function assignment does not grant rights on its own. govoplan-access maps organization and IDM facts to roles, rights, permission decisions, delegation enforcement, and explain responses.

This separation keeps the institution model stable even when authorization policy changes.

Access Projection Migration

govoplan-access now prefers organizations.directory for organization units and function definitions when the Organizations module is installed. It uses govoplan-idm for identity-to-function assignment facts and Access-owned external function-role mappings to turn accepted function facts into rights.

The legacy Access tables access_organization_units, access_functions, and access_function_assignments remain readable as compatibility/projection tables during rollout. They are no longer the target model for new module integrations.

Rollout plan:

keep direct Access function/organization reads as a fallback when Organizations or IDM are not installed;
backfill Organizations units/functions from the Access projection for existing installations that enable the Organizations module later;
move new identity-to-function assignment workflows to IDM rather than adding assignment ownership to Organizations;
use Access external function-role mappings for authorization and check that the referenced Organizations function is still active before granting derived permissions;
retire Access-owned organization/function tables only after a release-level migration/backfill and rollback plan exists.

The close-out condition is that Access role resolution works with canonical Organizations plus IDM installed and still works through projection fallback for transition deployments.

UI Boundary

The organization workspace at /organizations is the primary module UI for modelling the meta-model, concrete units, structures, and function definitions. Admin-only organization controls are still owned by this module, but are contributed to the platform admin shell through the admin.sections WebUI capability.

The admin contribution must not duplicate the organization editor. It is for governance and policy settings: whether tenant admins may customize the meta-model, whether model changes require recorded change requests, and how audit detail and retention behave for organization changes.

Boundary With IDM

govoplan-idm may import organization-unit and organization-function definitions from external directories. It should write those definitions through organization capabilities or APIs after preview, approval, and rollback planning. IDM owns identity-to-function assignments and bridge views that combine identity and organization facts, such as identity candidates for function assignments.

4.0 KiB Raw Blame History