Currently the system requires that you visit individual content types and cast them as being eligible for various relationships. This then populates the a page allowing you to say who is related to whom and how. We could clean this up a bit by building a new admin that allows users to create new "chains" of relationship. These could, in turn, build the required workflow, as well as open up the system to utilize any content type without the need for predefined casting. In the same way, these content types could continue to be utilized in normal situations separate from the relationship chains they may be part of.

This concerns me in a couple of places long term, i.e. mid chain relationships in which we'd like to move content from one type of chain into another type of chain. We're going to need the ability to define compatibility between multiple relationship chains, so that when content type x appears in 2 chains in different capacities, we can determine whether it can be moved from one chain type to another, and more importantly, how it's descendants are handled within the new chain.

I expect this to raise a lot of issues, but it should rock when we get it done. :-D

Eclipse

Comments

eclipsegc’s picture

eclipsegc commented

ok, I've started working through this and a few more interesting details have started to raise their heads. First off is the potential for two node types (or any objects really) to be related to each other in different chains by different (or even the same) relationship type. This was simply not possible in the old system, as everything was shared, but views integration will need to be retooled a little to consider the chain and relationship. I'm afraid we'll just end up with uglier names like project_task_chid_32 or something like that. This should provide a unique view per chid, regardless of what nodes or relationship is attaching them together.

In the same way, we won't be able to depend on the generic "create content" links that currently exist as these are unspecific about what chain a starting node might be a participating in. We'll need to add the ability to "Create Chain Name" into the create menu structure as it currently exists. We should also provide interface options to turn off the content type creation links (instead of the system choosing what will and won't display as it currently exists).

Eclipse

eclipsegc’s picture

eclipsegc commented

We'll also need "create chain A", "create chain B" perms like cck, but for chains instead of content types.

eclipsegc’s picture

eclipsegc commented
Priority: Normal » Critical
Status: Active » Needs review

This feature is in CVS and ready to roll. It required a significant refactoring of the riat_parent_views code, as well as the inherent menu code in the main riat module. The end product requires less code to do the common tasks we were doing before, and is much cleaner in its implementation, as well as its user interface. I need some people to look this over and start playing with it. There are definitely some bugs I haven't squashed yet that could let you shoot yourself in the foot, but over all, this is looking REALLY good.

As far as reparenting goes: I did the "sane" thing and you can only reparent content from one chain to another chain as long as they're the same chain types. No cross-chain-type intermixing... that would be crazy. :-D

Eclipse

csc4’s picture

csc4 commented

Any chance of committing this as a release even if it's an alpha? (means update status can see what's happening with it).

eclipsegc’s picture

eclipsegc commented

I will consider it. I have a new set of code I'm working through right now, and once I commit that I might be cool with an alpha release.

ingo86’s picture

ingo86 commented

Hi,
I updated riat but i can't use the new feature. Are that in CVS?
Thank you,
Ingo86