fix: Old custom fields from migrated contacts are not ignored on update

[matheusbsilva137]

Proposed changes (including videos or screenshots)

• On contact update, ignore custom fields that were previously in the contact, but are not registered in the workspace anymore (do not throw any error and do not change them);
• On contact update, keep "legacy" custom fields (which are not registered in the workspace anymore) even if they are not specified in the update;

Issue(s)

Steps to test or reproduce

1. Create an omnichannel custom field (Omnichannel > Custom fields);
2. Create a contact using the custom field that has just been created;
3. Delete the custom field created in step 1;
4. Try updating the contact created in step 2 (using the UI or the contacts.update endpoint).

Current behavior: if the old custom field is provided in the update payload (this happens by default when using the UI to update the contact), then RC throws an error (caused by the unsupported custom field);
Expected behavior: no error should be thrown on update (even if the old custom field is provided). The old/legacy custom field should be kept unchanged. We should still throw an error in case extra custom fields (that are not in the contact before the update) are provided.

Further comments

SCI-193

[dionisio-bot]

Looks like this PR is ready to merge! 🎉
If you have any trouble, please check the PR guidelines

[changeset-bot]

🦋 Changeset detected

Latest commit: d55f90b

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 35 packages

Name	Type
@rocket.chat/meteor	Patch
@rocket.chat/core-typings	Patch
@rocket.chat/rest-typings	Patch
@rocket.chat/uikit-playground	Patch
@rocket.chat/api-client	Patch
@rocket.chat/apps	Patch
@rocket.chat/core-services	Patch
@rocket.chat/cron	Patch
@rocket.chat/ddp-client	Patch
@rocket.chat/freeswitch	Patch
@rocket.chat/fuselage-ui-kit	Patch
@rocket.chat/gazzodown	Patch
@rocket.chat/livechat	Patch
@rocket.chat/model-typings	Patch
@rocket.chat/ui-contexts	Patch
@rocket.chat/account-service	Patch
@rocket.chat/authorization-service	Patch
@rocket.chat/ddp-streamer	Patch
@rocket.chat/omnichannel-transcript	Patch
@rocket.chat/presence-service	Patch
@rocket.chat/queue-worker	Patch
@rocket.chat/stream-hub-service	Patch
@rocket.chat/license	Patch
@rocket.chat/omnichannel-services	Patch
@rocket.chat/pdf-worker	Patch
@rocket.chat/presence	Patch
rocketchat-services	Patch
@rocket.chat/network-broker	Patch
@rocket.chat/models	Patch
@rocket.chat/ui-avatar	Patch
@rocket.chat/ui-client	Patch
@rocket.chat/ui-video-conf	Patch
@rocket.chat/ui-voip	Patch
@rocket.chat/web-ui-registration	Patch
@rocket.chat/instance-status	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 75.81%. Comparing base (75a14b2) to head (d55f90b).
Report is 1 commits behind head on develop.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop   #34139   +/-   ##
========================================
  Coverage    75.81%   75.81%           
========================================
  Files          512      512           
  Lines        22205    22205           
  Branches      5403     5403           
========================================
  Hits         16834    16834           
  Misses        4720     4720           
  Partials       651      651           

Flag	Coverage Δ
unit	75.81% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[github-actions]

PR Preview Action v1.4.8
🚀 Deployed preview to https://RocketChat.github.io/Rocket.Chat/pr-preview/pr-34139/
on branch gh-pages at 2024-12-18 07:55 UTC

[KevLehman]

Not a fan of the destructive behavior this may cause. Wonder if it would be better to create a setting to allow users to decide if we ignore or remove the old fields.

Some users may not have the custom field registered anymore but it can hold data they want or they access via some internal api 👀

[matheusbsilva137]

Not a fan of the destructive behavior this may cause. Wonder if it would be better to create a setting to allow users to decide if we ignore or remove the old fields.

Brought your suggestion to the product team and we decided to keep all "legacy" custom fields on update. They're not being deleted anymore
I updated all tests to follow this new behavior