Roster status is unchanged (Re: Updates and summer efforts)

[jim@mercury.laney.edu]

Hi,

Roster's status is unchanged from the original status I sent (which was aprox.
2-3 days ago.) 

I'm about to test roster-0.7.0.5 for the summer session. 

To people who are looking at the code and such now: You need to know things
that aren't yet documented!! Once this statement is not true, it might be time
to release 1.0.0.0 :)

The major thing you need to know, is the file formats of the files you need
to make in order to make this thing fly :)

Start by looking at paths.perl and posing questions to me... I'll respond
by writing a small treatice on each file format you refer to, and say something
about whether the file gets created, or whether you need to make it.

Should this traffic take place on the list? I think it should take place on
-a- list that archives so people can document.

Legal stuff: If you want to document, great!! I'll accept a piece of
documentation with my profound thanks if it does the job and if it gets
copyrighted by whoever writes it and placed under the GNU GPL, which as you
may know, would allow anyone to maintain and change the documentation as well.

The package does work, as long as you know the commands and what they do and
you run it with enough ram and disk space. Right now, roster checks -nothing-.
This will change :)

The other part I need to make explicit is that Roster does not know everyone's
different student list format! So, there is a script the admin must write 
which converts the incoming student list in whatever format it is, into
the common to-be-merged format, which is defined for you by Roster::Entry.

This is where the enterprising lab admin has to talk to the person who
admins the main school records computer, asking for access, and a sample
download to look at. I had to ask for additional fields in the download!

The admin might say the data can be delivered in the form

 "full name","student identifier","class code","enrolled status"

and you get one of these for each class a student is in, so you get five
for one student if she signed up for five classes. If this is the case, 
then you need create only one record for each record of input.

The admin might also say the data is of the form

 studentID:fullName:Semester:year:class1|class2|class3|...:dropDateOrBlank

which means: you have to make a Roster::Entry with repeated data for each
class the student is taking (and of course, you put the different classes
in each record). Somehow, you have to get the data. You might actually be
the first one to ask for records of this kind! Negotiate well :) You need
the data, and it might not work well the first time, so you might need a 
change... but anyways:

You collect the data, make a new Roster::Entry from it for each student
taking one particular class, and print its Record() to a text file.

What is needed from the school records, is a student's full name,
a unique identifier for the student that cannot change (well, if it does,
my scripts delete the old account and create a new one), a code to uniquely
identify a class during that term, and an indication of whether the student
is "just looking", enrolled or dropped. If you have more than one campus 
in your district and your lab needs to support them, then you can add a
campus code (which comes from the download) to the Roster::Entry. There's
a place for the campus code. All told, a Roster::Entry has a full name, 
a student identifier (which is the lookup key generally), a campus code,
a term (like summer 1999, or M1999), a code which uniquely identifies the
class the student is taking within a campus and term and a code indicating
enrollment status. It's -important- to stress to the admin people that you
need to (a) receive the records for students who drop, and (b) to know that
they are dropped just from looking at the record! Let the admin know it's
MUCH less work for them if you get all the records and can determine for
yourself if it's a drop or an add. Our admin has chosen to either have a
drop date in the download, or to leave the drop-date field blank if the 
student is currently enrolled.

The "just looking" case is possible in the Peralta district in Oakland: if
a student try to sign up for a class but it won't let you, a record is created
for him/her, and I get those records when I transfer the student lists from
the mainframe. SO: a student can be current, dropped or on what can be 
be thought of as a waiting list.

So.... one of the first things you have to do is come up with this script.
The README file -almost- describes the process; a recent change has altered
that.

Another thing you need to do is decide which servers you wish to create 
student accounts on. For each server, you'd make up a unique name, and when
the scripts create the login files, you can see the server names in the 
file names. Each server gets one line in the file servers, and the format
of this file has to be documented.

Here's an example of a servers file we used last time:

telstar:Novell3xx::
laney-net1:Novell3xx::
earth:UnixNewusers::
earth2:UnixNewusers::
mercury:UnixNewusers::

In general: 

serverName:serverType:allowedGroupList:extraInfo

If allowedGroupList is empty, then no one is denied to get into the server
that is currently enrolled in the dept. I did this because I foresaw the 
possibility of having certain servers only support certain classes. It's
even possible to make one kind of account for some students, and another
kind for others.

