Project

General

Profile

Bug #8177

Invalid values for success percentage

Added by Jurgen Gaeremyn about 6 years ago. Updated about 6 years ago.

Status:
Bug resolved
Priority:
Low
Assignee:
Category:
Exercises
Target version:
Start date:
01/04/2016
Due date:
% Done:

100%

Estimated time:
Complexity:
Normal
SCRUM pts - complexity:
?

Description

For an exercise, one can enter a percentage to define the threshold for succeeding.
It's possible to enter impossible values...

You can enter negative values. Here one could argue that it is possible to have a negative result, if you use negative scoring and don't cap your answers to zero if the value goes beneath.

You can also give values over 100. I can't possibly imagine a scenario where it's possible to achieve a 105% score.

While I don't think people will intentionally enter this, I can see accidental values being entered (500 instead of 50)

Associated revisions

Revision d3023571 (diff)
Added by jmontoyaa about 6 years ago

Add number validators see #8177

History

#1

Updated by Yannick Warnier about 6 years ago

  • Target version set to 1.10.6
#2

Updated by Julio Montoya about 6 years ago

I just added some validators

#3

Updated by Yannick Warnier about 6 years ago

  • Category set to Exercises
  • Status changed from New to Needs testing
  • Assignee set to Angel Quiroz
  • % Done changed from 0 to 80
#4

Updated by Jurgen Gaeremyn about 6 years ago

Seems to work now.
I admit, I have a bad mind (the devil is in the details)... but when you enter 66.67 as pass rate... it cuts down to 66. :)

#5

Updated by Julio Montoya about 6 years ago

Jurgen Gaeremyn wrote:

Seems to work now.
I admit, I have a bad mind (the devil is in the details)... but when you enter 66.67 as pass rate... it cuts down to 66. :)

The current database field "c_quiz.pass_percentage" is an integer.

#6

Updated by Yannick Warnier about 6 years ago

Jurgen, do you have a user case that really makes 66.67 a necessary percentage, or is it generally ok to use integers?

#7

Updated by Jurgen Gaeremyn about 6 years ago

No use case, just in the habit of trying out annoying values. :)
As far as I case, this is fixed enough.

#8

Updated by Yannick Warnier about 6 years ago

  • Status changed from Needs testing to Bug resolved
  • Assignee changed from Angel Quiroz to Julio Montoya
  • % Done changed from 80 to 100

Great, thank you!

Also available in: Atom PDF