Add point input to ProblemGrader.

[somiaj]

Add a point input field to set the problem score in the ProblemGrader. This is the same as what is being used in the SingleProblemGrader, and honors the same setting to show it or not. The input uses JavaScript to update the actual score which is what is submitted when the grader is saved. If the percent score is not shown, a hidden field is used instead.

This also adds a step of 1 to the percent score and validation on both the percent score and point score values.

Note, I couldn't think of a way to nicely use the same javascript for both the ProblemGrader and SingleProblemGrader due to slight differences in how the pages are setup and the fact the SingleProblemGrader shows per part scores too, so there is some duplication of the javascript to update the point and percent values.

[drgrice1]

I think that it would be better to put the point and score inputs into separate columns instead of trying to stack them in the same columns in the case that both are shown.

[somiaj]

Another thought I had, should checking the 'Mark Correct' checkbox set the score to 100% and points to max in the form with the javascript. It currently isn't doing that, but that is what happens in the end anyways, so that might be useful, or are there use cases where someone may want to uncheck it and keep the old score?

I will update it to separate columns, I just thought in terms of space it fit nicely there since that was empty space when there was more than one answer part.

[Alex-Jordan]

I think the ideal would be that the problem has an additional field in the database for "mark correct" so it's always undoable. Scoring would then always need to query the individual's status as well as that flag. Alex Jordan Mathematics Instructor Portland Community College

…

