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.

hanoii’s picture

Pushing this for review now there's some activity on the module.

stefan.r’s picture

If anyone else can review I'll be happy to commit this...

Georgique’s picture

Version:7.x-3.0-alpha6» 7.x-3.0-alpha12
Status:Needs review» Reviewed & tested by the community
StatusFileSize
new1.61 KB

Patch is nice. Here is patch rerolled against latest alpha12.

stefan.r’s picture

Status:Reviewed & tested by the community» Needs work
+++ b/hierarchical_select.module
@@ -1017,6 +1017,8 @@ function _hierarchical_select_process_get_db_selection($element, $hsid, $form_st
           $remove_from_db_selection[] = substr($x, 8);
+          // Remove the input reference this checkbox so that any rebuilt doesn't force it to be again
+          unset($form_state['input']['parent']['dropbox']['visible']['lineages'][$x]['remove']);

Comment "Remove the input reference this checkbox so that any rebuilt doesn't force it to be again" is unclear and over 80 characters. Please can you clarify?

hanoii’s picture

Status:Needs work» Needs review
StatusFileSize
new6.16 KB

OK, it's been a while, attempting to explain it better.

Also removing some whitespaces from the file. Let me know if you prefer a cleaner patch.

hanoii’s picture

stefan.r’s picture

Status:Needs review» Fixed

committed

  • stefan.r committed 3bbb9a1 on 7.x-3.x authored by hanoii
    Issue #1566878 by hanoii, csandanov, claudinec, Georgique: Term parent...

Status:Fixed» Closed (fixed)

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