Support for saving the term lineage

This is definitely something I want to do, but I don't know when. Patches are welcome ;) :)

I would very much like to see this too. My extremely clumsy work-around has been to clone the taxonomy for every multiple selection needed. Any other way is beyond my kung fu, but i picture it like this:
If multiple - display a clickable ("more") after the HS, which AHAHs a new HS below the first. New "more" behind this one, etc. Each HS must also have a clickable "clear this" to discard the selection.
Then my simple mind thinks it's a matter of submitting the array of selects somehow on save, and foreaching the array back to generate HSs when a node form is loaded.

But i know things aren't as simple as they seem...

Subscribing because I'd really like this as well. I have a vocabulary with two levels. I'd like to have all the top level terms in a single select dropdown that populates a multi select box with all the child terms for the selected parent. I haven't found any module that does this and it really would make UI on my site a lot better. Unfortunately, I don't have the skills to help write it. :(

Michelle

What you are suggesting Michelle, is some sort of "dropbox", and the ability to have a hierarchical select to select items that should be added to that dropbox?

If that's it, then that's definitely outside the scope of this module, and should be another form element.

I'm not sure what you mean by a drop box... I'm just looking for a way to make it easier for users to add terms to a node. I have an area directory that is two levels. So you'd have, for example:

Vocabulary: Directory terms
Terms:
Automotive
- Car dealerships
- Car repair
Food & Drink
- restaurants
- bars
- grocery stores
- coffee shops

There's actually hundreds of terms and the user can select as many as they want. The multi select box is so full, though, that it's hard to pick out what you want. So what I'd like to do is have a drop down with all the top levels (Automotive, Food & Drink, etc) since any item will only be under one parent term. When they choose the top level, it shows all the terms under it in the normal multi select box that you get with taxonomy and the user can pick as many as they want.

Does that make sense?

Right now I'm using taxonomy super select which helps some, but isn't that nice of a UI.

Thanks,

Michelle

Ok, never mind my explanation then. I thought you wanted some kind of mix between Hierarchical Select and Multiselect (which is a CCK widget). That module is a better fit already for your needs though, I think.

But after reading your latest reply, your suggestion is identical to the initial one.

"But after reading your latest reply, your suggestion is identical to the initial one."

Yeah, I know... I was posting to say I wanted the same thing and why I wanted it as a way to subscribe and +1 it. :)

Michelle

Forgot to say... That multiselect doesn't look like what I want at all. Yours is 90% what I want... I just need multiple terms chosen. I have the same problem with the active select in content taxonomy. :(

Thanks,

Michelle

My experience with normal multiselect form elements is that users will often forget to hold ctrl or the apple key when they're selecting, and the same users will often find the "Reset" form button spooky (thinking it could mean "reset to empty form"), and end up saving a node, and then complain to me that the form is forgetting what they chose before. For these users the ideal multiselect form is more like what I described above, I think. For myself and other experienced form users, though, I would be quite happy with the model michelle suggests, as it would be much faster for selecting lots of options quickly.

Interesting. Being a computer geek for so long, I never thought about a multi select list box being difficult. taxSSU, which I currently use, turns them into checkboxes under collapsed fieldsets for each parent term. I had been using this as a temporary solution until I could find _my_ ideal solution but your comment makes me wonder if what I already have isn't better? I didn't like it because it takes up so much space, but perhaps it's more intuitive for the users? Since I want to encourage users to enter their own directory listings, what's better for them is better for the site.

Thanks for the discussion,

Michelle

I've been thinking about it, and I think it's a bad idea to add support for multiple select. What if you want to select options at multiple locations in the hierarchy? e.g.:

culture
-opera
-theatre
sports
-ball sports
--baseball
--soccer
--tennis
-martial arts
--jujutsu
--karate

Suppose I want to select "tennis" and "martial arts". Then I would first have to select "sports", then "ball sports" and "martial arts" and then "tennis". But now I've selected 4 terms, which ones are the ones I really wanted to select?

Ok, you can solve this by only considering the selections in the deepest level as "truly selected options". But it stays confusing nevertheless.

Thoughts?

Well, I was assuming that it would only be used in cases like mine where a given node can only fit under one parent term. So you'd select the parent term and then narrow it down to which subterms under it that you want. Pizza hut, for example, would have Food & Dining as the parent and then choose the terms restaurant and pizza under that. It wouldn't fit under any other parent term.

If you want to be able to make selections across parent terms then, no, it's not useful. I don't know what a good interface for that would be.

Michelle

The previous example was extreme. Let's make a less extreme example: I want to select "tennis" and "jujutsu", since those are the sports I practice. Now I have to select both "martial arts" and "ball sports" in the second level, to get the mixture of all their child terms in the third level, and then I can select both "tennis" and "jujutsu".
This is also my original perspective for implementing multiple select.

I'm afraid the usability for this approach is really bad, because you get the mix of all children of the terms you've selected, so this hides the original hierarchical structure completely from the user. That can't be good.

Therefor, I'm marking this as "by design": by design, this form element isn't suited for selecting multiple options!

How about using this type of interface? I think it's pretty self-explanatory. :-)

Thanks, spartanbeast, excellent screenshot! That was exactly what I was talking about in follow-up #4. Only I would add the "add category" buttons below EACH level of the hierarchical select, because then you could really select anything in a hierarchy.

Reviving this issue. This will be implemented (it's working already actually), but not in the way everybody might suspect.
Some people asked me "Why is only the deepest term selected?", that was because, well, how this implementation worked. What I'm doing now, is adding the ability to store the entire "tree".

e.g.:

BMW > 7 series > 714i

Previously, only the "714i" term would have been saved. If you enable the "multiple" option, ALL terms will be saved now: "BMW", "7 series" and "714i".
This feature will be sponsored by Paul Ektov.

The other possible implementations, such as the excellent one suggested by spartanbeast in #15 should be implemented in *another* form element, that just builds upon Hierarchical Select.

Implemented and committed.

Well, I guess it is a kind of multiple selection. But while I can see good use of this approach (saving the full hierarchy of a term), I'm not sure it should be called multiple selection. I would call it "Save Term Lineage" or something like that.

For my needs, for example, I will still be bound to using clones of the hierarchy to save "multiple selections", in the way that other term selection methods do. (Yes, I could use other modules, but this is the friendliest interface I have found.)
Besides, the hierarchy/lineage of a term can easily be fetched and displayed in other ways, and the interface behaves exactly the same, so for most uses/users, I see no change.

Sorry if I'm overly critical here. I think you've done something really good with this module. What I want to get through here most is that I feel this implementation might be mislabelled.

I completely agree. That's why I've been so hesitant to support it. I was thinking about adding a new option to the vocabulary form, something like "Hierarchical Select: store all terms in hierarchy". What do you think about that?

That is as accurate as can be, describing exactly what the new function does.

We (Marmaladesoul) are hoping to use this module but also need multiselect and also came up with an idea virtually identical to that suggested in comment #2 above. I personally still think that option is the best way to provide true multi-select. Your new system is certainly handy, but I want users to be able to choose more than one final term.

We're looking into this idea (#2) and will submit a patch if it turns out to be relatively doable.

I agree that that is "true multiple select". A patch would be much appreciated. I will make the changes as described in #20 ASAP.

Renamed this issue to properly describe the added feature.

Changes suggested in #20 have been implemented and committed. You can now configure the Hierarchical Settings for each vocabulary on the vocabulary's configuration form. (As well as disable Hierarchical Select per-vocabulary.)

For "true multiple select support", see this issue.