Webservices create course, add/drop user. #7
Conversation
Same as the other xmlrpc functions, requires the same authentication
credentials to initiate a session. Also has the actual actions being
carried out by a separate module named CourseActions.
Beside the authentication credentials, each call needs these new entries
as part of the parameter.
createCourse:
"name": "course name"
"section": 100
addUser:
"firstname": "John"
"lastname": "Smith"
"id": "The Doctor" # username
"email": "doctor@tardis"
"studentid": 87492466
"userpassword": "password" # defaults to studentid if empty
# if studentid also empty then no
# password
"permission": "professor" # valid values from %userRoles
# in global.conf
# defaults to student if empty
dropUser:
"id": "The Doctor" # username
Note that dropUser does not delete the user, only marks them as dropped
from the course. Because of this, addUser has to deal with two cases: an
actual new user or a re-enrolling user.
The method return is the same as the other xmlrpc calls, except with a
'status' entry marking the call as 'success' or 'failure'. 'failure'
means the action did not go through, there will be an accompanying
'message' entry with the error message.
The course actions in webservices are now configured to be disabled by
default in global.conf.dist. In case there are security concerns.
There are 3 configuration options available now under the $webservices
hash.
1. enableCourseActions - If set to true, course actions will proceed.
Note that the course action enable check takes place after the normal
auth credentials check, not before.
2. enableCourseActionsLog - Will keep a record of course creations and
user add/drops in the log file.
3. courseActionsLogfile - Where the logfile is stored, defaults to
courseactions.log in the default Webwork logs directory.
To enable, just override in postlocal.conf e.g. add:
$webservices->{enableCourseActions} = 1;
$webservices->{enableCourseActionsLog} = 1;
During course creation using webservices, an admin user is added to the
course. This admin user is necessary since there isn't a classlist and
we need at least one user in the course. The admin user will be created
with the username and password specified in global.conf.dist.
These settings can be overwritten in postlocal.conf with:
$webservices->{courseActionsAdminUser} = "admin2";
$webservices->{courseActionsAdminPassword} = "blahblah";
The default admin user is "admin". It is recommended that the password
be changed from the default.
A new student joining the course late needs to be assigned the same
homework sets as the other students. There is now an option to enable
assigning all visible homework sets to new and re-enrolled students.
By default, this is disabled, to enable, override in postlocal.conf
with:
$webservices->{courseActionsAssignHomework} = 1;
|
Hi ionparticle, Thanks for patch. here are a few of my thoughts. From the web you can only create courses if you are logged in to admin course as an instructor. And when a new course is created all of the instructors in the admin course are added as instructors in the new course (instructors in the admin course should be thought of as administrators with access to all courses.) This can be modified after the course is created of course. Would this fit with your use cases for the "create a course" webservice? This means that not just any one with access to some course through the webservice can create a new course. Only those registered in the admin course can create one. On creating a new course I understand that you are concatenating the courseName and section to form a "courseID" What do you think? -- Mike |
|
Hi ionparticle and Mike, Just a short clarification. When Mike says "when a new course is created all of the instructors in the admin course are added as instructors in the new course", this is the default action. There is a checkbox on the course creation page that can be unchecked and then instructors in the admin course are not added as instructors in the new course. I haven't really looked at this but I agree with Mike's comments above. In particular I think you want to limit the people who can create courses. Thanks very much for your contribution. Arnie |
|
Hi Mike & Arnie, Just to make sure that I'm understanding this right: you're concerned that any new course created through webservices, since they have to login through the 'admin' course, will get the instructors from the 'admin' course classlist pulled in into the new course's classlist. It doesn't seem to do that when I tested it. I'm calling addCourse() from WeBWorK::Utils::CourseManagement, which requires you to specify a classlist param, and the only user I put into the classlist is the admin user as configured: $webservices->{courseActionsAdminUser} = "admin";
$webservices->{courseActionsAdminPassword} = "admin";This user is the only user in the new course, even if there are more users in the admin course.
You're right, I'll have to make another commit to limit course creation to users in the admin course.
That's fine. I didn't know about the conflict. Would it be better if we just have courseName? I'm fine with doing the name-number concatenation in our webservices client instead and it's less institution specific in case someone doesn't want the name-number format. |
|
On Apr 2, 2012, at 2:20 PM, ionparticle wrote:
We weren't concerned about adding admin course users to the new course, but that is the default behavior at the moment for creation of the course on the website. (Unless you uncheck the box which automatically adds admin instructors to new courses.)
Take care, Mike
|
Ok, my misunderstanding then. The reasoning sounds fine for our use case, I'll implement pulling in the admin course instructors and remove the custom admin user then. |
|
Sounds good -- we'll go with that for now since that will most closely mimic current behavior. We can add tweaks later if people want a different kind of control on who is automatically added Send me a pull request when it is ready and I'll update the openwebwork site. Take care, Mike
|
Course creation webservice requests will only succeed if you are successfully logged into the admin course and have instructor or above permission. This check is done in CourseActions. Note that there is a possibly duplicate check of the permission level since the session initiation function already checks for professor permissions.
As noted by Mike, section conflict with existing vocabulary already in use by Webworks. Now the create course webservice call will just use the name param for the new course's courseID. This way, it'll be less institution specific if someone doesn't use the name-number format, e.g.: MATH100-100.
On the regular webwork UI, when a new course is created, the instructors
from the admin course are copied over to the new course by default. This
allows admins easy access to the new course. The webservice course
creation call now also implements this by default.
The custom admin user configuration options are now dropped as a
result.
E.g., thse are no longer needed in postlocal.conf:
$webservices->{courseActionsAdminUser} = "admin";
$webservices->{courseActionsAdminPassword} = "admin";
|
It's done, looks like the additional commits just automatically gets added to this pull request? I guess that's why github recommend making a new branch for each pull request. |
|
I think that adding the new commits on the same branch is appropriate in this case where you are If you look at you'll see that your new commits listed at the bottom respond to the requests in the comments above it. -- Mike On Apr 2, 2012, at 7:53 PM, ionparticle wrote:
|
Webservices create course, add/drop user.
…le library loading and event system
Remove smtpserver from localOverrides.conf
disentangle the various features for branches 2.5.1 , 2.5.2 and 2.5.3
Updating how OPL problem statistics works.
Suggested styling to fix issues I mentioned for this pull request
Suggested styling to fix issues I mentioned for this pull request
…evert Make the backup radio button checked after reverting the tmp file
3 participants
Adds the add createCourse(), addUser(), dropUser() calls to Webservices.
Expected parameters for XMLRPC is in the comments of their respective functions in WebworkWebservice.pm
To enable all features, add to postlocal.conf
$webservices->{enableCourseActions} = 1; # enables course and user creation
$webservices->{enableCourseActionsLog} = 1; # creates a log file of all course actions performed
$webservices->{courseActionsAssignHomework} = 1; # added users will be assigned all visible homework sets