Adding extra fields to Account model

[mdodell]

How would I go about adding extra fields to the Account model? I understand that I can use omniauth_identity_update_hash after each login. I want to make sure things like the user's name/profile photo are kept to date.

[janko]

If I understand correctly, you want to store additional information from the OmniAuth login, but on the accounts table instead of the account_identities table?

[mdodell]

And if I want to fetch things like the user's first and last name/picture_url - I cannot fetch those from rodauth.rails_account, right? Since those would have to be stored under account_identities in new fields?

[mdodell]

I think looking at the rodauth-demo-rails, my best solution would be to have a Profile model that acts as the source of truth for user information, and then my Account model has one Profile and many identities.

That way, I could get information simply doing rodauth.rails_account.profile, and if a user wants to update their information, they can update that model directly. This would probably keep better separation of concerns.

[janko]

A user can have multiple identity records though, right? I.e. in the case of multiple providers?

Yes, if your application offers multiple providers, then they can have multiple identities.

What is the best way to discern where the single source of truth for user information is/what if a user wants to edit their information specifically on my platform (i.e. they want to update only their last name on my platform)?

If you want the information editable, then you can store them on the accounts table or an associated table such as profiles. But then you don't want to update that information on every OmniAuth login, because you'd overwrite any custom edits from the user.

The other option is storing it on the account_identities table, and making it non-editable and always reflect the latest information by refreshing it on every OmniAuth login.

The option you were suggesting – storing it on the accounts table, and making it editable, but still overwriting it on every OmniAuth login – doesn't make sense from the UX standpoint. If the information is editable by the user, then it should never be automatically overwritten.

My concern is a person calling the create-account endpoint with an email they already have via Omniauth provider - I guess in that case, it would probably be rejected since they already have an account via Omniauth?

That's correct, since the account was already created for that email address.

[mdodell]

That makes sense! I'll give this a try - thank you!

[janko]

Yes, I generally prefer keeping information not strictly related to authentication in a separate associated table such as profiles 👍🏻