Context
The User model already exposes a complementary field (added via modules/users/models/users.model.mongoose.js + schema + account controller projection). However the token handler in modules/auth/controllers/auth.controller.js hand-builds its own user projection and was missing this field.
Downstream projects were patching this locally, creating drift vs upstream devkit.
What this changes
- Adds
complementary: req.user.complementary to the user-projection object in the token handler — matching the existing account controller projection and User model.
- Ports a regression test (
auth.token.controller.unit.tests.js) to prevent future omissions: guards that /api/auth/token includes complementary so per-user UI prefs / extras rehydrate correctly across refresh.
Why
Every devkit downstream that stores per-user UI preferences or extra data in user.complementary needs this field to survive a full-page refresh (which re-calls /api/auth/token). Without it, client state silently resets on reload.
Context
The
Usermodel already exposes acomplementaryfield (added viamodules/users/models/users.model.mongoose.js+ schema + account controller projection). However thetokenhandler inmodules/auth/controllers/auth.controller.jshand-builds its own user projection and was missing this field.Downstream projects were patching this locally, creating drift vs upstream devkit.
What this changes
complementary: req.user.complementaryto the user-projection object in thetokenhandler — matching the existing account controller projection and User model.auth.token.controller.unit.tests.js) to prevent future omissions: guards that/api/auth/tokenincludescomplementaryso per-user UI prefs / extras rehydrate correctly across refresh.Why
Every devkit downstream that stores per-user UI preferences or extra data in
user.complementaryneeds this field to survive a full-page refresh (which re-calls/api/auth/token). Without it, client state silently resets on reload.