Implement Organizations module and refactor Portal according to latest API version#17
Conversation
|
Current dependencies on/for this PR:
This comment was auto-generated by Graphite. |
fec8d4b to
5f5b39d
Compare
1ddeeb8 to
60f4b13
Compare
blairworkos
left a comment
There was a problem hiding this comment.
Awesome! I left a few questions and comments. Let me know if anything doesn't make sense.
Also, not sure if it's in the scope of this PR or we should create a follow up issue - but error handling is also something lacking here, for example, we specifically handle errors from endpoints in the Ruby SDK: https://github.com/workos/workos-ruby/blob/main/lib/workos/organizations.rb#L169
| @doc """ | ||
| Create an organization | ||
|
|
||
| ### Parameters |
There was a problem hiding this comment.
Should we also support the idempotency key here, like in the Ruby SDK? https://github.com/workos/workos-ruby/blob/main/lib/workos/organizations.rb#L85
There was a problem hiding this comment.
Interesting, what's an idempotency key? I didn't find it in the API reference https://workos.com/docs/reference/organization/create
There was a problem hiding this comment.
Strange, I guess we have a separate section on Idempotency: https://workos.com/docs/reference/idempotency
Little blurb:
The WorkOS API supports idempotency which guarantees that performing the same operation multiple times will have the same result as if the operation were performed only once. This is handy in situations where you may need to retry a request due to a failure or prevent accidental duplicate requests from creating more than one resource.
Very helpful for these create requests, so a duplicate org isn't created. You can take it as an optional parameter, and if present, you can send it as a request header.
There was a problem hiding this comment.
We can also add this as a follow-up
There was a problem hiding this comment.
I think we can add it here already! I think it actually can be already used since we're passing directly the opts argument do the HTTP request, not limiting headers
| - params (map) | ||
| - intent (string) The access scope for the generated Admin Portal | ||
| link. Valid values are: ["sso"] | ||
| link. Valid values are: ["sso"] |
There was a problem hiding this comment.
We support the following values currently:
["sso", "dsync", "audit_logs", "log_streams"]
Is there a preferred way of checking against an enum value in Elixir? For reference, we validate that the intent matches a supported one in Ruby: https://github.com/workos/workos-ruby/blob/main/lib/workos/portal.rb#L58
There was a problem hiding this comment.
We could use the Enum module to verify if the given intent is supported, eg: Enum.member?(["sso", "dsync", "audit_logs", "log_streams"], "sso")
There was a problem hiding this comment.
So I ended up defining a module attribute called @generate_link_intents and then using it as a function guard 25a2af9
def generate_link(%{intent: intent} = _params, _opts)
when intent not in @generate_link_intents,
do:
raise(ArgumentError,
message:
"invalid intent, must be one of the following: sso, dsync, audit_logs or log_streams"
)
Implement a module for organizations and remove its related functions from the portal module, making it up to date to the latest API version
Closes #16