multiple dynamic relationships

This is gonna be a long one!;)

There is one thing I am missing in the platform – multiple dynamic relationships. I explain better:

Let’s say I have an application with the following bundles: Accounts, Contacts, Tasks, Meetings, Emails, Users.

What I’d like to achieve is to be able to create an ‘item’ in one of these bundles and associate it to one or more items in the other bundles. Specifically, I create a task and I want to associate it to one or more Accounts AND to one or more Users AND one or more Meetings … I think you got the point.

Moreover, I do not want to do this by hard coding these associations in the involved entities but I’d like to leverage on the entityConfig/entityExtend bundles and use Migration to activate the associations (by creating manyToMany in between tables).

So, that at the end, by making the necessary modifications to the views I can display all related entities (Accounts, Users, Meetings) under my Task and similarly all related Tasks under a specific Account, User and Meeting.

I have actually created a Migration extension (which does a ‘$this->extendExtension->addManyToManyRelation…’) to start off and by ‘activating’ it on my AccountBundle and I can see that it creates the ManyToMany JoinTable with the keys and all and in the app/cache/dev/oro_entities/Extend/Entity/EX_MekitAccountBundle_Account.php the property and the getter/setter methods were created correctly.

I was about to get into big time coding when suddenly it struck me!
Am I reinventing the wheel here?

Is ActivityBundle for this purpose?

Would I be able to do what is described above by declaring all my entities as “activity entity” by following what is described here?

Thanks
a\

---

oro/platform(1.6.2) + oro/doctrine-extensions(1.0.7) + symfony/symfony(v2.3.27)

Topic

[Dima SorokaKeymaster]

Hi

This is exactly what we are doing with activities. You already can see how it works with tasks, events, emails, calls and notes. So far we enabled activities management on entity level and showing activity list.

Next steps are to show all activity relations on the activity record level as well as allow to define relations from activity form.

Please take a look into latest updates and let us know if this is something you are looking for.

Thanks

[jakabadambalazsParticipant]

Thanks @Soroka,
Yes I looked into it yesterday. Some questions:

1) when you say “…show all activity relations on the activity record level…” – you mean show on the task view the list of all accounts (ie. the relationship from the the inverse side)?

2) for now (i am on platform 1.4.x-dev) when I do $activityExtension->addActivityAssociation($schema, 'my_activity_entity', 'my_target_entity'); I see that in the “EX_” Extend class extended by “my_activity_entity” I have the property and the methods to manage this relationship (this is the owning side I guess as far as ORM goes) but not on the other side. So, these relationships are not ManyToMany Bidirectional? Is this what you are working on?

I’ll definitely look into the dev-master branch because I think this is a crucial point of the platform. And maybe I can help out if not with code with ideas.

For me, the way I see CRM applications in general, is that there should be the possibility to “relate” any entity to others (the main entities like accounts, contacts, tasks etc – exactly the way you are doing this) – and now you are doing this with ActivityBundle because you are concentrating on ‘activities’ but let’s say tomorrow I will add a DomainBundle to be able track domain expiry dates/passwords/etc – and I’d have to declare my “domain” entity as an activity.
From what I understand so far, it should work (with the enhancements you are working on now) just like the other activities. Maybe the only thing that is a bit strange is that it would not be an activity. What I am trying to say is that maybe the naming “ActivityBundle” and the concept of “activity” could be a bit awkward in the future – maybe “RelationshipBundle” and ‘relationship’ concept, being more generic, would fit better. But hey! I can live with it.

---

oro/platform(1.6.2) + oro/doctrine-extensions(1.0.7) + symfony/symfony(v2.3.27)

[Dima SorokaKeymaster]

#1 – yes, show on the task level associated entities
#2 – please check dev-master, we did some changes to enable more activities

I don’t think defining each entity as activity will be a right solution as each relation usually has particular business case behind it and should be handled in proper way. In case of activity we are covering customer communication with possibility to assign it to any context. This is why we handled the relation in a special way.

Could you please describe a couple of cases not related to activity where you see the value of such “dynamic” relation?

Thanks

[jakabadambalazsParticipant]

Hi @Soroka,

Yes, I do agree that relationships must be handled in a proper way and it should be the task of the specific bundle do do that.

Let me try to think aloud to see if it makes sense (even to me). Let’s reason with activities first: Let’s stick to bundles: Accounts(A), Contacts(C), Emails(E), Tasks(T) and Calls(K).

Use case: I have Account A1 with two contacts C1 and C2. I receive an email(E1) from C1 saying that he needs a price quote but that he wants to be called by phone beforehand on a specific date/time. So I register a phone call(K1) for that date to remind myself. After the phone call(K1) we agree that in 5 days I’d send him(C1) and to C2 an email(E2) what he requested. So I register this as a task(T1).

What I’d like to see is:

1) on Account A:
a) list of emails exchanged with A and with C1 and with C2
b) list of calls exchanged with A and with C1 and with C2
c) list of tasks where A, C1, C2 are involved

