feat(tom-server/user-info-api): adds workplaceFqdn property

[pm-McFly]

Adds support for the workplaceFqdn field in the user-info API service, allowing retrieval of workplace FQDN information from the LDAP directory.

Changes

• Fixed bug in packages/tom-server/src/user-info-api/services/index.ts:242

  • Now properly includes workplaceFqdn in user information when available from UserDB/LDAP
  • Field is added from the directory source (second precedence after Matrix profile)

• Added tests in packages/tom-server/src/user-info-api/tests/service.test.ts

  • Updated MOCK_DATA.LDAP to include workplaceFqdn: 'workplace.example.com'
  • Extended useProfileTwake type to include workplaceFqdn: boolean
  • Updated mockUserDB function to handle the new field
  • Added 2 new test cases:
    • "Should add workplaceFqdn from UserDB when available" - verifies field is included when present
    • "Should not add workplaceFqdn when not available in UserDB" - verifies field is omitted when absent

Local Deployment Test Data

• Updated LDAP fixtures in .compose/ldap/ldif/base_ldap_users.ldif
  • Added workplaceFqdn attribute to 7 test users:
    • dwho → tardis.example.com
    • rtyler → badwolf.example.com
    • okenobi → jedi-temple.example.com
    • lskywalker → rebel-alliance.example.com
    • myoda → jedi-council.example.com
    • annasmith → acme-corp.example.com
    • johnjohnson → techcorp.example.com

Summary by CodeRabbit

Release Notes

• New Features
  • User profiles now support workplace fully qualified domain names (FQDN). Organizations can associate workplace domain identifiers with user accounts, enabling improved workspace integration, enhanced identity management, and better organizational identification capabilities across the system.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[nx-cloud]

View your CI Pipeline Execution ↗ for commit c84584b

Command	Status	Duration	Result
lerna run test	✅ Succeeded	1s	View ↗
lerna run build	✅ Succeeded	1s	View ↗

---

☁️ Nx Cloud last updated this comment at 2025-12-08 15:53:34 UTC

[coderabbitai]

Walkthrough

This change extends the LDAP schema and user information system to support a new workplaceFqdn field. Custom schema definitions add a workplaceUser object class with a workplaceFqdn attribute type, users are populated with these new attributes, and the API layer is modified to retrieve and expose the field.

Changes

Cohort / File(s)	Summary
LDAP schema extensions .compose/ldap/ldif/config-20230322180123.ldif, .compose/ldap/ldif/custom-schema.ldif	Added custom LDAP schema definitions under cn=custom,cn=schema,cn=config, introducing workplaceFqdn attribute type (OID 1.3.6.1.4.1.99999.1.1.1) and workplaceUser object class (OID 1.3.6.1.4.1.99999.2.1.1) with associated metadata.
LDAP user data .compose/ldap/ldif/base_ldap_users.ldif	Extended user entries with new objectClass: workplaceUser and workplaceFqdn attributes for multiple users without modifying existing DN structure or password data.
User information API type packages/tom-server/src/user-info-api/types.ts	Added optional workplaceFqdn?: string property to the UserInformation interface.
Service implementation packages/tom-server/src/user-info-api/services/index.ts	Extended directory query to fetch workplaceFqdn field and propagated it to the user info result object when present.
Test updates packages/tom-server/src/user-info-api/tests/service.test.ts	Updated LDAP mock data, test fixtures, and mock builders to include workplaceFqdn support; added test assertions to verify field presence and absence based on data availability.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• LDAP schema files contain straightforward schema extension with standard metadata
• Service change is a simple field addition to an existing query
• Type definition change is minimal and isolated
• Test updates are repetitive mock data alignments with consistent patterns

Poem

🐰 A workplace domain we now proclaim,
With FQDN to stake the claim,
Through schema and services, the field does flow,
From LDAP depths to API's glow,
One little attribute makes users complete! 🏢✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title directly and clearly describes the main change: adding a workplaceFqdn property to the user-info API service, which is the primary objective across all modified files.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch tom-server/identity-server/user-info-api/include-workplaceFqdn

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codescene-delta-analysis]

Gates Failed
Prevent hotspot decline (2 hotspots with Complex Method)
Enforce advisory code health rules (2 files with Complex Method)

Gates Passed
4 Quality Gates Passed

See analysis details in CodeScene

Reason for failure

Prevent hotspot decline	Violations	Code Health Impact
service.test.ts	1 rule in this hotspot	8.21 → 8.01	Suppress
index.ts	1 rule in this hotspot	7.73 → 7.71	Suppress

Enforce advisory code health rules	Violations	Code Health Impact
service.test.ts	1 advisory rule	8.21 → 8.01	Suppress
index.ts	1 advisory rule	7.73 → 7.71	Suppress

