feat: add util for preferredname checks - #1415
Conversation
|
@William-Edwards-STFC I am a bit non inclined with this. The Datasource layer needs to be as much as less opinionated towards the business layer. It should always bring out the truth in the raw form from the database, without altering the data. It is the business layer that should decide. If you require a need for a preferred name to always have a non nullable value, then we need to discuss and fix it from ground zero(ie., change the column type from nullable to non-nullable and proceed with other layers) |
…rumentScientist
eb1cda4 to
3e59b40
Compare
|
@William-Edwards-STFC Hi William. Would you like us to review this? If so, kindly attach the label "review:please" |
|
Hi I need to go back to this and fix the linter which I will do later today |
|
Hi @William-Edwards-STFC , since we have a massive PR queue I'm inspecting if there are PR's that are ready to be merged. I just looked at the PR and it looks solid. |
…ct/user-office-core into 1499-name-change
…ct/user-office-core into 1499-name-change
…ct/user-office-core into 1499-name-change
…nd fall back to first name if not
Description
Previously, preferredname was nullable throughout the codebase, requiring a preferredname ? preferredname : firstname check everywhere a user's name was displayed. This change moves the fallback logic to the datasource layer so that preferredname is always populated, removing the need for these checks across the frontend and backend.
Motivation and Context
The repeated fallback checks were scattered across utility functions, components, and backend code we may as well just do it once. firstname is kept separate on the model so it remains available for use in official documents.
How Has This Been Tested
Fixes
UserOfficeProject/issue-tracker#1499
Changes
Added utility to check for preferred name and imported that to do the checks
Tests included/Docs Updated?
Issue number is 1499 got a bit mixed up whilst doing commits