As a developer I want a re-usable externalId implementation so that I can easily apply this to different entity types.
SCIM provides [the concept of externalId](https://datatracker.ietf.org/doc/html/rfc7643#section-3.1) which can be used to identify a resource with an identifier that is known to the SCIM client. This prevents the SCIM client from having to store a mapping between its internal data and our ID, instead putting that burden on us as a service provider.
Although not covered by SCIM itself, it provides various [recommendations for multi-tenancy](https://datatracker.ietf.org/doc/html/rfc7644#section-6) where multiple external systems may want to manage their own user data. Given our intention of targeting Enterprise users it’s likely that they’ll want to connect multiple systems to Open Social (e.g. managing users within their organization). We’ll want to combine this with SCIM’s [privacy recommendations](https://datatracker.ietf.org/doc/html/rfc7643#section-9.3) and determine how we want to handle the externalId.
We’ll want to decide whether we want to support multiple external systems managing the same user. This may be desired for migrations or when we need to pull data from multiple systems that might overlap and want to de-duplicate users. We use this ourselves in our Private Packagist where a developer can login with either Bitbucket or GitHub and user groups are managed through both (until we fully move to GitHub).
Regardless of our support for shared management of resources we’ll want to make sure that our externalId is tied to the system that created the user. This ensures that if multiple systems can only manage their own users they don’t run into conflicts (e.g. because they both have an externalId of user:5 which represent their own 5th users).
SCIM provides [the concept of externalId](https://datatracker.ietf.org/doc/html/rfc7643#section-3.1) which can be used to identify a resource with an identifier that is known to the SCIM client. This prevents the SCIM client from having to store a mapping between its internal data and our ID, instead putting that burden on us as a service provider.
Although not covered by SCIM itself, it provides various [recommendations for multi-tenancy](https://datatracker.ietf.org/doc/html/rfc7644#section-6) where multiple external systems may want to manage their own user data. Given our intention of targeting Enterprise users it’s likely that they’ll want to connect multiple systems to Open Social (e.g. managing users within their organization). We’ll want to combine this with SCIM’s [privacy recommendations](https://datatracker.ietf.org/doc/html/rfc7643#section-9.3) and determine how we want to handle the externalId.
We’ll want to decide whether we want to support multiple external systems managing the same user. This may be desired for migrations or when we need to pull data from multiple systems that might overlap and want to de-duplicate users. We use this ourselves in our Private Packagist where a developer can login with either Bitbucket or GitHub and user groups are managed through both (until we fully move to GitHub).
Regardless of our support for shared management of resources we’ll want to make sure that our externalId is tied to the system that created the user. This ensures that if multiple systems can only manage their own users they don’t run into conflicts (e.g. because they both have an externalId of user:5 which represent their own 5th users).
- As a developer I should be able to apply/use this field on any entity type.
- As a developer I should be able to apply single or multiple external ides per entity type.
- As a developer I should be able to select which target entity types (external owners) are supported per each field.
- As a developer I should be able to use this field via UI or as hidden field.
- As a user or developer I should be able to save this fields with all subfields values empty
- As a user or developer I should not be able to save this field if any subfield value is missing (except if all are empty)
- Create new field type with 3 subfields:
- External ID (external_id, string)
- External Owner Target type (external_owner_target_type, string)
- External Owner ID (external_owner_id, integer)
- In the field storage settings, it can be determined which entity types can be referenced.
- Field provides magic method `entity`, which returns an entity object based on External Owner Target type and External Owner ID
N/A
N/A
N/A
N/A
Fixed
13.0
Code (back-end)
PR ready for review: https://github.com/goalgorilla/open_social/pull/3942
Reviewed by @tbsiqueira and @Kingdutch.
This feature will land on 13.0.0-alpha6 and higher. ATM back porting is not planned.
Patch for 13.0.0-alpha5 is provided
here →
Automatically closed - issue fixed for 2 weeks with no activity.