Skip to content

feat: add util for preferredname checks#1415

Open
William-Edwards-STFC wants to merge 12 commits into
developfrom
1499-name-change
Open

feat: add util for preferredname checks#1415
William-Edwards-STFC wants to merge 12 commits into
developfrom
1499-name-change

Conversation

@William-Edwards-STFC
Copy link
Copy Markdown
Contributor

@William-Edwards-STFC William-Edwards-STFC commented Mar 16, 2026

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

  • Existing Cypress E2E tests in userAdministration.cy.ts cover the two key scenarios:
  • A user with preferredname set — verifies the preferred name is shown in proposals
  • A user with no preferredname — verifies the first name is shown as fallback
  • New unit tests added to StfcUserDataSource.spec.ts covering the STFC-specific fallback from firstNameKnownAs to givenName, including the empty string case

Fixes

UserOfficeProject/issue-tracker#1499

Changes

Added utility to check for preferred name and imported that to do the checks

Tests included/Docs Updated?

  • I have added tests to cover my changes.
  • All relevant doc has been updated

Issue number is 1499 got a bit mixed up whilst doing commits

@William-Edwards-STFC William-Edwards-STFC requested a review from a team as a code owner March 16, 2026 15:21
@William-Edwards-STFC William-Edwards-STFC requested review from TCMeldrum and removed request for a team March 16, 2026 15:21
@yoganandaness
Copy link
Copy Markdown
Contributor

yoganandaness commented Mar 18, 2026

@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)

Copy link
Copy Markdown
Contributor

@TCMeldrum TCMeldrum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgmt

@William-Edwards-STFC William-Edwards-STFC changed the title feat: resolve preferredname at datasource layer to eliminate firstname fallback checks feat: add util for preferredname checks May 11, 2026
@yoganandaness
Copy link
Copy Markdown
Contributor

@William-Edwards-STFC Hi William. Would you like us to review this? If so, kindly attach the label "review:please"

@William-Edwards-STFC
Copy link
Copy Markdown
Contributor Author

Hi I need to go back to this and fix the linter which I will do later today

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants