Brainstorm: What do you want out of relation?

Suggest on future User Interface: 'Relation Designer' type sub-module:

1. On the content being edited, a ('popup'?) style Relation Design which allows you to easily connect your data visually (graphically?) using a pre-defined relation design 'template' (see point 2 below). It can incorporate various user-selected widgets (data select, specific drop-down selects, autocompletes, data relationships etc) to allow relations to be easily defined and 'connected' and all points are shown visually on the edit form - (with effortless 'drag and drop' type ease?). The key here is simplicity of use in connecting data points quickly for the user.

2. To go with above have a 'Relation Designer': Add/Edit/List A design that incorporates your relation model, choice of various widgets for selection, and ability to create 'jump around' systems to pick data easily. Allow easy widget/data plugin development so that others can add specific functionality to the 'relation designer' framework. The goal is to accommodate both easy and complex cases. This 'design' is then saved and used for front-end UI and data selection on respective edit forms. Or, additionally, have a dedicated edit page for relations.

Basic preset designs can be included with the module for those wishing to create simple node-to-node relations such as 'related news', data synchronization (e.g. back-references) with autocomplete widget so that the Relation module can be used 'out of the box' so to speak. Other presets can be added to the module for models such as 'Groups', various arity situations, and real-life scenarios defined and contributed by users over time.

