I was unable to create a task to a previously set up project as I was getting this message:

"An illegal choice has been detected. Please contact the site administrator"

See attached pdf file with screenshot

Note: I think there might be an issue with the "organization" drop down box. I was unable to pick any of the organizations that I set up (or does it inherit the organization from the project for which I was able to assign an organization).

N.B. This modules looks great!

#19 stormtask_illegal_choice.patch4.62 KBCarsten Müller
PASSED: [[SimpleTest]]: [MySQL] 94 pass(es). View
#2 storm-organizations.pdf110.11 KBrichoh
CreateTaskIssue.pdf115.74 KBrichoh
Members fund testing for the Drupal project. Drupal Association Learn more


Magnity’s picture

You need to select an organization.

So was the organization dropdown box empty?

Are organizations visible to you in the other Storm node forms?

richoh’s picture

110.11 KB

Yes, the organization dropdown box was empty.

I tried the expense form and I didn't see the organization box populated there either.

Attached is a copy of the 2 organizations I've set up.

Thanks for the help.

Magnity’s picture

Are the organizations active and checked as a customer?

BTW - any chance of attaching screenshots as images so I can view them in my browser?

richoh’s picture

Thank you!
Switching to customer worked.

I was confused with the vernacular since I was assigning a project to an internal department and had them assigned to "provider"

Magnity’s picture

What could we change to avoid this confusion?

I know its something that gets a lot of people.

JGonzalez’s picture

Why can provider companies not have projects also?

One solution to this would be to categorize the drop down menu (like the feature I recently recommended and was done for quicktimetracking module).

-Inactive (?)

(However, If you have the ability to select an inactive organization, creating something for it should make it active)

(in retrospect, why even make inactive orgs?)

barathee’s picture

I got similar error while entering Task or Ticket.
All my organizations are 'Customer's and 'Active'. I am not able create any task or ticket. Will you please guid me on how to proceed with this?

Magnity’s picture

Which Storm organization permissions do you have?

barathee’s picture

I got this error while working as admin user.

If I select the organisation, then selecting task, I am not getting this error. When I select task/ticket directly and choose everything (organisation, project etc) manually and updating the task/ticket I am getting this error.

Island Dave’s picture

Ditto to barathee's error on tasks, this is the exact behavior I am experiencing. Going through org->task does not produce the illegal choice error. Going from a general add task link will always produce this error if "assigned to" is set to someone rather than unassigned. Watchdog shows:

Illegal choice 5 in Assigned to element.

the # in the log error matches the stormperson nid, and all selected users will create this error.

Creating the task with no one assigned to the task, saving, then editing to assign a user will not produce the error.

Magnity’s picture

So to summarise,

The issue is with user/1, that no organizations display in the dropdown, despite there being organizations that are active and marked as a customer?

Are you using any other node access modules?

Island Dave’s picture

See update at bottom for useful info

For my error, I am user 1. I am not using any explicit node access modules and have not added any storm or stormtask specific access definitions myself.

Organizations do display in the add new task dropdown, and the dependent dropdowns of 'project' and 'assigned to' do change as the selected org changes (and the lists appear to be completely accurate).

I select the org & project, and a person in the assigned dropdown, add other details, and save node.

If I have gone through an org direct link (such as.../node/add/stormtask?destination=node%2F69&organization_nid=69 ), the dropdowns are prepopulated correctly. Choosing a person from the 'assigned to' dropdown and saving the task works and produces no error.

The same is true if I go from the project direct link (such as .../node/add/stormtask?destination=node%2F11&project_nid=11 ).

However, when I go to the add task form directly (such as .../node/add/stormtask ), choose org and project, select an 'assigned to' member, and save the task, the "Illegal choice" error is displayed and the node fails to save until the assigned person is set back to 'unassigned'. Later editing the node and assigning a person, and then saving produces no error and saves fine with the assignment in place.

In the direct add task, the dropdowns for org and its dependent project populate correctly, and the 'assigned to' dropdown also populates correctly in the UI. The source of each form element appears consistent across all three methods of adding the task.

Now, one thing I noted: Upon encountering the illegal choice error, the add task form is displayed again. The org previously chosen is still selected in the dropdown, but the project dropdown acts as if no org has been chosen (it is a shortened dropdown with zero options available). To actually reselect the org, I must first select a different Org (which then populates the project dropdown for that org correctly), then select the correct org (which also populates the project dropdown correctly again). Choosing an 'assigned to' person will still always lead to the Illegal choice error no matter which person is selected or how many times the Illegal choice error is encountered. Leaving that field unassigned is the only way I can save the node correctly.

To be more detailed, watchdog shows the following as a result of this error:

Type	form
Date	Monday, February 15, 2010 - 12:02
User	(...me...)
Location	(...)/node/add/stormtask
Referrer	(...)/node/add/stormtask
Message	Illegal choice 2 in Assigned to element.
Severity	 error

The number following "Illegal choice" always corresponds to the person's nid which would appear in the $node->assigned_nid field (if it saved correctly, that is).

