Current values not honored when set/problem settings are changed on the problem set detail page.

[drgrice1]

This is a rather serious regression that is caused by changes in pull request #2735. That pull request changed the inputs that were previously text inputs into number inputs using place holders for those textual type values. However, it also sets the value to the actual textual value in those cases. However, browser's do not ever submit textual values ever for number inputs. The result is that if one of those textual type values is not the default value for the field, then it will be set to the default value anytime the form is submitted.

For example, the "Show Me Another" field has two textual values. Those are "Never" and "Course Default", corresponding to the numeric values of -1 and -2, respectively. The default for this happens to be -1 or "Never" (that is really wrong though, it should be -2 or "Course Default"). So if the value for a problem is set to -2 (i.e., "Course Default"), then when the problem set detail page is loaded the place holder reads "Course Default" as it should, and the value of the input from the server is the text "Course Default". So now click the "Save Changes" button without making any changes. The browser submits the empty string for that parameter since the original value from the server is not valid for the number input (in fact the browser immediately changes the invalid text value from the server to the empty string as soon as the page loads). So the server now gets the empty string from the form submission and then uses the default value for the field.

One of the worst manifestations of this is if you have all of the problems set for show me another to use the course default, and then you select the option to add a problem to the set, and then save changes. Now all of the problems in the set have show me another disabled (set to "Never").

There are several possible fixed, but one must be made and this certainly needs a hotfix.

One possible fix is to try to make the number type input work. It may work that anytime the server receives an undefined value and the current value is one of these textual type values, then the setting is not change. This is probably the ideal way to go, but I am not entirely sure that it will fully work. I haven't tried to implement it yet.

Another possible fix is to stop using these textual values at all. Instead just show -2 to mean "Course Default" and -1 to mean "Never", and count on the help for the input being sufficient to inform the user what that means. This is certainly the least transparent way to go.

The only other fix I can think of is to go back to how it was before with a text input and actual values of "Course Default" or "Never" again. This way we know works, but it is not exactly ideal.

[somiaj]

Funny enough I was just noticing this, and thought I was going mad as the values of 'show me another' kept changing.

I don't have a strong feeling about which one to use, but the final one with just using a text input is fine by me, I always type in the number and don't use the arrows/scrolling to change the number. Maybe if we revert to just a text input, put some error checking so it only accepts integer values greater than or equal to -2.

[somiaj]

sorry, meant form validation.

[dlglin]

How hard would it be to change the interface so that the options that are textual are presented as a dropdown or radio buttons, and a text box is provided if an option that requires a number is chosen? Then the inputs would processed and the correct value stored to the database.

I'm envisioning a drop down that has the options "Never", "Course Default" and "After this many attempts" (there's probably a better way to word that choice). If the last option is selected, then javascript would show a text box to enter the number of attempts.

[somiaj]

I do like @dlglin suggestion, though one thing to consider since we need a hotfix, would changing the interface that much for a hotfix be acceptable (I don't care either way). Maybe a simple fix for the hotfix and then a change to the interface as @dlglin suggested for the next release? Just a thought. Only possible down side of having a drop down and an input would be takes up more space, but I think with the current layout that isn't a big issue.

[drgrice1]

I think that attempting to change the setting in that way would be extremely challenging. Making that work when editing the global set for all users and at the same time for specific users would not be particularly easy. Fitting that many UI elements into the layout as it is would be nigh impossible. Also, your situation only describes the show me another setting. Other settings would be different. Note that this bug does not only affect the show me another setting. That is just the one that I used to demonstrate the issue in my example.

For a hotfix that certainly shouldn't be done.

[Alex-Jordan]

Sorry for my role in causing this. I can't pay attention to the details until next week, but I'm happy to approve anything you all tell me to approve to get a hotdog in.

[drgrice1]

I am pretty sure you are not solely to blame for this. The review process is there so that these things get caught. So the reviewers that approved this are also at fault. I was one of those. So I am to blame as well.