2) on Contact C1 (same for C2):
a) list of emails exchanged with C1
b) list of calls exchanged with C1
c) list of tasks where C1 is involved

3) on Email E1:
a) list of Accounts and Contacts involved
b) list of Calls(K1)
c) list of Tasks(T1)

4) on Call K1:
a) list of Accounts and Contacts involved
b) list of Emails involved – in this case E1
c) list of Tasks(T1)

5) on Task T1:
a) list of Accounts and Contacts involved
b) list of Emails (E1 and when I send E2 I want to reference this task)
c) list of Calls (K1)

Here we would have bi-directional manyToMany relationships in between all entities. The way you are constructing the ActivityBundle does/will do this between an Account/Contact and an activity but will NOT give the possibility to do this between activities themselves. That is: I will be able to see 5a) but not 5b) or 5c).

Let’s look at Task T1:
I think it would be important to be able to view a task (as well as a call) and have the situation at hand on one screen. That is:
– see why this task exist (there was an mail(E1) requesting this)
– see who this task involves (A1, C1, [C2])
– see the story of this task(what has been done): calls(K1)

So this would mean that an activity should be able to reference another activity.

And to add some complexity to this ;) activities (especially tasks) should be self referencing as well: If I have the task T1, and for me to be able to make the price quote, I need to do other stuff like ask my supplier to do me a special price, I’d create a sub-task T2 connected to T1. And on T2 I could have calls, mails, etc.

And I think this could/(should?) be extendable to future entities as well. If a create a PriceQuoteBundle with entity Pricequote to complete my task T1 I should:
1) create Pricequote(PQ1)
2) send email E2

So when I create PQ1 I’d like to be able to reference the task T1 – so if some time from now I view that task I will be able to see the full story and from T1 I will be able to quickly jump to PQ1.

And when I send E2, again I’d need to reference both T1 and PQ1 for the same reason.

Does this make sense to you?

---

oro/platform(1.6.2) + oro/doctrine-extensions(1.0.7) + symfony/symfony(v2.3.27)

[Dima SorokaKeymaster]

Thanks for detail use case, this is very helpful.
We’ll update our backlog based on your scenario, as it has a lot of sense in terms of activities visibility and tractability.

As for general reference, please take a look into EntityExtend associations and NotesBundle as a use case for this. This functionality is more generic than activity and covers topic of many-to-many dynamic relationship so you could build price quote base on it, not on activity.

[jakabadambalazsParticipant]

Hi @Soroka,

(Here is the repo if you need to check something: repo)

I think I am getting somewhere with this. I try to describe quickly what I have done because I have a question related to this.

I now have a RelationshipBundle which is responsible for handling these synamic relationships.
I have created a “central” entity called “ReferenceableElement” which has circular(self-referencing) ManyToMany relationship to itself:

