Can the associated node be assigned the taxonomy term?

Forcing the user to go back to edit the node in order to assign it to the newly created term is a little bit unfriendly to the user. I agree this is a most valuable functionality. Is it in your plans to implement it?

I agree with everything said here. Is anyone interested in contributing or collaborating on this feature? I might have some time to put into this and would like to test the waters to see if this would benefit more than a handful of people.

I would be glad to test it! I wish I could help with code but my skills are limited

Subscribing.

I need this functionality too. If you're using panels2, which everyone soon will be :), this is a must have feature.

I'm looking into creating a patch. I'm just not sure if there's some solid reason the author did not include this functionality by default.

see also: http://drupal.org/node/194804

Yes, I'm realy hoping for this feature too. Something with computed field perhaps for the time being?

Me too!!

This is a good option to have available when syncing.
thanks

I'd consider this feature essential as well. I've also had some problems trying to go back and associate the term to the original node - my drupal site will time out, and when I refresh the term is gone. This may have been with delete node->term on.

What sort of work would need to go into this?

I create a little hack for this, I've only done a little testing and am not sure of the total system impact. It seems to work pretty simply but I'd definitely advise against trying it unless you know what you're doing.

Inside nat.module is a function called _nat_save_association that saves node id, term id and vocabulary id in a NAT-created table (called "nat") whenever a new node-type that's been set up with NAT has been created.

The problem that is occurring is that this same information (node id, term id) is not being stored in the normal taxonomy table for storing this information, "term_node".

My hack simply consists of doing an insert into "term_node" as well as "nat" since we have all the information we need to do both within this function.

I am fairly new to Drupal, does anyone know what the preferred method for rolling something into a module is? Ideally, this change would make this insert an option in the NAT module settings to turn on or off.

@ molenick - You can start by posting your code I guess

Suscribing, but not a developer myself... any heroes? - willing to test patches here!

Sure, it's simple:

Replace the function _nat_save_association in nat.module with this:

It's pretty straightforward, I don't know how to make a proper patch otherwise I would. I'm only using the NAT setting "Delete associated term if a node is deleted" and everything seems to be working fine after some light testing.

Also, I worked on making a NAT setting to turn this feature on/off but couldn't pull values out of the nat_config inside this function, I'll have to dig around a bit more to see if I can get it working.

Slightly off-topic: how do I subscribe to an issue?

Great, thanks molenick!

Answering your question on subscribing, you dont, basicaly you reply so that the thread gets listed in your user tracker page,
So in your case, you can just go to http://drupal.org/user/298111/track and see if anyone has replyed to the threads you have written to :)

Gotcha, figured as much. :)

I created a patch, but for some reason Vista/UnxUtils is being a flaky so I can't properly test it, but I followed the direction using diff here (http://drupal.org/patch/create) and the patch file looks about right. Give it a whirl and let me know how it looks.

This has to be an optional feature and requires updates to the configuration screen. Please also follow the other guidelines for patch creation including code and comment style etc.

Thanks,
-K

I've gone ahead and made the changes as suggested. I had to create a third parameter for _nat_save_association to take in $node_type so that I could check to see if the NAT option to associate an auto-term with its parent node was on for a given type.

_nat_save_association is only called from two places - during node creation and during NAT syncing. Both of these should be tested in addition to node deletion, ensuring that data is cleaned up properly from the NAT and node_term tables.

Also, the language for this setting reads like this:

"Associate an automatically created NAT term with %TYPE parent node?"

where %TYPE is the node type. That description feels a tad clunky to me, if anyone has any suggestions for altering it feel free to suggest.

K, I'll leave the patch's status marked as "patch (code needs work)" until you look it over.

I think the patch proposed here is written a bit incorrectly. Currently module hooks the node_api and adds associations just before (or after) node is saved. So basically taxonomy is associated with the taxonomy core, so there is no need to do that twice using module. Another issue - you'll get a double-assigned taxonomy when have vocabulary set to allow multiple selections.

I reworked the _nat_save_association function a bit. Hopefully it'll be useful for you.

Ah, one more thing. You need to assign the "Module Weight" for NAT to something like 10 or so to make it running after the other modules.

subscribing

I would like to humbly suggest a different implementation for this feature...

As far as I can tell, the whole point of the same-name term is to relate other nodes to the same-name node. What about implementing a feature that, without having to associate it with the term, the same-name node automatically appears as the first node in the same-name term's list; of course, you'd be able to turn this bahaviour off if you wish. This can be accomplished by modifying the taxonomy_term View, or by creating a module feature whereby NAT can be configured to "step in" to add the NAT node to the list right before displaying a NAT term's page. See also http://drupal.org/node/285125

I was thinking of working on this for 6.x once Views 2.x integration is established. Perhaps the current work wouldn't be thrown out if the "NAT node hooks to NAT term" implementation (discussed in this issue thus far) gets polished for 5.x, and this "automatic term view hook" idea gets developed for 6.x?

Thoughts?

I tested the function form #16 and got an error:

Missing argument 3 for _nat_save_association(), called in /my/site/adress/nat.module on line 656 and defined in /my/site/adress/nat.module on line 600

I've got drupal 5.7. installed if it matters.

UPDATE: Oh, it seems that it's I'm the one to blame, cuz, I think, I had to apply patch form #15 first and then had to replace the function... Poor me! )
But anyway! Can someone compose a normal patch from #15 and #16?

Hi, again!

I've applied the patch from #15 and then inserted function from #16 and got nothing... :(

I create a node of the type specified in NAT configuration to produce a category with the name of the node in a vocabulary. The category is created, but the created node is not associated with this category. I mean this node have no categories at all and I was expecting that he'll be categorized under newly created category!

Am I doing something wrong? Can anyone help?

@brainchild - thanks for the update! I haven't used multiple selections for the stuff I've been doing so it got neglected.

@white-raven - I'm not sure I understand your proposed approach. Mine revolved around the idea of using multiple CCK types to store data around a "core" CCK type object. Basically, you'd create your core object and then associate other types with and pull it all together using views and the data group's taxonomy term. I think what your proposing would require storing the association between the initial NAT-node and its term-related children somewhere, which the core taxonomy tables do nicely with no additional work.

@alex-and-r -
#19: I'll see about rolling patches 15 and 16 together this weekend or next as my free time allows.

#20: It sounds like you are creating the node first and then the category? Here are a few simple setup steps (#word# designates a placeholder):

1) create CCK-type #NAT_NODE#.
2) create taxonomy vocabulary #NAT_VOCABULARY#.
3) while creating #NAT_VOCABULARY#, click the checkbox for #NAT_NODE# under types.
4) go to admin>>NAT. inside, click on #NAT_NODE# and in the vocabularies listbox click on #NAT_VOCABULARY#.
5) Enable whatever other options you want (I used delete and the one I added in #15) and save.

Now, when you create a node of type #NAT_NODE#, it should create a term in #NAT_VOCABULARY# with the same name as the node's title.

@molenick

Thanks in advance for the patch! i think community will appreciate it!

And concerning my #20 comment and your answer to it - thanks for the step-by-step but as for now I figured out where is the problem by myself. It was because of the module weight. I had to go to my phphadmin, to system table and change weight of NAT module to 10. After that everything went smooth.

Subscribing

I made a patch that combines the modifications suggested in #15 and #16.

noob apology: I recognize that this should have been a patch, but I don't have CVS on the machine I'm on yet, and I need to review creating patches that contain new files (since there is no nat.views.inc in the 6-dev yet).

Recap: I'm trying to use Drupal 6-Views 2 to achieve the listing behaviour of "same-name node is assigned to its same-name term", without having to file the same-name node under its own term. Basically, if you go to the taxonomy_term view for a NAT term, you should see it's same-name node at the top, followed by all the associated nodes.

I've attached a file that SHOULD use Drupal 6-Views 2 to allow the user to modify the taxonomy_term view to include the same-name NAT node in the list. Haven't written anything to put it at the top of the list yet though. Basically, if you add the defined relationships without checking "require this relationship"--as far as I can tell--it SHOULD include nodes that match the required arguments, --OR-- are linked through the NAT table to the term (namely, the same-name NAT node).

There are issues here though: I don't know whether Views 2 will use --OR-- or --AND-- above... which means if the same-name node isn't linked to its own term (which is what I was trying to avoid requiring), this won't work. Also, I haven't written any code to force the same-name NAT node to the top of the list. Finally, these relationships aren't showing up when I edit a view and I don't know why. I've confirmed Views is seeing the file, but the relationships don't show in the edit view page.

Any help?

P.S. If this approach to this fix is too unrelated to the other code in this thread, let me know and I'll open a separate issue.

I agree that this is a much needed feature, and I appreciate the Drupal 6.x efforts, white-raven.

I was going to use content taxonomy w/ a freetag vocabulary and simply enter the title twice - the second one being in the content taxonomy field. However, utilizing NAT for this would be better, being "auto" and all.

Fail. All I needed to do was clear Views' cache and my data showed up. That patch doesn't do everything that's needed yet though (the relationships aren't enough alone). I hope to work on it more soon. Anyone else who wants to tinker feel free to post a revision of nat.views.inc.

