You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What?
When calling the user: import action (introduced in #2270), currently the protected fields (e.g. APP_FIRST_LAUNCH, APP_USER_ID etc) do not get imported. As pointed out on this comment on #2371, we should consider handling this case and potentially updating the active user's ID to match that of the imported ID, or at least exposing the option to do so.
Why?
When importing user data, if the current user ID is different to that of the imported data then on subsequent syncs, the data will be associated with the current user ID rather than that of the imported data. This may not always be desirable.
This is related to the same use case that highlighted the issue in #2366.
How?
I opened a PR, #2405, however I realised that the behaviour of always overwriting the user's uuid on import may not be desirable, I think further discussion is needed.
The text was updated successfully, but these errors were encountered:
Overwriting the current user ID with the imported one could cause data to be lost: any data associated with the current ID will be overwritten.
Therefore it may make sense to generate a new, third, ID when doing a user: import action. This could be a concatenation of the two previous IDs, or else we could store these two previous IDs within fields associated with the new ID.
What?
When calling the
user: import
action (introduced in #2270), currently the protected fields (e.g.APP_FIRST_LAUNCH
,APP_USER_ID
etc) do not get imported. As pointed out on this comment on #2371, we should consider handling this case and potentially updating the active user's ID to match that of the imported ID, or at least exposing the option to do so.Why?
When importing user data, if the current user ID is different to that of the imported data then on subsequent syncs, the data will be associated with the current user ID rather than that of the imported data. This may not always be desirable.
This is related to the same use case that highlighted the issue in #2366.
How?
I opened a PR, #2405, however I realised that the behaviour of always overwriting the user's uuid on import may not be desirable, I think further discussion is needed.
The text was updated successfully, but these errors were encountered: