UI/Model: Split User.name into first_name and last_name

[clstaudt]

Test feedback:

Name: It might be helpful to add verbiage for whether a full name should be entered or just a first name. I feel the use of a person’s name varies from app to app, so a user might think twice when seeing only “your name” as I did. If both first and last name are significant for Tuttle, it also might be suggested to break these apart into two separate text fields for data capture (only if the distinction is needed somewhere else in the app). If not necessary, one text field for name is fine.

The field User.name should be split into User.first_name and User.last_name. The UI should ask for these separately. Changes need to be applied and tested throughout the app (e.g. in invoice templates).

[clstaudt]

@flamesjames Thanks for the suggestion. If you want to start contributing more to the project, I think this ticket would be an excellent place to start. It's a relatively small change that nonetheless goes across various parts of the code base.

[vlad-ed-git]

Unless there is a place in the project or contract or invoice or timetracking or any feature where it matters (and I don't think there is), there is no reason to try and distinguish between first or last or middle or surname. Chinese people for example write and say their surname first and last name second. So Zhong Weili is actually miss Weili and her last name is Zhong. In this case writing their name as First name + Last name in an invoice would be incorrect. So name should be just that, your name. Let the user decide how they want to be addressed. A hacker might send a contract with their famous nickname as the name! Somebody else might write only their first name, and another their first middle and last name. It matters not. It is what they expect to see when they send an invoice or in another feature.

[clstaudt]

I agree there are various topics to consider here, including internationalization. But these are the same for Contact, where we have first_name and last_name.

For now we have a "Western" bias in the project. A larger and more diverse set of users and contributors is the way to deal with that. Especially we are very biased towards the English language:

In this case writing their name as First name + Last name in an invoice would be incorrect.

It wouldn't be if the invoice is written in English, the only language we support for now. Zhong Weili should probably sign her invoice to the English-speaking client as Weili Zhong.

@vlad-ed-git If as a user I want my full name on the invoice but want my first name in the e-mail template for my invoice because full name would sound very formal, how would we implement that?

[vlad-ed-git]

It wouldn't be if the invoice is written in English, the only language we support for now. Zhong Weili should probably sign her invoice to the English-speaking client as Weili Zhong.

No! They write the same way regardless of the app language and it can't be expected to alter according to the client's language or with internalization settings! Zhong Weili (for example) writes Zhong Weili on her contract with the UFC , an American fight org. Same way my name is written as Vladimir Peter on every Chinese form at every institute here not 弗拉基米尔彼得.

If as a user I want my full name on the invoice but want my first name in the e-mail template for my invoice because full name would sound very formal, how would we implement that?

At what point in the app does the user specify that they want a different signing name? That is the point where they would set a sign_as name (which would be a different field on the user model altogether) . This has the extra benefit of not making the assumption that this name can only be either full name or first name . The user could want to use their surname or whatever else.

[flamesjames]

Unless there is a place in the project or contract or invoice or timetracking or any feature where it matters (and I don't think there is), there is no reason to try and distinguish between first or last or middle or surname. Chinese people for example write and say their surname first and last name second. So Zhong Weili is actually miss Weili and her last name is Zhong. In this case writing their name as First name + Last name in an invoice would be incorrect. So name should be just that, your name. Let the user decide how they want to be addressed. A hacker might send a contract with their famous nickname as the name! Somebody else might write only their first name, and another their first middle and last name. It matters not. It is what they expect to see when they send an invoice or in another feature.

@clstaudt @vlad-ed-git I agree with where both of you are coming from. I would say that if there is no specific need to separate out first and last name (for some technical feature, reporting, db querying, etc.), then we should keep it as a single field as vlad is saying above.

My only other concern I'll raise with having only a single field is not having as much flexibility with sorting (say for a "Contact Book" feature) or things of that nature.. the same can be said for search features within the app. If a feature that would depend on this be requested later down the line, this might cause a limitation. Just something to think about as well..

This link I read thru also suggests going for a single field, as it helps internationlization.

[clstaudt]

I am going to close this according to your suggestions.

If first name / last name is indeed culturally exclusive, then the change is due in the Contact class.