Names order configuration options

[antespi]

Hi everyone,

We want to add a new feature in OCA/partner-contact: Odoo admin configures partner names orders when partner_firstname or partner_second_lastname addons are installed

We have two ways to do it:

1. Add this feature in partner_firstname and partner_second_lastname addons
2. Make two addons that add this feature:
   • partner_firstname_order
   • partner_second_lastname_order

I prefer the first way

BTW, there are several ways to allow Odoo admin to configure names order, for example with a partner: María José Espinosa de los Monteros we will have this:

• firstname: María José
• lastname: Espinosa
• second_lastname: de los Monteros

We can allow these possible configurations:

• last_first (default because it is the current behavior): Espinosa de los Monteros María José
• first_last: María José Espinosa de los Monteros
• last_first_coma: Espinosa de los Monteros, María José

An we have several ways to configure this:

1. Selection list in res.company: Then all partner in this company share this name order.
2. Selection list in Settings > Configuration > Sales: Then all partners in all companies of this Odoo instance share this name order
3. Selection list in res.partner: Then each partner can select the order he wants and we can define a default order in res.company or Settings > Configuration > Sales.

I propose 1, because I think it should be a company policy.

We can add a migration script in order to migrate all instances to the default configuration (last_first).

Any opinion or suggestion?

[elicoidal]

This should be part of localization (the address format in the country) which might conflict with your current proposal.
If any, I would add a setting in the country better than in the company (which can relate in multiple languages).

[antespi]

@elicoidal but this implies a module per localization, most of them implementing the same, isn't it?

[elicoidal]

@antespi You could have a default module for common behavior and have an extra per localization.

Where I am not completely sure is whether it should be at country level or at language level... (I think more the later actually)

[antespi]

@elicoidal This approach doesn't allow to Odoo Admin to configure the behavior he wants. I'm imaging a german customer that wants one order and other german customer with other, both have germany localization.

Are you proposing to configure this for all partners in all companies using addons?. If so, I don't understand why use language or country model.

BTW, maybe language is a good place where configure names order, but sometimes partner has no lang configured. What could happen then?

[elicoidal]

@antespi I dont think language order/placement is an administrator decision but rather a localization decision.
Nevertheless, even if it would be, you can easily design the solution to fit all needs:

• add to the language a field similar to address in the country
• add the same at partner level
• have a default one defined in property or system parameter or company.
  Have a rule:
• If the field is defined in the partner, use it, otherwise,
• If the field is defined in the language you use it otherwise,
• you use the default one

[antespi]

Thanks @elicoidal your second propose (use lang model to add a field for defining names order) sounds good for me. And the rule for defining default behavior is flexible enought

Any other opinion? The goal of this issue is get the most consensual way to do it, thanks.

[rafaelbn]

My opinion is:

Need is clear, it must be a module in partner-contact and not in localization. This is not a localization need.

Apple could want to have names like "Jobs, Steve" and not Steve Jobs.
Same, any customer could want to have in CRM names like "Caudal, Eric"

Who is interested, customer which would like to change order. Customer could use one or both of next modules:

• https://github.com/OCA/partner-contact/tree/8.0/partner_firstname
• https://github.com/OCA/partner-contact/tree/8.0/partner_second_lastname

I don't think any customer will say:

• I would like that my users could choose the order
• I would like that each partner have diferent order

I think customer could say I would like to change order in my CRM for purposes like, letters, exports, lists

In other CRMs and Office Suites you can choose this, is very common. But you choose this globally. Ex. Dynamics, Outlook, ...

cc @yajo @bwrsandman @pedrobaeza

[hbrunn]

In the Dutch version of this, we do something quite similar: https://github.com/OCA/l10n-netherlands/blob/8.0/l10n_nl_partner_name/model/res_partner.py#L45

If we read the name template from a field on the language, we're done I'd say.

[JordiBForgeFlow]

