You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In my admittedly not terribly thorough look through the code, it seems that we have a mechanism to require certain fields in the body of the packet, per packet type, but there doesn't appear to exist a way to require particular header fields.
It would be useful to be able to require the originating_site_name in the header for notify_person_ids (and/or have it default to the remote_site_name), as this packet type originates at the remote site, and is not a reply to any other packet.
The text was updated successfully, but these errors were encountered:
It'd be pretty easy to require certain header fields on packet creation and/or validation, but I'd need more info on what is required when in what cases. Separately, having default values in certain cases is doable but might complicate things a bit.
For example, can we assume for all packets that originating_site_name should be remote_site_name unless otherwise specified? Or would the 'rule' be, for certain specific packets, we can assume that; otherwise we must require it?
Namely, notify_person_ids is one of the few packets that a remote site can POST to start a new transaction--it isn't in reply to another packet, and thus the API (which knows as little as possible about the specifics of the packets it processes) needs to know what the originating_site_name is.
As of the resolution of that JIRA issue, the API rejects packets that are posted not-in-reply-to another packet, if they don't include an originating_site_name. It also enforces that the originating_site_name must match either "TGCDB" or the remote_site_name.
It would still be nice if the amieclient would do this too, but the API gives a reasonable error message now if not, so it's probably not a big deal.
End result of the discussion is that adding a validation check for notify_person_ids that will check if originating_site_id is present and equal to either TGCDB or remote_site_name will be added to the next release, but it's nothing that needs to be pushed out on its own.
In my admittedly not terribly thorough look through the code, it seems that we have a mechanism to require certain fields in the body of the packet, per packet type, but there doesn't appear to exist a way to require particular header fields.
It would be useful to be able to require the originating_site_name in the header for notify_person_ids (and/or have it default to the remote_site_name), as this packet type originates at the remote site, and is not a reply to any other packet.
The text was updated successfully, but these errors were encountered: