feat: create, update, and delete integrations (stacked version)

[toph-allen]

Intent

Add functions to create, update, and delete integrations.

N.B. This supersedes #439, which was based on main, and did not include changes from #437.

Fixes #434

Approach

• Three pretty simple functions to create, update, and delete integrations.
• create_integration() takes a client.
• update_integration() and delete_integration() take a connect_integration object as their first argument.
  • To support this, the connect_integration class now gets a client as an attribute when it is created.
• Some other simplifications where appropriate, e.g. as_integration() no longer uses method dispatch.

Checklist

• Does this change update NEWS.md (referencing the connected issue if necessary)?
• Does this change need documentation? Have you run devtools::document()?

[toph-allen]

Looks like CI will not run until the parent PR is closed and this targets main.

[nealrichardson]

Link to API docs for where you can get a complete list of supported values?

[toph-allen]

The API docs say "See List OAuth templates for more information" — I think our idea is that people call that endpoint. I think linking to the OAuth integration docs overview here might be better right now? 🤔

Adding a get_templates() function is tracked here: #435

[nealrichardson]

Sure, whatever is best. Just flagging that we should provide users with a way of knowing what the valid values here are.

[nealrichardson]

Link to API docs?

[mconflitti-pbc]

"creates"? or just "gets"

[toph-allen]

Oh yeah lol you're exactly right, I was thinking in a different frame when I originally wrote it

[joshyam-k]

Is there a reason we're returning an actual object on a PATCH method? I wouldn't expect a function updating an integration to return the new integration object but maybe that's a reasonable side effect in the context of this package.

[toph-allen]

Yeah, the reasons are two-fold. One is that it matches the way that if you're working with local R objects, the way you update an object is to call a function on it and assign that result to something -- like:

animals <- c("cat", "dog")

# update animals
animals <- c(animals, "bat")

In the context of integrations and Connect, it matches the way the PATCH API works (it returns the updated object, and we're just passing it on.)

So if you imagine that in the context of a script, if I'm say, updating an integration, like giving a GitHub integration a new key, it makes sense for my local representation of that object to be updated to the new version.

client <- connect()

github_integration <- get_integrations(client) |>
  purrr::keep(~ .x$template == "github")[[1]]

github_integration <- update_integration(github_integration, config = list(key = NEW_KEY))

# Now this object will reflect the updated info.
github_integration$config$key

[joshyam-k]

ah, makes perfect sense. thanks!!