For courses like Calculus, where some instructors don't use Webwork, we would like to make Webwork available to any students who would like to use it to test their calculus skills. Initially, we thought we would set it up by:
1. Creating a Calculus course
2. Creating a classlist with say 30 guest accounts.
3. Assigning all the problem sets to the guest accounts at the beginning of the semester
4. A student would login into Webwork by choosing one of the guest accounts to use.
The only problem we see with this arrangement is that if student A logs in as "guest001" and then student B logs in as "guest001", the system may be confused and this may cause a problem for one/both of the students.
Other than getting the class lists for all the students in the entire course each semester (which we'd prefer not to have to do), is there a better way (or any other way) to have a "public" Webwork course that any student could log into it for practice?
Thanks,
Tom
How to have a Webwork course open to the entire student body?
by Thomas Hagedorn - Number of replies: 10
In reply to Thomas Hagedorn
Re: How to have a Webwork course open to the entire student body?
by Arnold Pizer -
Hi Tom,
If a student logs in as a practice user (e.g. practice2), then another student will not be able to login as practice2 until the original student log's out (or timed out). This is different than for regular users. It's set up this way for exactly the reason you state above. If a student logs in as e.g. practice2, works on some problems, logs out and then later logs in as practice2, they will see exactly the same problems again (but it's possible someone else will have works on them).
Arnie
If a student logs in as a practice user (e.g. practice2), then another student will not be able to login as practice2 until the original student log's out (or timed out). This is different than for regular users. It's set up this way for exactly the reason you state above. If a student logs in as e.g. practice2, works on some problems, logs out and then later logs in as practice2, they will see exactly the same problems again (but it's possible someone else will have works on them).
Arnie
In reply to Thomas Hagedorn
Re: How to have a Webwork course open to the entire student body?
by Davide Cervone -
By default, the practice accounts are named "practice1", "practice2", etc. If you really want to call yours "guest001", etc., you can do that by putting
$practiceUserPrefix = "guest";in the couse.conf file for this course. The students will have to use the "login as guest" button on the login page, since WeBWorK won't accept a practice account name explicitly in the login name box.
It is possible to make a link that will log you in automatically using the first free guest account by using an address of the form
http://yourserver/webwork2/yourcourse/?login_practice_user=true
You can have this link on a page that gives students the information that this course is available to them, for example. You could also make it a button rather than a link by using this URL as the target of a form:
<FORM METHOD="POST" ACTION="http://yourserver/webwork2/yourcourse/?login_practice_user=true">
<INPUT TYPE="SUBMIT" NAME="submit" VALUE="Practice Calculus">
</FORM>
If you set the permissions for the course correctly, then the answers will not be saved and so won't be displayed when the next person logs into the same practice account. I think you can also arrange it so that there is only a "check answers" button rather than "submit" and the "number of attempts" will always be 0 rather than showing how many times other people tried the problem. Making sure that the guest accounts have permission level -5 (the standard guest permission level) is the first step in that.
Anyway, hope that helps.
Davide
In reply to Davide Cervone
Re: How to have a Webwork course open to the entire student body?
by Paul Bolton -
How could this be done? When I set the permission level to 0, the student level, the number of attempts is recorded, as is whether or not the account user, perhaps a different user with the same practice account, has previously answered a given question correctly. When I set permission level to -5, the guest level, it seems that users can then only preview answers, not check them for correctness.
Paul Bolton
University of Manchester
Paul Bolton
University of Manchester
In reply to Paul Bolton
Re: How to have a Webwork course open to the entire student body?
by Samuel Lundqvist -
To let a guest user submit answers, change
record_answers_after_open_date_with_attempts = student
to
record_answers_after_open_date_with_attempts = guest
in global.conf
However, "number of attempts" still shows how many times the practice user has tried the problem. There is a variable called record_answers_after_open_date_without_attempts
but setting it to "guest" and record_answers_after_open_date_with_attempts to "student" won't help.
This makes me wonder what the purpose of the record_answers_after_open_date_without_attempts variable is?
Best regards
Samuel Lundqvist
record_answers_after_open_date_with_attempts = student
to
record_answers_after_open_date_with_attempts = guest
in global.conf
However, "number of attempts" still shows how many times the practice user has tried the problem. There is a variable called record_answers_after_open_date_without_attempts
but setting it to "guest" and record_answers_after_open_date_with_attempts to "student" won't help.
This makes me wonder what the purpose of the record_answers_after_open_date_without_attempts variable is?
Best regards
Samuel Lundqvist
In reply to Samuel Lundqvist
Re: How to have a Webwork course open to the entire student body?
by Gavin LaRose -
Hi Samuel,
The record_answers_after_open_date_with_attempts and _without_attempts variables come into play for gateway/quiz assignments, for which it seemed ideal to have another level of control over who could record results or create new set versions.
(Sorry about that; I wrote, then actually checked the ContentGenerator code more carefully.) The _without_attempts variable is used when a problem is submitted after all allowed attempts on the problem have been exhausted.
Gavin
(Sorry about that; I wrote, then actually checked the ContentGenerator code more carefully.) The _without_attempts variable is used when a problem is submitted after all allowed attempts on the problem have been exhausted.
Gavin
In reply to Samuel Lundqvist
Re: How to have a Webwork course open to the entire student body?
by Dick Lane -
Is Samuel's recipe
change value of
record_answers_after_open_date_with_attempts
from "student" to "guest" in %permissionLevels section of global.conf
still the best way to enable a "Submit Answers" button for the Practice users? E.g., is that the method used for the model_Calculus_1 course at test.webwork.maa.org ?
change value of
record_answers_after_open_date_with_attempts
from "student" to "guest" in %permissionLevels section of global.conf
still the best way to enable a "Submit Answers" button for the Practice users? E.g., is that the method used for the model_Calculus_1 course at test.webwork.maa.org ?
In reply to Dick Lane
Re: How to have a Webwork course open to the entire student body?
by Dick Lane -
Would it be preferable to have that change of value be done in an individual course.conf file? If so, can this be done without needing to include all 75 lines from that section of global.conf ?
In reply to Dick Lane
Re: How to have a Webwork course open to the entire student body?
by Michael Gage -
it is still a reasonable way to do it.
model_Calculus_1 uses an alternative approach -- it simply gives practice1, practice2, practice2, etc. the "student" permission level instead of the guest permission level. This is easily done from the classlist editor and there is no need to change lines in global.conf or course.conf.
If you want to change just one of the permission levels in the course.conf file you use this syntax:
$permissionLevels{record_answers_after_open_date_with_attempts}="guest";
which changes just that entry in the %permissionLevels "hash" (or key/value data structure).
The code in global.conf is written using the Perl syntax.
The book "Learning Perl" is one of the best introductions and gives you more than enough knowledge to understand the hidden workings of WeBWorK.
model_Calculus_1 uses an alternative approach -- it simply gives practice1, practice2, practice2, etc. the "student" permission level instead of the guest permission level. This is easily done from the classlist editor and there is no need to change lines in global.conf or course.conf.
If you want to change just one of the permission levels in the course.conf file you use this syntax:
$permissionLevels{record_answers_after_open_date_with_attempts}="guest";
which changes just that entry in the %permissionLevels "hash" (or key/value data structure).
The code in global.conf is written using the Perl syntax.
The book "Learning Perl" is one of the best introductions and gives you more than enough knowledge to understand the hidden workings of WeBWorK.
In reply to Michael Gage
Re: How to have a Webwork course open to the entire student body?
by Danny Glin -
One thing to add to the wish list would be student self-registration, where students can create accounts for themselves in a given course. This could also be useful to professors who can not easily translate registration data into Webwork class lists.
In reply to Danny Glin
Re: How to have a Webwork course open to the entire student body?
by Michael Gage -
Since I often use moodle as a front end for my webwork courses this hasn't been high on my personal list of things that need to be done. (Moodle already allows for email registration -- then the student has access to webwork through moodle).
However, to add email self-registration to WeBWorK itself would probably not be that difficult. The module needed is a subclass of WeBWorKAuthen.pm and would be placed in the WeBWorK/Authen directory.
There are currently examples that allow verification using LDAP and Cosign and modified verifications when using Proctors. Also an obsolete protocol for Moodle for an earlier bridge between Moodle and WeBWorK.
The LDAP and Cosign don't require additional input from the user, but Proctor does (see ContentGenerator/LoginProctor) -- so that could be mined for ideas for the user interface for self-registratering students.
It's a project, but not an enormous project in my view. I'm happy to answer further questions if someone is interested in undertaking it.
Take care,
Mike
However, to add email self-registration to WeBWorK itself would probably not be that difficult. The module needed is a subclass of WeBWorKAuthen.pm and would be placed in the WeBWorK/Authen directory.
There are currently examples that allow verification using LDAP and Cosign and modified verifications when using Proctors. Also an obsolete protocol for Moodle for an earlier bridge between Moodle and WeBWorK.
The LDAP and Cosign don't require additional input from the user, but Proctor does (see ContentGenerator/LoginProctor) -- so that could be mined for ideas for the user interface for self-registratering students.
It's a project, but not an enormous project in my view. I'm happy to answer further questions if someone is interested in undertaking it.
Take care,
Mike