Quality Gate Profile: Pay Down Tech Debt
Want more control? Customize Code Health rules or catch issues early with our IDE extension and CLI tool.

[coderabbitai]

Actionable comments posted: 0

♻️ Duplicate comments (1)

packages/tom-server/src/user-info-api/tests/service.test.ts (1)

73-88: workplaceFqdn wiring through useProfileTwake and mockUserDB is correct but increases helper complexity

The new workplaceFqdn flag is correctly added to:

• the useProfileTwake type and defaults (defaulting to false), and
• the mockUserDB destructuring and conditional defineProperty logic,

so that profile.workplaceFqdn is only present when explicitly requested and uses MOCK_DATA.LDAP.workplaceFqdn, mirroring the pattern for other LDAP fields.

Given mockUserDB was already flagged as complex, this extra branch pushes it a bit further; over time it might be worth extracting a small table‑driven helper for these field toggles to keep cyclomatic complexity in check, especially if more attributes get added.

Also applies to: 106-107, 138-142

🧹 Nitpick comments (2)

packages/tom-server/src/user-info-api/services/index.ts (1)

147-162: Directory fetch and propagation of workplaceFqdn are consistent

Including 'workplaceFqdn' in the userDb.get field list and assigning it to result.workplaceFqdn when directoryRow.workplaceFqdn is present fits the existing pattern for other directory‑backed attributes and respects the overall precedence chain (matrix → directory → settings → address‑book).

One point to consider: unlike mail and mobile, workplaceFqdn is always returned when present, without visibility checks. If this value is considered sensitive in your domain, you may want to gate it behind the same visibility rules (or a dedicated setting); if it’s intentionally always public, then the current implementation is fine.

Also applies to: 216-245

packages/tom-server/src/user-info-api/tests/service.test.ts (1)

517-565: New workplaceFqdn tests validate presence/absence behavior in the base scenario

Both tests correctly set up Matrix (displayName+avatar) and UserDB profiles, then assert that:

• workplaceFqdn is exposed when the LDAP mock includes it, and
• the field is omitted when workplaceFqdn is not provided,

while keeping the expectations for other fields consistent with existing precedence rules. This gives good coverage for the core behavior; if you later extend workplaceFqdn to other data sources or visibility modes, you can mirror these tests in those contexts too.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between bb2ea4a and c84584b.

📒 Files selected for processing (6)

• .compose/ldap/ldif/base_ldap_users.ldif (4 hunks)
• .compose/ldap/ldif/config-20230322180123.ldif (1 hunks)
• .compose/ldap/ldif/custom-schema.ldif (1 hunks)
• packages/tom-server/src/user-info-api/services/index.ts (3 hunks)
• packages/tom-server/src/user-info-api/tests/service.test.ts (5 hunks)
• packages/tom-server/src/user-info-api/types.ts (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: Build And Test / test
• GitHub Check: update

🔇 Additional comments (5)

packages/tom-server/src/user-info-api/types.ts (1)

17-30: Expose workplaceFqdn on UserInformation looks correct

Optional workplaceFqdn?: string is a backward‑compatible extension and aligns with how the service now populates this field.

.compose/ldap/ldif/base_ldap_users.ldif (1)

19-38: LDAP entries correctly extended with workplaceUser / workplaceFqdn

Adding objectClass: workplaceUser alongside inetOrgPerson and populating workplaceFqdn for selected users is consistent with the new AUXILIARY schema and should provide good coverage for the new field in tests and local deployments.

Also applies to: 48-56, 146-155, 156-165, 198-219

.compose/ldap/ldif/config-20230322180123.ldif (1)

242-253: Custom schema entry for workplaceFqdn / workplaceUser is coherent

The new cn={4}custom schema fragment defines workplaceFqdn and the AUXILIARY workplaceUser class consistently with how they are used in user entries and in custom-schema.ldif. This should integrate cleanly with the existing cn=config setup.

.compose/ldap/ldif/custom-schema.ldif (1)

1-15: Standalone custom schema for workplace attributes looks good

The custom schema LDIF cleanly defines workplaceFqdn and the AUXILIARY workplaceUser class with matching OIDs to the config snapshot and is compatible with how user entries are authored.

packages/tom-server/src/user-info-api/tests/service.test.ts (1)

42-43: MOCK_DATA.LDAP extension for mobile/workplaceFqdn is consistent with usage

Defining mobile and workplaceFqdn on MOCK_DATA.LDAP matches how later tests reference MOCK_DATA.LDAP.mobile and MOCK_DATA.LDAP.workplaceFqdn, and keeps the mock payload self‑contained and realistic. No issues here.