Tryton - Issues

 

Issue7347

Title Party's rec_name should not search on bank accounts
Priority feature Status chatting
Superseder Nosy List Timitos, albertca, ced, pokoli, resteve
Type behavior Components bank
Assigned To Keywords
Reviews

Created on 2018-04-13.10:15:56 by albertca, last changed by ced.

Messages
msg40429 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2018-04-27.12:20:07
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.
msg40427 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2018-04-27.09:17:19
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.
msg40401 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2018-04-25.14:12:09
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.
msg40393 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2018-04-25.11:40:08
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.
msg40390 (view) Author: [hidden] (Timitos) Date: 2018-04-25.10:57:32
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.
msg40389 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2018-04-25.10:52:42
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?
msg40348 (view) Author: [hidden] (albertca) (Tryton committer) (Tryton translator) Date: 2018-04-24.00:01:15
2018-04-21 14:21 GMT+02:00 Cédric Krier <issue_tracker@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 <issue_tracker@tryton.org>
> <https://bugs.tryton.org/issue7347>
> _______________________________________________
msg40314 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2018-04-21.14:21:26
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.
msg39950 (view) Author: [hidden] (resteve) Date: 2018-04-13.11:12:43
+1
msg39949 (view) Author: [hidden] (albertca) (Tryton committer) (Tryton translator) Date: 2018-04-13.10:15:55
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.
History
Date User Action Args
2018-04-27 12:20:07cedsetmessages: + msg40429
2018-04-27 09:17:19pokolisettype: behavior
messages: + msg40427
2018-04-25 14:12:10cedsetmessages: + msg40401
2018-04-25 11:40:08cedsetmessages: + msg40393
2018-04-25 10:57:32Timitossetnosy: + Timitos
messages: + msg40390
2018-04-25 10:52:43pokolisetmessages: + msg40389
2018-04-24 00:01:20albertcasetmessages: + msg40348
2018-04-21 14:21:26cedsetnosy: + ced
messages: + msg40314
2018-04-13 11:12:43restevesetstatus: unread -> chatting
nosy: + resteve
messages: + msg39950
2018-04-13 11:04:47pokolisetnosy: + pokoli

Showing 10 items. Show all history (warning: this could be VERY long)