white-raven, I'm still not clear on what you're trying to achieve - I know that you don't want the term associated with the original node that creates the term but I'm not sure why. Is there some special hurdle you're trying to overcome that precludes this? I'd think that this route gives the most flexibility so that site developers can tie related data together in the manner of their liking.

I think assigning the node it's own term is the most straightforward, flexible way of adding this functionality. Then Views (or Views 2) is not a required component for NAT too. Also, this work is related to 5.x-2.1 and hasn't taken delving into Drupal 6 into consideration.

@molenick:

I realize this has been work for 5.x; I tried to make it clear that I can move this work to another feature request if the NAT developers think that 6.x development shouldn't be in this thread. I guess, ideologically, associating the same-name node with it's term, to me, sort of "throws it in the bin" with everything that is supposed to point to it, instead of it being "different", "special", or "on top". My reasons for developing in this direction were:

(a) Based on issues I've seen for this module, there has been difficulty finding a bug-free way of associating the same-name node-term pairs; I thought that getting the same-name node in the taxonomy view without having to associate it would "skip over" the bug-fixing for this issue
(b) The ideological issue mentioned above
(c) I was trying to make it so that the same-name node would appear at the top of the term's list--of course, this can be achieved regardless of whether the node is associated with the term.

Shall I create a new issue? Would you recommend developing the "same-name node at top of list" without excluding the "associate same-name node with term" feature? I can see how this would be more useful to developers that aren't using Views, but want to see the same-name node in the list of nodes associated with the same-name term. I agree that tying a feature to Views 2 may not be ideal, but the feature can be seen as optional since all the code would be in Views 2 include files.

I'm happy to hear suggestions from more seasoned Drupal and NAT developers on the best direction for 6.x development.

Ok, I understand now! :)

So basically, you want to create a hierarchy where the original node is a parent above its tagged children. I've use NAT is a similar sort of way but leave the actual taxonomy structure loose and tighten down the information while developing my site. Basically, I create CCK types to represent different satellite nodes orbiting around a core node. There is no hierarchy in the data/taxonomy itself, it is all enforced in the site logic based on taxonomy and CCK type.

I prefer a looser approach as it allows for greater overall flexibility. There are probably a number of ways in which it is preferable to use NAT without forced hierarchy. I do agree with you though, there probably is good use for strict hierarchical (parent-child) relationships.

I know that hierarchical tagging is possible with taxonomy but do not have much experience with it - would it be possible to create a feature of NAT that piggybacks on that to create these strict relationships?

Personally I would not focus so much on the representation (i.e. parent node at the top of the list), rather the underlying data structure - that way once the relationship exist, people can display the data however they wish.

That's an interesting thought. I'm trying to think of how to make use of hierarchical taxonomy without feeling like I'm "wasting a term" (i.e. having one node be the only thing related to a "parent" term). Although that "waste" I guess wouldn't necessarily be a bad thing. Based on your inspiration, maybe the following feature would be better...

- A Settings option for NAT that says "use a child taxonomy term"
- Setting this option opens up another option that says something like "name of child term (use %parent to insert the parent's name)

Here's an example of usage:
Suppose I have content types "Album" and "Music Review". I set up the Album node type to be NAT nodes under a vocabulary called "Albums", and the Music Review node type can be categorized under Album name NAT terms. Next, I check "use a child taxonomy term", and set the "name of child term" to be "Reviews of %parent"

Now I could have nodes like this:

Album: "Dark Side of the Moon"
Music Review: "Pink Floyd Needs to Lighten Up"
Music Review: "Bring on the Darkness"

And I'd end up with Taxonomy like this (Nodes contain a ^ under their term):

Vocabulary: Albums
-- Term: "Dark Side of the Moon"
^- Album: "Dark Side of the Moon"
---- Term: "Reviews of Dark Side of the Moon"
^--- Music Review: "Pink Floyd Needs to Lighten Up"
^--- Music Review: "Bring on the Darkness"

I think this is what you were thinking, molenick. I can see how this might be more useful and flexible than a hard-coded Views feature that only works when Views is configured to be the "one true way" of viewing taxonomy-classified data.

I'm in the same boat as Molenick with hierarchical Taxonomy terms. I know they exist, but I don't know exactly how easy it is to navigate through the hierarchy. If it is easy, this system would provide quick access to the "parent" NAT node by simply navigating to the parent term's page.

slight aside: While there's work being done to optimize this module, I have a question and a suggestion about the following query in _nat_sync_associations.

SELECT n.nid FROM {node} n INNER JOIN {node_revisions} nr USING (vid) LEFT JOIN {nat} n1 ON (n.nid = n1.nid AND n1.vid = %d) LEFT JOIN {nat} n2 ON (n.nid = n2.nid AND n2.nid <> n1.nid) WHERE n.type = '%s' AND ISNULL(n1.nid)

Question: What is achieved by the join to node_revisions? Does Drupal track deleted nodes in the node table, an just delete revision when a node is deleted? The reason I guess this is that the inner join would filter out deleted nodes.

Suggestion: The join "nat n2" seems superfluous to me. E.g. (without omitting the node_revisions join):

SELECT n.nid FROM {node} n INNER JOIN {node_revisions} nr USING (vid) LEFT JOIN {nat} n1 ON (n.nid = n1.nid AND n1.vid = %d) WHERE n.type = '%s' AND ISNULL(n1.nid)

As far as I can tell, since the join on "nat n1" is a left join, all nodes will join irrespective of a relationship with the nat table, and then only nodes of type %s that do not have an entry in the NAT table (i.e. n1.nid is NULL) will remain in the final result due to the WHERE clause. Is there something subtle here that I'm missing?

The #24 patch doesn't seem to work with "sync".

This patch fixes issue in #33, and I strongly believe this is ready for a commit, can you please include in dev.

Blessings!

patch in #34 works for me at group node creation and deletion. however, my browser times out when i edit the group node. if i then edit the group node, the new nat term is deleted.

i then save the group node again with no problems. editing this iteration of the node shows the nat term is back in the list. however, if i select the nat term again and try to save, the problem repeats itself?

does the above patches only address a group node at the time of creation and not during an update?

has anyone else experienced this problem?

subscribe

Tested patch at http://drupal.org/node/155411#comment-1082354 worked! Terms were added to nodes...

One small issue that I am having is that when I edit the nodes that terms are attached to, they time out when trying to save them (sometimes a fatal error against taxonomy.module, the process times out)

#38 is the same issue i reported in #35.

Hmmm...a bit of difference in behavior from what you describe, masande, vs. what I experienced. But, they could be related.

In my instance, the terms are saving to the nodes, but when a node is edited and submitted, the submission process times out/takes a huge amount of time, and does not load the saved node upon submission completion, but just gives a WSOD (once with a fatal error). This seems to be what you are describing. But, terms are not being deleted for me. They remain assigned to the node

...another issue that I noticed, when editing nodes that are term descriptions and attempting to save them, they WSOD as reported in last issue, and top shows that CPU % usage jumps to 99%! Something is of course fundamentally wrong here.

Actually, problem does not seem to be with patch, as the same problem happened when I tried to edit nodes even before the patch was applied.

masande, further testing shows that indeed my terms are being deleted, too. So, our issue is the same. I upgraded to dev version, and rolled back to older versions of the module, and problem persists

The same issue (terms not linking to nodes) appears in 1.1-beta2 for Drupal 6... Should I open a new issue for that?

@SamRose, please confirm CPU overload occurs WITHOUT this patch, if so, please file another issue and place the link here.

Blessings!

I have question.

Is purpose of this patch to assign new created term to new created NAT node?

Because I tested 6.x version and it does what I expect to do, that:
If I create new NAT node, it creates new term which is associated with that node, but node doesn't belong under that term. So By this I can use it for media gallery, where albums are NAT nodes. And photos, videos and other albums are assigned to term which has been created by album and is associated with it. Later I can use Views to show items for specific album (views argument or filter - node nid of album).

So if created term will be assigned as parent for NAT node, this module will not make too much sense for me.

it creates new term which is associated with that node, but node doesn't belong under that term.

So is this a future feature?

This is current state:

it creates new term which is associated with that node, but node doesn't belong under that term.

This is text from NAT project page:

The NAT module is a helper module used to maintain node-term relationships, i.e. when a node is created, an equivalent taxonomy term is automatically created in any associated vocabularies. This module is a simple but effective way to create node-node relationships via the taxonomy module.

As I understand NAT node supposed to be on same level as associated term, not as child of that term. Assign to node same term which has been created with that node and is associated by NAT, doesn't give a sense for me.

The same issue (terms not linking to nodes) appears in 1.1-beta2 for Drupal 6

They are linking to nodes. If you create node, new term is created. That term is associated with that node. If you create other nodes and assign them that term, you can than see them as children of that term, or you can make views with NAT node nid filter and it will show you nodes which belongs to term which is associated to that node.

And if terms link to taxonomy term page, you can change settings in NAT module to replace it with link to NAT node instead of term.

Can you please write more information what is exactly problem?

When a node is created, the relevant term is added to taxonomy. However, the node isn't linked to the term and when a node's terms are listed the NAT-added term isn't among them.

When a node is created, the relevant term is added to taxonomy. However, the node isn't linked to the term and when a node's terms are listed the NAT-added term isn't among them.

Yes, and this is right behavior.

Example with gallery:
1. You have album node type which with NAT creates terms in 'Album hierarchy' vocabulary
2. When you create album 'Album 1' it creates in 'Album hierarchy' vocabulary term 'Album 1' which is associated with that term through NAT, but created album node is not in that term.
3. When you create another album 'Album 1-1' you can set parent term to 'Album 1'. And also term 'Album 1-1' is created as child of term 'Album 1'
4. When you create another album 'Album 1-2' you can set parent term to 'Album 1'. And also term 'Album 1-2' is created as child of term 'Album 1'
5. You can now create some nodes (photo type, video type, album, ...) and assign them for example term 'Album 1-2'.
6. Now when you make new view with Views 2 module. And use filter or argument 'NAT: Nid' (The node ID of the NAT node) with value of node id of 'Album 1', it will show you nodes which have assigned NAT associated term to node id you provided. In our case you will get 'Album 1-1' and 'Album 1-2'.
7. If you will do same as in previous point (6), but provide node id of 'Album 1-2', you will get list of nodes you made in point 5 and has parent term 'Album 1-2'.

And if you checked 'Make NAT terms in %type node views point to the associated node rather than the taxonomy page.' on settings page, you will see on 'Album 1-2' link to node 'Album 1' instead of link to term 'Album 1'.

So it seems that NAT node is linked to term and everything works as it supposed to work.

@anantagati, nice explanation, but NAT is not useful only for those cases, current patch provides a feature based on real needs and we don't want to create a forked module for just one feature, right?
I'm using the feature 'Associate an automatically created NAT term with %type parent node?' for a conference site which depends on event.module.
The content type structure is:
Conference (event)
Session
Speech
I need to display a calendar with all sessions and speeches of a particular conference, and the conference. I don't have to create a custom module for that because event.module already provides a filter by taxonomy terms. With this requested feature interface becomes transparent, avoiding to manually associate the automatically created NAT term with the parent for let event.module display the conference in the calendar view.

I'm sure there are another real life cases needing this feature, that is why I encourage you to apply this patch in favor of community.
If you still not agree, please at least provide a hook in order to let us create a plug-in module and avoid hacking.

Thanks in advance for your comprehension.

Blessings!

[posted by accident]

I am taking care about Views support for NAT. So lets make a nice patch and let Karthik apply it. Any ideas Karthik?

I went quickly through patch in #34:
- there should be some checking if NAT node type is allowed type for that vocabulary, otherwise we skip setting from Vocabulary edit page.
- use Drupal coding standards (http://drupal.org/coding-standards), for example $vocabulary=taxonomy_get_vocabulary($term['vid']); should be
$vocabulary = taxonomy_get_vocabulary($term['vid']);

please at least provide a hook in order to let us create a plug-in module and avoid hacking.

There is no need to make new hook for this, because you can use hook_nodeapi. You just have to make sure, your module is called after NAT module.
I created new issue #334165: Set $node->nat when new node is created, that NAT module will already fill $node->nat during node insert and you will not need to call nat_get_terms there. Until that issue will be committed, you can just call: $node->nat = nat_get_terms($node->nid); to get NAT associated terms.

Maybe we can try to find how many uses cases we have for this feature and see if it is better to include it in NAT module or make helper module to enable that.

I would have used NAT with this feature for the following use case:

A node for a certain content type automatically gets a taxonomy term.
When a node of another content type is edited and this term is selected it will automatically be displayed in a faceted search facet.

If I select the taxonomy term in faceted search I also want the original node to be displayed in the results.

+1

I would also like to be able to choose the option "assign auto-created term to original node", as long as it doesn't break existing functionality.

If

• I am not re-directing the term's link to the same-name node but going to the native taxonomy term display

or

• setting up a View based just on the term (not using the "Nat: nid")

then I want the "NAT node" to show up in the listing

This feature is apparently also required for Panels integration.

PS I'm on D5

Thank you anantagati for your response. I think it would be a nice feature to be added in this module...

Karthik, can you look on this one?

In the meantime, I've found "Taxonomy Node", thinking that it would assign the auto-created same-name node to the original term. I've posted questions on a comparison to their issue queue:

http://drupal.org/node/335496

Edit: apparently does not, and also no Views integration

Subscribing, greetings, Martijn

Subscribing

Subscribing

Though I'm a little confused if the patch i supposed to fix the original topic of this thread the

patch in #34 hangs for me
Drupal 6.9

Is there any progress?

I tested the D5 patch.

• When I create a NAT node, it becomes a child of "itself" cleanly enough. However, I cannot view the associated term on the taxonomy admin page.
• When I try to view the term's page, I get a WSOD and Drupal times out.

If somebody can rework and reroll for D6, it'll be great.

Cheers,
-K

it doesn't look like this one has been solved yet

[subscribing]

Subscribe

I ported the patch in comment 34 (here) to drupal 6 against the latest dev version. It appears to work as advertised. Anyone want to test it out?

*edit*

I found that the patch works fine when creating a node, but it loses the association upon editing the node, mainly because elsewhere in the module (its in hook_form_alter) the associated term with the node is unset from the list of terms when editing a node by design. Perhaps I'll try adding a case to check if the content type has automatic association, and if so, skip the block that unsets the taxonomy term associated with it. I'll try and get something up later tonight. Thanks,

-Rich

I updated the patch to conditionally *not* remove the NAT term from the taxonomy form element in the case that automatic association is turned on for the current content type; this allows the term to remain associated after editing, or you can opt to unassociate it, if you wish.

Then I ran into a bigger problem - the WSOD/script timeout others experienced above. The script was timing out on the taxonomy_get_parents() function in taxonomy.module. I found this was called from taxonomy_del_term(), which is called from taxonomy_save_term() (probably, since this is one of the only entry points to the function anywhere I could find), which is called from _nat_update_terms() in the nat module. There has to be some sort of bad bit of data being passed into the ['parent'] element of the "form" data passed to taxonomy_save_term(). Here's the node object I was trying to save at the time:

And the $edit array that was passed to $taxonomy_save_term() from _nat_update_terms():

The auto-created term had an ID of 38 and a VID of 4.

I would take a guess that it has something to do with the parent being set as itself, causing an endless loop, but I didn't read into the taxonomy module enough to know exactly what was happening.

To temporarily fix it, I removed the parent key from the $edit array in the patch from _nat_update_terms(), and it works fine on a flat (non-hierarchical) vocabulary, but I don't know what effect that will have on a tree-type vocabulary.

Maybe someone more familiar with the effects of removing the 'parent' attribute could elaborate more, but as far as I can tell, unless the hierarchy was updated from the node edit form (I don't see how), the drupal_write_record() function that actually stores the data shouldn't overwrite the current parent data associated with the TID. Ideas? Thanks,

-Rich

subscribe

Would definitely love to be able to have the node creating the term auto-associated with the term it creates. (Or at least a way to avoid a manually added link to that term via the normal taxonomy method not fall apart when the node gets edited.)

subscribing

subscribing

This would be great functionality, for example it could be used to make views sortable from taxonomy weight and then use taxonomy for clients to order the nodes.

subscribing

The logical thing, to me, seems to be to add a form field (radio) which reads like this:

"(For hierarchical vocabularies,) when assigning a term to a node:

- assign the selected term to the node (term is 'parent' of the node, new unassigned child term is created also)
- assign the newly created term to the node (new term is created as child of the selected term - node is directly related to the new term via a one-to-one relationship)"

Or something like that. Then we just have to switch on that based on what the setting is and save the node relationships accordingly.

Edit: probably also need to cater for this: If the "Make NAT terms in *type* node views point to the associated node rather than the taxonomy page." option is selected and we're on a node page that relates to one that's configured with that option, we need to _alter out the link, otherwise it will be linking to itself! :)

+1

Actually, that applies in some cases to non-hierarchical vocabs too...

NikLP etc - He's a quick patch that applies all the nat-module terms to the node itself. It doesn't have any UI, and requires that you (manually) set the module weight of "nat" lower than "taxonomy" (say to -1). Let me know if this is (the start of) what you're looking for.

[Edit: patch is against NAT 6.x-1.1-beta3]

Si - In the patch, you add three lines for _nat_fixup_term_node($node); when actually moving it outside the case statements will do, I think. FYI.

I know you probably just C&P'd that in there - just noting it down.

NikLP: The code is fine - you should only fixup the node terms when they are updated ($op = insert/update/delete), not the many other times hook_nodeapi is called.

Here's another patch (for 6.x-1.x-dev) that adds some UI for configuring this.

Other stuff for consideration....

Maybe change text: "Make NAT terms in property node views point to the associated node rather than the taxonomy page."
to
"Make NAT term links in property node views point to the associated node rather than the taxonomy term page."

Maybe change text: "Attach the newly created term to the property node"
to
"Assign the newly created term to the property node (otherwise the term selected at node add time will be assigned)", WDYT?

For the option: "Make NAT terms in property node views point to the associated node rather than the taxonomy page."...

I'm not sure this makes complete sense. This says, "on property pages, show the taxo link as a node link". This effectively means that the node will forever be linking to itself on the same page, which is crazy.

It would make sense to me that anywhere terms from this *vocabulary* were displayed, that they linked to the nodes - is that the case? Otherwise, there should probably be another option "remove link when it points to it's own node". I.e., if we're showing a property node, we don't need to link to it. If we're showing a profile node, where the also profile is categorised with this vocab, THEN we should definitely be linking to the property node.

*Edit: You know what... I'm starting to think that scrapping this and starting again might be an idea, for my use case at least... "taxonomy_nodemap" namespace is looking ever more attractive.