Take data from a field from exsisting node and make that the default value of a field in different content type

I don't know if I'm on the right track but I'm trying to let users of my web site create there own versions of pages on my web site. Basically I'd like to make our documentation used as a starting point where they just add details and make a new page for 开发者_JS百科themselves in the process. I have a 'book' content type that I have changed with CCK and a 'client edits' content type that uses a nodereferencefromURL widget to link itself to the book node.

So simple version of what I'm saying is I have a link on my book pages that creates a node using client edits content type. I would like to put some fields on the client edits content type that take the values of some of the fields from the book page it is linked from.

I'm sure I'm missing something as I would have thought someone would have tried this before but I can't even find a hint on how to go about this.

All I really need is a point in the right direction if my current thinking is wrong. Current thinking is that I use a php script to get the default value for a field on the new node add screen that drags the value for a field from the book I'm linking from. I'm thinking this is the case because there is an option for default values for the field in cck manage fields that lets you put in a php value to return a default value for your field.

Am I on the right track or is there already a module or process that does what I'm talking about and I'm just too dumb to find it.

---

This sounds a little strange, are your client edits going to be a diff from the original node or just coppied data?

I would prehaps do it a more simple way, just have book nodes, and have different fields disaply depending on who edits it (enable the content_permissions module). That way you can use the node clone module to create the users copy.

You will need to make a module to contain your custom php code.

---

I ended up using rules to save information from the user and the cloned node into hidden fields. One that saved the original node ID into a field when ever you create content of that type unless the url ends with Clone. This means that when you create the clone the original node ID is kept in the field. That made it easy to use a views argument that took the node ID to make the clone appear along side the original when a user visits the original page. The second rule trick was to compute a field that saved the "store name" from the profile of the user only when saving clone content. This meant that there was a hidden field on the clone that stored the info so I could then use another views argument to restrict the view to only people with the same store name in their profile. I am no good with PHP but I managed to find a snippet (can't remember where) that returns the store name of the current logged in user as the argument.

global $user;

profile_load_profile($user);

return $user->profile_store_name;