/** * @ORM\Entity(repositoryClass="Mekit\Bundle\RelationshipBundle\Entity\Repository\ReferenceableElementRepository") * @ORM\Table(name="mekit_ref) * @Config() */ class ReferenceableElement { /** * @var int * * @ORM\Id * @ORM\Column(type="integer") * @ORM\GeneratedValue(strategy="AUTO") */ protected $id; /** * @var Collection * * @ORM\ManyToMany(targetEntity="ReferenceableElement", mappedBy="references") */ protected $referrals; /** * @var Collection * * @ORM\ManyToMany(targetEntity="ReferenceableElement", inversedBy="referrals") * @ORM\JoinTable(name="mekit_ref_refs", * joinColumns={@ORM\JoinColumn(name="referral_id", referencedColumnName="id")}, * inverseJoinColumns={@ORM\JoinColumn(name="referenced_id", referencedColumnName="id")} * ) */ protected $references; //-----------------------------------------------------------------------------------------------------------ACCOUNT /** * @var Account * * @ORM\OneToOne(targetEntity="Mekit\Bundle\AccountBundle\Entity\Account", inversedBy="referenceableElement") * @ORM\JoinColumn(onDelete="RESTRICT", nullable=true) */ protected $account; /** * @return Account */ public function getAccount() { return $this->account; } /** * @param Account $account */ public function setAccount($account) { $this->account = $account; } ...

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

/** * @ORM\Entity(repositoryClass="Mekit\Bundle\RelationshipBundle\Entity\Repository\ReferenceableElementRepository") * @ORM\Table(name="mekit_ref) * @Config() */ class ReferenceableElement { /** * @var int * * @ORM\Id * @ORM\Column(type="integer") * @ORM\GeneratedValue(strategy="AUTO") */ protected $id;   /** * @var Collection * * @ORM\ManyToMany(targetEntity="ReferenceableElement", mappedBy="references") */ protected $referrals;   /** * @var Collection * * @ORM\ManyToMany(targetEntity="ReferenceableElement", inversedBy="referrals") * @ORM\JoinTable(name="mekit_ref_refs", *      joinColumns={@ORM\JoinColumn(name="referral_id", referencedColumnName="id")}, *      inverseJoinColumns={@ORM\JoinColumn(name="referenced_id", referencedColumnName="id")} * ) */ protected $references;   //-----------------------------------------------------------------------------------------------------------ACCOUNT /** * @var Account * * @ORM\OneToOne(targetEntity="Mekit\Bundle\AccountBundle\Entity\Account", inversedBy="referenceableElement") * @ORM\JoinColumn(onDelete="RESTRICT", nullable=true) */ protected $account;   /** * @return Account */ public function getAccount() { return $this->account; }   /** * @param Account $account */ public function setAccount($account) { $this->account = $account; } ...

and each entity /account/contact/task/etc) has a OneToOne relationship to ReferenceableElement:

/** * @ORM\Entity() * @ORM\Table(name="mekit_account", * indexes={ * @ORM\Index(name="idx_account_owner", columns={"owner_id"}), * @ORM\Index(name="idx_account_organization", columns={"organization_id"}), * @ORM\Index(name="idx_account_created_at", columns={"createdAt"}), * @ORM\Index(name="idx_account_updated_at", columns={"updatedAt"}), * @ORM\Index(name="idx_account_name", columns={"name"}), * @ORM\Index(name="idx_account_vatid", columns={"vatid"}) * } * ) * @ORM\HasLifecycleCallbacks() * @Oro\Loggable * @Config( * defaultValues={ * ... * "relationship"={ * "referenceable"=true, * "label"="mekit.account.entity_plural_label", * "can_reference_itself"=false, * "datagrid_name_list"="accounts-related-relationship", * "datagrid_name_select"="" * } * } * ) */ class Account extends ExtendAccount implements Refererenceable, Taggable, EmailOwnerInterface { ... /** * @var ReferenceableElement * * @ORM\OneToOne(targetEntity="Mekit\Bundle\RelationshipBundle\Entity\ReferenceableElement", cascade={"persist"}, orphanRemoval=true, mappedBy="account") */ protected $referenceableElement; /** * @return ReferenceableElement */ public function getReferenceableElement() { return $this->referenceableElement; } /** * @param ReferenceableElement $referenceableElement */ public function setReferenceableElement(ReferenceableElement $referenceableElement) { $this->referenceableElement = $referenceableElement; $referenceableElement->setAccount($this); } ...

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

/** * @ORM\Entity() * @ORM\Table(name="mekit_account", *      indexes={ *          @ORM\Index(name="idx_account_owner", columns={"owner_id"}), *          @ORM\Index(name="idx_account_organization", columns={"organization_id"}), *          @ORM\Index(name="idx_account_created_at", columns={"createdAt"}), *          @ORM\Index(name="idx_account_updated_at", columns={"updatedAt"}), *          @ORM\Index(name="idx_account_name", columns={"name"}), *          @ORM\Index(name="idx_account_vatid", columns={"vatid"}) *      } * ) * @ORM\HasLifecycleCallbacks() * @Oro\Loggable * @Config( *      defaultValues={ *          ... *          "relationship"={ *              "referenceable"=true, *              "label"="mekit.account.entity_plural_label", *              "can_reference_itself"=false, *              "datagrid_name_list"="accounts-related-relationship", *              "datagrid_name_select"="" *          } *      } * ) */ class Account extends ExtendAccount implements Refererenceable, Taggable, EmailOwnerInterface { ... /** * @var ReferenceableElement * * @ORM\OneToOne(targetEntity="Mekit\Bundle\RelationshipBundle\Entity\ReferenceableElement", cascade={"persist"}, orphanRemoval=true, mappedBy="account") */ protected $referenceableElement;   /** * @return ReferenceableElement */ public function getReferenceableElement() { return $this->referenceableElement; }   /** * @param ReferenceableElement $referenceableElement */ public function setReferenceableElement(ReferenceableElement $referenceableElement) { $this->referenceableElement = $referenceableElement; $referenceableElement->setAccount($this); } ...

The idea is that this way I have “abstracted” the ManyToMany relationships and I have a central element on which to create the relationships.

For now I did not get to the point of implementing the selection/creation of the relations through the entities so I do in in the db table “mekit_ref_ref” and it works well.

As you can see I have also implemented the “Relationship” config scope which is used to check if an entity is “referenceable” and some other options like which datagrid to use when listing related elements.

To make long story short it seems that this model could work … do you have any observations? Do you see anything that in the long run could create problems?
I have checked and even the query builder works when creating reports.

Here is where I have the problem: As you can see the OneToOne relationship(and its getter/setter methods) is hard coded into the ReferenceableElement and today I got to the point where I wanted to extract it from there by creating and implementing a migration extension and by using the Oro\Bundle\EntityExtendBundle\Migration\Extension\ExtendExtension create the OneToOne relationship.

The problem is that ExtendExtension does NOT have an addOneToOneRelation method.

Q) Is there a reason why it is not there? Or better, is it not there because nobody has thought it could be necessary or is it because of some particular problem?

thanks
\a

---

oro/platform(1.6.2) + oro/doctrine-extensions(1.0.7) + symfony/symfony(v2.3.27)

[Author]

Replies