Release Notes - SchoolTool/SchoolBell 0.9
=========================================


Upgrade Issues
~~~~~~~~~~~~~~

Database Upgrades
-----------------

The SchoolTool/SchoolBell database in 0.9 is compatible with previous databases.
Upgrades are strictly one way and are performed automatically by the new server.

Unfortunately only some database objects are currently upgraded [1]. The rest
will be deleted.

Full upgrades from SchoolBell 1.0 onwards.

[1] All IApplication objects and calendars.

New Features in 0.9
~~~~~~~~~~~~~~~~~~~

The new features in this release are primarily from the SchoolBell User
Interface bounty by etria and the ongoing conversion to Zope 3 by POV.
And of course, bug fixes.

The full text of the user interface bounty can be found at
http://www.schooltool.org/bounties/ui/SchoolBell09.

The Zope 3 conversion is not very visible to the user and will be finished by
SchoolBell 1.0. The aim of this conversion is to remove the dependency on
Twisted.

The user visible parts of the changes from 0.8 to 0.9 are described below.

Anonymous User
--------------

When an anonymous user navigates to the root of the site, they should see a
calendar for the day containing public events from all the calendars that have
been selected by the administrator. They'll also be able to use the legend to
view additional public calendars.

There won't be any navigational aids to view person/group/resource calendars,
but if you navigate there by entering the right URL you'll see a similar
calendar, showing public events for that person/group/resource.

Regular User Point of View
--------------------------

SchoolBell should give the user the option of getting a cookie that will
automatically log them in from that browser.

When an authenticated user logs in to the root of the site, they should be
redirected to their calendar.

For each hour (in the daily or weekly view) or each day (in the monthly view)
there is a link to create an event which will pop up a form with the relevant
day and time.

For each hour there is also a "book" icon. The user clicks "book" at tomorrow
9am he will get a simplified version of busysearch with the start time
"Tomorrow 9am selected." He picks from all available resources and sets the
duration. He gets back a list of everything available at that time for that
duration. The resources which he is looking at are preselected.

Changes to the legend (calendars added or removed from the list, turned visible
or invisible) those changes should be persistent.

Each event that the user can manage should should have a link which pops up an
edit window for the event.

Manager Point of View
---------------------

When a user logs in as a manager, they'll still see the root calendar, which
they'll be able to edit, and also a link to the admin page, similar to the
current one, where they can:

    * Set up the default page -- which calendars should be overlaid on it by
      default.

    * Add users, one at a time via form or via CSV import. They should be able
      to add users to groups when they create the users.

    * Add resources, via a text box (just the titles, one per row), in a form
      one at a time (with groups and specifying id and title) or via CSV.

    * Add groups, via text box, form or CSV, as for resources. I don't think we
      need to allow members to be added at the time of creation. Perhaps that
      could be a second step. All groups will just be subgroups of the root
      group. All the UI elements related to the group hierarchy should be
      removed.

    * View index pages for persons/resources/groups

    * The info pages for persons/resources/groups should be able to stay the
      same, more or less.

    * Logs (as is)

    * Delete (as is)

    * Reset (as is)

    * Options. As is, plus an option to start or stop using the REST interface
      (restart required?). REST will be off by default. Also, the iCal
      representations of calendars should be made available via the browser
      interface.