Oracle defines the name format as dependent of country and language at the same time (data that is held at country + language they call it locale):
http://docs.oracle.com/cd/E29505_01/fusionapps.1111/e20433/F490064AN2F73D.htm

I think that it is more of a country setting:
When you print an invoice where the destination is an egyptian customer, regardless if the invoice is written in egyptian or plain english, is that the person that reads the invoice in Egypt is not confused by the order of the name, the same as you need to respect the format of the address for Egypt.

While in Odoo you will have all the countries defined, you might only have a few languages installed.

[antespi]

Well, after listening all opinions we can now vote for one, then

A. Implementation

1. Localization addon define names order, one common addon and one addon for specific localization
2. Extension addons add configuration fields, those addons inherit from partner_firstname and partner_second_lastname
3. Configuration fields are added to partner_firstname and partner_second_lastname

B. Configuration fields (only if A2 or A3)

1. Added to language (res.lang)
2. Added to country (res.country)
3. Added to company (res.company)
4. Added to partner (res.partner)
5. Added to general settings (base.config.settings)

C. Selection algorithm (only if A2 or A3)

1. Use partner configuration (partner.names_order or partner.lang or partner.country_id), fallback to company, fallback to general setting, defaults to last_first (current behavior)
2. Use company configuration, defaults to last_first (current behavior)
3. Use general setting, defaults to last_first (current behavior)

Thanks for your opinions

[antespi]

My vote is:

• A3, because is simpler and this feature is close to partner_firstname and partner_second_lastname current features
• B3, because I think that this is a decision of company owner. All our customers wants to define this as a company policy
• C2

[rafaelbn]

👍 agree

[carlosdauden]

A3
B2

[elicoidal]

A1

[pedrobaeza]

