Apologies if this is a common thread but i have looked around the site and the web and i cant find a definitive set of notes on how to setup a one to many relationship between two nodes ( content types ) i have set up .
I ve seen a lot of questions , a lot of abstract answers , some inappropriate videos on vimeo ... a lot of modules to install but little or no guidance on how to use them .
I am quite new to drupal and would appreciate being pointed to a straight-forward guide on how to achieve what looks like a standard process

thanks in advance

Comments

John Pitcairn’s picture

At its simplest, use entityreference module. Add an entityreference field to the "one" content type, set to allow multiple values.

gjlook’s picture

thanks for that
i will have a go
and theres documentation with this module as well

i'll see if this helps

gjlook’s picture

hi , thanks for the info

i have looked at entityreference . Ive added an entry reference field and played around with adding client history from a client page and tried attaching a view to display client history for that one client but im basically clicking fields making educated guesses and getting nowhere ....

isn't there just a simple set of tutorials that tell me how to :

prepare my client node/entity/content page and my client history node/entity/content page to link to each other .

(there will be multiple client history records for every client)

then tell me how to set a relationship to each other

then tell me how to open the client page and add a new client history record from that page

then view client history from the client page

or another scenario :

setup a customer and add the products the customer buys and view those products from the customers page.

i'm really looking for a step-by-step guide / s

John Pitcairn’s picture

Everybody's implementation requirements tend to be different, which is why you won't see many tutorials.

So each client history record is currently a node? Is this an actual e-commerce site, or are you just using it to enter and track external sales?

If a client history record always refers to one and only one parent client node, and its parent relationship never has to change, then I'd consider using a multi-value field_collection field instead of entityreference. In that case, your client history records would be added/edited as part of the client node, and would not be nodes themselves (they would still be entities). Client history display in the client node would be controlled by the field collection's "manage display" settings.

gjlook’s picture

while the drupal site was down i carried on and found some documentation for entity reference - which i finally got to work but cant seem to get the block to appear in my client page the documentation page is https://drupal.org/node/1465920 ... im using panlizer to add my final block

but yes my client and client history is a one-to-many that doesnt change so i will go back and have a look at field_collection

i saw a tutorial on vimeo that related to this but the author was too busy saying you dont need this or that while his colleagues were laughing in background which wasnt much help

thanks for the link - i'll try that . i agree all configurations may be different but a simple step-by-step for one-to-many relations for example would be great - and then you can take it from there once you know the basics and scour the forums , videos etc.

gjlook’s picture

Hi

In the end I had another look at the enitiyreference idea and the clearest tutorial I could find https://drupal.org/node/1841004 however the author said its important to choose the right content type to add enitity reference to - but forgot to mention which of his example content types I should use which is confusing to the first time tryer.

In my example I had a list of clients ( content type one ) and then a list of relevant client History e.g. telephone calls , actions taken ( content type two )

From what I could understand I added the Entity Reference field to client type two . In the entity reference field options, I used content type one as the Target bundle.

As described in the authors tutorial , I then created a view to show Content of content type two - (my client history) and un-ticked page and instead ticked Block . Made my selections on that screen and continued to the main options page and Added a relationship and used the Entity Reference: Referenced Entity option that mentioned my entity reference field. I completed that section as author specified.

I then used the contextual filter to add the Content NID option and filled out the settings as the author specified

I saved the view.

I then went into structure menu - then block as instructed , found the view I previously saved and changed the region/location to content and saved..

I now add or edit a client history record – Content Type Two - and select a client using my new entity reference field and save the record

I now open any record on my client list – Content Type One - and I can see the relevant client history as a block .

That is fine – Finally I would like to see the client history as a table with columns rather than just a block – what would be the best and most straightforward way of achieving that

many thanks in advance.

VM’s picture

I would like to see the client history as a table with columns rather than just a block

A view can be generated to provide this type of feature displayed in a table.

gjlook’s picture

i created a block view for what i described earlier
do i create a page view to get the table format ?
or still use a block and just add more fields

VM’s picture

you can use a block view as well. Set the view style to table.

gjlook’s picture

i'll try that thanks

gjlook’s picture

one of the flaws in drupal org is the lack of usage notes for modules. each module page has a plethora of bug reports etc but no actual instruction on what to do once you have enabled a module. not everyone's a drupal expert where you instinctively know where to go once you have enabled a module.
a simple paragraph or two would help

VM’s picture

WorldFallz’s picture

so true--- particularly when a module usage stats show thousands of users (and that's just the ones with update module enabled) who can't seem to be bothered to contribute a paragraph or two of documentation.

Jaypan’s picture

One thing I do when I find a module with little/no documentation, is open up the MODULENAME.module file, and look for their implementation of hook_menu(). This is easier than it sounds. FIrst, I do a search for the following pattern:

function MODULENAME_menu()

...where MODULENAME is replaced with the name of the module (which is the name of the folder, and the name of the MODULENAME.module file).

In MODULENAME_menu(), you will see a number of items with a path:

$item['some/drupal/path']

The path in the above code is some/drupal/path. I look for administration paths, that look something like admin/something/something_else. Doing this you can get an idea for some of the options the module provides, and maybe guess at what it does. Note that if you see paths that have a % in them, or a %word in them, it means they are dynamic paths. If you see %user, then using your User ID in that spot in the path will lead you to that page, as it relates to your user.

The other thing to always look at is the permissions page. See what permissions (if any) the module provides. Usually permissions are written in descriptive terms, so you can sometimes get an idea of what the module can do here as well.