Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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!
Comment | File | Size | Author |
---|---|---|---|
#19 | stormtask_illegal_choice.patch | 4.62 KB | Carsten Müller |
#2 | storm-organizations.pdf | 110.11 KB | richoh |
CreateTaskIssue.pdf | 115.74 KB | richoh |
Comments
Comment #1
Magnity CreditAttribution: Magnity commentedYou need to select an organization.
So was the organization dropdown box empty?
Are organizations visible to you in the other Storm node forms?
Comment #2
richoh CreditAttribution: richoh commentedYes, 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.
Comment #3
Magnity CreditAttribution: Magnity commentedAre the organizations active and checked as a customer?
BTW - any chance of attaching screenshots as images so I can view them in my browser?
Comment #4
richoh CreditAttribution: richoh commentedThank 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"
Comment #5
Magnity CreditAttribution: Magnity commentedWhat could we change to avoid this confusion?
I know its something that gets a lot of people.
Comment #6
JGonzalez CreditAttribution: JGonzalez commentedWhy 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).
-Active
xxx
xxx
xxx
-Provider
xxx
xxx
xxx
-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?)
Comment #7
barathee CreditAttribution: barathee commentedI 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?
Comment #8
Magnity CreditAttribution: Magnity commentedWhich Storm organization permissions do you have?
Comment #9
barathee CreditAttribution: barathee commentedI 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.
Comment #10
Island Dave CreditAttribution: Island Dave commentedDitto 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.
Comment #11
Magnity CreditAttribution: Magnity commentedSo 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?
Comment #12
Island Dave CreditAttribution: Island Dave commentedSee 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:
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.
Comment #13
Island Dave CreditAttribution: Island Dave commentedI have just tested this cross-browser, and the Illegal Choice error is found in IE8, Fx3.5, and Opera10
Comment #14
Magnity CreditAttribution: Magnity commentedBumping up, and changing status to probable bug. Although I haven't reproduced it myself yet.
Comment #15
juliangb CreditAttribution: juliangb commentedThis 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...
Comment #16
tazus CreditAttribution: tazus commentedI 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.
Comment #17
juliangb CreditAttribution: juliangb commentedDo you have links to any of these other errors that you think are related?
Comment #18
twooten CreditAttribution: twooten commentedJust 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.
Tim
Comment #19
Carsten Müller CreditAttribution: Carsten Müller commentedHi,
here is a patch for this bug. Please review and test if this fixes the issue.
Greetings
Carsten
Comment #20
juliangb CreditAttribution: juliangb commentedAny chance of some more explanation as to where the problem was and how the patch solves it to aid in reviewing? Thanks.
Comment #21
Carsten Müller CreditAttribution: Carsten Müller commentedHi 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'])
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.
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
Comment #22
Carsten Müller CreditAttribution: Carsten Müller commentedThe followin line in hook_form_alter() breaks the upload
because there is a validation in the upload module
Comment #23
Carsten Müller CreditAttribution: Carsten Müller commentedThe 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.
Comment #24
juliangb CreditAttribution: juliangb commentedCNW based on #22 and #23.
Comment #25
minorOffense CreditAttribution: minorOffense commentedI'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.
Comment #26
vojnar CreditAttribution: vojnar commentedstormtask_illegal_choice.patch
Did not resolve this issue
Comment #27
FrancewhoaConfirming this issue is also present in Storm 6.x-1.35
Steps to reproduce issue
/storm/tickets
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
Comment #28
enikola CreditAttribution: enikola commentedHi,
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.
Cheers
Nikola
Comment #29
juliangb CreditAttribution: juliangb commentedBased on #28.
Please reopen if you're still seeing this issue.
Comment #30
bradspry CreditAttribution: bradspry commentedThe 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."
Comment #31
juliangb CreditAttribution: juliangb commentedThis 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.