I have multiple hierarchy vocab
For example:
Term1 => Term2 => Term3
Term4 => Term5 => Term3
Term4 => Term6 => Term3
So Term3 has multiple parents. When field is set to "Save only the deepest term", if I add Term3 to the dropbox, it displays all lineages together, something like that:
Term1 > Term4 > Term4 > Term2 > Term5 > Term6 > Term3
In general it is something like that:
Level1 terms, then Level2 terms, then finally selected Level3 term.
I think it is very confusing from the point of UX, and is bug.
When "Save term lineage" option is set, lineage displaying in dropbox is ok.

Comments

crea’s picture

crea commented
Version: 5.x-3.x-dev » 5.x-3.0-rc7

Because lineage is bugged in "save deepest term" mode, I switched my CT field to "save lineage" mode.
HS set to limit field values to maximum of 3
Example vocab:
Term1 => Term2 => Term3
Term1 => Term2 => Term4
Term1 => Term2 => Term7
Term5 => Term6 => Term3
Term5 => Term6 => Term4
Term5 => Term8 => Term7

Bug #2:
Go Term1 -> Term2 -> Term3, press "add", dropbox contains "Term1 -> Term2 -> Term3" as it should.
Go Term5 -> Term8 -> Term7, press "add", dropbox contains 3 entries:
"Term1 -> Term2 -> Term3"
"Term1 -> Term2 -> Term7"
"Term5 -> Term8 -> Term7"

Bug #3:
Start from the scratch,
Go Term1 -> Term2 -> Term3, press "add", dropbox contains "Term1 -> Term2 -> Term3" as it should.
Go Term5 -> Term6 -> Term4, press "add", dropbox contains 4 entries:
"Term1 -> Term2 -> Term3"
"Term1 -> Term2 -> Term4"
"Term5 -> Term6 -> Term3"
"Term5 -> Term6 -> Term4"
And after bug #3 there is no complaint that maximum # of values reached

crea’s picture

crea commented
Title: When "Save only the deepest term" is selected, wrong lineage is displayed in dropbox » Bugs with lineages and dropbox in multiple hierarchies
Version: 5.x-3.0-rc7 » 5.x-3.x-dev

Installed latest 5.x dev, bugs are still there...

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Version: 5.x-3.0-rc7 » 5.x-3.x-dev
Assigned: Unassigned » wim leers

HUH? This is *very* weird stuff. This is — or should be — impossible. In a couple of weeks, I'll have the time to try to reproduce this. But I'm pretty sure I'll fail in doing so …

crea’s picture

crea commented

I'm now in the process of fixing HS CT 6.x port, and watching your implementation of lineage calculating.
If I understand it correctly, HS does not store any additional information about lineage, i.e., which path we go in the tree. Instead, HS uses ready to use hierarchy information straight from the taxonomy system and saves individual terms. This leads me to several conclusions:

  1. Multiple hierarchy is thing that HS cannot deal with effectively at the moment.

    2. Ofcourse, HS can write and read parent items in hierarchy, but it can't guess right path in multiple hierarchy. Simple example:
    4 Terms, A, B, C, D with multiple hierarchy:
    A -> C
    A -> D
    B -> C
    B -> D
    If we save any 2 lineages using all 4 terms, and then calculate possible lineages using tree, we always get 4 lineages, because terms are saved, while parent information is not.
    So once terms are saved, correct lineage is lost forever. So we can only guess all possible lineages, which leads us to duplicates. This fact must be clearly explained in documentation and UI.

  2. With current implementation, HS could use information provided by JS during node creation stage, but that would bring UX problems

    3. Only thing we can do with correct lineage is to show it during node form edition - because JS can tell us correct lineage path used. Does it work so at the moment ? It seems that HS widget does not use "actual" path used, but simply calculates it using terms selected. That brings us to problem listed above: duplicates.
    But, OTOH, showing "right" lineage on node creation could bring us major UX problem: user may think lineage information is saved, while it is lost right after node is submitted. Even second node edit would bring duplicates again! Not to speak about hierarchical cck formatters, that would show duplicates too.
    So that brings us to next conclusion:

  3. To support multiple hierarchy, HS module should have additional means to store lineage information

    4. Either store on its own in different table, or extend API so HS implementations that need multiple hierarchy feature should provide their own lineage storage. API way seems to me the best
    While I understand that this is big-big-big feature request, let's put it here anyway :)

  4. Bug#2 and Bug#3 are "by design"

    5. These are situations where HS cannot know "right" lineages so it simply includes all possible ones

  5. Bug #1 is indeed bug

    6. In that case, lineage includes terms missing from the selection - which HS should be able to deal with.

I'm very interested in your opinions.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

HS can store the lineage. Use the "save lineage" setting. That answers everything.

However HS doesn't really store the lineage. It can't. It's just a widget. So it stores all terms that were selected, instead of just the deepest. It can then reliably reconstruct the saved lineage.

Thanks for working on this! :)

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Assigned: wim leers » Unassigned

Since you're working on it now … :)

crea’s picture

crea commented

I created #492068: Change HS API to support lineage storage provided by implementations regarding lineage support in multiple parents hierarchies.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Title: Bugs with lineages and dropbox in multiple hierarchies » Limitations of lineages and dropbox with multiple parent hierarchies
Status: Active » Closed (fixed)

I committed (http://drupal.org/cvs?commit=239158 and http://drupal.org/cvs?commit=239160) an addition to the README. I added this to the Limitations section:

- In hierarchies where items can have multiple parent items and where you have
  enabled Hierarchical Select's "save lineage" setting, it is impossible to
  remember individual hierarchies, unless the underlying module supports it.
  So far, no module supports this. Hierarchical Select is just a form element,
  not a system for storing hierarchies.
  For example, if you have created a multiple parent vocabulary through the
  Taxonomy module, and you have terms like this:
   A -> C
   A -> D
   B -> C
   B -> D
   If you then save any two lineages in which all four terms exist, all four
   lineages will be rendered by Hierarchical Select, because only the four
   terms are stored and thus there is no way to recover the originally
   selected two lineages.

I of course credited you :)

eiland’s picture

eiland commented
Version: 5.x-3.x-dev » 6.x-3.6
Status: Closed (fixed) » Active

also in 3.6 :(

In fact, I have

ASIA > RUSSIA > TOWN
and
EUROPE > RUSSIA > TOWN

I added a Russian town to the drop box, and up next is to add a German town.

As ASIA is lighter than EUROPE, EUROPE > RUSSIA > St. Petersburg changed itself to ASIA > RUSSIA > St. Petersburg, that I can live with.

However, after dropping SPB, I changed ASIA into EUROPE, but it is automatically selected back to ASIA, hence I cannot select EUROPE to get to GERMANY > KÖLN or whatever :(

The way around it is first to select none in the country category, and then to change to Europe.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Status: Active » Closed (won't fix)

See the updated project page:

Note: the Content Taxonomy module integration is no longer supported. Patches are accepted and committed, but the maintainer does no longer want to fix bugs with this integration. The reason is simple. It's a nightmare. It makes one suicidal. Content Taxonomy is rotten. It needs to die. Thank god it won't be necessary to port this functionality to Drupal 7