On Fri, Feb 27, 2026, 7:59 AM Jaimos Skriletz ***@***.***> wrote: *somiaj* left a comment (openwebwork/webwork2#2921) <https://urldefense.com/v3/__https://github.com/openwebwork/webwork2/pull/2921*issuecomment-3973718552__;Iw!!Ka_JY85zDv0FFw!mqvw3W3j8W6nddCNMg4UP2GQMU7NzGL5BLXGZWIw5WHpvQjLAcO74eJo-qPxiQHplA8pg45w3GMVvLiVnjwE-bJvb0Q$> Another thought I had, should checking the 'Mark Correct' checkbox set the score to 100% and points to max in the form with the javascript. It currently isn't doing that, but that is what happens in the end anyways, so that might be useful, or are there use cases where someone may want to uncheck it and keep the old score? I will update it to separate columns, I just thought in terms of space it fit nicely there since that was empty space when there was more than one answer part. — Reply to this email directly, view it on GitHub <https://urldefense.com/v3/__https://github.com/openwebwork/webwork2/pull/2921*issuecomment-3973718552__;Iw!!Ka_JY85zDv0FFw!mqvw3W3j8W6nddCNMg4UP2GQMU7NzGL5BLXGZWIw5WHpvQjLAcO74eJo-qPxiQHplA8pg45w3GMVvLiVnjwE-bJvb0Q$>, or unsubscribe <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABEDOADJ2MKWWJMGSOXUN734OBSXHAVCNFSM6AAAAACWBEBZ5GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSNZTG4YTQNJVGI__;!!Ka_JY85zDv0FFw!mqvw3W3j8W6nddCNMg4UP2GQMU7NzGL5BLXGZWIw5WHpvQjLAcO74eJo-qPxiQHplA8pg45w3GMVvLiVnjwEqyfT-NM$> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[drgrice1]

No, the javascript should not modify the point and score inputs when the mark correct checkboxes are used. It is very easy to accidentally check a checkbox, and that would mess things up.

@Alex-Jordan: I don't think that @somiaj is referrng to undoing from the database. I think he just meant undoing what has been done in the UI. I don't think that adding a mark correct field in the database is a good idea. If we were to do that, then shouild we add a complete history of grade changes that is stored for a real undo? I don't think that is a road I want to go down.

[somiaj]

@Alex-Jordan yea, I wasn't thinking of going as far as changing the database or going down that path. I was just wondering if the UI should update.

@drgrice1 I was coming to the same conclusion and was considering if I went that route, saving the previous score in the dataset of the checkbox so it could be undone easily. Though I will just leave it as it is, just something I noticed while testing things out.

[somiaj]

Updated the layout so it puts the points and percent in their own column.

[somiaj]

@drgrice1 I cannot find any CSS defined for the class score-selector attached to the score % and now the point value since I copied over all classes, and it appears this is also not being used in any javascript. I am going to remove it unless I overlooked something.

[drgrice1]

I was actually going to suggest that you remove it. I had also seen that it is unnecessary.

[drgrice1]

I don't exactly see the point of adding this stash value. The problem is in the stash, and so the value can be accessed from there anywhere already. Stashing the problem value additionally is unnecessary.

Although, there is perhaps a bigger issue with this in the pull request in general. This is using the same problem value for all students. Yes, usually this is the same for all students, but it does not have to be. The problem value can be set per student. It is probably bad teaching practice to do so, but it is a supported override setting. So the merged user problem should be used for this instead. The single problem grader does use the user's specific value for the problem.

This probably means you cannot show the Points (0 - n) in the header for the column since n is not necessarily the same for all students. Furthermore, the stepsize for the number input will need to be set for each student separately.

[somiaj]

I originally tried to use the user problem value, but it was undefined in my tests because the ProblemGrader currently isn't pulling in merged sets. Which lead me to just using the template assuming that if someone was going to make different users have different values, they would be able to adjust. But I agree, I probably should have dug deeper (mostly I was just trying to get something to work and forgot to go back and deal with this, so thanks for catching it).

Instead of using the merged set, I am still going to use the template set value unless the user set value is defined and different. So I left the header Points (0 - n), since it probably relevant most the time.

In the case that a user's set value differs from the template set, I use it for the max value and the stepsize. I then write Points (0 - m) under the the number input to let the user know that the point value is different in this case.

I'm not fully sold on adding the Points (0 - m) there. I probably need to update the aria stuff for accessibility. Maybe a tooltip would be better. I am going to think on it a bit, but I have pushed my updates and any other suggestions are welcomed.

[somiaj]

I tried to put 0 - n as a tool tip for each number input, and I am not liking that any better. Since it will probably be rare this case happens, probably best to show the different point range in the rare case it was different than the template set.

[somiaj]

I am thinking maybe a tooltip only on the number inputs that differ from the template set would work and be the least intrusive.

[drgrice1]

This looks good now (other than the minor character limit issue).

I think that what you have done will work for the case that a user has the value for a problem overridden. Although, there is one odd case. If the value for the global problem is nonzero, and the user's value is overridden to be 0, then things don't quite work right. You can ignore this for now if you don't want to mess with this probably extremely rare odd case. Even with the single problem grader this case is a bit odd. It shows points possible of 0-0 and if the user has a status of 0, then it shows the user has 0 points, but 100%.

[drgrice1]

This is exceeding the 120 character limit. Probably the cleanest way to fix this is to change it to

Suggested change

	% param("$userID.$versionID.score", undef);
	<%= number_field "$userID.$versionID.score" => wwRound(0, $_->{problem}->status * 100),
	% param("$userID.$versionID.score", wwRound(0, $_->{problem}->status * 100));
	<%= number_field "$userID.$versionID.score" => 0,

That is equivalent in behavior. The same change would fix line 232 exceeding the character limit.

[somiaj]

Thanks, unsure how I missed that exceeded 120 characters.

[drgrice1]

To fix the user value 0 versus nonzero set value issue, I think it is sufficient to just change this to

Suggested change

	% my $problemValue = $_->{problem}->value || $problem->value;
	% my $problemValue = $_->{problem}->value ne '' ? $_->{problem}->value : $problem->value;

This exceeds the 120 character limit by 1, but we can let that slide. Note that $_->{problem}->value will always be defined and is the empty string if NULL is in the database. So there is no need to also check that it is defined.

[somiaj]

% my $problemValue = ($_->{problem}->value ne '' ? $_->{problem} : $problem)->value;

Does the same thing and doesn't exceeded 120 characters so I went with that.

[drgrice1]

Yep. That works too. Looks good.

[somiaj]

I added one more tweak, in the case the user value is different than the template value, I put the label Points (0 - n) in a div with an id, and updated the aria-labeledby of the number input to use that vs the set header for accessibility.