If I can provide any more details, please let me know, I'll be digging around today to find the source of the error, hoping to push this live for our firm tomorrow. I know I can get around the problem (by creating only add task links from projects/orgs), but I'd much rather do this right if possible.

UPDATE: Upon examining the source, I've found why form validation thinks an illegal choice is made. The "Assigned to" dropdown displays the correct list of people to the UI, but the source shows this list is populated with key-value pairs belonging to people who are members of the organization which is default in the original form.

For instance, if I have Orgs called "Foo" (with members "Jane" and "Steve") and "Bar" (with members "Doug" and "Mary"), and Foo is the default selection upon going into the add task form directly, changing from Foo to Bar will have the "Assigned to" dropdown change in the UI to show the correct people (Doug and Mary are now listed). However, the source shows that the Assigned To dropdown still contains key-value pairs belonging to Foo (Jane and Steve) no matter which org/project is selected and despite the form dropdown in the UI showing the correct list.

Upon validation, the form balks at the fact that, for example, the nid for Doug was passed despite the form only knowing about nids for Jane and Steve.

Will keep digging.

Island Dave’s picture

I have just tested this cross-browser, and the Illegal Choice error is found in IE8, Fx3.5, and Opera10

Magnity’s picture

Category: support » bug
Priority: Normal » Critical

Bumping up, and changing status to probable bug. Although I haven't reproduced it myself yet.

juliangb’s picture

This issue has been quiet for a couple of months. Could I confirm that the error is still present and causing a problem?

If so, it sounds from reading through that this is a javascript issue. Anyone with an eye for that sort of thing? It isn't my strongest point...

tazus’s picture

I have the same problem as #12.

What I got from Watchdog is:

Illegal choice 57 in !name element. (57 is the person_nid) but I got "!name" instead of "Assigned to".

The problem is when I download the whole system to Winodws AMP testing local site but I can't reproduce the problem. It looks like not the problem of Storm but the parameter passing to core module? I did a search with this error title and other modules' patches were talking about the leading space.

Hope this help.

juliangb’s picture

Do you have links to any of these other errors that you think are related?

twooten’s picture

Just wanted to confirm that I have had the exact same experience as #12. I'm using 6.x-1.x-dev downloaded 4-16-2010. Wish I was a JavaScript guru but alas, I am not.


Carsten Müller’s picture

Version: 6.x-1.30 » 6.x-1.x-dev
Status: Active » Needs review
4.62 KB
PASSED: [[SimpleTest]]: [MySQL] 94 pass(es). View


here is a patch for this bug. Please review and test if this fixes the issue.


juliangb’s picture

Any chance of some more explanation as to where the problem was and how the patch solves it to aid in reviewing? Thanks.

Carsten Müller’s picture

Hi juliangb,

sure, here an short explanation:

The problem is, that the form is fetched from the cache when it is submitted. The options from the select items are fetched from the cache too. So the options are the loaded options when the form waas rendered through the form API. If the options are modified by JavaScript they are not available during the validation of the form through the form.inc.
So, first in the form itself the options have to be fixed by checking the submitted form values ($form_state['post']['organization_nid'], $form_state['post']['project_nid'])

