Tryton - Issues

 

Issue5853

Title Sort parties according to their relationship
Priority feature Status resolved
Superseder Nosy List ced, nicoe, pokoli, reviewbot, roundup-bot
Type feature request Components party_relationship
Assigned To ced Keywords review
Reviews 28731002
View: 28731002

Created on 2016-09-06.18:40:33 by nicoe, last changed by roundup-bot.

Messages
New changeset a72226bf5b3a by Cédric Krier in branch 'default':
Add proximity sorting of parties
https://hg.tryton.org/tryton-env/rev/a72226bf5b3a
New changeset d1109e268342 by Cédric Krier in branch 'default':
Add proximity sorting of parties
https://hg.tryton.org/modules/party_relationship/rev/d1109e268342
review28731002 updated at https://codereview.tryton.org/28731002/#ps278551002
review28731002 updated at https://codereview.tryton.org/28731002/#ps268911002
review28731002 updated at https://codereview.tryton.org/28731002/#ps268741002
review28731002 updated at https://codereview.tryton.org/28731002/#ps289131002
review28731002 updated at https://codereview.tryton.org/28731002/#ps278381003
msg54830 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2020-01-13.14:08:03
I have updated the review. I also changed the group by a "usages" MultiSelection field as now we have such field. I think it is better because the usage keys will be defined by other modules so it will be simpler to use a key string than fetching the XML id.
review28731002 updated at https://codereview.tryton.org/28731002/#ps50001
review28731002 updated at https://codereview.tryton.org/28731002/#ps40001
review28731002 updated at https://codereview.tryton.org/28731002/#ps20001
msg28364 (view) Author: [hidden] (nicoe) (Tryton committer) Date: 2016-09-07.13:17:33
* Cédric Krier  [2016-09-07 12:35 +0200]: 
>
>Cédric Krier <cedric.krier@b2ck.com> added the comment:
>
>On 2016-09-07 11:46, Nicolas Évrard wrote:
>> * Sergi Almacellas Abellana  [2016-09-07 10:04 +0200]:
>> >I agree that we should be able to apply a factor on each relation
>> >type, as different relations may have different proximity meanings.
>>
>> We discussed it with Cédric today and we're thinking about adding
>> relationship groups and use those to get the factor to apply.
>>
>> I think it should be a M2M field. The developer will be able to
>> specify in the context the weight to give to each group.
>
>I do not think we need to be able to use many group for one search.
>So I think the group will only be there to filter valid relation type
>for the computation of the distance.

Then there's no need for a weight neither.
msg28363 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2016-09-07.12:35:09
On 2016-09-07 11:46, Nicolas Évrard wrote:
> * Sergi Almacellas Abellana  [2016-09-07 10:04 +0200]: 
> >I agree that we should be able to apply a factor on each relation
> >type, as different relations may have different proximity meanings.
> 
> We discussed it with Cédric today and we're thinking about adding
> relationship groups and use those to get the factor to apply.
> 
> I think it should be a M2M field. The developer will be able to
> specify in the context the weight to give to each group.

I do not think we need to be able to use many group for one search.
So I think the group will only be there to filter valid relation type
for the computation of the distance.
msg28362 (view) Author: [hidden] (nicoe) (Tryton committer) Date: 2016-09-07.11:46:43
* Sergi Almacellas Abellana  [2016-09-07 10:04 +0200]: 

>I agree that we should be able to apply a factor on each relation
>type, as different relations may have different proximity meanings.

We discussed it with Cédric today and we're thinking about adding
relationship groups and use those to get the factor to apply.

I think it should be a M2M field. The developer will be able to
specify in the context the weight to give to each group.
msg28361 (view) Author: [hidden] (pokoli) (Tryton committer) (Tryton translator) Date: 2016-09-07.10:04:51
I agree that we should be able to apply a factor on each relation type, as different relations may have different proximity meanings.
msg28360 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2016-09-06.22:28:59
Do you think it is possible to make it more generic?
For example, it could be interesting to use a concept of distance between two parties. And we could apply different factor to each relation type.
New review28731002 at https://codereview.tryton.org/28731002/#ps1
msg28358 (view) Author: [hidden] (nicoe) (Tryton committer) Date: 2016-09-06.18:43:35
review https://tryton-rietveld.appspot.com/28731002 propose a design for this functionality.

I also propose to add another context value to specify the list of the relation types to take into account (if empty all types will be used).
msg28357 (view) Author: [hidden] (nicoe) (Tryton committer) Date: 2016-09-06.18:40:33
Given that party_relationship defines the relationship between some parties it would be interesting to use this information to selectively sort the parties according to their proximity.

The idea is to use the context to trigger this functionnality by specifying to which party the relationship proximity should be computed.
History
Date User Action Args
2020-03-07 00:27:40roundup-botsetmessages: + msg56142
2020-03-07 00:27:31roundup-botsetstatus: testing -> resolved
nosy: + roundup-bot
messages: + msg56141
2020-02-16 11:37:32reviewbotsetmessages: + msg55393
2020-02-15 01:59:33reviewbotsetmessages: + msg55379
2020-01-15 15:32:16reviewbotsetmessages: + msg54878
2020-01-14 17:56:21cedlinkissue8992 superseder
2020-01-14 17:56:00reviewbotsetmessages: + msg54869
2020-01-13 14:31:34reviewbotsetmessages: + msg54831
2020-01-13 14:08:03cedsetstatus: in-progress -> testing
messages: + msg54830
2020-01-13 12:00:15cedsetstatus: testing -> in-progress
assignedto: nicoe -> ced

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