POV is ready to start working on more attendance functionality. I've
gotten a bit crunched by my multiplicity of roles this week (too much
time writing code (I produced the first SchoolTool-generated report
cards, more on that soon...), not enough project managing, so these
are still a bit rough, but I had to get something out before getting
on a plane to London tomorrow.
As usual, your feedback is welcome!
Bugfixes, etc.
==============
Resource management/booking in timetables
-----------------------------------------
Relatively straightforward and something we've done before.
Unfortunately it disappeared somewhere when SchoolTool was ported from
Twisted to Zope 3.
Deleting School Timetables and Terms
------------------------------------
Many users complain, clearly more of a pain than Tom thinks it is.
Timezones in timetables
-----------------------
Right now timetables are put in the timetable of user's preference,
which is absolutely bogus. Assignments in the section's calendar will
align with the timetable period only if the user's timezone coincides
with the timezone of the teacher who added the assignment!
The timezone should be stored with each School Timetable. The wizard
should have a dropdown for the timezone, defaulting to the school's
timezone.
Ignas's Handy Guide to Not Creating New Timezone Bugs in SchoolTool
-------------------------------------------------------------------
Creating some developer documentation on this theme. In particular,
stressing that the vast majority of actions in SchoolTool should
default to the school's timezone.
Other timezone cleanup
----------------------
I will never second guess Steve Alexander again.
Attendance
==========
Attendance Control Panel
------------------------
The stories below have made it pretty clear that a "attendance control
panel" will be necessary for administrators and clerks. We'll have to
discuss how it will work, though.
Period Absences Inheriting from Day Absences
--------------------------------------------
When there is a day absence, the status of the day's constituent
periods is not relevant. You can't excuse one period at a time in
this case, and you shouldn't have to deal with the individual periods
when resolving day absences in the interface. Also, when producing
reports for attendance in a given class, it will be helpful to know
whether an absence was part of a day absence or a period absence. I'm
not sure what the best way to implement this will be.
Day Tardies
-----------
This one will make you grind your teeth, but bear with me. If a
student doesn't make the homeroom period, they will be marked for a
"day absence." Often, of course, they'll show up later in the day
and, typically in the US, check in at the main office. So the "day
absence" has to become a "day tardy," which then can be excused or
not. As in day absences, the status of the periods missed completely
or in part is inherited from the status of the day tardy. I think
this can reasonably be managed from the current student attendance
form.
Attendance Status Codes
-----------------------
The site manager creates a dictionary of codes that indicate the
status of explained absences. This probably should just be done via a
web form. The structure of the dictionary is a abbreviated code and a
human readable string like ('001':'excused'). The UI should use the
string. In some schools, the code won't really be used at all, but in
other cases it will be important for reporting to higher-ups.
Probably the form should allow you to just enter a list of strings
without codes if you don't need any codes, and the application can
arbitrarily assign codes.
Once the list of codes is entered into the system, when absences and
tardies are resolved, the user MUST also assign a code. We'll have to
provide a default set of codes.
Retrospective Attendance Form
-----------------------------
This is the form that will be used by teacher who are entering
attendance after class, or by clerks who are entering attendance for
everyone after the fact. Similar to the realtime attendance form, but
no sparklines, and a drop down menu with [present, absent, tardy] and
a field for tardy time if you select tardy. In this case the user
will not be converting absences to tardies, but creating them
directly.
Corrections
-----------
If a teacher or clerk makes a mistake, the correction of the mistake
should be a part of the attendance workflow. Both the real-time and
retrospective attendance form should have a "Correction" button that
takes the user to a form that submits a request to correct the
attendance. By default, this will have to be approved (by default) by
a school administrator or clerk. The end result should be that a
removed absence or tardy looks like a regular successful attendance
for most reports, but the sequence of changes has been logged.
Future Absences
---------------
Clerks or administrators need to be able to create and explain section
absences that will happen in the future (for field trips, for example)
for groups of students or individual students.
_______________________________________________
Schooltool mailing list
[email protected]
http://lists.schooltool.org/mailman/listinfo/schooltool
