Unable to find and then save a contact due to tag_ids attribute

[kewan]

$contact = $infusionsoft->contacts()->find(1);

will result in a contact object with a tag_ids attribute, eg:

$contact->attributes['tag_ids']

Then when you try to save the contact using:

$contact->save()

You will get the following error:

400 Bad Request` response:\n{"message":"Unrecognized property: tag_ids"}

As a workaround you can do this:

unset($contact->tag_ids);
$contact->save();

[N30]

I would do if(isset($cid->tag_ids)) unset($cid->tag_ids); That way your code won't break again when InfusionSoft decides to take the tag_ids out again. This has been going on since April and messed up our code. Did anyone tell InfusionSoft that the point of versioning APIs is to not make changes to existing versions.

[acobster]

Looking for input from @kewan and the InfusionSoft team - would calling unset inside ContactService be an acceptable solution to this? I'd be happy to submit a PR.

[mfairch]

@acobster that feels like a bandaid fix. Ideally we'd have a transformer in the sdk that handles all of that for us. The problem with a transformer is that we'd have to update it every time a field changes on the model, however there might be ways to automate updating that.

[acobster]

Taking a step back, would a more appropriate fix be to ignore tag_ids on the server side? Or perhaps even honor updates to tag_ids? The Principle of Least Astonishment leads me to the conclusion that any data I get back about a Contact (or any RESTful entity) should bear meaning when sending them back in an update, or at least shouldn't cause any errors when you do (with the possible exception of truly immutable values, like id). And I can't imagine that other client implementations wouldn't run across this same issue.

[brumiser1550]

I agree with @acobster on this. As far as I know a resource obtained through a GET method should be the same resource provided to the POST/PATCH/PUT methods without any alterations. I am not sure the best way for IFS to handle this because I don't know the code base but I think customizing the endpoint to allow the tags array to be accepted and parsed, removing and adding tags as necessary, would not be a breaking change since everyone currently has to remove the tags before sending back. This would simply allow any future calls to allow tags to be passed.

[jwong-quaver]

This is still happening.

You can't have $contact = $infusionsoft->contacts()->find(1); and then immediately follow up with $contact->save() without running into this error. It's a little frustrating.

[cosmastech]

I can't believe how long this has been problem, judging by the comments on this issue. At the very least put a note in the README that explains the workaround of unsetting the tag_ids.

[cosmastech]

Another problem I ran into is that if there are data validation errors which were set on the front end, as mentioned by @jwong-quaver, pulling one of these records and immediately calling $contact->save() will cause an exception.

I am running into this problem with billing/shipping addresses that use abbreviations rather than full state names.

[MCKLtech]

Still happening in April 2020.