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 openwebwork#2820 and reverted in openwebwork#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.

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 openwebwork#2820 and reverted in openwebwork#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.

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 openwebwork#2820 and reverted in openwebwork#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.

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 openwebwork#2820 and reverted in openwebwork#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.

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 openwebwork#2820 and reverted in openwebwork#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.

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 openwebwork#2820 and reverted in openwebwork#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.

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 openwebwork#2820 and reverted in openwebwork#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.

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 openwebwork#2820 and reverted in openwebwork#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.

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 openwebwork#2820 and reverted in openwebwork#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.

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 openwebwork#2820 and reverted in openwebwork#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.

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 openwebwork#2820 and reverted in openwebwork#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.