Remove deprecated name-related Address fields

[filippoliverani]

Description

Ref #3816 and #3234

This PR removes deprecated public-accessible Address name fields and their aliases:

• full_name
• firstname
• first_name
• lastname
• last_name.

Address name attribute is still interally persisted on the DB as two separate firstname and lastname columms, in a future PR we can move them to a new name column and provide a rake task to help migrate existing data.

Checklist:

• I have followed Pull Request guidelines
• I have added a detailed description into each commit message
• I have updated Guides and README accordingly to this change (if needed)
• [] I have added tests to cover this change (if needed)
• I have attached screenshots to this PR for visual changes (if needed)

[DanielePalombo]

LGTM

[kennyadsl]

Thanks, @filippoliverani!

[spaghetticode]

@filippoliverani can you please rebase with the recent changes in address.rb?
Otherwise, it looks good to me 👍

[peterberkenbosch]

how about we keep the first & lastname and add has_person_name dependency? This way we can still use firstname etc for integrations that need that but also just have a name field.

[DanielePalombo]

@spaghetticode I have rebased this PR

[filippoliverani]

@peterberkenbosch @kennyadsl @spaghetticode

how about we keep the first & lastname and add has_person_name dependency? This way we can still use firstname etc for integrations that need that but also just have a name field.

An important principle behind the whole refactoring is that a name in an address doesn't have to map to a person name, I'm not sure we should encourage users to think otherwise.
Internally we were already splitting a full name to make legacy address-name based integrations work, we can keep using the same technique.

Moreover, splitting a name in multiple components make sense only for some kind of names and for some locales, Basacamp's name_of_person works only for english names unfortunately.

I think that, in general, developers should add their opinionated or locale-dependent way of saving persons' names to their User models. Address names instead can be more flexible and future-proof if kept as generic as possible.

What do you think?

[kennyadsl]

As already suggested by someone else (maybe @elia), I also think we should have a name field on the user, which should represent how the user wants to be called. This could be optional so that we have a migration path for stores that want to keep that information present.

Also, we are still on time to keep both code paths (firstname+lastname and fullname) in Solidus 3, by removing the deprecation and allowing people to choose what works best in their store while we work on providing a better alternative for having a valid person name stored instead of using the shipping address name.

[filippoliverani]

Also, we are still on time to keep both code paths (firstname+lastname and fullname) in Solidus 3, by removing the deprecation and allowing people to choose what works best in their store while we work on providing a better alternative for having a valid person name stored instead of using the shipping address name.

If we want to keepfirstname+lastname in Address, we have to explicitly write and save them to two separate attributes, otherwise we won't know how they should be split in the first place. If this is what we want, we should disregard #3234 and revert the work done up to now.

[kennyadsl]

No wait, I didn't mean to revert what we did up to now 😅 , I meant (and I'm not even sure it's possible) to keep allowing both paths based on the use_combined_first_and_last_name_in_address preference value, until we have a clear alternative for those who were using the first name for specific reasons, like marketing emails or stuff like that. Of course, if we have a solution in mind we can go ahead, merge this, and release Solidus 3.0, but it sounds to me like something that a lot of stores will need to solve on their own before upgrading to Solidus 3.0.

[peterberkenbosch]

I'm late to the party around the naming, I don't really understand or see the need to make this generic tbh. What I see right now personally is that it is causing more problems then it's solving. I do like the idea of moving the person name (firstname, lastname, mabye even middlename) to the user. That seems to be semanticly more correct. However this will cause some issues on what to do when a user wants to ship to someone else. What do we put on the shipping information? We do need a name there. Just a generic name field on address does not make sense to me tbh. Again, I'm late to the party, I might have missed the initial discussion around that (reading up on that right now).

Either way, it's easy enough to manually override this or make a tiny extension that does what I need :) Just a bit confused about the need. Feel free to ignore the above, the PR itself looks good to me.

[peterberkenbosch]

I don't really understand or see the need to make this generic tbh.

And now I do.. 👍 any specific needs should be implemented by users indeed.