Is there a way to limit the number of times a student can use the check button or disable it? Even if the penalty is 100 we do not want students to "guess" the right answer by running their solution an infinite number of times.
And how is the answer graded if we disable the check button?
A really dirty way to hide the check button is adding javascript to the question:
window.onload = function() {
var el = document.querySelector(".im-controls");
el.style.display = "none";
};
There's currently no way to disable the Check button. I am planning on providing a checkbox to disable it in the question editing form, but I hadn't considered making it programmable. I'll think about that.
If the Check button is hidden the question will still be graded when the student submits and finishes the quiz.
Your cunning dirty way of hiding the check button has proved useful to me and a couple of colleagues, by the way! But because we wanted to hide the Check button for only some of the questions in the page, and wanted to leave the Precheck button usable, I we extended it so that it hides only the Check button and only for questions that contain an element of class 'cr_hide_check_button'. I just paste the entire script into each question that should have Check hidden - it means the script runs multiple times and hides the same buttons multiple times but we don't usually have more than a couple of affected questions on a page. The script also has lots of extra checks in it to make sure the world is as I expect. It does seems rather complicated though - perhaps someone can suggest an easier way of doing this?
<div class="cr_hide_check_button">
<script>
window.onload = function() {
var all_qs_to_hide, me, controlDiv, buttons, button, i, j;
all_qs_to_hide = document.getElementsByClassName('cr_hide_check_button');
for (i = 0; i < all_qs_to_hide.length; i++) {
me = all_qs_to_hide[i];
do {
me = me.parentNode; // Search up the dom for the content div
} while (me && me.className.indexOf('content') === -1);
if (me === null) continue;
controlDiv = me.getElementsByClassName('im-controls'); // Buttons div (should be just 1)
if (controlDiv && controlDiv.length === 1) {
buttons = controlDiv[0].getElementsByClassName('submit');
for (j = 0; j < buttons.length; j++) {
button = buttons[j];
if (button.tagName === 'INPUT' && button.type === 'submit' && button.name.indexOf('submit') !== -1) {
button.style.display = 'none';
}
}
}
}
};
</script>
</div>
Of course, hiding the Check button in this way is unsafe - a sufficiently cunning student can unhide it again and click it. But if I implement a show/hide Check button feature, I can disable the functionality properly.
Hello, how can the code be added to the question?
You need to have the question open in a HTML editor. The default Moodle editor, Atto, has an HTML mode, activated with the '</>' button. Or you can set your default editor in your personal preferences to "Plain text". However you can't use the TinyMCE editor, which strips <script> tabs.
When the question is open in HTML mode, just paste the entire script at the end. You won't see it when you go back to WYSIWYG mode, but it's still there :)
Thank you very much, I changed the editor to atto, perfect, solved the exam problem, thank you again.
Hi,
Sorry for reviving this thread. I've just added this feature into a questionnaire, that I will use as an exam, in order to prevent students to guess answers by trial and error.
But now I'm worried about the load this may throw onto the Jobe server. The questionnaire is configured to open and close at given instants in time and, as I understand this, when time expires, will all questions, of all students (that have not yet closed the exam), be thrown onto the Jobe server to be graded with IS_PRECHECK == 0? In my case this may lead to jobs in the thousands.
Thanks and regards.
That's a good question but I'm not sure I have a good answer. My gut feeling is that you won't have a problem, but the dynamics of the combination moodle/jobe servers at the end of a quiz are very complex and I don't feel very confident predicting outcomes.
A few semi-random observations:
- All load on Jobe comes from Moodle, so Jobe's peak load is limited by the rate at which Moodle can process all the quiz-closing submissions. That smoothes out the load on Jobe a lot.
- I often monitor Moodle and Jobe load factors during tests. Both peak a bit at the end of a normal quiz (when there are always unsubmitted questions to be graded) but peaks are generally pretty moderate.
- As a rule of thumb, it's probably a good idea to have a Jobe server with comparable specs to the Moodle server. If the Jobe server specs are much lower than Moodle's, the risk of Jobe overload is higher.
- Our 8-core Jobe server can handle peak loads of several hundred C or Python submissions per second, although steady-state loads are down around 100 submissions per second or less. But Java is a complete dog in comparison. Even a simple hello world Java run consumes over 1 sec of CPU time, which is around 40 times the cost of C or Python.
- At the end of a quiz, all runs will not be submitted simultaneously. The JavaScript timeout starts from when the user clicks start, and in our exams there's typically a range of up to a minute in those times.
- You can always smooth start and finish loads by walking slowly down a lab, starting groups in waves as you walk. We used to do that as a matter of course, but nowadays don't bother.
Thanks for the info. I think you'll be OK. And in the worst case scenario a regrading should resolve any problems, anyway. Regrading is single-threaded, so places only a light load on Jobe.
I'm afraid there's no way to monitor server loads if you're not a sysadmin. Except in the case of overload :)
Richard