Revert number inputs for fields with labels on the problem set detail page. #2823
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
drgrice1
force-pushed
the
bugfix/problem-set-details-number-settings
branch
from
1398a78 to
20986a4
Compare
Member
Author
|
Note that this also does not set the |
… page. This is a quick fix that will make things function for now, and is good for a hotfix. This just reverts all of the fields that were switched to number inputs and that have labels for special negative values back to text inputs and the functionality prior to WeBWorK 2.20. The fields that do not have those labels can still be number inputs. That will work fine for those. Also set the default for showMeAnother to the "Course Default" instead of "Never" which is what it should be. This resolves issue openwebwork#2820 for the current release. We can try to do better for the next release, but I don't see any other easy way to fix this that is appropriate for a hotfix.
drgrice1
force-pushed
the
bugfix/problem-set-details-number-settings
branch
from
20986a4 to
f37ba13
Compare
dlglin
approved these changes
Sep 23, 2025
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this pull request
Nov 10, 2025
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.
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this pull request
Dec 2, 2025
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.
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this pull request
Dec 9, 2025
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.
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this pull request
Dec 10, 2025
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.
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this pull request
Dec 19, 2025
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.
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this pull request
Dec 30, 2025
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.
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this pull request
Dec 31, 2025
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.
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this pull request
Jan 1, 2026
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.
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this pull request
Jan 2, 2026
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.
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this pull request
Jan 2, 2026
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.
drgrice1
added a commit
to drgrice1/webwork2
that referenced
this pull request
Jan 13, 2026
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a quick fix that will make things function for now, and is good for a hotfix. This just reverts all of the fields that were switched to number inputs and that have labels for special negative values back to text inputs and the functionality prior to WeBWorK 2.20.
The fields that do not have those labels can still be number inputs. That will work fine for those.
This resolves issue #2820 for the current release.
We can try to do better for the next release, but I don't see any other easy way to fix this that is appropriate for a hotfix.