Action Builder Deactivate & Reactivate Connections #965
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Connection records in Action Builder cannot be deleted. Instead, there's an "Inactive" flag that determines whether they appear in the UI or not on either of the two Entity records they connect. This PR introduces a new method,
deactivate_connection()
, which deactivates an existing Connection.The method requires the "interact ID" for one of the two Entities as a positional argument. One of two additional (keyword) arguments is required to make the change: either the interact ID for the other Entity (POST request to the connection helper endpoint), or the interact ID of the connection itself (PUT request to the specific connection endpoint).
This PR also updates the existing
upsert_connection()
method to include by default an explicitFalse
value for theinactive
flag when upserting Connection data, under the assumption that upserting to a given Connection implies that the user wants that Connection to be active. Thereactivate
argument can be set toFalse
to prevent this and make changes to inactive Connections without reactivating them.Tests were written and adapted for these additions and changes, and are running successfully. Furthermore, these changes were successful in live tests done by defining the two methods locally and overriding the Class definitions before instantiation.
A good future PR might be to adapt the existing
upsert_connection()
method to accept the Connection ID as an optional keyword arg, to trigger a PUT request directly to the specific Connection endpoint. Argument validation could be updated such that a single-item list (or even a string) could be accepted for the positionalidentifiers
arg if the Connection ID is provided.