I have posted a very rough draft of SAM at
http://code.google.com/p/our-student-access-module/downloads/list .
It is stitched into Keystone, so for it to work you need to create an
account in at least a few of the Keystone files.
files: ksStudents, ksPermRecs, and ksEnrollment
account name: SAMuser
password: SAMuser
privileges: viewer or ViewerNoSensitive
other: IWP should be enabled for that privilege set, and under file /
sharing / instant web publishing it should be turned on.
SAM automatically opens on the SAMuser account. The opener script
opens ksStudents, ksPermRecs, and ksEnrollment on that account (by
running scripts in them, since the File Open script step isn't webby)
and then asks the user to re-login. An admin type should login with
admin - inresonance, our student users would login with their own
account username and password.
SAMuser - SAMuser is the opening login for SAM, not connected with a
student in Keystone
student - student is a student login for SAM that shows info for the
student Alison Tolman
admin - inresonance is a top login for SAM that shows info for the
student James Christe
SAM needs a lot of work before it is ready to roll, and Matt Z and I
realized a bit too late that its foundation really should have been a
polling tool, not the overly-specific Community Service and Weekend
Pass bits that we spent a little time on. Oh, well, maybe that is a
job for the next dev camp!
To Do
*make sure that when a web user click logout it closes other keystone
files, too
*test SAM more thoroughly on the web
*write a script that will create an account in the SAM file for each
student with the SAMuser privilege set
*more carefully define the SAMuser privilege set
*build out the admin side of SAM
*consider whether SAM would do better if it was more stand-alone, less
reliant on Keystone
*others? I'm sure I'm missing something