SchoolTool
==========
SchoolTool - a common information systems platform for school administration.
Website: http://www.schooltool.org/
Mailing list: http://lists.schooltool.org/mailman/listinfo/schooltool
Bug tracker: http://issues.schooltool.org/
Overview
--------
SchoolTool is an open source school management information system. It is
a distributed client/server system. The SchoolTool server presents two
interfaces to clients:
- a traditional web application interface, usable with an ordinary browser.
- HTTP-based programming interface suitable for fat clients, adhering to
the Representational State Transfer (REST) architectural style (see
http://rest.blueoxen.net/).
The web application interface is the primary one. The RESTive interface is
there for potential interoperability with other systems and fat clients to
perform data entry that is inconvenient to do via the web application
interface.
There are several clients that demonstrate the usage of the REST interface
(a command-line client that is used for functional tests, a wxWidgets GUI
client, and a command-line client for data import).
Any modern web browser is suitable for the web application interface. The
interface degrades gracefully, so a browser that does not support CSS or
Javascript will be usable, although perhaps not very nice or convenient.
System requirements
-------------------
- Python 2.4 (http://www.python.org/)
(Debian users will need python2.4 and python2.4-xml packages)
- libxml2 Python bindings (http://xmlsoft.org/). Windows users can find
binaries here: http://users.skynet.be/sbi/libxml-python/
- (optional) the ReportLab Toolkit (http://www.reportlab.org), and
Arial and Times New Roman TrueType fonts. ReportLab is only needed if
you want to generate PDF calendars. To enable PDF support you will
need to specify the path to fonts in the configuration file.
- Development environment and a C compiler
(pre-compiled binaries are available for Windows users at the SchoolTool
website)
Building SchoolTool
-------------------
Run 'make build update-translations' to build the necessary extension modules
and translations. You will need to have gettext installed to compile the
translations.
It is a good idea to run 'make test' and 'make ftest' to check if all the
essential unit and functional tests pass.
Installing and Configuring with Distutils (optional)
----------------------------------------------------
WARNING: distutils does not yet take care of removing old packages or ensuring
that dependencies are correct. If you don't know how to resolve these issues
manually, you should probably use one of the packages or run SchoolTool from
an unpacked tarball/subversion checkout.
It is possible to install SchoolTool and SchoolBell using the python distutils.
To do this, you have to use one of the distributed tarballs/zip files, which
you unpack in a directory with the tools appropriate to your OS. First, it is
necessary to install the version of Zope included with the tarballs, this can
be done by running
python setup.py install
from the Zope3/ directory included with the SchoolBell distribution. From the
top level directory, the commands
python setup.py install (inside the unpacked schoolbell tarball/zip)
python setup.py install (inside the unpacked schooltool tarball/zip)
will install SchoolBell and SchoolTool respectively. Note that SchoolTool
depends on SchoolBell, so you will have to install both if you want to run
SchoolTool.
Finally, to setup a SchoolBell / SchoolTool instance, copy the installed
script, /usr/bin/schooltool, into a separate directory and create a config file
with the name of the script and an extension .conf. A good template can be
found in the top level of the tarball (.conf.in). Running this script will then
run an instance in that directory.
Those interested in installing into a non-standard location should investigate
the --paths and --default-config option for the install distutils commands.
Running SchoolTool
------------------
The top-level project directory contains the following executable Python
scripts:
schooltool-server.py starts the SchoolTool server
The SchoolTool server automatically creates an empty database if it cannot find
an existing one. You can customize the location of the database and a few
other parameters in a configuration file called schooltool.conf. There's
an example file called schooltool.conf.in, you can simply rename it and modify
to suit your needs.
Beware that the file which contains the database, Data.fs, is not given any
special permissions to prevent it from being read by other users by default.
You will have to change the umask or the permissions of the file manually to
prevent unauthorized access.
By default a user with manager privileges is created in the new database.
The username is 'manager', and the password is 'schooltool'. The database
is otherwise mostly empty.
The default web application port is 7080. Once the server is running, you can
connect to it with a web browser.
Project structure
-----------------
GPL the GNU General Public License, version 2
README this file
README.schoolbell README for SchoolBell
RELEASE release notes for the latest release
Makefile makefile for building extension modules
setup.py distutils setup script for building extension modules
test.py test runner
remove-stale-bytecode.py
script to remove stale *.pyc files
schooltool-server.py script to start the SchoolTool server
schooltool.conf.in sample configuration file
build/ temporary files are placed here during build process
coverage/ unit test coverage reports are placed here
debian/ Debian packaging support
doc/ documentation
src/ source code
schooltool/ Python package 'schooltool'
main.py the SchoolTool server
*.py other modules (see docstrings)
tests/ unit tests for the schooltool package
browser/ web application views for the server
resources/ resource files (images, stylesheets)
templates/ page templates
tests/ unit tests for the schooltool.browser package
rest/ RESTive views for the server
templates/ page templates
tests/ unit tests for the schooltool.rest package
schoolbell/ Python package 'schoolbell'
Testing
-------
There are two sets of automated tests: unit tests and functional tests.
Unit tests (sometimes also called programmer tests) test individual components
of the system. Functional tests (also called customer or acceptance tests)
test only externally visible behaviour of the whole system.
Tests themselves are scattered through the whole source tree. Subdirectories
named 'tests' contain unit tests, while subdirectories named 'ftests' contain
functional tests.
To run all unit tests, do
python test.py -pv
To run all functional tests, start the SchoolTool server using the test.conf
configuration file (hint: make runtestserver) and then do
python test.py -fpv
The test runner has more options and features. To find out about them, do
python test.py -h
Functional tests are are not completely isolated. Some functional tests
create named database state snapshots, while other tests reuse those snapshots
of known database state. The test runner does not know which tests create
which snapshots, so if you want to run just one (or a couple) of functional
tests in isolation, it is likely that you will have first run the full suite
to create the necessary snapshots. Do not restart the test server, or all
saved snapshots will be gone.
Unit test coverage
------------------
All code should be covered by unit tests. The test runner can help you look
for untested code by producing code coverage reports.
To generate unit test coverage reports, run
make coverage
This command will run the full SchoolTool unit test suite and produce a
number of files (one for each Python module) in ./coverage/. Every
report file contains the source of the corresponding Python module.
Each source line is annotated with a number that shows how many times
this line was reached during testing. Watch out for lines marked with
'>>>>>>' as they indicate code that is not unit tested.
There are some more helpful make targets:
make coverage-report-list
Lists all non-test modules from the schooltool package that contain
untested code.
make coverage-report
Like 'make coverage-report-list', but is somewhat slower and also
shows the number of untested lines in each module.
make vi-coverage-reports
Launches vi for all coverage reports listed by 'make
coverage-report-list'. Type />>>>>> to search for untested code,
then type :next to look at the next report.
make edit-coverage-reports
Like 'make vi-coverage-reports' but uses $EDITOR rather than
hardcoding 'vi'.
Translation
-----------
Translation files live in src/schooltool/translation. There is a directory
for each language that contains a subdirectory called LC_MESSAGES that
contains two files: schooltool.po and schooltool.mo.
To start a new translation, create a language directory and LC_MESSAGES and
use src/schooltool/translation/schooltool.pot as a template. Generate
schooltool.mo with msgfmt (or by calling make update-translations).
When you change the translatable strings in the source code or page templates,
be sure to run
make extract-translations
Virtual hosting
---------------
SchoolTool provides support for virtual hosting with Apache's mod_rewrite.
For example, let's say you have two SchoolTool instances running on ports
7001 and 7002, and you want to make them available as school1.example.org
and school2.example.org, both on port 80. In order to do that, add the
following to your Apache configuration file:
NameVirtualHost *:80
ServerName school1.example.org
RewriteEngine On
RewriteRule ^/(.*) http://localhost:7001/++vh++http:school1.example.org:80/++/$1 [P]
ServerName school2.example.org
RewriteEngine On
RewriteRule ^/(.*) http://localhost:7002/++vh++http:school2.example.org:80/++/$1 [P]
Also, enable mod_proxy and mod_rewrite.
You can also get SSL support in the same way.
NameVirtualHost *:443
ServerName school1.example.org
SSLEnable # Apache 1.3
# SSLEngine On # Apache 2.0
RewriteEngine On
RewriteRule ^/(.*) http://localhost:7001/++vh++https:school1.example.org:443/++/$1 [P]
The web application interface also supports virtual hosting in this manner,
the only differing thing would be the local port number.
Copyright information
---------------------
SchoolTool is copyright (c) 2003--2005 Shuttleworth Foundation
All files in the src/schooltool directory (with some exceptions in
src/schooltool/locales) are part of SchoolTool, and are (c) Shuttleworth
Foundation.
Unless otherwise stated, files in src/schooltool are released under the
terms of the GNU General Public License as published by the Free
Software Foundation; either version 2 of the License, or (at your option)
any later version.
Files in the following directories are (c) their respective owners. See
the individual files and directories for details of the licences.
Zope3
Files in the same directory as this README file are (c) Shuttleworth
Foundation, with the exception of GPL, which is a copy of the Free Software
Foundation's General Public License, and is (c) FSF.
Files in the debian/ subdirectory are (c) Shuttleworth Foundation and
contributors.
SchoolTool is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
You can find the full copy of the GNU General Public License in a file called
GPL in the project directory.