2.7 KiB
Work Time Tracker
add idp-mapping to existing orgs
Context
The Org schema contains an optional field named idp-mapping:
(s/defschema OrgIdPMapping
(st/open-schema
{:idp (describe s/Str "Internal idp-id")
:organization-id (describe s/Str "the organization id provided by the IdP")
:enabled? (describe s/Bool "Do we allow the connection through this IdP?")}))
(s/defschema NewOrg
"Org before being saved to DB"
(st/merge
{:id s/Str}
(st/optional-keys
{,,,
:idp-mapping OrgIdPMapping
,,
})))To support CSA Migration it should be replaced by:
(s/defschema OrgIdPMapping
{:idp (describe s/Str "Internal idp-id")
:organization-id (describe s/Str "the organization id provided by the IdP")
:enabled? (describe s/Bool "Do we allow the connection through this IdP?")})
(s/defschema NewOrg
"Org before being saved to DB"
(st/merge
{:id s/Str
:idp-mapping OrgIdPMapping}
(st/optional-keys
{:old-idp-mapping OrgIdPMapping
,,,
})))This issue is about a second step toward this goal (cf. https://github.com/threatgrid/iroh/issues/4204).
So at the end of this issue the schemas should be:
(s/defschema OrgIdPMapping
{:idp (describe s/Str "Internal idp-id")
(s/optional-key :organization-id) (describe s/Str "the organization id provided by the IdP")
:enabled? (describe s/Bool "Do we allow the connection through this IdP?")})
(s/defschema NewOrg
"Org before being saved to DB"
(st/merge
{:id s/Str
:idp-mapping OrgIdPMapping}
(st/optional-keys
{,,,})))Migration task
The migration service should be used to create a new migration task. The main algorithm should be something like:
For every existing org O that do not have any idp-mapping;
Retrieve all the idp-mappings of every users of this org.
Keep the fields idp-id and organization-id of those mapping.
Use the most present couple idp-id, organization-id as new IdPMapping
from the org.
In the current state, you should always consider enabled? of the
IdPMapping is true and ignore this field.
Also note migration tasks often fail during TEST environment due to QA testing that could create entities with the wrong schema. Most of the time, we should only logs such errors and not make the migration fail.
Most of the time we use a heuristic, if we detect too much errors we make the migration fail. Recently we also introduced migration that could write to another table to minimize the risk of data loss. I'm not sure this will be much needed here.