[
https://issues.apache.org/jira/browse/UNOMI-813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Romain Gauthier updated UNOMI-813:
----------------------------------
Description:
In Unomi 2, aliases were introduced to make it easier to work with several
identifiers for one profile.
However there is no endpoint to create a profile using an external identifier.
Improving the current endpoint to create profile or creating a new one would be
helpful for organizations looking to create profils using CRM ids, customers
ids etc..
Such endpoint:
- Cannot not be public for security reasons, it would need to be added to
/cxs/..
- Would cover creation or update of profiles by external systems. If the
profile is updated by the visitor, this still needs to happen through events
- Shouldn't be able to force the value of the profile id. Profile ids need to
stay secure and it's better to have unomi generate them
- Would require an alias in the payload. Likely: alias id + alias property
(examples: [email protected], email or johnSmith, login)
- Would trigger the merge logic, for data consistency reasons
h3. Limitation / to keep in mind:
In a better world, it might make more sense to restrict the creation and
updates of profiles/ sessions through events.
In that case, we might need to support a new event type: createOrUpdateProfile
This event type would not be public, it would be restricted as login and
updateProperties
Warning: To send process an event, unomi needs a profile id. However, in that
case, there wouldn't be any. That is why it might be better after all to allow
the creation of profiles from private endpoints. Otherwise, we'd need to make
sure that unomi can process this event type without any profile id.
was:
In Unomi 2, aliases were introduced to make it easier to work with several
identifiers for one profile.
However there is no endpoint to create a profile using an external identifier.
Improving the current endpoint to create profile or creating a new one would be
helpful for organizations looking to create profils using CRM ids, customers
ids etc..
Such endpoint:
- cannot not be public for security reasons, it would need to be added to
/cxs/..
- would cover creation of profile using aliases
- would need to trigger the merge logic, for data consistency reasons
h3. Limitation / to keep in mind:
In a better world, it might make more sense to restrict the creation and
updates of profiles/ sessions through events.
In that case, we might need to support a new event type: createOrUpdateProfile
This event type would not be public, it would be restricted as login and
updateProperties
Warning: To send process an event, unomi needs a profile id. However, in that
case, there wouldn't be any. That is why it might be better after all to allow
the creation of profiles from private endpoints. Otherwise, we'd need to make
sure that unomi can process this event type without any profile id.
> New endpoint to create / update / merge profiles
> ------------------------------------------------
>
> Key: UNOMI-813
> URL: https://issues.apache.org/jira/browse/UNOMI-813
> Project: Apache Unomi
> Issue Type: New Feature
> Reporter: Romain Gauthier
> Priority: Major
> Fix For: unomi-2.5.0
>
>
> In Unomi 2, aliases were introduced to make it easier to work with several
> identifiers for one profile.
> However there is no endpoint to create a profile using an external
> identifier. Improving the current endpoint to create profile or creating a
> new one would be helpful for organizations looking to create profils using
> CRM ids, customers ids etc..
> Such endpoint:
> - Cannot not be public for security reasons, it would need to be added to
> /cxs/..
> - Would cover creation or update of profiles by external systems. If the
> profile is updated by the visitor, this still needs to happen through events
> - Shouldn't be able to force the value of the profile id. Profile ids need to
> stay secure and it's better to have unomi generate them
> - Would require an alias in the payload. Likely: alias id + alias property
> (examples: [email protected], email or johnSmith, login)
> - Would trigger the merge logic, for data consistency reasons
> h3. Limitation / to keep in mind:
> In a better world, it might make more sense to restrict the creation and
> updates of profiles/ sessions through events.
> In that case, we might need to support a new event type:
> createOrUpdateProfile
> This event type would not be public, it would be restricted as login and
> updateProperties
> Warning: To send process an event, unomi needs a profile id. However, in that
> case, there wouldn't be any. That is why it might be better after all to
> allow the creation of profiles from private endpoints. Otherwise, we'd need
> to make sure that unomi can process this event type without any profile id.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
