Repository navigation
refactor: remove redundant roles/type copy from LDAP login sync - #42993
MateenAkram1 wants to merge 2 commits into
Conversation
|
Looks like this PR is not ready to merge, because of the following issues:
Please fix the issues and try again If you have any trouble, please check the PR guidelines |
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📜 Recent review details
WalkthroughThe LDAP login path no longer copies an existing user’s roles and type into mapped data before conversion. Tests cover how user updates handle omitted roles and type, default values, and imported values. ChangesLDAP user update
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Refactor Suggested labels: Suggested reviewers: Merge Risk: ⚪ Minimal · up to
|

Proposed changes (including videos or screenshots)
Removes the block in
LDAPManager.syncUserForLoginthat copied the existing user'srolesandtypeinto the LDAP data before conversion, along with itsTODO.The block was added in #23378 because the import converter used to reset
rolesandtypeto their defaults on every update. A month later, #23608 changedUserConverter.updateUserto apply those defaults only when both the incoming data and the existing user have no value. Since then the block has had no effect on the stored user:existingUserundefined)$setwrites back the same rolesrolesis not written; the stored value is kept['user']['user']typemapUserDataalways setstype: 'user', so this branch never ranThe background LDAP sync (
LDAPEEManager.updateExistingUsers) already passes existing users through the sameLDAPUserConverterwithout this block.The converter keeps its defaults, because newly inserted users still need them.
Two commits:
test:three unit tests forUserConverter.updateUser:roles/typeare left alone when the data has noneNo test covered this before. The tests pass on the current code. With the pre-[FIX] Advanced LDAP Sync Features #23608 unconditional defaults put back, the first test fails.
refactor:remove the block fromManager.ts.No changeset: there is no user-visible change.
Issue(s)
Closes #42981
Steps to test or reproduce
cd apps/meteor && yarn .testunit:server: 3129 passing (3126 before, plus the 3 new tests), 0 failing. The run includesee/server/lib/ldap/**/*.spec.ts.yarn .testunit:jest,yarn .testunit:definitionandtsc --noEmit --skipLibCheckpass. ESLint reports no new warnings on the touched files.yarn devboots without errors.I did not test a live LDAP login, because I don't have a Premium license and LDAP server locally. The table above shows the stored result is the same in every case.
Further comments
Things I noticed nearby and left out to keep this to one concern. Happy to open separate PRs for them:
UserConverter.updateUsercallsUsers.updateOne({ _id }, updateData)with an inline filter instead of a named model method (seedocs/database-access.md).LDAPManager.onMapUserDatafirescallbacks.run('mapLDAPUserData', …)withvoidinstead of awaiting it.mapUserDataalways setstype: 'user', so an existingbotaccount that is synced from LDAP is changed touser. This is existing behavior and this PR does not change it.Summary by CodeRabbit