Right now, I support three different kinds of servers, and for each kind
I do support, there needs to be two things: a line in a text file called
server types, which includes the name of the type, and a perl script that
defines how to add accounts for that kind of server (and also named for the
type.)

An example server-types file:

Novell3xx:
UnixNewusers:
NT:

in general:

serverTypeName:extraInfo

Right now, the extraInfo fields do nothing, so users should leave them blank 
for the moment.

Two more file formats,

database of teachers:

andrew:Andrew:andrew@ledu::aPass
jose:Joseluis Flores:joseluis@laney.edu::another
ddawson:Darrelle Dawson:ddawson@lane.edu::passwd
cgrinage:Celeste Grinage:cgrinage@l.edu::sharedSecret
thomash:Thomas Hetherington:thomash@ledu::thereitis
ebell:Elise Bell:ebell@edu::
jwallace:Joaquin Wallace:jwallace@edu::
shirley:Shirley Bardon:shirley@::
teecee:TC:teecee@a.b.c.d::
carole:Carole Rogers:carole@::

Or, more generally,

teacherLoginName:Firstname M. Last:teacher@school.edu:teacher@home.com:secret

Note that the password at the end is just there as a shared secret between
the teacher and the lab admin, it's NOT necessarily a password on any server.
The idea here is you set the passwd initially and the teacher privately
changes it. Then, if the teacher ever forgets his private password,
he can call the lab admin and have her change his password back to the
shared secret. 

database of classes:

0075:005:carole
0076:005:shirley
0077:005:andrew
0078:005:andrew
1495:048GK:jose
1727:048GK:jose
1807:205:
0869:233:teecee
1335:233:teecee

Or, 

classCode:classNumber:teacherLoginName  <--- this must match in teacher db

Notice that a teacher can have more than one class, and you can have a class 
without a teacher... Often, there is a time before the teacher is known.
Records would still get kept, but lists would not get emailed without knowing
if there's a teacher to email to :)

NOTE that this format will change SOON! It does not store enough about a class
to be general enough to go outside a single department or campus, and there
are other possible databases that can be added, such as session lists, long
and short class descriptions, etc.

A few files that have freer formats are also needed, I'll describe some of
those:

This is our welcome-message.txt file, and is emailed as part of 
a class list to a teacher (as the first mime attachment):

---------
WELCOME to the roster mailing format! 

You will receive a message such as this one, which has a text informational
part (like the one you are now reading) and two attachments: the first
is a tab-delimited database containing full names, student IDs, login names and
passwords, while the second (and possibly last) attachment will contain
exactly the same data in printable form. You will be sent one of these
messages for each class you teach in this dept.

Also from this point forward: students who drop all class will be 
automagically removed from all servers. If they are reinstated, they
will get new accounts: absolutely nothing about the old accounts
will be saved. In particular, all pending email will be removed.

-Jim

P.S...

------

A blank line was placed at the end to set off the info that gets appended.
I put the ps at the end because the email script adds a bit more info, 
I think it's the specific class and when the roster was downloaded.

Speaking of which... there is a file called time-roster-downloaded.txt.

It actually specifies the exact start and end time of the download, with
the interpretation that the student who is asking for his account should
be in the database if he enrolled before the start of the download, should
NOT be in if he enrolled after the end time and if he enrolled inbetween
no one has any idea whether he's in or not :) You'll just have to check the
master printout in that case.

for example:

Mon 4/26/1999 9:42-9:47 PM

This is NOT determined automatically!! Reason: most of you will not have 
a synchronised clock available right there, so maybe you put the speaker-
phone on and call the phone time while you hit the GO key on your roster
download... so you record the start time and end time. What I always do,
is try to make the download period a bit longer in both directions by
rounding the start time always down (4:37:59 becomes 4:37) and rounding
the end time always up (4:43:04 becomes 4:44) so I don't have to pay 
attention to seconds. Note that the string should be kept short, because it
will be printed as part of a line of text, on every page.

The file term.txt keeps track of the current semester. I put strings
like "F1999" meaning fall '99 term, and I use the string primarily to
name term-sensitive files.

I was considering campus.txt, but I'm not sure that has meaning.

OK, enuf for now. This is most of the data you have to set up.

-Jim