Add external_id to user and organization #381
Conversation
On create and update (@mxlje already added to user update).
81e2663 to
8003c5b
Compare
There was a problem hiding this comment.
Greptile Summary
This PR adds external_id parameter support to both user and organization creation methods in the WorkOS Ruby SDK. The changes enable developers to associate their own external identifiers with WorkOS entities during creation, complementing the already existing update functionality.
For organizations, the external_id parameter is added to the create_organization method in the Organizations module, following the same pattern as other optional parameters. The implementation includes proper documentation, conditional inclusion in the request body, and follows existing SDK conventions.
For users, the external_id parameter is added to the create_user method in the UserManagement module. This provides feature parity since the update_user method already supported this field. The User and Organization model classes were already equipped to handle the external_id attribute, indicating this was planned functionality.
The changes are supported by comprehensive test coverage through VCR cassettes that verify the complete request/response flow for both user and organization creation with external IDs. The implementation maintains consistency with existing SDK patterns and provides a valuable integration feature for applications that need to maintain their own identifier mapping alongside WorkOS-generated IDs.
Confidence score: 4/5
• This PR is very safe to merge with only minor inconsistencies that don't affect functionality
• The implementation follows established patterns, includes proper tests, and the underlying models already support the feature
• The update_organization method needs attention for consistent parameter handling - it always includes external_id in the body hash even when nil, unlike the conditional approach used in create_organization
4 files reviewed, 1 comment
External IDs can actually be set to null. On create this isn't an issue, not sending it will result in it being null. But on update if a user passes nil we want to be sure a null value goes to the API. Since organizations and user update methods are different I opted for a slightly difference solution in each place.
| allow_profiles_outside_organization: nil | ||
| ) | ||
| body = { name: name } | ||
| body[:domain_data] = domain_data if domain_data | ||
| body[:stripe_customer_id] = stripe_customer_id if stripe_customer_id | ||
| body[:external_id] = external_id if external_id != :not_set |
There was a problem hiding this comment.
Nice catch! Wonder how we support unsetting the other arguments. 🤔
There was a problem hiding this comment.
Right now that's just not possible. I haven't done a thorough look to see what can be set to null or not. I think we should likely revisit the sdk and do this not_set thing in a bunch of places, but didn't want to get into that in this PR specifically
| @@ -310,6 +325,21 @@ | |||
| end | |||
| end | |||
| end | |||
| context 'with an external_id' do | |||
There was a problem hiding this comment.
Think it's worth tests for unsetting external_id?
There was a problem hiding this comment.
Ya, that's a good callout, will do!
1d03bba to
f6291b9
Compare
Description
On create and update (@mxlje already added to user update).
Documentation
Does this require changes to the WorkOS Docs? E.g. the API Reference or code snippets need updates.
If yes, link a related docs PR and add a docs maintainer as a reviewer. Their approval is required.