Party's rec_name should not search on bank accounts

The bank account module overrides party's rec_name to also search by bank account:

http://hg.tryton.org/modules/bank/file/tip/party.py#l17

If really desired, I think this could be implemented either on another module or depending on the context because only in very few circumstances will the user want to search the party by its bank account number.

Currently, searching the party by its code (ie. 54321) can return parties that have a bank account that contains that number which is very surprising for the user.

added bank + 1 deleted label

+1

added 1 deleted label and removed 1 deleted label

I think it is a good feature to search party by all identifier available.
I think here the problem is to not make distinguishing enough the party code. Having a specific prefix (but small) would make searching on party code much more efficient.

2018-04-21 14:21 GMT+02:00 Cédric Krier @tryton.org>:
>
> Cédric Krier <cedric.krier@b2ck.com> added the comment:
>
> I think it is a good feature to search party by all identifier available.
> I think here the problem is to not make distinguishing enough the party code. Having a specific prefix (but small) would make searching on party code much more efficient.

In Tryton we tend to search only for those fields that are seen in the
tree view and AFAIK that is because the user should be able to check
the search is correct. But in this case, we're returning very
suprising results.

If I search "0081" I can get hundreds of results just because it is
the number of a very frequent Spanish Bank. I don't think anyone will
ever want to get that result when creating a sale. If I search "0081"
I'm certainly not searching for a bank account.

If the context idea is not satisfactory an alternative that it comes
to mind is searching on account numbers only when the provided string
is long enough. For example, spanish bank accounts are 20 digits so
searching on bank accounts when the number is 20 digits makes sense
but not when it's smaller because as said, it can return too many
results that I cannot easily check.

Though I still can not understand the use case for searching on bank
account when searching for a party on a sale or purchase.

>
> ----------
> nosy: +ced
>
> _______________________________________________
> Tryton issue tracker @tryton.org>
> <https://bugs.tryton.org/#7347>
> _______________________________________________

I'm wondering if a bank account is really an identifier of the party. I haven't seen any company use the bank account to identify somebody but yes it's name, vat or customer code.

I share the same feeling as Albert. What's the use case to identify a party by it's bank account?

I agree with Sergi and Albert. If there is really a need for the bank account in search_rec_name it should be done in a custom module.

On 2018-04-25 10:52, Sergi Almacellas Abellana wrote:
> I'm wondering if a bank account is really an identifier of the party. I haven't seen any company use the bank account to identify somebody but yes it's name, vat or customer code.

Use case: statement where often the only identifier available is the
bank number.

The search_rec_name already searches for identifiers, contact mechanisms so for me the bank account number is the same and it should not be disqualified.
Indeed as I said in msg40314, the problem is too have not distinguished enough codes/numbers. The prefix suggested is probably not enough.
But I think we can take the problem in another way, the fact that codes/numbers are not distinguishable enough is mainly because we do an 'ilike %<value>%' on them. For name/sentence it makes sense, but I do not think for codes/numbers. It will be very unusual that a user will type the VAT code or the bank account number starting in the middle. So I propose that the search_rec_name remove the starting '%' when searching on codes/numbers and keep the queried value as-is for names.

msg40401 seems a good solution for me but I'm wondering if we should also apply it for other modules (for example product code) to keep a coherent behaviour.

added type::behavior label

On 2018-04-27 09:17, Sergi Almacellas Abellana wrote:
> msg40401 seems a good solution for me but I'm wondering if we should also apply it for other modules (for example product code) to keep a coherent behaviour.

I would say yes.

Here is review64541002 which implements it.

assigned to @pokoli

added accounting country party product purchasing + 1 deleted label and removed 1 deleted label

review64541002 updated at https://codereview.tryton.org/64541002/#ps1

review64541002 updated at https://codereview.tryton.org/64541002/#ps20001

review64541002 updated at https://codereview.tryton.org/64541002/#ps40001

review64541002 updated at https://codereview.tryton.org/64541002/#ps60001

review64541002 updated at https://codereview.tryton.org/64541002/#ps80001