Restore firstname lastname on address

[fthobe]

Summary

Description:
This PR introduces updates to the address model, admin components, backend, API, and associated logic to handle firstname and lastname as separate fields, replacing the previous name field providing backwards compatibility to existing implementations of name. The updates aim to improve data handling and increase clarity when working with user and address-related data.

For the purpose of not breaking name and provide a smooth transistion if first and last name are used name is compiled with the concatenated value allowing the fields to coexist.

Changes:
Admin: Updated admin components to use firstname and lastname fields separately in place of the name field.
Backend: Modified backend logic to separate name into firstname and lastname, adjusting user and address forms, search functionality, and related views.
API: Updated the API and its associated tests to manage firstname and lastname fields separately, replacing the name field.
Core: Unignored the firstname and lastname fields in the address model. Introduced a set_full_name method for backward compatibility, concatenating firstname and lastname. Updated tests, factories, and locales to align with the new model structure.

Checklist

Check out our PR guidelines for more details.

The following are mandatory for all PRs:

• I agree that my PR will be published under the same license as Solidus.
• I have written a thorough PR description.
• I have kept my commits small and atomic.
• I have used clear, explanatory commit messages.

The following are not always needed:

• 📖 I have updated the README to account for my changes.
• 📑 I have documented new code with YARD.
• 🛣️ I have opened a PR to update the guides.
• ✅ I have added automated tests to cover my changes.
• 📸 I have attached screenshots to demo visual changes.

[mamhoff]

I'd like this to be optional. Either dependent on the store, or as a global configuration - something like

store.separate_first_and_last_name

or

Spree::Config.separate_first_and_last_name

The way it's currently implemented, the store I work with that works perfectly fine with a single name field will have their name field overwritten with empty strings, because there is no condition that stops the address model from overwriting name.

Furthermore, I think firstname can be optional. Shopify has implemented it like that, too.

The configuration can also be used to display / hide the name or firstname/lastname fields. Right now we have a situation where we can have conflicting fields, which I'm not a fan of.

[jarednorman]

Yeah, I'm with @mamhoff. There ware services out there that handle name as a unified field, which is preferable due to... reality. That said, a huge number of services that expect separate fields, and other reasons why separate fields are preferable for many orgs. Option to choose needs to remain, even if it's kind of annoying from a maintenance perspective. The alternative creates too much work for existing stores working with unified names.

[fthobe]

Yeah, I'm with @mamhoff. There ware services out there that handle name as a unified field, which is preferable due to... reality.

@jarednorman
I know it's from a technical point of view challenging. I hope I outlined the reasoning in the tickets for anybodies satisfaction on the reasoning why this should be done. The current default configuration makes it very hard to reach compliance in multiple large European markets.

@mamhoff
Actually as you can see also by the tests the name is only overwritten if fname and lname are not empty. We will roll another check on that.

Right now if not used first name and last name have no impact on name. This is a very aggressive stance, I'd love to call it a strongly opinionated default incentevize migrate back to these fields also because the pain of splitting those fields is much bigger than the pain of joining them. If that approach has no chance for majority we can put it behind a configuration flag, I wouldn't necessarily motivate people to fragment the DB structure that way but I can understand your point.

@tvdeyen @jarednorman @kennyadsl
We will align this thing with the modus operandi you prefer, could you three decide what to do? If you could also check if anything is wrong with the code itself we might be able to upstream this in the fewest possible feedback cycles. Mayur did his best to align with quality requirements regarding the PR and commit.

[tvdeyen]

I am imagining a `firstname` attribute and use the current `name` attribute as either the full name or last name. The first-name should not be mandatory by default and it should be probably hidden in forms. That way we do not have three hard to align fields and reflect what already is the case in ie. Germany where most address forms only have the (last) name attribute mandatory. All of this should be a - by default disabled - feature toggle (ie. `enable_address_firstname`). Maybe we even have a second toggle for showing / hiding the first-name field and validation separately.

[fthobe]

I am imagining a firstname attribute and use the current name attribute as either the full name or last name.
ok, that's not stupid as we can reuse most of the stuff with least effort for everybody.

@jarednorman @kennyadsl is that something you can get on board with?

[kennyadsl]

If we have both firstname and name, I think we only need one preference: if the store wants the validation on the firstname. If they don't want to use it, they can still remove the field from the forms where it's displayed, or just leave it empty.

On a side note, it's the same option that Shopify offers:

I'm ok with this path, as soon as the solution is backward compatible.

[fthobe]

Ok, so here's probably the easiest way to do it then:

• we do not reintroduce last name
• we use name as last name
• we reintroduce first name
• we toggle a switch in admin to define the preference

Is that ok for everybody?
@JustShah @tvdeyen @jarednorman

[tvdeyen]

[...] they can still remove the field from the forms where it's displayed, or just leave it empty.

This is true for the starter front end maybe, but not for admin forms. I suggest just displaying/hiding the field on the preference then.

If we keep the field and only require one of them, we will end with inconsistent data.

Examples

firstname	name*
	John Doe
Jane	Doe

*) required

vs.

firstname*	name*
John	Doe
Jane	Doe

*) required

and

name*
John Doe
Jane Doe

*) required

Ok, so here's probably the easiest way to do it then:

• we do not reintroduce last name
• we use name as last name
• we reintroduce first name
• we toggle a switch in admin to define the preference

I would prefer to use Spree::Config instead of a switch in the admin.

Oh, and maybe we should call the field "given_name"? 🤔

https://www.dictionary.com/browse/first%20name

[fthobe]

@tvdeyen I don't want to argue about naming schemes, buuuuuuuuuuuttttt:

Oh, and maybe we should call the field "given_name"? 🤔

Microsoft: first_name
Google: first_name
Shopify: first_name
BigCommerce: first_name

I would prefer to use Spree::Config instead of a switch in the admin.

I know you would :) but can we try to find something for newbies that is friendly.