'Relation Designer' could even extend to a Views created/driven system that the user could incorporate into content pages for setting relations. (e.g. in a similar way the 'Viewfield' module adds views into nodes for data selection etc. (http://drupal.org/project/viewfield))**

**FYI - Entity Reference has something similar now for those interested in this approach:
entityreference_view_widget

Thanks!

I would like to relate material below the field level, ie, in content, possibly through the DOM.

I know this is not really very crazy or far-out, but I'd really like a nodereference/userreference replacement (i.e. http://drupal.org/project/references, except with relation as the "backend" as it were)

Awesome posts, so far, keep them coming.

#1 : great idea. Probably a way off, but definitely something I will keep in mind.

#2: great use-case, exactly what I was looking for. I wonder how they do their data entry at the moment?

re: #3, you mean like specific elements in a page? Relation isn't likely to support that, since we're only dealing with drupal entities, no DOM involved. But if there's a way to reference such elements, then the concept could be extended, and perhaps implemented as a separate back-end?

re: #4 that's more or less relation's raison d'être. It's already implemented too ;). Absolutely that's within the context of what's being asked here, this thread is for all the crazy stuff that doesn't really fit in proper feature requests yet.

re #5: for anyone who's not following it already, discussion on relation-as-a-abckend-to-references is mostly taking place over here: #1175386: Provide widgets for specific entity types

A stake in the ground that what we have is stable enough to build with, with another beta release :-)

#7: naught101, regarding #2, they are using ASP.NET and perhaps a 'feature rich' set of .NET web controls for data entry such as:

http://www.telerik.com/products/aspnet-ajax/grid.aspx (just as an example).

The main reason I am excited about relation is the possibility of dropping a whole lot of User Relationship's design debt it has been carrying forward.

There are a lot of existing feature requests that border on the impossible using the current model, and relation has been tackling some of these thorny issues head on.

That would be awesome.

#12 using relations as a views relationship already kind of does filter the view, no? If not, that sounds like a good one for a feature request.

#14 Interesting. There'd need to be a bit of work done on actually getting RDF sorted for relation, first though. There are a couple of open feature requests on the queue, if anyone has any know-how.

#16 hrm.. not sure if you've grasped the relation concept. relations are not fields on an entity, but stand-alone entities. The information they contain can be displayed in a field-like manner using the dummy field. There's no need to add fields anywhere. For 1) - we're working on a widget, #1175386: Provide widgets for specific entity types, and for 2) that behaviour you describe is basically EXACTLY what the entity collector block currently does, if you have it enabled and go to the content admin page, but it allows you to do the same thing anywhere, and over multiple pages...

Nice work, keep it coming, especially any any interesting and out-there use-cases.

The widget seems to be for binary relations, but #16 has 1:M. That's a humongous win, if do-able.

The problem with a relation field widget is that it's conceptually wrong. A relation is NOT part of an entity. This would be like saying "equals" is part of 4, because 2+2=4. They are distinct things. A relation can be thought of as adding information to an entity, but the the relationships it defines are not attributes, not inherently part of an entity.

In any case, I just added new block that has everything a widget would have and more (including multiple autocompletes, and relation fields). It will allow you to add relations on the entity page, or on the entity edit page (but not on the entity create page).

Anyway, I know the widget discussion is going to be ongoing, but it'd be nice if we could leave it for other issue threads, so we can get back to the more general brainstorming here.

Another real world use case. I want to add a "Multimedia Assets" field to the article content type. This field should be able to reference multiple entities of the following types (and only these types):

- node entity, bundle "gallery"
- node entity, bundle "Poll"
- file entity, bundle "video"

For each reference I want to select how the relation should render: as the primary media (ie. at the top of the page), as a sidebar link, sidebar rendered as a thumbnail etc. Only one of the references should be selectable as the primary media. To select primary media at all is optional.

Do-able?

I have two sites on where I use relationships... they work like this

First:
It's a video streaming site. Users can create Channels, and assign other Users of the site as Contributors (able to add videos to that Channel) or Admins (able to manage all users within Channel) to the channel.

Second:
It's a church site, it's bit more complex.
Site is divided into Ministries (Main Church, School, Youth, etc...). Site has 3 Member roles (besides guest and administrator) - Webmaster, Staff and Members.
Users with a "Webmaster" role can create Ministries, and assign "Staff" as admins to that ministry.
Staff can add Content (Blog, Events, etc...) to the Ministry they belong to. Staff can also register Members and give them access to the Ministry they are in charge of.

I am currently using a patched nodeaccess_userreference/nodeaccess_nodereference modules, but am trying to accomplish the above in Relation module.

Just like in node/user reference modules, I'd like to be able to reference a relationship on the same page that users and nodes are created on. Say if the content type Blog has a relationship with Users, maybe being able to insert a field into Blog content type to reference it to the user, during the Blog creation.

msevrens: ugh.. what a facepalm that is. Thanks for catching that, We'll have to come up with a better solution for enabling the block.

Perhaps this already exists, but I can't seem to find it.

Let's say I create a node type called "Person" and I create basic fields such as first name, last name, DOB, etc.

Then I create a "Publications" node so that I can catalog publications, and that node type has basic data such as name of publication, date of publication, type of publication, etc. Let's also assume in the publications node, I have a node reference to the person's node, so I can relate to the author -- what a concept.

Now comes the seemingly obvious question: what publications did Robert Ludlum write? How do I create a block listing Persons that, when a name is clicked, sends the PersonID to a View based on the Publications node saying gimme all results where PersonID = Robert Ludlum and then returns a View list that contains the results?

If there is a View (that acts as a template), I would need something that fills in the PersonID to filter the results. But if I do this with Views, I need to create a separate View for each person. How do I do it so that any person I click on uses that one View, the only thing that would change is the PersonID in the filter, which would be automatically filled in by click a name in the block of Persons?

Or further, if I have a list of Persons (block), I would like to be able to have a page created on-the-fly that pulls a list of publications from that person from the Publications node, a list of articles from the Articles node, a list of videos from a Videos node, etc., all in one page for that Person. Again, simply by adding the filter by the PersonID into a template that pulls in all the data. It would only pull data from these other nodes where the PersonID was the same.

I am not sure if this is a relation module function of if this would be a Views function or a combination.

EDIT: Seems like I am having some success now within Views...

I found the relation module when searching for a solution to display entity power relations in our society. Bold is a content type , italic a relation type and underscore a taxonomy vocab

*A shareholder in a company is the brother of a minister.
* A journalist uncovered/wrote something about a project administered by a company
* A judge was permanently appointed to a regional court by a minister that is a friend from childhood

All these power relationships in our societies is what can be visually represented with the Graph API or Graphviz (Asterisq designed a commercial solution but that´s another matter).

Nothing new here but creating a new Drupal installation profile using the relation module and a java/flash visual tool as the core feature would set the platform for people to open up the corruption that takes place within the power entities in the world.

This is not a request to the maintainers of the Relation module but more an insight about how this module can put the financial and governmental bodies in a visual context.

#31 This is exactly what I want, with the simple (ha) addition that I'd like to be able to address, say, am occurence of a shareholder in the text of the body field, for example, and not in field_shareholder.

#33 shunting, that's never gonna be somethign that relation will do. That's a whole other ballpark. However, if someone could get something like that working with generic fields, then that would also work with relation.

@davidwatson Great proposal/example David, thanks.

#38 - A big +1 to making things easier for site maintainers. Correct me if I'm wrong, but this seems very similar to the Relation Select module (if you haven't already, definitely check it out!). I'm curious, how would this differ in concept?

Just reverting the component for bookkeeping purposes, since this is still meta/discussion. Leaving the tags intact though; we could always use the UX perspective!

I am working on a model where relations are use to apply node access permission based on roles referenced in the relation. I looks like described at #25.

I use the Role Reference module to add a field to the Relation Type. This creates a directional relation to a node from User -> Node. The node access model checks if there are relations implementing the role reference field and if any relations exists with referenced roles. These roles can be maintained in the general permissions page.

If, for example, a content type exists for Group and the permission 'can edit any Group content' is given the user is permitted to edit the group he has a relation with.

This permission model could be extended in many different directions and would be very powerfull. I would realy like to see this build also in a way that ancestors (in a tree) or somewhere in the relation model can define permissions for a node or any entity. Lets also look at entity_access and how that will evolve as a working permission model and integrate that.

I originally posted this idea on GDO, but it seems like it bears repeating here.

The motivation:

For sometime we have been working on a publication workflow system at the California Science Center in D6 and I've been considering how such a system might be implemented in D7. This lead me to the work being done on the Relation module, which lead me to the following conceptual model. The system should be able to adapt to any publication workflow, but to ground this discussion in a real use case, let me first review the basis for my own workflow. All managed content can have revisions in one or more of six different states: Draft, Review, Pending Approval, Approved, Published and Archived. Content moves between Draft, Review and Pending Approval states, until it has been approved for publication. Approved content that is scheduled for future publication goes into the temporary Approved state, until the scheduled time arrives. The Published and Archived states are what you might expect. Content in this system is moderated, so the current, published, revision of a node stays published while newer revisions go through the approval process. I won't go into that mechanism here, but assume it's something like the Workbench Moderation, or State Machine modules. This content is controlled by users in one or more of four different editorial roles: Editor, Reviewer, Approver and Overseer. Editors can create and edit content. They are responsible for moving content through the workflow. Reviewers are notified when content reaches the Review state. Approvers are notified when content is Pending Approval and can either approve it, moving it toward publication, or reject it, moving it back to the Draft state. Approvers can also archive published content, or republish archived content. Overseers have all the rights and privileges of Approvers, but none of the responsibility, so they don't receive any notifications.

The implementation:

Lets assume we have a new entity called a "Workflow". Each Workflow instance will contain fields listing the users in each editorial role for that workflow. We can have as many different workflows defined as we need, with different sets of users in each. Now we create a relation called "Moderated", using the Relation module. This is a unique, 1-to-1, directional relationship, with the source entity being a node and the target being a workfow.

To start with, I'll need a way to assign a default workflow to each content type, so this relationship could be created automatically when the node is created. I suppose this could be done with Rules. However, once created, administrators would need the ability to change the target of the Moderated relationship from one workflow to another, for a given node, on a case-by-case basis.

Let's pause for a moment and consider the Drupal permission system, which is one of the primary motivations for my approach. Normally you would create user roles for each workflow role and assign permissions accordingly. However, I may need ten or more workflows and each of those will have four editorial roles, which means I'd need at least forty different user roles. This seems a bit excessive. Instead, I'm proposing we only have three user roles: Workflow Editor, Workflow Reviewer and Workflow Approver (remember Overseers have the same permissions as Approvers); but no users would actually be assigned to any of these roles. Instead, when viewing a node, the system could look to see if you are in the list of Editors on the related workflow. If you are, then it would temporarily treat you as if you had the Workflow Editor role (see the OG User Roles module from D6 for a similar approach). The other roles would be assigned in a similar manner. This means I only need to concern myself with configuring permissions settings for three roles, which makes site maintenance easier. It also means I can give someone permission to edit workflow assignments, without giving them any access to edit user accounts. In fact, I could allow a user to create and manage new workflows, without giving them any access to the permissions system at all.

Now, to make this more interesting, let's consider that relations are fieldable entities. So, I can add some override fields to my Moderated relation, allowing me to add or remove additional users to/from each of the editorial roles on a node-by-node basis. Now, when a node is loaded, the system can take the default user lists provided on the Workflow, apply any overrides from the Moderated relation and then look to see if the current user should be assigned any of the workflow user roles. This has the added benefit of maintaining overrides even if the base workflow is edited, or if the nodes relation is switched to a different workflow target.

Already this seems pretty cool to me, but I wonder if we could take it one step further. What if we could create a parent/child relation between workflows? Then the system becomes hierarchical. The roles granted on any given page would be the sum of the roles granted on all parent workflows, with the current node's overrides applied. This sounds interesting to me in theory, but truth be told, I also question its feasibility in practice.

Even without the hierarchical workflows, I think this would be an extremely powerful and flexible workflow system. Any thoughts on the approach? Hidden gotchas? Does this seem reasonably doable?

What about Drag and Drop?
Drag and drop may be intimidating to everyone, but it keeps coming up, and frankly Relations is quite cumbersome without it. Please correct me, but I don't at all see how the Relation Select module helps with that. The main encumbrance is to expose a form. Even an invisible form, if it requires a refresh of the page, just drags the UI down.

File/Folder Metaphor
The idea is as simple as the old file/folder metaphor. You just grab an object (file) and drop it onto the target (folder). Just think simple. There's no special edit page to go to, no refresh of the page needed and no bulky status message crowding your space. At most a JavaScript alert could come up, but that should be optional. Perhaps some visual indicator could appear at the target.

New Drag and Drop Module
Here's a possible recipe for a simple drag and drop module. I've done some of this and am working on more, but what I have is pretty rough for a standalone module.

1. JavaScript JQuery functions
   • addEvent() function.
   • some processDrag() function to define the events to call the PHP functions.
2. CSS file
   • Drag, drop classes and ID's.
3. Admin file to configure settings.
   • Content types / entity bundles to be draggable.
   • Content types / entity bundles to be drop targets.
   • Whether to display a JavaScript alert
4. Module Functions
   1. Render Alter functions
      • Changes the given node displays to include drag or drop classes and a node ID if draggable.
      • Adds a x-icon to displayed relations for deletion.
   2. Node Add function
   3. Node Delete function

Am I on the right track?

It also needs to take into account that some relations have extra entity fields, as it is particularly usefull.

Just so I get the use case straight, could you give me an example of the "particularly useful" use of extra entity fields?

I want to relate things that are not entities. Blocks, Field instances attached to entities, Field delta values, Views module displays, and *cough* entity revisions. Just give me a hook or something. It seems like Blocks and Views could be macgyvered to be entities though...

cheers

Got a screenshot, jaypark?

@jaypark 100% yes on relation designer

One thing that would be great is to re-use / share the graphic UI (MindMap style interface). I don't know yet if it is a separate sub-module, an external library or if it is deeply merged with the core code.
But since I saw maesto's video, I'm convinced I need this UI for a module I'm working on, and also to manage relations.

Wondering how we could have this as a separated module API.

I intend on fully leveraging Relation for every aspect of a Drupal Sports API. From using relations to define the parent/child relationships between league containers (think Season->conference->division->tier), to possibly even using fielded relations to represent an individual match between two opponents (and a relation between that match and the match results).

And then there is the Club->team instance->team roster->team lineup hierarchies, with team instances being related to a particular season and team lineups being related to a particular match.

So from a UI perspective, the ability to easily display trees resulting from directional parent/child relationships would be a plus. I'd also love the ability to provide an endpoint and array of allowed directional relation types, and be returned the child->parent->parent->parent chain all the way up the tree (along with the relation type at each stage of the chain).

Similar to the Field Collection module, I'd like the ability to attach fields to individual members of a relation. For instance, take my example from #60, where I have a relation designating members of a project team. It would be nice if there was a text field associated with each user referenced in the relation, allowing me to indicate that user's job role within the project.

#24 for genealogy relation seems to be a very good solution, since any event on a persons timeline might be related to one or more people. At marriage you have the two people that marries, the relation might have extra entites for ceremony, for assigning best man etc, and each relation might have other fields attached to record further info, like location, time, etc.

The same goes for any kind of bibliography site. You might have a quote from an article in a publication, the relation would be a reference, and that reference might hold information about which issue of said publication, at which pages etc. you would find the original article.

This is exactly why I find the Relation module exciting, because it lets me add information to the relations.

#44 #43 I love your idea, especially since it gets around the cumbersome built in permissions system. The glue for this would probably be the Rules module, with a few others added to the mix for effect.

#47 I think #44 had a strong use case for particularly useful entity fields.

User experience

Old-school

I agree that a relation is a separate entity, as described by naught101 in #17. Since other relationship modules before have relied on fields this is a break from a tested and true user experience, see for example the nodestream distrobution on how images, fact (boxes), contributors etc. are linked to the current item you are working on. Lets call this old-school.

The good thing about the old-school way of doing it, is that it maps to all other kinds of software, this is how we have been conditioned to look at UIs.

New-school

I don't know the answer ;) I'll venture a vague guess, but with time and more brainstorming (anyone for a separate issue on this?) we could probably work out some ideas that are better and truly "new-school".

Since a relation knows which entities are allowed, if they are symmetrical, directional and also the number of entities allowed at each end, it is natural (in my humble opinion) that a relation_ux module (relation_ui would be the admin, I guess) would expose this knowledge at points where builders and users would find it natural to expand upon a piece of content. I suggest at its simplest it would supply virtual fields (I would say links, but only nodes have links, I believe, not all entities) that at its most basic is just URL alias + Tokens (as suggested by #42).

Two such urls would be needed for each relation type, one for creating a new endpoint entity and one for browsing for existing ones.

Rationale

As I mentioned, this is how we are conditioned to do things. As a journalist using different content management systems to publish information, I know I don't always want to browse around collecting the info I need, though it has a very good appeal when you can see the content on the front end and can't find it easily in the backend.

Sometimes the info I need are entities, but only visible as a part of another entity. Think factboxes in a news paper article as an easily imagined case.

Finally, if I do write a fact box, I would like to know it is related to my article when I create it, because it is there I need it.

Caveat

This is how it seems from my point of view, as I stated above a brainstorm might do better. A kind of drag and drop might be good, as suggested by #45, until you realize that many people don't even grasp files and folders, and dragging and dropping requires a certain dexterity that some users do not have.

A multiselect solution, like suggested in #38 is a kind of two pane file manager, not unlike Norton Commander and Directory Opus, both have fallen by the wayside, which suggests that the metaphor provided isn't exactly what mainstream users need. But it has clarity, you know your left from right, and thus can't be confused as in a wider, more open file and folders system as implemented by Windows and other current OSes.

However, there is nothing wrong with implementing several user experiences for this, and I do love drag and drop as well as two pane file managers. I don't use the latter anymore.

How to do it now?

For those who know rules module by heart (I have only watched screencasts) I am sure that the previous is a piece of cake. Just add text links somewhere in your entity, go to a dummy path, use rules to trigger on that dummy path, do your magic.

EDIT: Some more thoughts

Having a relation_ux module would provide a service/extension for entities, not unlike comments, ping and similar services that are common add-ons. If we look at relation entities and say they provide an extra service, no field is neccessary, yet we get the familiar experience.

Genealogy

A person has events in her history. Some types of events create relations. A birth-event creates a relation to the mother, a parent-relation. If the mother has any previous children they will be added as half-siblings-relation by a ruleset.

A parent-relation to the spouse-relation of the mother is not created automatically, but can be added, and will then create an automatic relation to any previous children as half-siblings.

In either case the ruleset will have to add two associations as half-silbing to a sibling.

A marriage-event will create a spouse-relation to another person.

Events might have to be specialized with date and reference fields, which the rulesets can use to create relations. Each event will have to be a field in the relations they create.

This method would create an UI where the wellknown UI-widgets of the relationship module can be used to create automatic relations, as well as creating needed new persons inline.

I have no idea if it is possible to do this with rules and relation. I specifically need to find out if I can find the relations needed in a ruleset, and count each sibling and thus creating full-siblings upon need.

The best thing about this method is that the events are needed for each relation anyway, there is some overhead, and it leaves me the option of reconsidering, or retailoring, the events at a later date, without changing the relations.

Furthermore, if I have understood GEDCOM files correctly, this system would probably make it easier to import gedcom (if ever I will) files as it fires rules for each created event, perhaps by using Feeds.

Any thoughts?