Sort parties according to their relationship

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.

assigned to @nicoe

added party type::feature + 1 deleted label

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).

New review28731002 at https://codereview.tryton.org/28731002/#ps1

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.

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

* 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.

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.

* 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.

review28731002 updated at https://codereview.tryton.org/28731002/#ps20001

review28731002 updated at https://codereview.tryton.org/28731002/#ps40001

review28731002 updated at https://codereview.tryton.org/28731002/#ps50001

assigned to @ced and unassigned @nicoe

added 1 deleted label and removed 1 deleted label

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.

added 1 deleted label and removed 1 deleted label

review28731002 updated at https://codereview.tryton.org/28731002/#ps278381003

review28731002 updated at https://codereview.tryton.org/28731002/#ps289131002

review28731002 updated at https://codereview.tryton.org/28731002/#ps268741002

review28731002 updated at https://codereview.tryton.org/28731002/#ps268911002