On 10/10/13 00:53 +0200, Albert Cervera i Areny wrote: > 2013/10/9 Cédric Krier <[email protected]>: > > On 09/10/13 19:15 +0200, Albert Cervera i Areny wrote: > >> It has come up several times the need of a party_relationship module > >> that allows to relate one party to another. > >> > >> I've just created a blueprint for it. Your comments will be very welcomed. > >> > >> > >> [1] https://code.google.com/p/tryton/wiki/PartyRelationship > > > > Some remarks: > > > > - I will keep the module name party_relationship but name the > > models: party.relation.type, party.relation. > > As a non-native English speaker both options (relation and > relationship) sound good to me. > > > - I don't like the xx_related Functon fields. I think the problem > > could be fixed by using a Model with a table_query using a UNION > > like: > > > > SELECT id, from, to, type FROM party_relation > > UNION > > SELECT -id AS 'id', to AS 'from, from AS 'to', reverse_type AS > > 'type' > > FROM party_relation > > > > rem: -id is perhaps not the best idea. > > reverse_type could come from a join on party_relation_type > > I thought of that too initially but I thought it would not be possible > to make it create/write/delete on such models. Is it supported simply > by overriding the appropriate methods? If so, it sounds got to me.
I don't think we have such example but I'm quite convident it should
work and if it doesn't we should make it work.
> Negative ids are "reserved" for new records on the client, aren't
> they?
Yes client uses negative ids for "not yet saved" records that's why I
made the remark.
> Maybe we should simply do "id + 100000" or something like that,
> although it looks very fragile for me.
Yes it is. I thought about a smarter way:
SELECT id * 2, … FROM party_relation
UNION
SELECT id * 2 + 1, … FROM party_relation
> It be cool if Tryton accepted
> strings as ids to ensure we can avoid collisions in such
> circumstances.
Ha the old surrogate vs natural key :-)
> > - I will add a start_date and end_date on party.relation with an
> > active Function field that deactivate the relation if current is
> > out of the limit.
>
> Nice idea.
>
> > - I'm wondering if party.relation.type should not simply have an
> > option link to the reverse party.relation.type
>
> I prefer the current design because it is easier to configure.
I don't like it because it rely on context and give a sens to the
relation. But the sens of the relation is already defined in
party.relation with the from-to
> > A question:
> >
> > - I don't understand the "embedded party.relationship" view.
>
> It is just the party.relationship tree (and form) view with two
> fields: type and to_related.
>
> In fact, we would probably NOT want any other views for
> party.relationship, but if desired a menu entry could be created. In
> that case, the view would contain "from", "type" and "to" fields.
Tryton takes care of that, we just have to define a generic view with
all fields. (Also using list instead of tree is clearer)
--
Cédric Krier
B2CK SPRL
Rue de Rotterdam, 4
4000 Liège
Belgium
Tel: +32 472 54 46 59
Email/Jabber: [email protected]
Website: http://www.b2ck.com/
pgpHam7Abd4nr.pgp
Description: PGP signature