if ((!empty($form_state['post']['organization_nid']) && is_numeric($form_state['post']['organization_nid'])) && (!empty($form_state['post']['project_nid']) && is_numeric($form_state['post']['project_nid']))) {
  $options = storm_get_assignment_options($form_state['post']['organization_nid'], $form_state['post']['project_nid']);
else {
  $options = storm_get_assignment_options($node->organization_nid, $node->project_nid);

Then it has to be avoided that the form is fetched from the cache. (only possible in hook_form_alter())


This should avoid the error message of this issue, because the right options are set during the validation of the form in the form.inc.

And at least i added a pre render function which checks the options of the form before it is rendered as HTML. This makes sure, that the right options are displayed in the form if an error occurs.

 * pre render the timetracking form before it is rendered as html
 * update the options of the select forms because they maybe were modified by javascript
 * but the form is fetched from the cache without the modifications
 * @param unknown_type $form
function stormtask_pre_render_task_form($form) {
  // --------------------
  // --------------------
  if (!empty($form['group1']['organization_nid']['#value']) && $form['group1']['organization_nid']['#value'] != $form['group1']['organization_nid']['#default_value']) {
    $form['group1']['organization_nid']['#default_value'] = $form['group1']['organization_nid']['#value'];
  // ----------------
  // ----------------
  if (!empty($form['group1']['project_nid']['#value']) && ($form['group1']['project_nid']['#value'] != $form['group1']['project_nid']['#default_value'])) {
    $form['group1']['project_nid']['#default_value'] = $form['group1']['project_nid']['#value'];
    $s = "SELECT n.nid, n.title FROM {node} AS n INNER JOIN {stormproject} AS spr ON spr.vid=n.vid
    WHERE n.status=1 AND spr.organization_nid=%d AND n.type='stormproject' ORDER BY n.title";
    $s = stormproject_access_sql($s);
    $s = db_rewrite_sql($s);
    $r = db_query($s, $form['group1']['organization_nid']['#value']);
    $projects = array();
    while ($project = db_fetch_object($r)) {
      $projects[$project->nid] = $project->title;
    $form['group1']['project_nid']['#options'] = $projects;
  // -------------------
  // -------------------
  if (!empty($form['group1']['parent_nid']['#value']) && $form['group1']['parent_nid']['#value'] != $form['group1']['parent_nid']['#default_value']) {
    $form['group1']['parent_nid']['#default_value'] = $form['group1']['parent_nid']['#value'];
    $tree = _stormtask_get_tree($form['group1']['project_nid']['#value']);
    $parent_tasks = _stormtask_plain_tree($tree);
    $form['group1']['parent_nid']['#options'] = array(0 => '-') + $parent_tasks;
  // -------------------
  // -------------------
  if (!empty($form['group5']['assigned_nid']['#value']) && $form['group5']['assigned_nid']['#value'] != $form['group5']['assigned_nid']['#default_value']) {
    $form['group5']['assigned_nid']['#default_value'] = $form['group5']['assigned_nid']['#value'];
    $options = storm_get_assignment_options($form['group1']['organization_nid']['#value'], $form['group1']['project_nid']['#value']);
    $form['group5']['assigned_nid']['#options'] = $options;
   return $form;

The main problem is that in the form.inc during the validation of the form the old options are set because the form is fetched from the cache.


Carsten Müller’s picture

The followin line in hook_form_alter() breaks the upload


because there is a validation in the upload module

// Load the form from the Form API cache.
  if (!($cached_form = form_get_cache($_POST['form_build_id'], $cached_form_state)) || !isset($cached_form['#node']) || !isset($cached_form['attachments'])) {
    form_set_error('form_token', t('Validation error, please try again. If this error persists, please contact the site administrator.'));
    $output = theme('status_messages');
    print drupal_to_js(array('status' => TRUE, 'data' => $output));
Carsten Müller’s picture

The Java Script Callbacks have to be changed like the function upload_js() in the upload.module to handle the problem of the cached form. the form has to be cached each time it is changed by JS

Because i am not a js expert i'll try to give the problem to weboholic. When he has time again he can maybe write a patch.

juliangb’s picture

Status: Needs review » Needs work

CNW based on #22 and #23.

minorOffense’s picture

I'm experiencing this bug (or something very similar) with v1.34 of Storm. I tried the patch and it didn't fix my problem.

Essentially, if you create a task from the main storm page (http://example.com/storm) by hitting the plus sign, switching the organization to something other than the first option, then you can't then select a user to assign it to (as long as that user doesn't belong to that initial organization and the one you've selected).

But if you go to a specific project, then click the add task button, everything works fine.

Hopefully this helps track down what's going on.

vojnar’s picture


Did not resolve this issue

Francewhoa’s picture

Confirming this issue is also present in Storm 6.x-1.35

Steps to reproduce issue

  1. Go to /storm/tickets
  2. Click on "Not filtered | ** items per page" link to expend it
  3. Click on "Reset" button
  4. Click on the add Ticket button "+". Located on the right side of the page.
  5. Under "Organization" select the second listed Organization. The issue is only present with the second or following listed Organization. Not with the first listed Organization.
  6. Select any "Project"
  7. Leave all the other fields to their default value
  8. Type in a "Title"
  9. Click on "Save" button
  10. Storm will return the error message. Expected result is Storm should not return an error message.

The same issue is also present on all the other Storm pages with a add Ticket button. Storm will return the same error message with all add Ticket buttons. Except one: If you first go to a specific Project, then click the add Ticket button, then Storm will NOT return the error message. For this to work ensure you leave the default specific Project selected.

EDIT: Steps updated on Mar 27

weboholic’s picture


we are currently working with storm 6.x-2.x-dev and we don't have the issue anymore. Can you confirm, bug is fixed in 6.2.x. Or else please provide some very thorough step-by-step description to reproduce the bug.


juliangb’s picture

Version: 6.x-1.x-dev » 6.x-2.x-dev
Status: Needs work » Closed (cannot reproduce)

Based on #28.

Please reopen if you're still seeing this issue.

bradspry’s picture

Status: Closed (cannot reproduce) » Needs work

The issue is absolutely still present in 6.x-2.x-dev.

The steps to reproduce are exactly what's found in post #27 above.

"Under "Organization" select the second listed Organization. The issue is only present with the second or following listed Organization. Not with the first listed Organization."

juliangb’s picture

Status: Needs work » Closed (won't fix)

This issue has been fixed in Project Management (Drupal 7) as we now use core APIs for altering the form, so the system never thinks that an illegal choice has been detected.

Whilst I realise that this is critical for those users that experience it, it is also something that developers are having trouble systematically reproducing, so I propose we do not spend time on this and instead focus on how we can help migrate Storm users to the Drupal 7 version of Project Management.