A3, B5, C3, because you will have problems defining a configuration per company because the display_name is not a property (and it shouldn't be), so it won't behave correctly when a partner is shared across multiple companies.

[JordiBForgeFlow]

A3, B2. The reason being, the format of the name is a cultural aspect of the country that this person belongs to, not a policy of a company.

If you send an invoice to a US customer as "Sebastian Bach, Johan", it will not be well perceived by the recipient of the invoice.

So I agree with @elicoidal that should be a country setting.

[yajo]

I live in a country where the "official" template would be last1 last2, first, but most people prefer first last1 last2, so it should be configurable, either by language or by company.

But if a user must remember which company is the partner in, or which language it chose, and has to remember how to write each first/last names combination, that will lead to problems for sure, and @pedrobaeza's and @jbeficent's comments are quite insightful IMO.

To fix all those problems, I think the best way would be to make it depend on current context lang. But that would force you to recalculate name on each request instead of saving it to the database, and that would slow too much almost any Odoo operation.

So here comes my question: Can computed fields be translatable? If so:

A3 + B1 + C4.

Being C4 = name field is marked as translatable, and writes translations to all installed languages when updated. Algorithm selection depends on lang in current context.

This way, DB searches will be quick, a user will always write names in the way his language is set up, a company can set up custom formats per lang, and a customer will receive documents with the format preferred in their language.

[pedrobaeza]

Can computed fields be translatable?

I'm afraid not, or at least not the regular way.

[elicoidal]

I think this is mostly a reporting issue, similar to addresses.
You need a function to deliver a string with the result of the pattern.
You can have that function result displayed in the form view.
Whenever you have a report, you get the result.
You donot need to translate anything, just display according to pattern.
Is there anything I am missing?

[antespi]

According to @elicoidal, @yajo and @pedrobaeza then we have two scenarios:

1. Name displayed in any Odoo form/tree view, where user (Odoo operator) search, list, order, select, add, edit, ... Here criteria is owner company policy. So Odoo Admin configures it as his internal policy.
2. Name displayed in reports (sale orders, invoices, ..., mostly PDFs), where user (customer, partner) reads his name and we don't want that he feels confused. Then it is a translating issue depending to user (customer, partner) language or country.

Here we are discussing the first point. After this, we can go with second point. Everyone agree?

[yajo]

I think we are discussing both. Partner's name is by far the most used field everywhere. The only way to know what layout is expected is context, that's why I suggest using that.

The problem with what @elicoidal says is that you cannot use a function every time you search for a partner, it's very time-consuming. You need to have a value stored in the database to allow fast searches. And partner searches are used too often.

And the problem with reports is that there are a lot. You cannot change all one of them that call .name_get() or .name for another thing, it's too much work. You simply have to make those functions return what the recipient expects.

Can computed fields be translatable?

I'm afraid not, or at least not the regular way.

Do you mean there is another way? If so, even if it is complicated, I still think it will be the best solution.

If there is absolutely no way, then my vote goes for A3 + B1. Companies can still customize the layout for the main language they use.

BTW, I forgot to mention one detail: all current tests must pass (at least in en_US lang).

[pedrobaeza]

The other way is very nasty: to write directly to the translations table, which invalidates cache system and other possible side effects.

[yajo]

That's what I was thinking in the first place. Good tests should ensure no strange things happen. And I hope many methods from core translation system could be reused (still blind guess though). My vote goes for that then.

[antespi]

@yajo think in impact to database where you have 50.000 partners and 4 languages, then you'll have at least 200.000 entries in ir.translation table only for saving partners name.

[yajo]

What's the problem? Disk is cheap, CPU not. Think about calling a python function 50.000 times each time you want to search a partner's name.

[elicoidal]

@yajo Why would you need to modify your name search? Your name_search is not impacted by my proposal.
I dont even consider changing the name_get (which is a killer in CPU even if this would be the most complete solution).
My solution relies better on displaying the result of a function as additional field in form view (no impact in CPU) or tree view (impact if you display 10000 lines at once) besides the firstname+lastname.
On report, actually impact in CPU is low for SO but could potentially be high if you have to calculate a full list of contacts.
Now we actually need to display this change only in very few reports where it is important to have the last name/first name of the contact (this is not even the company name) properly displayed so this is not so many reports (eg: SO or email templates).
I would try to limit this kind of change where it is really important, not to impact performance or have to rewrite all reports.

[yajo]

@elicoidal You cannot use a different string for searching and for displaying, because users will try to search by what they see. Example: View displays name as Sheldon Cooper, but DB stores it as Cooper Sheldon; users will have a problem when they search for Sheldon Cooper: it will not be found.

And if you do not change the name field, then there is no benefit in all of this. That's exactly the goal, because otherwise you will have inconsistent displaying of names, or you will need to change reports and views almost everywhere the name field is used, and it's used very often.

[elicoidal]

@yajo I understand but this is a matter of balance between performance and usability here, not what I would like in the perfect world (which is a stored value of the expected format with search function, propagated in all views and reports)

[yajo]

Well we are discussing here to get to the best solution, the closest one to "perfect". Anyway using different values for display and search is not a good idea IMHO, not usable. Users need to be able to search by what they see.

[antespi]

Hi everyone,

Thanks all for your opinions. IMHO, this has been a good collaboration exercise.

By now we have implement a minimal (but functional) approach: Configure names order at system level. You can review here: #227

After this, anyone can go forward and implement any other approach commented here, in OCA or in a custom addon for fitting customer needs, now it's simpler because:

• You can add more patterns at system level extending base.config.settings._partner_names_order_selection method
• You can change the way names order setting is calculated and implement a cascade selection extending res.partner._get_names_order method
• You can define a custom algorithm of computing name from its parts extending res.partner._get_computed_name. As you can do now.
• You can define a custom inverse function to split name in its parts extending res.partner._get_inverse_name method. As you can do now.

[gokhanerdogdu]

Hello,

When will this be released for V9?

[yajo]

Sorry, this is fixed in #227. Please somebody close this.