Provisioning is overly-complicated and ends up relying on numeric ids for confirming whether GitHub has provisioned teams and repos. Instead of this implicit approach, add some kind of provisioned identifier to Team and Repository. Note, a boolean probably isn't sufficient because a team can be provisioned but not attached to its repo, and we'd probably like to distinguish this kind of case. Similarly, a repo could be provisioned but read-only.
86 is a prerequisite for this so we can focus on those points where these teamNumbers actually matter first.
Current provisioning-related fields:
Team {
URL: string | null; // null when not yet created
githubId: number | null; // null when not yet created
custom: {
githubAttached?: boolean,
}
}
Repository {
delvId: string, // says used for provisioning
custom: {
githubCreated?: boolean,
githubReleased?: boolean
}
}
Provisioning is overly-complicated and ends up relying on numeric ids for confirming whether GitHub has provisioned teams and repos. Instead of this implicit approach, add some kind of provisioned identifier to
Team
andRepository
. Note, a boolean probably isn't sufficient because a team can be provisioned but not attached to its repo, and we'd probably like to distinguish this kind of case. Similarly, a repo could be provisioned but read-only.86 is a prerequisite for this so we can focus on those points where these teamNumbers actually matter first.
Current provisioning-related fields: