equinor / equinor/fusion-framework
services module: review required attributes used to identify ApiPerson v2/v4
- Dominant language
- TypeScript
- Stars
- 10
- Forks
- 10
- Avg merge
- 19h 40m
- Merged PRs (30d)
- 150
Description
## Context
In `packages/modules/services/src/people/is-api-person.ts`, the required-attribute lists used to identify a person object per API version carry open questions:
```ts
const requiredApiPersonAttributes = {
[ApiVersion.v2]: [
'azureUniqueId',
/** TODO - has to be more required attributes to identify V2??? */
] satisfies Array>,
[ApiVersion.v4]: [
/** TODO - has to be more required attributes to identify V4??? */
'azureUniqueId',
] satisfies Array>,
};
```
Currently only `azureUniqueId` is checked for both v2 and v4, which may not be sufficient to reliably distinguish a valid `ApiPerson` from other objects that happen to have that field.
## Task
- Review the v2 and v4 People API contracts and decide whether additional required attributes should be checked to reliably identify a person object.
- Update `requiredApiPersonAttributes` accordingly, or confirm `azureUniqueId` alone is sufficient and remove the TODOs.
## File
`packages/modules/services/src/people/is-api-person.ts` (lines ~9, ~12)
Contributor guide
Research direction
Start in packages/modules/services/src/people/is-api-person.ts and compare its v2 and v4 attribute lists with the People API contracts. Decide whether azureUniqueId uniquely identifies each version, then update the lists or remove the TODOs; done when identification behavior matches the contracts.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- api, backend-api-design
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100