In APIv3, when Activity.get receives a request for a custom field via the return parameter, it returns other, unrelated custom fields if they have a default value set. This is true even if the custom field should not be available for the relevant activity type.
In Contract.process_scheduled_modifications, this code is triggered and the result of such a call is then passed to CE. The called code then calls Activity.create with these unrelated custom fields set, leading to the actual creation of these rows.
This adds a workaround that strips these custom fields before passing the API results to the engine. A better long-term fix would be to move the relevant code to APIv4.
In APIv3, when
Activity.get
receives a request for a custom field via the return parameter, it returns other, unrelated custom fields if they have a default value set. This is true even if the custom field should not be available for the relevant activity type.In
Contract.process_scheduled_modifications
, this code is triggered and the result of such a call is then passed to CE. The called code then callsActivity.create
with these unrelated custom fields set, leading to the actual creation of these rows.This adds a workaround that strips these custom fields before passing the API results to the engine. A better long-term fix would be to move the relevant code to APIv4.