Remove the label/value hack on the "Set Detail" page.

[drgrice1]

This make those fields that have the special word values (such as "Unlimited", "Set Default", etc.) be numeric inputs again. However, those special word values are separated into a select. So now there is a select and a number input. The select gives the option to choose one of those word values, and it also has a numeric option (labeled appropriately for the field). When that numeric option is selected then the value in the number input is used.

With this change the old "undoLabels" hack is no longer needed. That is the hack that switched the word values back to the numeric values server side. The select options already have the correct value. The select also has a special "numeric" value that signals that the number in the number input is to be used instead.

This is an approach to replace the previous number input approach implemented in #2820 and reverted in #2823. Unfortunately that approach had some issues that could not be relegated purely with a number input.

I also noticed that there was an issue when the $test{maxProblemsPerPage} variable is set to 1. In that case the problems_per_page setting would not be shown when editing the global set or editing a set for several users. However, when editing the set for a single user the setting would be shown, although it still couldn't be edited. It doesn't make any sense to show an option that can't be edited for the set as a whole, and isn't even shown in that case, when editing for a single user. In fixing that issue I noticed that the override "none" setting in the FIELD_PROPERTIES hash is rather messed up. See the comment I added on line 84 of the ProblemSetDetail.pm file. That setting is no longer used since I removed the attempted, last_answer, num_correct, and num_incorrect fields from the hash that were nonsensically included in that hash with the override "none" and type "hidden" values, which basically meant that those fields were ignored everywhere.

Note the FIELD_PROPERTIES_GWQUIZ constant was also remove because it was not used in actuality. The only field in that hash was the max_attempts field, but since it is no included in the GATEWAY_PROBLEM_FIELD_ORDER array that hash key was never accessed.

[Alex-Jordan]

This is good!

[somiaj]

Should we allow 0 attempts? Though I guess 0 does make sense for show me another and show hints.

Also when moving from Unlimited to Limit to, maybe fill in a default value? Though I don't know what a good default would be, but the number field being empty was a bit strange to me.

[somiaj]

Not part of this pull request, but while I was looking at it, was wondering if the 5/7 for col size could be changed to 4/8 for larger windows, so add a col-lg-4 and col-lg-8 styles appropriately. This looks a little better for my window sizes.

I did think this was to keep the words in the drop down menu from getting cut off for various window sizes, but currently if the window size is near the md break point, they do get cut off. Also right at the md break point, you can't even see the numbers in the number select if the menu is open.

[somiaj]

Just checked, didn't realize that it is currently possible to allow 0 attempts, so that is nothing new with this PR, but maybe something to consider.

[drgrice1]

The only option for setting a value when switching from the non-numeric select values to the numeric value would be to use the min attribute of the number input. I can set it up that way, but I don't really see the benefit of that. In the case of max_attempts that would be 0 which has always been a valid value for this, although I don't know why, and that wouldn't usually be what is desired, so it still requires changing the input value. For the others the minimum value might be what is desired (I use 0 for showMeAnother in my classes), but it frequently won't be.

The suggested addition of col-lg-4 and col-lg-8 is not a good idea. When the window size is between the md and lg break points but close to the md break point that has display issues similar to those you mentioned in between the sm and md break points, and I don't really see the benefit you suggest is there when the window is considerably above the lg break point. I also don't think you are taking into account what happens when you are editing a set for a user. The fields take up even more width, because the "course" values are also shown.

As to the issue when the window size is in between the sm and md break points but close to the sm break point, the only option that I see would be to change to using col-lg-5 and col-lg-7 instead of col-md-5 and col-md-7 for the split of the fields and the problem render area. That would mean that already in the md range the problem rendering is below as it is currently when below the sm break point, but in testing, that actually seems to work rather well. So I think I will switch to that. Even with that the display is not so great right above the sm break point, but there isn't much more that can be done.

[drgrice1]

I went ahead and made it so that when switching from a non-numeric selection to the numeric selection, the number input now gets the minimum value.