@DanBradbury Saw your note in HipChat about the confusing update_associations method. You are totally right that thing is poorly commented and confusing. I don't blame you for throwing up your hands. I myself was confused at the the code when I looked at it the other day (it was written quite a while ago and I'll take the blame for that). What I can tell you is that it was written for a particular purpose to allow people from other contexts to modify their associations to an object (like assigning a corporate message to their own local item) in a way that would preserve the associations made by someone at at a sibling level entity that they cannot see. As such, the above being said it may not be as necessary to use that method when updating associations via the API since we likely will never have to deal with that complicated context issue that we need to in the UI.
All that being said, something has gotten lost in the the functionality in how the update action has been handled (where it no longer calls the 'update' method, and how only one method is returning the xml error response code) and there is still some duplication on how the nutritional updates are being handled. No matter what direction we go I feel strongly that the nutrition updates and other associations should be handled universally for all API types with the same set of code and not be handled differently for Computrition than they are for the Import and any other uses that come under this fold. I think this can be fixed with a little walk through of the controller logic and combining them to use the same update methods (whether the new ones or the old ones) and to make sure we trap the XML error response code.
I'm game to work through this in a variety of ways either together or if you would like me to work on tweaking the controller logic to bring the two interfaces together I am game to do that as well. Let me know your thoughts.
-BB