Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restore firstname lastname on address #6159

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

fthobe
Copy link
Contributor

@fthobe fthobe commented Feb 24, 2025

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:

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.

- Unignored `firstname` and `lastname` field in the address model.
- Updated validations, attributes, and views to handle 'firstname' and 'lastname' separately.
- Modified tests, factories, and locales to align with the new structure.
- Introduced a 'set_full_name' method callback to concatenate 'firstname' and 'lastname' for backward compatibility.
Update the address handling logic in the APIs and tests to for 'firstname' and 'lastname' fields, instead of using a single 'name' field.
- Update the backend logic to separate 'name', 'firstname' and 'lastname' for better data handling.
- Adjusted user and address forms, search functionality, and related views to use the new fields.
Update the address handling logic in the admin components and tests for 'firstname' and 'lastname' fields,
instead of using a single 'name' field.
@fthobe fthobe requested a review from a team as a code owner February 24, 2025 16:28
@github-actions github-actions bot added changelog:solidus_api Changes to the solidus_api gem changelog:solidus_backend Changes to the solidus_backend gem changelog:solidus_core Changes to the solidus_core gem changelog:solidus_sample Changes to the solidus_sample gem changelog:solidus_admin labels Feb 24, 2025
@mamhoff
Copy link
Contributor

mamhoff commented Feb 25, 2025

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog:solidus_admin changelog:solidus_api Changes to the solidus_api gem changelog:solidus_backend Changes to the solidus_backend gem changelog:solidus_core Changes to the solidus_core gem changelog:solidus_sample Changes to the solidus_sample gem
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants