Environment

Drupal 6.19
Hierarchical Select 6.x-3.x-dev from 08 Oct 2010 (according to Drush)

Configuration

I have simple hierarchy of tags: Human Resource -> Absence Management -> Time Off
The "Time Off" is currently assigned as the only tag to my post.
Hierarchical select for the above taxonomy is set to use: Save term lineage

Bug

If I view the post I see the "Time Off" as a tag - CORRECT.
If I edit the post tag is not shown on node edit form - WRONG.
If I save the post the tag is removed from post - WRONG.

However if I change configuration of Hierarchical Select to use: Save only the deepest term and re-edit the post tag is displayed on node edit form and gets saved.

Expected behavior

For lineage save the term should be shown with parents on node edit form and all (great/grand)parents should be saved along.

CommentFileSizeAuthor
#7 change_hs_lineage.php_.gz1.04 KBfp

Comments

wim leers’s picture

Assigned: Unassigned » wim leers
Category: bug » support
Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

I suspect this node already had the "Time Off" term assigned *before* you enabled HS with the "save term lineage" setting?

Peter Swietoslawski’s picture

Category: support » bug

Yes Wim I have tag "Time Off" assigned before I've enabled Hierarchical Taxonomy with "Save term lineage" for its vocabulary.
This is quite common situation. You have site with zillions of pages each tagged and you decide to use Hierarchical Taxonomy. So you'd expect that enabling module and editing node will assign all ancestors of a given term to a node rather than erasing the term.
So when you edit the node you still have the information in *term_node* table. I assume it's during creation of a "dropbox" for HS where the current tag is being discarded because there is no correct ancestor information for it, right?
I think this is wrong and counterintuitive and might cause serious problems on live site as each time you edit a node for the first time after enabling HS you have to remember all the tags the node was assigned to otherwise they will be removed from node.

YK85’s picture

Status: Postponed (maintainer needs more info) » Active

subscribing

gtaylor’s picture

It's a bit limiting if the module only works on new installs / new vocabulary.
Besides, it's actually destructive behavior. It's not just that it doesn't inherit the parents properly, it actually REMOVES the original child tag when you edit it.

This issue http://drupal.org/node/986122 also shows that even if you turn on hierarchical select on a new vocabulary you'll have the same problem editing historical nodes if you reorganize the hierarchy. I think these are related problems.

wim leers’s picture

Category: bug » support
Status: Active » Fixed

You might expect that HS will launch Drupal's Batch API and expand all nodes' terms from one term to multiple terms, as many as are necessary for the save lineage functionality. Unfortunately, that's wishful thinking. That's not easy to implement, a lot of work, and it's rarely needed.

As gtaylor says, this works fine if you first define your vocabulary properly, then enable HS Taxonomy with the save lineage setting, and then start creating nodes.

This is NOT a bug with HS. It's a limitation of core's Taxonomy. The multiple parents functionality was added more as an after thought than as truly supported functionality. HS is merely a form element and therefor it is not responsible for these data structure problems. You may want it to, but you can't reasonably expect it to.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

fp’s picture

StatusFileSize
new1.04 KB

We ended up with a similar situation where we were saving only the deepest term and found out later that we need the lineage. I wrote a little script (attached) to remedy to this situation and accommodate this change.

A couple things:

  • This is D7 and we're working on the "section" taxonomy, hence the reference to the field_data_field_section table;
  • You will need to change the primary key for your table. Change it back after running the script.
    • mysql> ALTER TABLE mytable.field_data_field_section DROP PRIMARY KEY, ADD PRIMARY KEY (entity_type, entity_id, deleted, delta, language, field_section_tid);

That's about it.