Entity Reference: Two-way referrence (synchronize 2 fields or use one storage for two-way link)

Hi there. I'm not very comfortable with this feature request. It has been suggested a couple of times before (#1267884: Synced field instances (aka cnr), and a lot more and #1280752: Please add two-way relations), so it's obviously a popular feature request, but I'm not sure I completely understand the need, and I'm not sure it actually fit within the Entity Reference model.

I see it this way:

• If the reference you are trying to implement is perfectly symmetric (like a bunch of related nodes, etc.), you should use Relation. Entity Reference is for directed references only.
• Else, what you want is actually a view of the backreferences displayed on the target entity. You can attach it there using EVA or similar modules.

This doesn't solve the "editing back-references" feature you mention. How common is this type of requirement?

Let's discuss further.

I also need it to attach teachers to subjects and subjects to teachers.

That album has this song.
This song appears on that album.

#1313766: Reverse Relationships (or is it called two-way relations)...

I also vote for the two-way reference sync model. I already needed it many times. The whole idea behind it, is that it takes work out of the users hands. Without it, the user needs to navigate back and forth between entities to update everything. The drawback of using EVA is that the user can only manage what's showing up on the album, by editing the song entity. So in the future ease of use will always win...why not choose for that right away?
So actually we need a Relations variant with the difference that the synced references are fields (not entities) and that the synced reference is updatable from both sides.
...just like Entity Reference Field has. So please make that part of Entity Reference (or the future merge with Reference).
Thank you.

I've been using the Corresponding Node References module to provide this functionality. The great thing about CNR is that it allows you to maintain separate ordering of referenced nodes (via drag and drop) from both directions. It also has an interface for batch synchronizing older nodes.

I wonder if it could be forked into a Corresponding Entity References module.

This is functionality I am also looking for, I have looked at "relation" and while its functionality might have an audience I just don't have a need for the references to be entities.. Also "relation" is complicated in creating the relationships from what I could see.. attaching references (user, node or entity) is far simpler and that's a good thing..

What I am currently working on is a system to manage a business profile, sites profile (offices) and people profile.. Sites and people are related to the business profile.. A site could be related to multiple businesses and these could change.. People can be referenced to multiple sites and these will certainly change..

So I create the business and then add a site and relate it to the business.. If I now add another business on the same site I have to create and save the business and then go find the site and add the reference to the business.. Not very intuitive.. If I was able to create the second business and then reference the site straight away (automatically adding the reference from the site to the business) then the process is far slicker and more user friendly.. Similarly adding a person to a site requires the site to be added and then I would have to find all the people connected to that site rather than just being able to select them using all and have the reverse reference created/updated automatically..

To recap, there are three ways to get this functionality (entity back references) today:

1. Use relation instead of entityreference. Advantage: very robust two-way relationships (each relationship is a node). Downside: the user experience is more complicated than entity reference, as there is an extra object to create and maintain. As explained in #10, this is not desirable for some users.

2. Use references instead of entityreference, and manage back links with cnr. Advantage: provides bidirectional back reference editing without an extra relation object. Downside: references only supports nodes and users.

3. Use EVA or views_content (from ctools) with entityreference to create the back-links. (I added an explanation about this to #1313766: Reverse Relationships (or is it called two-way relations)....) Advantage: simple. Downside: no bidirectional editing of references. [Okay, #3 isn't really in-scope for this issue, but I think it's a perfectly reasonable substitute for some use cases.]

The missing functionality is simple bidirectional entity reference editing without the extra UX weight of relation objects. I think that the best solution was suggested in #9: extend cnr to work with entityreference. I think I'd be inclined to not fork, but instead have cnr work with both references and entityreferences. See #1201596: Corresponding Entity References. I would be disinclined to recommend supporting two-way entities in this module.

For now, I'm happy with the behavior I get with panels and views_content.

This cnr feature request fits nicely with owl:inverseOf:
http://www.w3.org/TR/owl-ref/#inverseOf-def

Properties have a direction, from domain to range. In practice, people often find it useful to define relations in both directions: persons own cars, cars are owned by persons. The owl:inverseOf construct can be used to define such an inverse relation between properties.

Defining such a mapping in the way cnr does will keep the simple model favoured by entityreference but also allow for back references which are editable from the target.

yea - we should focus upon entity references instead of just references.

#1308490: Migration from references module - There is a module under development to convert the fields over. We need to ensure a migration path from CNRs to the Corresponding Entity References setup. Therefore, we should focus upon converting http://drupal.org/project/cnr to work with both Entity References & Node References simultaneously, then an upgrade path should be easier.

According to #1240234: Use EntityReference as a generic reference field - KarenS supports deprecating References in favor of Entity References, but webchick likes References for now & said that Entity References was an "up and comer."
Logically everything will go to Entity References eventually, but the only thing that would stop this is if References solved this #1240234: Use EntityReference as a generic reference field, which it doesn't look like there has been much progress on.

So for now we need:

1. Corresponding Entity References (CER) via CNR #1201596: Corresponding Entity References
2. References to Entity Reference Field Migration: #1308490: Migration from references module http://drupal.org/sandbox/btmash/1404542
3. CNR to Corresponding Entity References (CER) Migration: There has already been progress with CER though the scope should be more limited initially #1267884: Synced field instances (aka cnr), and a lot more

That album has this song.
This song appears on that album.

I am planning a site with this need. I am deciding on which modules to use.

Subscribing

If you don't think entity references are ready, http://drupal.org/project/cnr (based on Node References) is one option.

#12 1. each reference is an entity. They are not nodes. 3. I tried to go with eva for a client just to make sure I am not favoriting my own module but when doing a track-album-track relationship chain and providing track 1 as an argument you will get track 1 in the result list and so it's not well fit when you are looking for other siblings but not the original. Especially relevant when you know there are only two of them.

Hey! how did this got assigned to me?

jsacksicks sandbox entityreference backlinks module works fine for this, providing back-references for any application you cant just use a view for.

http://drupal.org/sandbox/jsacksick/1301456

but via this way we can't edit this field in target node, only in source.

is this possible with the sandbox module mentioned in #20?

thanks

Ah no, it dosn't solve the editing... just supplies the backlink. Didn't read the issue closely enough sorry...

That artist has made a painting,
This painting was made by that artist.

Yes would love to see this functionality and be able to create views with filters based on the relationships

Subscribing :)

@jorisx and others entity reference already supplies views for backreferences, so on the display side you can create views both ways. This issue is about being able to set the references in the node forms (either side) so the end user doesn't have to go through multiple forms to set up references.

(Entity)Reference Field Synchronization since version 2.x provides two way synch for Entity reference fields.

It deprecated its field (version 1.x) in favor of this module.

Note that now there are various widgets for creating relations with relation module, study the modules linked from the project page.

I just finished porting CNR to work with entities, before I thought to look here for this functionality.
Anyway for any future people here is a link to Corresponding Entity References.

Marking as fixed as Corresponding entity references solves this.