I am using D7.12 and HS 7.x-3.x-dev (2012-Apr-19).
1. Created new vocabulary.
2. Added first term without changing anything.
3. While adding second term I set the first term as parent and removed "" from parent list.
4. When I hit submit I get the message "Parents field is required" and the parent list is empty.

Any clues?

Comments

wiifm’s picture

Having exactly the same issue, steps to reproduce:

Edit a taxonomy term (with no parent), notice that the hierarcy is currently:

All parent terms
<root> Remove

I add another parent

All parent terms
<root> Remove
Customer Remove

I then remove 'root', leaving

All parent terms
Customer Remove

Clicking Save reveals Parents field is required.

Does anyone have a fix for this. This is extremely frustrating especially when you need to re-parent 50+ terms

iMiksu’s picture

Experiencing the same thing.. Very annoying bug :/

csandanov’s picture

StatusFileSize
new701 bytes

Patch attached. Same logic as in taxonomy module.

claudinec’s picture

StatusFileSize
new522 bytes

Patch in #3 had incorrect paths. New patch attached with correct paths.

kle’s picture

Patch #4 works fine for me !

Thanx a lot

jackbravo’s picture

On latest dev for hierarchical_select those lines already appear fixed, but I still have this error.

This is how it's currently on dev-7.x-3.x

<?php
 
// Use Hierarchical Select for selecting the parent term(s).
 
$parent_tid = array_keys(taxonomy_get_parents($form['#term']['tid']));
 
$parent = !empty($parent_tid) ? $parent_tid : array(0);
 
$form['relations']['parent'] = array(
   
'#type'          => 'hierarchical_select',
   
'#title'         => t('Parents'),
   
'#required'      => TRUE,
   
'#default_value' => $parent,
   
'#config'        => $config,
  );
?>
Gold’s picture

Status:Active» Needs review

@jackbravo, the patch in #4 is checking $parent, not $parent_tid. If the error is still there though...

I'll add my +1 to the patch in #4. I'm not confident changing the status to reviewed & tested though. I'm applying the patch against contrib, not -dev.

J V’s picture

Just ran into this bug in alpha5, patch at #4 worked like a treat, but only if the root term is deleted before the custom term is added, if the custom term is added and the root term is deleted it still gives you an error.

This also happens when moving terms from a to b and deleting b after adding a.

Why is HS used for parent terms anyway? IIRC there should only be one parent. (Or better yet let us turn it off for term editing but keep it for field editing)

Edit: Actually testing shows patch #4 doesn't work any more - it's entirely dependant on the order of delete/adding terms.

Wim Leers’s picture

Please test with alpha 6 now.

martins.bertins’s picture

Version:7.x-3.x-dev» 7.x-3.0-alpha6
Status:Needs review» Needs work

The problem still exists in alpha 6.
Here's a screencast. http://screencast.com/t/pB9rDmfhe0X

k.skarlatos’s picture

i have got the exact same problem. Is there any other module that can replace the default widget in the term_add page?

hanoii’s picture

Issue summary:View changes
Status:Needs work» Needs review
StatusFileSize
new1.61 KB

I think I found the culprit of this issue. All the reproducible cases here are OK, but I found that the issue was basically a double-removal. Once you remove one item from dropbox, the newly rendered dropbox comes with a checked checkbox for the position of the previous removal.

If you have:

Item 1
Item 2
Item 3
Item 4

If you remove Item 2,

The newly created table will be:

Item 1
Item 3
Item 4

However, Item 3 will have the remove checkbox checked (you don't see it because it's hidden by JS), so once you submit it, you will lose Item 3 as well.

Attach is a patch that solves this by removing the reference on the form_state array of the removed checkbox. I am not 100% sure this won't cause other issues, but I think fairly sure that it won't on JS behavior. Non-JS behavior doesn't work properly anyway, as far as my tests went, so this is a good enough fix IMHO. It was a hard one to fix.

Patch is against latest dev.

Also, I am not sure why or how patch #4 worked, but that's on the current dev code anyway, I just don't think the fix was related to this issue.