RELEASE_NOTES

v1.17.2   2024-10-15

* Don't allow users who can't add resources to set organiser

  There are some users - typically pupils - who can create events but
  can't add arbitrary resources to them.  They just create events
  involving themselves.  A small wrinkle arose in that one such user
  discovered he could still set the "Organiser" field on his event and
  set it to be a member of staff who was then a bit surprised to see it.

  For such users, the "Organiser" field is now disabled as well.


v1.17.1   2024-09-19

* Propagate changes to organiser in repeating events

  In a collection of repeating events it is possible to edit one event
  and then propagate the changes to all the others in the set.  The
  code to do this was missing out the organiser field from the propagation.
  Now fixed.


v1.17.0   2024-09-14

* Add extra id fields for staff and pupils

  A requirement has arisen to identify pupils and staff using IDs which are
  common between iSAMS and SOCS.  This update adds those fields to the
  staff and pupil records and then populates them in the iSAMS importer.


v1.16.1   2024-09-05

* Add an extra field to element display call in API

  At the request of Abingdon school an extra field containing the element's
  UUID has been added to the element display call in the API.

  Code by Kevin Ramadhan


v1.16.0   2024-02-05

* Update various ancillary packages

There have been vulnerability warnings on a number of the ancillary packages
used by Scheduler.  This release pulls in fixed versions of the packages.
See the git log for full details of which ones.

* Allow more flexible import of CSV/ICS calendars

Scheduler has the means to import existing calendars from other systems
by way of CSV or ICS files.  This was originally intended for existing public
calendars and so the import would be done against a Property in Scheduler.
A need arose to import a set of room bookings so the linking has been
loosened up to allow them to be imported against any resource.


v1.15.17  2024-01-19

* Fix a problem importing sets from iSAMS where name and id differ.

The set records arriving from iSAMS give each set both a SetId and a Name.
Usually these are the same but they can be different.  For historical
reasons (see next item) we were linking them up to the timetable by Name
but it should have been by SetId.  Fixed.

* Remove frig code added to cope with broken iSAMS data.

Way back in the mists of time when the module for importing data from
iSAMS was first added (mid 2016) there was an error in the design of the
iSAMS data output which meant it was impossible to link a lesson involving
a tutorgroup (TeachingForm in iSAMS terminology) to the matching tutorgroup.

iSAMS refused point-blank to investigate or even acknowledge the problem
and so a workaround was implemented using external knowledge and mapping
by set name.

About 8 months later they quietly fixed the problem (which they had previously
insisted did not exist) but the code here never got changed.  As it led
recently to the issue mentioned above it has now been removed entirely
and such lessons link correctly to the relevant tutor groups.


v1.15.16  2023-10-27

* Fix a problem with manually creating new subject records

In implementing the AdHoc lessons functionality a bug was introduced which
prevented the dialogue for creating Subject records manually from working
correctly.  This release fixes that problem.


v1.15.15  2023-09-04

* Cope with SHSK girls in Abingdon feed

  Abingdon school has added some SHSK girls into their iSAMS database
  using National Curriculum years 16 and 17 because iSAMS can't cope
  with different cohorts of pupils.

  Imported enhanced to cope with this.


v1.15.14  2022-12-04

* Allow the display colour of events to be forced by a property

  Properties in Scheduler have long had a "preferred colour" field.
  If someone asks to view all events with a given property then they
  will by default be displayed in that colour - typically used to make
  sure everyone sees the public calendar in the same colour.

  This release adds a "force" flag, which if set then means that
  all events with the relevant property will be displayed in the chosen
  colour, regardless of the route by which they are viewed.  Thus
  a normal event in a user's schedule can be changed to appear in a
  different colour from the rest of the user's events.


v1.15.13  2022-11-22

* Allow ?include parameter on commitment listing in API

  The API call to list the commitments of an element now allows
  the relevant staff and locations used by the resulting events
  to be included in the data returned.

  This is to allow for quick listings of any staff member or
  pupil's up-coming commitments.


v1.15.12  2022-11-13

* Upgrade Nokogiri and Omniauth

  These two packages have been updated for security fixes.

* Update user details at login

  Scheduler learns each user's name etc. from the chosen authentication
  server, but historically has not updated this information when it changed.
  Scheduler will now update its idea of the user's details if the information
  coming from the authenticator changes.

* New API call to amend existing events

  As the first step in some API enhancements, and to check that we're all
  talking the same language, a new API call has been added to allow the
  information relating to an existing event - like title or organiser - to
  be amended.


v1.15.11  2022-10-20

* Add HashWithIndifferentAccess to serializable

  A new security feature in the latest version of Rails requires all
  objects which are to be serialised to the database to be declared
  as such.  The previous release missed out HashWithIndifferentAccess
  from this list.

* Fix error in setting of element_owner flag

  The User model tries to keep track of whether each user owns (controls)
  at least one item (Element) in the system.  The code for doing this
  was flawed and several users were not correctly recorded as owning
  elements.  The flawed code has been fixed and a maintenance method
  has been added to allow all affected User records to be corrected.

* Allow an admin user to delete any note

  The test for deleting notes has been updated to allow any admin user
  to delete any note.

* Cope with multiple week sets arriving from iSAMS

  Scheduler has no limits on how many sets of week definitions it can cope
  with.  Until recently, iSAMS could cope with only one definition of
  A/B weeks.  iSAMS has been enhanced to cope with multiple sets which
  exposed an error in the Scheduler import code for iSAMS data which
  implicitly assumed there would be only one set.  This release removes
  that pinch-point in the import processing.

* Add list_rooms flag to mimic existing list_teachers

  A request arose to include details of the rooms for lessons in the
  general schedule display.  It has long been possible to list the staff
  involved in lessons in this display and this is the default for students
  using the system.  The display is controlled by a flag in the Concern
  record, so users can choose for each item which they are looking at whether
  to list staff or not.

  An additional flag has been added - list_rooms - so now they can choose
  whether to have rooms listed as well.

  There is also a list_rooms flag on the User record so the user can choose
  what is the default setting for newly created Concerns.


v1.15.10  2022-08-16

* Allow import from iSAMS without populating sets

  A requirement has arisen to prevent students from knowing which sets
  they are in prior to the start of term.  A new switch has been added
  to the importer to allow this.  Passing "--no=setlists" to the
  importer utility will cause the sets themselves to be created (and
  thus allow the timetable to be loaded) but won't populate them with
  pupils.  As soon as this option is removed, the next run of the importer
  will populate the sets.

* Allow extreme case of lesson merging

  A problem was discovered where a very large number of iSAMS timetable
  events were merged to a single logical event in Scheduler.  The
  identifying string got too long for the database field.  The string
  is now limited so as not to get too long.


v1.15.9   2022-08-09

* Upgrade rails-html-sanitizer


v1.15.8   2022-08-09

* Upgrade Rails to 5.2.8.1

  This gives us a range of security fixes.  Also upgraded other contributory
  gems.  It was necessary to re-arrange the initialisation of the app to
  pass new more stringent security checks in Rails.


v1.15.7   2022-05-14

* Add further functionality to dummyloc

  The previous frig wasn't enough to make the broken client work.  If
  it gets LOCATION: with nothing after it it still sometimes adds a
  random location to its display.

  You can now add a string to dummyloc - "?dummyloc=None" - or whatever.


v1.15.6   2022-05-04

* Add an extra option on ical feeds for a broken client program

  An extra option - dummyloc - has been added to the ical feed URLs
  to accommodate one broken client program which adds random
  incorrect locations to events which don't specify any.

  If you add "?dummyloc" to the end of your ical feed URL then every
  event will have a LOCATION: field, even if empty.

* More debug information for invalid cover from iSAMS

  The iSAMS MIS seems to lack integrity checking in various areas.
  In particular, if a lesson with cover is deleted the cover record
  doesn't get deleted with it.  The Scheduler importer copes fine
  with this but a little bit more debug information has been added
  to help in tracking down instances.

* Dependent packages updated

  The following packages have been updated:

    moment.js   2.29.3
    Rails       5.2.7.1
    Nokogiri    1.13.4
    Puma        5.6.4

  to fix the following vulnerabilities:

    CVE-2022-24790
    CVE-2022-24836
    CVE-2022-23437
    CVE-2022-24839
    CVE-2022-22577

    and a directory traversal vulnerability in moment.js

  The update to Puma means it is essential to completely stop
  the web server whilst applying this update.


v1.15.5   2022-03-30

* Add checks to prevent accidental Markdown in auto-generated notes.

  A really surprising circumstance arose.  The system does checks
  to identify clashing events for students and then adds notes to
  events indicating when students will be away.  E.g. if there is a
  geography field trip then each affected lesson will be annotated
  with a list of the students who will be absent.

  In doing this, it includes the body text of the clashing event in
  the annotation, *but* someone created an event which included some
  text in square brackets - [].  These have a special meaning to Markdown
  and so that part of the note got turned into a URL, which another part
  of the note processing code fell over because it wasn't a valid URL.

  Two fixes have been implemented.

    * The note post-processing code no longer fails if it finds an
      invalid URL in a note.

    * The note generation code in the clash checker now escapes any
      characters which have special significance in Markdown so
      the above-mentioned event no longer generates a URL at all.

* Update Rails to 5.2.6.3 (from 5.2.6)

  There have been several minor point releases of Rails.  This
  brings Scheduler up to date within the Rails 5 tree.


v1.15.4   2022-01-28

* Allow the calendar view to be specified in the URL.

  An additional parameter has been added to the ones understood on
  the main page of the application, allowing the initial view to
  be specified.  By adding "?view=<choice>" to the URL, the view
  can be set to something other than the default week view.  Valid
  values for <choice> are: week, month, day, daylist and list.

* Fix missing "require" in mail storage.

  A require statement was missing which prevented access to stored
  e-mails.


v1.15.3   2022-01-22

* Remove spurious debug line

  A line of debug code had been left in the JavaScript which prevented
  it running on production servers.


v1.15.2   2022-01-22

* Flag unavailable resources with red events

  In the Resource Group allocation code (for mini-buses and the like)
  it is now possible to flag individual resources as being unavailable
  by creating an event involving them and adding a nominated property
  to that event.  The relevant property is under the control of the
  system administrator.

  Such events will then appear in red on the resource allocation screen.

* Change item in use by dragging for non-request items

  Similarly in the resource allocation screen, it is now possible to
  change which item is involved in an ordinary event (not involving
  a resource request) via dragging the event.  It appears to be doing
  the same thing from the point of view of the user, although the
  behind the scenes processing is quite different.


v1.15.1   2022-01-17

* Implement auto-allocation of staff lessons for a whole cycle

  This release enables another button in the AdHoc lesson auto-allocation
  area.  Instead of clicking for one week at a time in a staff member's
  area you can click and get the whole cycle allocated for that staff
  member.

* Improve auto-allocation algorithm

  In testing the previous change it became apparent that in some
  pathological cases (typically where a staff member has no slack
  in his or her schedule) the algorithm could be improved.  This
  has been done, although doubtless a lot more improvements will
  come to light in the future.

* Simplify expression of algorithm

  The actual implementation of the algorithm has been simplified
  almost to the point of being a Domain Specific Language (DSL), which
  makes it much easier to tweak in the future.

* Fix problem with empty allocation

  If a staff member had an empty allocation - no lessons - then clicking
  the auto-allocate button led to an error.  This has now been fixed.

* Add statistics

  In order to be able to judge how well the auto-allocation algorithm
  has performed, statistics have been added to the display.  These consist
  of a ratio and a max score - like this, "12/23   2".

  The denominator of the ratio is the number of middle school (not sixth
  form) lessons which need to be allocated.

  The numerator of the ratio is the sum of all the clash scores.  The
  value shown here of 12 could mean that 12 lessons have each hit a subject
  once, or that 8 lessons have hit a subject once, and 2 lessons have
  hit a subject twice (8 * 1 + 2 * 2).  Etc.

  For a good allocation, the numerator should be less than the denominator.

  The final number - the 2 - gives the maximum clash score which a lesson
  has achieved.  This may well change in a future release to the maximum
  number of hits which a subject as received per student (potentially a
  smaller number).

* Fix to cope with blank pupil timetables

  The auto-allocation algorithm also failed to cope when a student had
  no other timetable at all.  Fixed.

* Change "Implement" to "Publish"

  The "Implement" button has been renamed as "Publish" to make it more
  clear what it does.


v1.15.0   2022-01-04

* Implement direct links for element schedules

  A requirement has arisen for some staff to be able to view their
  schedules within Scheduler without actually logging on.  This has
  long been possible by way of an external calendaring program, by
  taking an ical feed from Scheduler into that program.  It can now
  also be done directly within Scheduler by use of an appropriate
  link.  The necessary links can be found within Scheduler in the same
  place where ical feeds are provided.

  The most obvious immediate use is to allow peripatetic music teachers
  who don't normally use Scheduler to get a quick view of their scheduled
  lessons.

* Implement scoring for peripatetic music lesson sets

  Scheduler now automatically calculates a score for each peripapetic
  music teacher's schedule, giving an overall rating and an indication
  of the worst (as in most lessons missed) individual score.

* Implement auto-allocation of  peripatetic music lessons

  The process of finding times for students to take music lessons outside
  their academic timetable is a laborious one.  This release adds a facility
  whereby Scheduler will draw up a proposed schedule automatically, taking
  account of students who are not allowed to miss academic lessons, and for
  those who are allowed to miss them, minimizing the number of times they
  miss any particular subject.


v1.14.9   2021-10-08

* Run AdHoc lesson implementation jobs in the background

  It was found that on slow systems the implementation of a large set
  of AdHoc lessons could take 10 minutes or more, causing the browser
  front end to time out whilst waiting.

  This release switches to processing such jobs in the background.  The
  user initiating the task will get immediate feedback that the job
  has been queued and then the user's screen will update every 5 seconds
  with progress information until the job completes.  The user can
  even navigate away from that screen and come back later to see how
  the job is doing.

  Some additional steps are required when installing this release,
  specifically:

    The Scheduler user's crontab needs an extra line at the end to
    start the background job processor.  See support/crontab

    The system file /etc/logrotate.d/scheduler needs an extra file
    adding to it.  See support/logrotate

* Fix to the date fields in the ICS import screen

  A problem was found in the ICS import screen (dating from November last
  year) in that the date fields were being filled by default with nonsense
  instead of the dates found in the import file.  This problem has been
  fixed.


v1.14.8   2021-09-30

* Provide some visual feedback when a user Implements an AdHoc Cycle

  When a user hits the "Implement" button to propagate a set of music
  (or whatever) lessons into the main database it can take a minute or
  two to create all the necessary events.  The button is now disabled
  and a message appears so that the user knows that something is happening.

  The button is re-enabled when the work completes.

* Eventcategory updated if changed

  If a user re-runs an "Implement" cycle, the code tries as far as possible
  to adjust existing events rather than creating new ones.  One thing
  which did not get updated was the events' eventcategory, but it's possible
  that the system administrator might want to change it.  This now gets
  updated along with everything else.

* Editing AdHocCategory should not remove the identifying property.

  A small bug was identified in that if an existing Ad Hoc Event Category
  was edited without the "Identifying Property" field being changed, then
  when the edited record was saved that field got blanked.  This bug
  has been fixed.

There is also a changed to the advice on how to set up Ad Hoc Event Categories.
Previously the instructions recommended using an Eventcategory of "Lesson",
but it turns out this is not a good idea because the ad hoc lessons then get
flagged as having pupils missing from them because the pupils have ordinary
lessons at the same time.  Instead, create a new dedicated Eventcategory
for Ad Hoc lessons and don't include it in the list to be flagged with
absences (although it will still be used when flagging absences from other
events).


v1.14.7   2021-09-20

* Add a daily check for clashes in controlled locations

  When a location has one or more controllers, they can control most of
  the events which get added to those locations.  However, events can
  still arrive directly from the school's MIS and end up clashing with
  events entered manually.

  This release adds code to do an off-line check for such clashes and to
  e-mail such controllers as choose to receive those e-mails.


v1.14.6   2021-09-12

* Remove spurious console.log message from JavaScript

  ...which used a JS6 feature and thus prevented pre-compilation.


v1.14.5   2021-09-12

Two bug fixes

* Cope with the deletion of a student after music lesson allocation has started

  A problem was found in the code for peripatetic music lessons in that if
  allocation of a teacher's lessons had started and then one of the
  students was deleted from that teacher's list - after at least one
  lesson had been scheduled for that student - then the host sent down
  slightly inconsistent JSON data to the front end at the next attempted
  allocation session and the user ender up with a blank screen.

  Two fixes have been implemented.  The host now checks the JSON data
  for this circumstance and ensures the data actually sent are consistent -
  no references to non-existent records.  The front end JavaScript code
  now also copes if such a reference exists.

* Clip very long student names so they don't overflow

  In the lesson allocation screen, very long student names were overflowing
  out of their intended space.  This was because, although the containing
  element had been set to clip overflow, its size had been left to float
  and so the element itself increased to be wider than its parent.

  The element now has an explicit width of 100% (of its parents width) and
  so the student name clips as intended.


v1.14.4   2021-09-03

* Add extra column to resource approvals screen

  Some resources (e.g. rooms) within the system have one or more administrators
  appointed and requests for those resources need to be approved by an
  administrator.  This can be done either from the main calendar event view
  or from a screen showing a textual listing of events.

  This release adds an extra column to the latter screen so that the
  administrator can immediately see what events clash in their requests
  for a given resource.

* Add a check button to the event repetition screen

  Administrators of a resource can enter events for that resource directly
  without needing approval.  This can lead to problems when someone asks
  for a repeating event in a given room (e.g. every Thursday of week B from
  14:00 to 14:30).  Previously the administrator had to check each of the
  projected booking slots manually.

  Now there is an additional button for administrators (labelled "Check")
  which they can use to see whether the proposed booking clashes with
  anything else.  This can be used before the event is repeated and it's
  then up to the administrator to decide whether to continue with the booking
  or not.

* Fix a problem counting subjects in the MIS importer

  The MIS importer was counting all subjects (not just those it had imported)
  when deciding whether the number had changed in the course of an import.
  This led to an erroneous message saying that the number had gone up even
  when it hadn't.

* Bump addressable gem to 2.8.0.

  A bug was found in the addressable gem - CVE-2021-32740.  Although it did
  not affect Scheduler, the gem has been bumped up to a fixed version.

* New flag in user profile

  An immediate future piece of work will be to add a batch job which checks
  for clashes between manually entered events and those coming from the MIS
  in controlled resources.  In preparation for this, a flag has been added
  to the user profile to allow resource administrators to decide whether
  they want to receive these e-mails or not.


v1.14.3   2021-08-20

* Add the option to do authentication with Microsoft Azure

  The Scheduler application relies on an external service to do user
  authentication.  Up until now this has always been Google's authentication
  service but this release adds the option to use Microsoft's Azure
  instead.

  Full documentation on how to do this will be found in the installation
  guide.


v1.14.2   2021-07-15

* Fix a permissions bug

  Ordinary Ad Hoc Domain Controllers (not admin) could not edit the
  availability schedule for Ad Hoc staff.

* Add more seed data for the demo system

  The demo system is used to create the documentation.  More seed data
  has been added to facilitate this.


v1.14.1   2021-07-10

* Bump up versions of packages to fix vulnerabilities

  Rails goes up to 5.2.6 to fix CVE-2021-22904

  Nokogiri goes up to 1.11.7 to fix a number of CVEs

  Puma goes up to 4.3.8 to fix CVE-2019-16779

  Two redundant packages - json and grunt - were removed entirely.

* Tweak seed data for demo system

  The seed data for the demo system was tweaked to work with
  the new AdHoc lessons feature.


v1.14.0   2021-07-09

* Implement support for Peripatetic Music Lessons (and other similar)

  This release adds a major new feature - the ability to organise
  what it terms Ad Hoc lessons.  The most obvious example of this
  would be peripatetic music lessons, but it could also be used for
  learning support lessons and the like - anything where pupils are
  taken out of normal timetabled lessons for time doing something else.

  Scheduler will assist the organiser of such lessons to ensure the
  pupil's missed lessons rotate around - avoiding hitting the same timetabled
  subject more often than is necessary.


v1.13.1   2021-04-08

* Tweak to event timing in the SOCS feed.

  It transpires that the SOCS feed does something slightly odd once you
  start adding meet times and the like to an event.

  If you have just a match time, it feeds that through as the time of
  the event.  Once you add a meet time, it passes that as the time of
  the event instead.  We thus have to use the explicit fixture time and
  not the integrated date/time field provided by SOCS.


v1.13.0   2021-04-05

* Upgrade Rails to 5.2.5

  A licensing problem was discovered in one of the Rails dependencies,
  in that a BSD-licensed component depended on another library which
  was under the GNU General Public Licence.  This was not a problem for
  Scheduler because it too is GPL licensed, but it was a problem for Rails.

* Upgrade redcarpet to 3.5.1

  CVE-2020-26298 affected the version of redcarpet previously used by
  Scheduler (although not in the way Scheduler used it).  Upgraded to
  remove the warnings.

* Fix to detection of overlapping events.

  The start and end times of Scheduler's events are stored in the database
  complete with Time Zone information.  Thus an all day event in the summer
  starting on the 1st of June is stored as starting at 20XX-05-31 23:00.

  If a query was then issued to the database specifying just a date (and
  no time) the event would appear to exist in 20XX-05-31.  The relevant
  code in the Event model has been updated to make sure it always uses
  a full TimeWithZone to specify the required threshold.


v1.12.1   2021-01-01

Three minor fixes/tweaks

* Detect and discard fixtures arriving from SOCS with a negative duration.

  It seems that the SOCS system for sports fixtures does not properly
  validate the fixtures as they are being entered, allowing the entry of
  events with negative durations.  That is, events which end before they
  started.  This caused a problem with the SOCS => Scheduler importer because
  such events are not allowed within Scheduler.

  The import now detects, logs and discards such events.

* Correct listing of "All but:" staff in free staff report for combined weeks.

  The report on free staff in nominated time slots introduced in release
  1.11.8 had a small bug in the report for combined weeks.  If for any
  given slot fewer than 10 staff are busy - that is, almost everyone is
  free - it attempts to list those who are busy rather than giving a
  very long list of everyone who is free.

  It was found that, although it was correctly detecting the circumstance,
  it then listed everyone instead of everyone who was busy.  This has
  been corrected.

* Improve algorithm to retro-generate activities timetable from iSAMS input

  The Scheduler importer fetches information on scheduled activities from
  iSAMS (the iSAMS Activities module) and loads them into the schedules
  of individual staff and pupils.  It also puts them onto the timetables
  of users as well, but here it has a slight problem in that iSAMS does
  not store them in timetable form - merely as a long list of dates during
  the term.

  The importer thus needs to work backwards and reconstruct a proper
  timetable from these individual events.  Previously it did it by the
  very simple approach of looking at the coming seven days - starting
  from today's date - and putting each event which it found on the appropriate
  day of the week in the timetable.  This led to problems when doing
  advance analysis of staff loading and availability for duties - until
  the start of term the timetable was not complete.

  The algorithm now looks at a 28 day period of the iSAMS output, starting
  7 days in the past.  Any activities which it finds in that range are
  allocated to the appropriate day in the timetable, with duplicates being
  dropped.  The timetable is thus available for use much earlier.


v1.12.0   2020-12-08

* New feature - Finding Free Times

  Scheduler has long offered the ability to find a free resource of
  a given type at a specified time - e.g. find a prefect who is free
  from 12:30 to 13:30 on Thursday 12th.

  This release adds a new facility to do it the other way around - given
  a list of resources (typically, but not necessarily, people) and a
  specified duration (e.g. 45 minutes) it will search for a time when
  all the indicated resources are free and offer a quick way of creating
  a new event at that time.

  The user can either list resources individually, or use pre-existing
  groups.  When a group is specified, the code looks at all the individual
  members of the group to find when they are all free.  Thus it is
  possible to search for a free slot for:

    * The Senior Leadership Team
    * The board room

  and the code will try to find a time when all the SLT, plus the board
  room are free.


v1.11.8   2020-10-13

Adds a couple of utilities to aid in managing staff duties and free
periods.

* findfreestaff

  This utility takes a list of staff (defined by a Group within the
  system) and a set of time slots (defined as a Day Shape) within the
  system and produces a report on which are staff are free (i.e. not
  timetabled to be doing anything) in the indicated periods.  This
  report takes account of both the academic timetable and scheduled
  extra-curricular activities.

  The report by default lists the requested time slots and the staff
  free within them, but it can also provide the information the other
  way around - a list of staff, and the periods in which each is free.

  The utility runs from the command line but it can automatically
  send its report to the Files area of a nominated user.  Thus it
  can be configured to run every night, and then the user can download
  the report from Scheduler as and when it is needed.

* timetabletoxls

  Similarly, this utility can convert the entire timetable (*including*
  activities) to an XLS spreadsheet.  It goes beyond just the timetable
  periods and can produce a report for any set of time slots defined
  within the day.

  Again, it is intended to be run as an overnight job with the output
  file being placed in a nominated user's Files area within Scheduler.


v1.11.7   2020-09-21

* Improve timetable printing

  When the "Print" button is used to print timetables the page header
  is now suppressed, resulting in a tidier print.

* Fix to issue displaying elements without can_roam? set

  When an admin user who happened not to have the can_roam? bit set in
  his or her user profile tried to show details of an element an error
  was displayed instead.  Admin privilege is now enough to show details
  of any element.

* Utility to list staff with blank zoom IDs.

  A very minimal utility has been added to generate a listing of any
  active staff members (those with timetables) who have a blank zoom id.

  Invoke it with:

  . ~/etc/whichsystem
  lib/import/findblankzoom.rb

  It is inefficient but will produce a listing in about 15 seconds depending
  on the speed of your system.


v1.11.6   2020-09-09

* Enhance Zoom ID import utility

  The Zoom ID import utility has been enhanced to cope with a slightly
  different format of input file.

* Fix to timetable printing

  It was found that the buttons for printing a whole set of timetables
  did not work correctly on MacOS computers.  This was caused by an error
  in the code which first invokes the print dialogue and then closes the
  window - the window was closing too soon.

* Cope with events with negative duration from iSAMS

  An event had been erroneously entered into iSAMS with a negative
  duration (from 17:00 to 16:30).  This caused the Scheduler import
  utility to fail.  The utility will now log and ignore such events.


v1.11.5   2020-09-06

* Allow tutor period to be only 15 minutes long in printed timetable

  A tutor period of only 15 minutes was causing the printed timetable
  to have text outside the bounding box for that period.  This release
  moves the text back inside the bounding box.


v1.11.4   2020-09-05

* Default to showing initials in pupils' view of their schedules.

  Scheduler has long allowed for the teacher's initials to be included
  in the listing for each lesson, but it's a configuration option which
  defaults to off.

  In this release, the default for pupils is changed to be on.  They can
  still opt to turn it off, but by default it's on.

  A maintenance method is also provided to convert all existing students
  to having it switched on.


v1.11.3   2020-06-25

* Upgrade rack to version 2.2.3

  This implements a fix for CVE-2020-8184

* Upgrade websocket-extensions to 0.1.5

  This implements a fix for CVE-2020-7663


v1.11.2   2020-05-29

* Ruby updated to version 2.6.6

  Ruby 2.7 was released on 2019-12-25 (as is traditional) but it contains
  certain deprecations in preparation for Ruby 3.  Rails 5 applications
  will run with Ruby 2.7 but produce quite a lot of warnings about
  the deprecations.  The latest versions of Rails 6 are fully compatible
  with Ruby 2.7, so an upgrade to that release will have to wait until
  Scheduler is upgraded to Rails 6.

  In preparation for installing this release, it's worth getting
  Ruby 2.6.6 installed on your system.  Log in as your scheduler user
  to the command line and type:

    $ rvm install ruby-2.6.6

  This may take 10-15 minutes to run, depending on the speed of your
  system, but it can be done whilst your system is still open to users.

  To install this release, some extra steps are required over and above
  those given at:
  
    https://xronos.uk/admin/upgrades.html#basic-steps

  Having stopped your web server and fetched the new version with "git pull",
  you then need to move out of the Scheduler directory and back in again:

    $ cd ..
    $ cd $SCHEDULER_DIR

  This will cause rvm to notice that the new version of Ruby is required
  and it will create a new gemset for it.  You then do:

    $ bundle install

  to install all the required gems in the new gemset, and:

    $ rvm alias create scheduler ruby-2.6.6@scheduler

  to switch the environment to the new version of Ruby.

  If you are using Passenger to run your live application, then
  edit /etc/nginx/sites-available/scheduler to change the version
  of Ruby used by Passenger.  If your relevant line reads:

    passenger_ruby /home/scheduler/.rvm/gems/ruby-2.5.5@scheduler/wrappers/ruby;

  then you can change it to just:

    passenger_ruby /home/scheduler/.rvm/gems/scheduler/wrappers/ruby;

  (making use of the alias which you just created) and thus avoid
  having to make this change in future releases.

  With these steps done, resume the normal upgrade at "rake db:migrate".

* Loofah gem upgraded to version 2.5.0

  For some odd reason, GitHub has a thing about applications using old
  versions of Loofah.  For most gems, it complains merely if there is
  an actual problem with the old version, but for Loofah it complains as
  soon as a new version comes out.  Just to shut it up, Loofah has
  been upgraded to 2.5.0.

* Puma gem upgraded to 4.3.5

  There are two vulnerabilities (CVE-2020-11076 and CVE-2020-11077) in
  Puma 4.3.3.  These affect only sites using Puma rather than Passenger
  as their application server.


v1.11.1   2020-05-24

Tidying up and polishing the move to Rails 5.

* Version number added to all old database migrations.

  As of version 5, Rails requires all database migrations to specify
  which version of Rails they were generated for.  Anything before
  Rails 5 should carry a version number of 4.2.

  Whilst really old migrations shouldn't really be needed by anyone,
  it's difficult to know exactly where to cut off and so all the old
  ones have had version 4.2 added to them.

* Puma gem added to Gemfile

  Rails 5 uses Puma as its application server by default.  Whilst existing
  installations will continue to use Passenger for now, Puma is included
  in the distribution.

  Several empty directories have been added to support the use of Puma
  in a live installation.

* Convert database schema to specify utf8mb4 on all tables

  The database schema - used to create new databases - now specifies
  utf8mb4 as the charset on all the tables.

* Specify correct charset and collation when creating a database.

  The sample database creation script provided in the distribution -
  support/setupmysql - has been modified to specify utf8mb4 as well.

* Convert to using Rails 5 style credentials

  Older versions of Rails used a file - config/secrets.yml - to hold
  a magic random string.  This in turn was used by the application to
  thwart session hijacking attempts.

  As of Rails 5, the equivalent information is held in an encrypted
  file, with the encryption key being held in another file.  As part
  of installing this release it is necessary to create these files
  with the command:

    $ EDITOR=vi rails credentials:edit

  The necessary files are not included in the distribution because
  they need to be unique to each individual system.

* Add various files to the support directory

  Several files have been added to the support directory to assist
  in the installation of a new system.  These are referenced by
  the updated installation instructions.

* Update to Rails 5.2.4.3

  A minor bug-fix release of Rails was put out in the course
  of preparing this release of Scheduler.  It is included with
  this release.

* Don't require subject names to be unique

  Scheduler has a check to ensure that subject names fed from the MIS
  are unique.  It was discovered that this clashed with one MIS where
  they weren't unique.

  It's not really Scheduler's job to police this kind of things - it's
  up to the MIS and its manager to decide.  The check has therefore
  been removed from Scheduler.


v1.11.0.1 2020-04-19

* No code changes - one extra step in the installation instructions

  TL;DR - As part of installing this release, copy the definition
  of SECRET_KEY_BASE from ~/.profile to ~/etc/whichsystem in
  addition to the usual steps documented at:

    https://xronos.uk/admin/upgrades.html

  Long version:

  One tiny wrinkle cropped up when the previous release was deployed
  to a staging server for final testing.  There are various cron
  jobs included in the system and since the upgrade to Rails 5 these
  had been tested both from the command line and as cron jobs on a
  development system.  Where they didn't however work was as cron jobs
  on a production system.

  This is because of an item required by Rails applications - a
  secret key to secure the interactive sessions with browsers.  This
  key is hard coded for development and test modes, but requires
  an environment variable to be defined when the system is running
  in production mode.

  Previously (Rails 4) rake jobs were run from cron entirely separately
  from Rails, and as they don't involve an interactive browser session
  they didn't need this secret key.  In Rails 5, there has been an
  attempt to integrate rake and rails - maintenance jobs which would
  previously have been invoked as "rake ..." are now invoked
  as "rails ...", apparently to avoid operator confusion.

  A possibly unintended side effect of this is that when you invoke
  a rake task in production mode you now need the SECRET_KEY_BASE
  environment variable to be defined, where you didn't in Rails 4.

  Again, all is well in an interactive terminal session on a production
  system (because the key environment variable is defined in ~/.profile,
  which is included as the user logs in) but not in a cron job,
  the setup for which skips ~/.profile.

  Scheduler already has a file ~/etc/whichsystem deliberately
  designed to set up things needed by the cron jobs, so adding the
  definition of SECRET_KEY_BASE to that file fixes the problem.

  There are no code changes in this release - merely changes to this
  documentation.  As this document forms part of the release, that
  in turn needs a minor version number bump.


v1.11.0   2020-04-18

* Upgrade Rails to the latest version 5 - 5.2.4.2

  This has involved quite a lot of work behind the scenes, upgrading
  first to 5.0, then 5.1, then 5.2.  At each stage various systematic
  adjustments were needed, followed by extensive testing.

* A very large number of new automated tests

  To facilitate the upgrade process, a lot more automated tests were
  written.  The more the code is exercised automatically, the more
  confident one can be in an upgrade.

* A number of small bugs fixed

  In the course of writing the tests, several small bugs were discovered
  which had never been noticed in the course of normal usage.  This is
  because the tests exercise code paths which are seldom used in
  a live system.  These bugs had never been reported before so aren't
  listed individually here.  If you really want to know them, look
  at the git change log.

* GitHub Issue #12 resolved

  Cloning a group put you in an endless loop of editing

* GitHub Issue #13 resolved

  After deleting a group membership record, the back button didn't
  take you back to the group listing.

* GitHub Issue #19 resolved

  Un-cloneable groups no longer have a Clone button.

* Stop auto-complete of date fields on Report form

  When generating a report for an element, the date fields have a
  selector provided by the application, but some web browsers were trying
  to do auto-complete as well which was confusing.  Auto-complete from
  the web browser now switched off.


v1.10.0   2020-03-15

* Add a new Agenda view

  The software now has a completely new view, available to logged in
  users only and intended to be compatible with mobile devices.  It
  has no options and simply shows the user his or her agenda for the
  coming week.

  It is accessed via the URL https://scheduler.myschool.org.uk/agenda

  If a user is not already logged in, he or she will be prompted to
  log in.

* Add links for launching video-conferencing sessions

  It is now possible to add configurable links for launching video-
  conferencing sessions.  Each staff record has an extra field
  for an individual-specific code.  The system settings gain two
  extra fields - one for the link text and one for the URL to use.

  These links are then available in two places - in the modal dialogue
  box showing event details to a logged in user, and in the agenda
  view mentioned above.

  Within the agenda view, the currently relevant sessions will be
  highlighted.  All the links will work (even those not highlighted)
  but the system uses the current time to highlight those which should
  be relevant.


v1.9.5    2020-03-10

* Specify how far in the future to import SOCS events.

  By default the SOCS package exports events for the next 100 days.
  Sometimes this is not enough for planning purposes.  It is now
  possible to specify an explicit future duration in the ~/etc/socsauth
  file.  A sample will be found in the support/socsauth file.

* Fix bug in identifying home fixtures from SOCS

  The SOCS importer was checking for the prefix "Home:" in order
  to identify home fixtures coming from SOCS.  This is normally OK, but
  just occasionally the feed contains "Home" instead, without the colon.

  The importer now looks for just "Home".

* Two gems have been upgraded for minor security issues:

  * Nokogiri has been upgraded to 1.10.9.  Fixes CVE-2020-7595

  * Rake has been upgraded to 13.0.1.  Fixes CVE-2020-8130


v1.9.4.2  2020-02-11

* Another fix to v1.9.4.

  A typo had crept in to the Elements controller with the result that
  requesting an ical feed using a staff member's initials (an archaic
  and deprecated method) no longer worked.  Fixed.


v1.9.4.1  2020-02-11

* Fix to logic of User#can_retime?

  A problem was discovered with the changes made to User#can_retime?
  in the previous release.

  Given an event with a locking property attached, but where the
  event was not actually locked (because it was created before the
  relevant property acquired its locking attribute) the can_retime?
  function would return false for everyone - even the owner of the
  locking property.

  This meant that no-one could re-time the event.

  This release restores the previous behaviour in this particular instance,
  which is that any controller of an attached resource can re-time the event.

  For similar events which *are* locked, only controllers of the locking
  resource can re-time the event.


v1.9.4    2020-02-02

* Update images for GitHub README.

  The images shown on GitHub to browsers were a couple of years out
  of date.  New ones installed.

* Tweak to the logic of User#can_retime?

  Under the old system of constrained events, users with an approved
  resource request could not change the timing of their event, but any
  resource controller potentially could.

  With the addition of locked events, this isn't quite enough.  Only
  the lock controller should be able to re-time the event.  The logic
  of User#can_retime? has been changed to implement this.

* Disable "all-day" field rather than hiding it.

  When a user lacks permission to re-time an event, the "all-day" flag
  field is now disabled rather than hidden.

* Two new options for ical feeds - lm and zulu

  Two new options have been added to the ical feeds.

  * lm - or last modified.  If specified this will cause each event
    to carry the ical-standard specified LAST-MODIFIED field.  The value
    in it will be calculated from the event record and all its attached
    commitment records.  The one of them which was modified last provides
    the datetime stamp.

  * zulu - Zulu time.  The start and end times of events will be given in
    Zulu time (UTC) rather than the local time usually provided.  It is
    then up to the client program to adjust these times for presentation.

    In particular, note that if Daylight Saving Time is in effect on the
    date of any given event, the client code will have to add the necessary
    adjustment.


v1.9.3    2020-01-21

* Prevent NaN% in event resource summary.

  For an event with no controlled resources, the percentage completeness
  was coming out as NaN%.  Now shows 100%

* Add tree view for locations

  The previous release added the means to make locations subsidiary
  to each other in a tree-structured way.  This release adds the means
  to view this tree when editing.  Menu => Admin => Models => Locations =>
  Tree view.

  Locations can be edited directly from the tree view by clicking on
  their names.

* Don't repeat resource name in "event deleted" e-mail.

  In the event deleted e-mail, the resource name was being added
  to the first header in the e-mail, resulting in messy word-wrap.

  It also appears further down in the body, so it's been removed
  from the header.  It is still in the subject line.

* Add the concept of locked events.

  It is now possible to lock certain events in the system to prevent
  them being edited, even by their owners.

  Each event carries a "locked" flag, and this gets set when a locking
  Property is attached to the event (either via the approvals system, or
  directly if the Property does not require approval).

  Once an event is locked, the owner can still add and remove other
  resources (although not the locking Property) but cannot change
  the title or delete the event.

  (Any approved property already prevents the event being re-scheduled.)

  The controller of the locking Property will need to be consulted
  to remove it again.  He or she can delete it.

  The idea is to allow users to submit events for inclusion in,
  for instance, a public calendar, but once they're in there then
  the users won't be able to arbitrarily remove them again.

  Note that it doesn't really make sense to have a locking Property
  which does not require approval.  If you create one, then users will
  be able to add it to their events, but will never be able to remove
  it.

  If the "locking" flag is set on an existing Property it will affect
  all events entered in the future but not those which already have
  the property.  If it is desired to lock all the existing events
  then the following command can be used at the Rails console:

    Element.find_by(name: "whatever...").update_potentially_locked_events

  It can take a minute or so to complete.

* Implement some tweaks for the SOCS feed

  A new requirement arose to cope with events arriving from SOCS which
  aren't really wanted in the Scheduler database.  Typically these are
  fixtures which have been entered by someone at the other school.

  To assist in coping with them, a few changes have been made to
  the way Scheduler handles rejected commitments.

  1.  If a commitment for an event from SOCS is rejected, no
      e-mail is generated to the events owner.

  2.  Likewise, if the commitment is left in the rejected state
      the owner won't get nightly nagging e-mails about it.

  3.  Rejected events (as opposed to those awaiting approval) no
      longer appear in the context of the rejected resource to users -
      even users with the "View unconfirmed" permission bit set.
      They are visible only to the event owner and the controllers
      of the resource.

  Note that Scheduler needs to retain them in its database, because
  it needs to know that they're not wanted.  If they were simply
  deleted then the next time the SOCS feed ran, they would be imported
  afresh.  Likewise they need to remain visible to some users because
  otherwise there would be no way to manage them.

  Such events can thus remain in the Scheduler database, but make no
  appearance in the public calendars.

* Allow editing of the non_existent flag on events

  Each event in the Scheduler database has long had a flag called
  "non_existent".  Typically this is set to false, but if it is set to
  true then the event is considered as not really existing.  It can
  be seen, but it is permanently shaded out.  It won't appear in any
  feeds.

  Historically the only way this could be set was via the importer
  from the MIS.  The importer uses Scheduler's idea of suspension intervals
  to mark appropriate lessons in those intervals as non_existent,
  meaning the staff and pupils are freed up for other things.  Typically
  this happens during exams, and the invigilation component takes
  account of these suspensions when suggesting staff to do invigilation.

  Suitably privileged users can now edit this bit directly.  If an
  event is marked as non existing (called a "Shadow event" in the UI) then
  it is shaded out and the resources are not regarded as busy.

  It may be desired to add more effects as this facility is used.


v1.9.2    2020-01-11

* Add extra decode for faulty SOCS string

  It was observed that some of the strings coming from SOCS seem to be
  double-encoded.  The SOCS feed is XML so an ampersand (&) should be
  transmitted as "&amp;".  Instead it was being sent as "&amp;amp;"

  The best guess is that it has been encoded once so it can be displayed
  quickly in an HTML page (which also requires encoding), and then again
  for transmission as XML.

  The import utility now applies a second decoding step to affected strings.

* Two Gems updated for minor vulnerabilities

  The Loofah Gem has been updated to version 2.3.1.  CVE-2019-15587
    As a side effect, the Crass Gem has been updated to 1.0.5 and
    the Nokogiri Gem has been updates to 1.10.6

  The Rack Gem has been updated to version 1.6.12.  CVE-2019-16782

* Show "Repeating event" message to all users

  When you open the dialogue box for additional details of an event,
  users with edit privilege for that event were shown a message,
  "This event is one instance of a repeating set.  If you edit it..."

  This message is now shown to all known users, but the "If you edit it..."
  part appears only if you have edit permission.

* Small fix to SOCS import utility

  One of the options to the SOCS import utility is "--intelligent".  This
  causes the utility to try to assign ownership of each fixture to the
  relevant member of staff.

  The utility was actually ignoring this option and behaving as if it
  had been specified all the time, meaning you couldn't do a non-intelligent
  import.  Fixed.

* Add entity type to predictive text box

  When a user is typing the name of an element, you can end up with
  two different elements of the same name but different types (e.g.
  Subject and Group).  The predictive text code now appends the type
  of the element to the name being displayed in the menu to ease
  the selection.

  The type does not then appear in the value auto-filled into the
  predictive text input field.

* Compress SOCS import file after archiving

  Each time an import utility runs it archives the data files for later
  analysis if needed.  The SOCS script was archiving its input file
  but not compressing it.  Fixed.

* Add event summary to relevant e-mails

  The system generates various e-mails to users when significant things
  happen to their events (resource approved, resource allocated, etc.)

  Some users were apparently assuming that because they had had one
  resource request approved, that implied the event was all complete.
  To try to counter this, all such e-mails now include an event summary
  saying exactly what resources have been requested and the status
  of each request.

  There is also a numerical percentage completion figure, and only when all
  requested items are approved/allocated does the percentage reach 100%.

* Make deletion message in SOCS importer conditional on verbosity

  The SOCS import process was logging event deletion even when the
  "--verbose" option was not specified, resulting in unnecessary
  notifications.  This message is now conditional on verbosity.

* New "Event deleted" e-mail

  Scheduler has long had the option to send immediate e-mails to
  resource controllers about new or cancelled requests for their
  resources.  For controllers who have opted to receive these
  e-mails, they are sent every time a fresh request is entered, or
  a pending request is removed.
 
  A new and slightly different case for sending the e-mail has been
  added.  If a request for a controlled resource has been confirmed,
  or pooled resources (mini-buses) have been allocated, then the
  controller gets the e-mail regardless.

  Also, if an event is deleted by anyone other than the owner of the
  event then the owner gets the e-mail.

* Suppressing locations in a public calendar feed.

  Two mechanisms have been added to allow for some locations to be
  suppressed when using the ical interface to provide a public
  calendar feed.  This is to cope with events which are making use
  of a large number of locations, but where only some of those
  locations should be included in the public description.

  * Location weighting

    Each location now has a numeric weighting - default 100.
    This can be edited by a system administrator.

    When taking an ical feed, one can now add a modifier "spread=NN"
    and then for each event in the feed the ical generator will
    find the location with the highest weighting and then exclude
    all locations whose weighting is more than the spread value
    less than that.

    Thus given a location with a weighting of 150 and a specified
    of 20, none of the locations with the default weighting of 100
    would be included for that event.

  * Subsidiary locations

    Each location record also gains a field "subsidiary to".
    By default this is blank but it can be set to be any other
    location.

    Again, when assembling details of an event for an ical feed,
    the generator will look at all the listed locations, and omit
    any which are subsidiary to any other location attached to
    the event.

    The "subsidiary to" property is transitive.  If A is subsidiary
    to B, and B is subsidiary to C, then A is subsidiary to C.

    The location editor will not allow any kind of circular
    relationship to be set up.

* Add "?clip" option to ical feeds

  In ical feeds (as in any kind of calendar event handling) end
  dates/datetimes are defined as being *exclusive*.  That is, the
  end date/datetime given is not itself part of the event.

  At least one piece of client software has been find which does not
  implement this correctly, and considers an event ending at exactly
  midnight to extend into the next day.

  Since it isn't apparently possible to fix the client code, a
  workaround has been added to Scheduler's ical feeds.  If the
  client specifies "?clip" as part of the URL used, then the
  ical generator will modify the end time for any timed event of
  non-zero duration which ends at exactly midnight.  It will
  chop of one second and end the event instead at 23:59:59.

  Using this option should be regarded as a purely interim measure
  until the client software can be fixed.  It may well have
  undesirable knock-on effects if anyone tries, for instance, to
  calculate the duration of such an event.

* More tests

  A large number of additional tests have been added to the automated
  test suite.


v1.9.1.2  2020-01-03

* Hotfix to iSAMS data import

  A problem became apparent in the import of activity data from iSAMS.
  An activity group was deleted but the corresponding events still
  existed, causing the Scheduler import process to trip out.

  The importer has been fixed to cope with this anomaly.


v1.9.1.1  2019-12-04

* Fix to traditional twin-wrapping of events.

  Duplicate fields meant that, if you wrapped an event in the old-fashioned
  way - with a set-up event and a clear-up event - these two events got
  not the time you specified but the time for the single wrapping
  event.  Fixed.


v1.9.1    2019-12-03

* Add intelligent event ownership to SOCS import

  The SOCS import utility acquires a new option - --intelligent.  If
  specified then the importer will check each fixture's indicated
  sport and if that sport has an owner on Scheduler (given by a
  user having "Controls" privilege over the sport's fixtures) then
  it will make that user the owner of any fixture events for that
  sport.

  Thus, if "Able Baker" controls the "Rugby fixture" property, then
  he will gain ownership of all Rugby fixture events too.

  Fixtures for sports without an owner will continue to be owned by
  the user specified on the command line, or be system events if
  no-one is specified.

* Add single-event wrapping

  Scheduler has long had a facility for wrapping events to create
  times for set-up and tear-down.  Thus, if a concert is scheduled
  in the theatre for 14:30 to 16:00 (which is how it should be shown
  in the public calendar) then it is easy to add some non-public
  events before and after for the time needed for setting things
  up and clearing things away in the theatre.

  For sports fixtures, having two separate wrapping events is less
  appropriate.  Like the concert, a fixture might be scheduled to
  last from 14:30 to 16:00, but one might need a mini-bus from 13:00
  to 17:30.  It's not a case of needing a mini-bus for a little while
  before and a little while after - it's needed throughout.
  
  An extra tick-box has been added to the wrapping dialogue - "Single
  event" - and if ticked then one encompassing wrapping event is
  created rather than two separate ones.

* Additional tests for wrapping controller

  More test have been added to exercise the wrapping controller.


v1.9.0    2019-11-25

* Add SOCS import facility

  SOCS is an external package which allows schools to arrange
  sports fixtures cooperatively between themselves.  Each fixture
  need be entered only once, and then appears for both relevant
  schools.  SOCS makes the resulting information available through
  web pages and via an XML feed tailored to each school.

  A facility has been added to Scheduler to use the XML feed to
  import the fixture information and add it to the school's general
  scheduling information.

* Fix timetables for 12 day fortnight

  Scheduler can produce printed timetables for staff and students,
  integrating all the information held from various sources.  The
  timetables are configurable for a one or two week cycle, and for
  5 or 6 days in the week.

  Previously, for a school with a 12 day fortnight (school on Mon
  to Sat and a 2 week cycle) the formatting of the printed timetable
  went wrong as not all the periods would fit in the available width.

  The formatting is now done dynamically and the 12 day fortnight
  appears correctly.

* More automated tests

  More tests have been added to the automated test suite.


v1.8.10.1 2019-11-13

* Fix to group editing

  An error introduced in v1.8.9 prevented the correct evaluation of
  permissions when a user tried to edit a group.  Fixed.


v1.8.10  2019-11-12

* Enhance the working of invigilations

  The code has been improved to do more of the routine work of
  setting up invigilation slots prior to populating them.

  Major changes:

  * The system can auto-generate your room records (ProtoEvents) from
    some simple events specifying when you want to have exams.

  * The system will mask the specified exams against your defined
    invigilation periods to produce invigilation slots of exactly
    the right length.

  For full details see the documentation at:

    https://xronos.uk/advanced/invigilation.html


v1.8.9.1 2019-10-15

* Re-work the API su interface slightly

  On writing the documentation for the new API facilities it was
  realised that although the new features worked, they weren't
  as logically implemented as they could have been.

  The API calls have been re-done slightly to make them more logical.

* Tweak seed data for demo system

  The seed data for the demonstration system has been tweaked to
  allow the new features of the API to be used.  Specifically the
  user Simon Philpotts now has su permission.


v1.8.9   2019-10-14

* Add un-su ability

  Scheduler has long allowed a suitably privileged user to "su" to being
  a different user.  This is very useful for system administrators to test
  things from the point of view of an ordinary user.

  The system now keeps track of such an administrators original user id,
  and adds a "Revert su" option to the main menu.  Selecting this takes
  the user back to being him or herself.

* Add su ability to API

  It is now also possible for a suitably privileged user to execute
  the equivalent of an "su" through the API.  This is potentially useful
  if it is desired to create events on behalf of another user.

* Prevent gaining of privileges via su

  It is just possible that a user using the API might have su privilege
  but not admin privilege.  In that case, the user cannot su to being
  any user with admin privileges.

  The same is true through the GUI, but the user wouldn't be presented
  with that option in any case, since only admin users can view user
  listings in order to effect an su.

* Re-work handling of user permissions

  A large, but not very apparent piece of work.

  In the beginning, Scheduler simply recognized staff, pupils and guests.
  Staff had a certain number of hard-coded privileges, pupils a smaller
  number and guests none.

  Since then, permission bits have been added, along with user profiles
  to allow the permissions to be applied to users en masse.

  A few areas of code had not been updated to reference these new bits,
  and quite a lot of tests were done on whether a user was "known" - that
  is, a staff member or a pupil.

  A new bit has been added to the user profile records called "known", and
  this then affects all the users with that profile.  By default, staff
  and pupils are known and guests are not, but the system admin can add
  as many more user profiles as are needed with the known flag set or
  not as required.

  For instance, one could add a user profile for PTA members, with the
  known flag set, and then assign users to that to give them a selected
  small range of permissions.  It is no longer necessary to give them a
  dummy staff record for them to have access to the system.

  Similarly, one could create a user profile called "Ex staff" with
  the known flag unset, and then move staff members to it as they left
  the school.  This would immediately revoke their access to Scheduler,
  rather than waiting for the authentication through Google to be
  removed.

  If it was desired to block access to all pupils, it would be enough
  to set the known flag on the pupil user profile to false, and then
  all students would be blocked.

  More details will be found in the Scheduler Admin Guide at

     https://xronos.uk/admin/

  Any user who is not "known" will be treated as a guest.  If a user
  is "known" then all the other permission bits become effective.

* More tests on user permissions

  A large number of tests have been added to the test suite covering
  the area of user permissions.

* Fix test for user access in resource allocation screen

  The test for whether a user could do allocation of resources (e.g.
  Minibuses) was simply wrong.  For a user to be able to access that
  screen, he or she needed permission to create groups.  This has
  been fixed.

* Add special login for test suite

  In order to implement integration tests within the test framework
  it is necessary for the test user to be able to login to Scheduler.
  A special test login facility has been added, which is available
  only when Scheduler is running in the test environment.

* Rationalise session manipulation to common code

  There was duplicate code for manipulating the user's session in the
  main application and in the API.  This has been extracted and put
  into a common code module.

* Permission bits for event journals

  An extra permission bit has been added to allow users to access
  event journals.  Previously only admin users could see these journals,
  but now any user who has been given the appropriate permission can
  do it.

* Fixes to Pass import process

  In release 1.8.5 a change was made to the way in which pupils are
  identified when importing from Pass.  The obvious "Pupil ID" field
  in the Pass record turns out not to be suitable because it changes
  every year (!).  Instead the importer uses the "Name ID" field
  from the same record which is apparently constant.

  This change led to a problem in populating teaching groups, which
  has now been fixed.

* Allow multiple teaching groups when merging Pass lessons

  Pass suffers from a problem apparently common to most MISs.  It
  can't cope with more than one teacher per lesson.  Sport lessons
  and the like often have more than one teacher.

  The workaround in Pass is to have several pretty much identical
  lesson records, with different teachers in each one.  The Scheduler
  importer then merges these back to form a single lesson event.

  Sometimes it is necessary to merge such lessons where each has a
  separate teaching group attached.  Scheduler now attaches all
  the teaching groups to the new merged lesson.

* Code specific to one school for adjusting tutor group times

  School-specific code has been added to adjust some tutor group
  times from 23:00 back to the right time.

* Two upgraded gems.

  Two gems have been updated to the latest versions

  Nokogiri has been updated to 1.10.4 to fix a security issue.
  Scheduler was not actually affected by the security issue
  (CVE-2019-5477) because it didn't use the relevant code, but
  best upgraded.

  Charlock_holmes has been updated to 0.7.6 so that it will build
  on later systems - specifically to allow Scheduler to be run on
  a Raspberry Pi 4.


v1.8.8   2019-09-19

A large collection of small fixes and tweaks.

* Reduce verbosity of iSAMS importer

  There are various common data inconsistencies which crop up in the iSAMS
  database.  Historically the Scheduler importer has whinged about them
  but coped.  Now, if the Scheduler importer is invoked with the --quiet
  option that it will simply cope without whinging.

* Fix styling of "New Era" button

  The button in the Era listing screen for creating a new Era has
  had its styling made the same as everywhere else.

* Disable browser autocomplete on Era data fields

  The form for entering/editing Era data uses a pop-down data selection
  dialogue.  It is therefore not helpful if the browser is trying to
  provide auto-completion as well.  Browser auto-completion has now
  been disabled on these fields.

* Fix format of displayed date in Era editing.

  The existing dates in Eras were being displayed in a different format
  from the usual.  Fixed.

* Add Cancel button to the Era editing form

  When editing an Era, there is now the usual Cancel button as well
  as a Save button.

* Add validations to the Era model

  The Era model lacked a full set of validations.  These have been added
  and the test suite enhanced appropriately.

* Remove spurious debug statements

  A number of left over debug statements were removed from the code.

* Add past_days/future_days as options for calendar feeds

  When you take an ICAL feed from Scheduler, it by default feeds you events
  starting from the beginning of the previous academic year (Era) and going
  on for as long as there are events.  This is to allow reference
  back to earlier events, even once they are in the past.

  It has always been possible to specify explicit start and end dates
  as part of the options when taking a feed, but that has the disadvantage
  that you need to remember to change them as time passes.

  Two new options have been added to the calendar feeds:

    * past_days=N
    * future_days=N

  These allow you to specify rolling start and end dates for a feed.

  For full details, see https://xronos.uk/feeds.html#additional-options

* Don't link non-current pupil to new user

  When a user logs in for the first time, the system attempts to associate
  the user with a Staff or Pupil record.  For Staff records, it was looking
  only at current staff, but for Pupil records it was looking at all of them.

  For an ex-pupil who had come back as a member of staff, it selected the
  pupil's old record instead of his current Staff record.

  The relevant code now looks only at *current* pupil records, in the same
  way as it looks only at *current* staff records.

* Prefer Staff to Pupil for new user

  It's just possible that a user might have both a Staff and a Pupil
  record.  In this case, the code now prefers the Staff record.

* Fix display of initials on meetings

  When generating a printable timetable, the system includes the initials
  of the staff member taking each lesson provided there is room in the
  box (long enough lesson).

  For meetings, it was including the initials of the first listed staff
  member in the meeting, which is kind of pointless.

  It now lists initials if an event has either one or two members of
  staff involved - "ABC" or "ABC/DEF".  Any more than two and it doesn't
  bother trying to display the initials.

* Fix order sensitivity in tests

  It was discovered that a few of the tests in the test suite needed to
  be run after other tests to have the right initial conditions set up.

  All the tests are now capable of being run individually.

  The necessary pre-conditions (User Profiles) are set up by way of
  fixtures.

* When the system is run in demonstration mode (as on
  https://schedulerdemo.xronos.uk ) some elements now have fixed UUIDs.
  This is to enable feeds to be taken from the demo system and to
  persist through the nightly data reload.

* Include thumbnail for file in demo data note.

  One of the events in the demonstration data has a note attached
  and the note has an embedded file.  The demonstration data now
  causes the thumbnail for this file to be shown too.

* Add explicit 404 handler for stupid requests from the 'net

  Any web server which is publicly visible gets regular requests
  for URLs like "/admin.php".  These are generated by robot scripts,
  searching for systems to break into.

  By default, these cause a lengthy (many lines) error message in
  Scheduler's production log, and for no good reason.

  Scheduler now has an explicit catch-all handler for these unexpected
  requests.  It simply returns a 404 status and page.  The request
  is still logged, but the entry is much shorter.

* Add organiser_id to the fields for events created through the API

  API clients can now specify an explicit organiser_id when creating
  new events.  For full details see

    https://xronos.uk/api/events.html#parameters

* Allow event organiser to increment/decrement requests
  GitHub issue #8

  The organiser (as opposed to the owner) of an event has limited
  edit privileges, including the ability to add or remove resources.

  An error in the permissions checking meant that the organiser could
  not increment or decrement a resource request, even though he could
  create or delete one.  Fixed.

* Fix issue with concerns in a different view suppressing events
  GitHub issue #5

  When a user asks to see his or her own events in the schedule display,
  the system automatically shows only those which are not otherwise
  visible.  This is simply so the events are not displayed twice
  unnecessarily.

  An error in this area of code meant that events which would
  be visible in *any* of the user's views got suppressed.

  Now only events in the user's current view are considered by the code
  preventing double display.

* Generate right report type - CSV or DOC
  GitHub issue #4

  A really old one.  If a user generated a report sending the output to
  the screen, then went back and tried to generate a CSV or a DOC instead,
  the output again went to the screen.  It was necessary to exit the
  report dialogue entirely, come back in and start again.

  This has now been fixed.

* Use correct colour to display resource requests.
  GitHub issue #7

  If a Resource Group had been created with no default colour specified,
  then a user watching requests for the Resource Group by way of a concern
  would see the Concern (LHS of screen) in one colour, and requests in
  a different colour.  Fixed.


v1.8.7.1 2019-08-31

* Remove accidental use of ECMAScript 6 feature

  In final release testing, compilation of the JavaScript failed in
  the Production environment because of the use of an EC6 feature.
  This has now been removed.


v1.8.7   2019-08-31

* Streamlined file attachment to events

  Since version 1.8.2 it has been possible to store files within Scheduler
  and embed links to them in notes attached to events.  A helper is
  provided to generate the necessary Markdown link text.

  In this release, a shortcut way of doing this is added.  A new button
  is available in the "Show event" dialogue labelled "Attach file".
  Clicking this button takes you straight to the file selection
  dialogue, and if you select a file and click OK then the file
  is immediately attached to the event without having to go through
  the note editing process.

  (The file is still actually embedded in a note, so it is possible
  to edit it later and add more if required.)

* Add thumbnails for image files

  Scheduler will now create thumbnails for any image files (including
  PDF and PostScript) which are uploaded to it.

* Improved file listing in file attachment dialogue

  When a user is attaching a file to an event (or embedding one
  in a Note) they are shown a pop-up selection dialogue, with the
  means to pick one to use.  The display of files in this dialogue
  has been improved to look more like a normal graphical file listing.

  Where a file has a thumbnail, it is included in this file listing.

* Facilitate thumbnails in file attachments

  The file attachment dialogue now allows the user to tick a checkbox
  which will cause the corresponding thumbnail to be included as part
  of the link to the file.  This is in addition to any file description
  or file name which the user provides.

* Most recent files shown first in attachment dialogue

  When a user is attaching a file to an event, it is more likely that the
  most recently uploaded files will be the one wanted.  The files
  in the dialogue are thus shown with the most recent one first.
  
* Maintenance job to remove orphaned UserFile records

  When a user uploads a file to Scheduler, the file itself is stored
  on disk and a UserFile record is created in the database to keep
  meta-data about it.

  Under exceptional circumstances, it is possible that someone with
  privileged access to the system could delete the underlying disk file
  without updating the database.  This would then result in a "File not
  found" error page each time someone clicked on a link to that file.

  A cron job has been added which runs each night and removes any
  UserFile database records which have lost their underlying disk files,
  which in turn triggers the processing described next...

* Deleting a UserFile removes any corresponding links attached to events

  Scheduler is not intended as a large scale file store.  Users have
  a limited amount of disk space and they will probably want to remove
  old files once their utility has passed to free up space for new ones.

  Each time a UserFile is deleted, Scheduler now updates any affected
  Notes and removes all links to the deleted file.

  A link like this:

    <a href='/user_files/12345678'>My lovely document</a>

  will become:

    My lovely document (File deleted)

* Automatic purging of old e-mails (configurable)

  In a similar vein, Scheduler keeps copies of all the e-mails which
  it sends.  The quantity stored increases quite quickly and it may be
  desired to keep them under control.

  A new setting field has been added - "How many days to keep emails".
  By default it has a value of 0, which means "Keep forever", but if
  the value is set to something above 0 then all e-mails more than
  that many days old will be purged by a nightly cron job.

  A value between 30 and 90 might be a useful one to set.

* Fix indenting of email paragraphs

  The CSS for styling emails in the previous release had a mistake
  in that only the first line of some paragraphs was being indented
  when the intention was to indent the whole paragraph.  Fixed.


v1.8.6   2019-08-21

* Re-style customer-facing e-mails to allow customisation

  All e-mails which are sent to end users (as opposed to resource
  administrators) have been re-styled in a customizable way.
  System administrators can edit the CSS on their individual
  systems to give the e-mails an in-house look.

  Previously e-mails contained mark-up like <h1> and <p class='indent'>
  but now they just use divs of specified classes - e.g.
  <div class='um-event-timing'> so it's entirely up to the CSS how the
  message is displayed.

  If you wish to customize these e-mails on your system, look first
  at app/views/user_mailer/Originals/emails.css.scss for instructions
  and examples.

* Re-work e-mail specific CSS.

  The custom e-mail specific CSS was introduced in v1.8.4.1 but
  was not then well structured.  This release re-works it for
  better maintenance.  In particular, the CSS previously used
  element IDs, but now uses element classes.

* Immediate notification of resource requests/cancellations etc.

  Previously the system gave immediate notifications of request
  alterations and cancellations only if allocation of the requested
  resource had started.  Now the resource administrator can opt to
  receive immediate notification of all requests, alterations and
  cancellations.

* Batch notification for resource requests

  The event repetition facility can cause a large number of resource
  requests to be created, updated or deleted all in one go.  Each such
  repetition will now cause at most one e-mail to the resource
  administrator.  The single e-mail will list the dates and times
  of all the affected events.

* Add "request adjusted" journal message

  When event repetition is used, an event's request for a resource
  can move in one step from a quantity of, say, 1 to a quantity of 3.
  A journal message has been added to allow this to be recorded.

* Absence projection notes re-formatted

  When the system detects that pupils are going to be missing from
  a lesson due to a clashing activity (trips, etc.) it attaches
  a note to the affected lesson giving details of the absentees.

  If more than one event is causing absences from the same lesson,
  the system now does a calculation of the overall number of absentees,
  rather than listing them for each event separately.

  Thus, if A, B, C and D are meant to be in a lesson, but A and B
  are on a trip, and B and C are playing in a concert (it happens!)
  then the system will summarize with the message "3 missing out of 4".


v1.8.5   2019-08-10

Improved MIS imports in the run-up to end-of-year processing

* Allow import from iSAMS without using their Batch API

  The iSAMS Batch API has become thoroughly unreliable.  In a completely
  unpredictable way it sometimes runs quickly and sometimes slowly,
  timing itself out after 35 seconds.  It's not a question of the
  quantity of data being requested - even the smallest possible
  request will time out sometimes.  Running it on a very fast system
  helps, but then it can also trip over its own database row locking,
  and error out due to getting into a deadly embrace.

  In the absence of a fix from iSAMS themselves, a new method of
  data extraction has been added - direct database table access.
  We are thus dependent only on the Microsoft database engine, which is
  reliable.

  For a full list of the tables and columns accessed, see:

    lib/extractor/isams_extractor.rb

  The iSAMS => Scheduler import process always has had the capability of
  getting some data via direct d/b access (Cover and Activities) because
  these are missing from the data made available by the Batch API.

  This new extractor subsumes the previous functionality.

  To use the new method of working, use utils/importisdata2 instead
  of utils/importisdatamulti.

  The importisdata2 script is more sophisticated than its predecessor,
  accepting various run time options.  Invoke it with no options in
  order to see these.  A normal full import run can be achieved
  with:

    utils/importisdata2 -f -a -i

  The old import mechanism is still in place and can be used if
  preferred.

* Change pupil key when importing from WCBS/Pass

  Scheduler needs an invariant key for each record which it imports
  from an MIS, so it can match things up.  The obvious one to use for
  pupils coming from WCBS/Pass is PUPIL_ID, but it has become apparent
  that this changes with each new academic year.

  The WCBS/Pass importer now uses NAME_ID from the pupil record instead
  as this seems to remain constant.

* Move daily maintenance to a separate cron job from daily reports

  A small amount of routine maintenance is needed each night within
  Scheduler, adjusting the "current" flag on groups as they reach their
  expiry dates.

  Previously this was done from the same cron job as the daily reports
  (items awaiting attention), but whilst it can be desirable to stop
  the latter over the summer, the maintenance tasks really need to
  continue.

  These have now been separated into two separate cron jobs - daily_report
  and daily_maintenance.  On existing systems the installed crontab
  should be adjusted when this release is installed.


v1.8.4.1 2019-07-22

A transitory release intended only for Abingdon School

* Implement deep-linking into an individual event

  It is now possible to have a link which takes a user into Scheduler's
  calendar display and immediately opens a specific event for viewing
  or editing.  Which you get depends on the individual user's permissions.

* Re-format e-mails

  The structure of outgoing e-mails has been changed to allow
  local tweaking of their appearance.  This is still a work-in-progress
  which is why this is a transitory release.


v1.8.4   2019-07-08

* List categories in ICAL feeds

  The ICAL feed specification allows for a field CATEGORIES, which
  lists all the categories into which an event falls.

  Scheduler's idea of a category is a little different.  Each event
  belongs to just one EventCategory, which gives you a general idea
  of what's going on at the event - Lesson, Sport, Activity, Meeting,
  Entertainment etc.  These do not map well on to the CATEGORIES
  field of the ICAL feed, not least because each event belongs to
  one and only one of them.

  A better fit are Scheduler's Properties.  Each event may have zero
  or more properties - things like "Public Calendar", "Sport Calendar",
  "Music Calendar", "Key dates" and many others.

  Only some of these properties are appropriate to put in an ICAL feed.
  A new boolean field has therefore been added to the Property database
  record - feed_as_category.

  For each event in an ICAL feed, the feed generator will now look
  at all the Properties attached to the event, filter to only those
  with the feed_as_category bit set, and then pass a list of the names
  of those Properties in the feed.

  Note that the list is comma separated, and the ICAL spec doesn't
  cover how commas within a name should be escaped.  Avoid therefore
  creating a Property for this purpose with a comma in its name.

* Allow editing of default colour for a property

  Properties have long had the means to have a default colour specified.
  Thus, for instance, everyone sees the school's public calendar in the
  same colour.

  This release provides an easy mean to edit these colours.  Previously
  command line intervention was needed.


v1.8.3   2019-07-02

* Provide more details when a single event is queried through the API

  The API has always allowed individual events to be queried, but
  previously provided no more information than it would have done
  in an event listing.  The returned data now include extras like
  the owner and organiser of the event.

* Re-arrange order of fields in system settings

  In writing documentation for the system settings it was noticed that
  the fields in the settings dialogue were in a less than logical order.
  They have been re-arranged to make slightly more sense - and to match
  the new documentation.

* Place limit of 100 on API fuzzy element search

  The API provides the means to list elements using a fuzzy match
  call.  If the provided string is really short - e.g. just "e" - then
  the API would end up listing pretty much every element in the system.

  It now limits the total number of elements returned in such a
  search to 100.

* Allow file upload from note editing dialogue

  The previous release added the means to upload files, plus a helper
  for generating links in notes.  However the two processes were separate.
  The user had to upload the file first through a top level menu choice,
  then create/edit a note and create a link.

  It is now possible to upload the file as part of using the link
  creation helper.

* More events in seed data

  The seed data used by the Scheduler demonstration system now
  has significantly more calendar events in it, giving a more
  realistic view to the sample week.


v1.8.2   2019-06-18

* Allow users to store files in Scheduler

  It is now possible for suitably privileged users to upload files
  for local storage within Scheduler.  This facility is intended for
  embedding files within notes as described next.

  The system administrator can control which users are allowed to
  upload files, and how much disk space each user can use.

  The default web server - Nginx - also puts a limit on how large
  each individual uploaded file can be.  The Nginx configuration
  file can be altered to set whatever limit is required.  The
  relevant line goes in /etc/nginx/sites-available/scheduler
  and looks like:

    client_max_body_size 20M;

  or whatever you choose.  The above line sets a limit of 20 mebibytes
  for any one file.

  The facility is not intended to be used as a general purpose bulk
  file store.  It is advisable to set a fairly low limit on the total
  disk space available to any individual user - perhaps something of
  the order of 100 mebibytes, depending on the amount of disk space
  available on your server.

* Assist users in embedding files with notes

  Since v1.8.0, notes attached to events have allowed the entry of
  formatted text using Markdown.  This includes the ability to create
  links within the notes.

  With files now being available in Scheduler, the user can first upload
  a file, then embed a link to it within one or more notes.  To assist
  with the process, a helper dialogue has been added to the note
  editing interaction.  The user clicks on a button to invoke it, then
  selects the file to embed and the helper creates the required
  Markdown text.

  The helper can also be used to generate Markdown for external links -
  e.g. a link to a Google Maps location.

  Full documentation for notes and files will be found at:

    https://xronos.uk/notesnfiles.html

* Separate flag to control e-mails about resource loading

  An extra flag has been added to the user record allowing a user
  to choose whether or not to receive resource loading e-mails
  separately from whether or not they receive daily request e-mails.

  This affects only users who manage resources.

* Speed up resource count queries

  If a user leaves Scheduler open in the browser, the front end sends
  a periodic (10 minutes) query to the back end to find out if there
  are any items awaiting the user's attention.  The response is used
  to update the numbers in the user's menu structure.

  For some heavily loaded users, the processing of this request could
  take as long as 5 seconds under very bad conditions.  By adding a
  cache field to one of the database records this has been reduced to
  100ms.

* Enhance seed data for demonstration system

  The seed data for demonstration systems has been enhanced to show off
  the new file embedding facilities.

* Enhance API to allow creation/modification/deletion of notes

  The API has been enhanced to allow the manipulation of notes
  attached to events.  Full details are in the API manual.


v1.8.1.1 2019-06-11

* Hotfix for a problem with empty notes

  In v1.8.0, the means to use Markdown in notes attached to events
  was added.  This meant the introduction of a new text field in the
  notes record - formatted_contents.  Unfortunately, the database
  engine does not allow the setting of default contents for a text
  field, so it's really important to make sure it is given an explicit
  value, otherwise it ends up as nil.

  An error in the code for generating the formatted text meant that
  if a user created a completely blank note, the formatted text didn't
  get filled in, rendering the parent event undisplayable.

  This release fixes that error in the code.  A helper method is
  provided:

    Note.format_missing_contents

  which should be run after the release is installed.  It will find
  any affected notes in the database and give them formatted contents
  of "<p></p>".


v1.8.1   2019-05-18

* Enhance import of staff records from WCBS/Pass

  The automated import from WCBS/Pass was using the timetable table
  to get a list of all the teaching staff.  It nows uses a staff
  table to get a list of all staff, including their initials and
  correct e-mail addresses.

* Exclude confidential events from searches

  The code which searches for events by name now explicitly excludes
  all confidential events.  Previously you could, for instance, search
  for "hummus incident" (see below) and it would be found, but then
  displayed as just "Busy".  Now it simply won't be found.

* Provide link to event on search results page

  The search results page now provides links to open each found event
  directly, much like on other event listings pages.

* Add consistent styling to "Add staff" button

  The link in the staff listing page for creating a new staff record
  did not have the usual styling applied to it.

* Move event summary back to the top of user forms

  When comments were added to user forms, the event summary was moved
  to the bottom of the form, below the field data.  In this release
  it is moved back to the top.


v1.8.0   2019-05-07

* Upgrade version of Ruby to 2.5.5

  Previous versions of Scheduler used Ruby 2.3.6 but that is approaching
  end-of-life.  Ruby 2.6 has been released but is still relatively
  young, hence this conservative upgrade.

  Extra steps are needed to upgrade to this release.  See:

    https://xronos.uk/admin/rubyupgrade.html

* Add an API to allow client programs to create and query the d/b

  In this release, an API has been added which allows client-written
  programs to interact with Scheduler's database.

  For full information, see:

    https://xronos.uk/api/

* Add confidential events

  It is sometimes desirable to enter an event into Scheduler but
  keep the details of the event secret from those not involved.  The
  presence of the event indicates that those involved are busy, but
  general users of the system need not know exactly what they are
  doing.

  A new flag has been added to the Eventcategory model - confidential.
  The system administrator can create as many confidential eventcategories
  as desired.  An obvious one might be called "Personal".  A user could
  then enter in "Appointment at the JR" with appropriate timing,
  but all anyone else would see is that the user is busy.

  The text which appears instead of the normal body text of the event
  is configurable on each system.  It defaults to "Busy".

  The "confidential" flag can be combined with any of the other flags
  which already exist on Eventcategories.  E.g. one could have an
  eventcategory which is both "confidential" and "privileged".

  The real description of any confidential event is visible only to those
  directly involved in the event.  So, if for instance an event is
  entered as "Meeting with Mr and Mrs ..... re the hummus incident"
  in a confidential category, then only those invited to the meeting
  could see that text.  Everyone else would see just "Busy", or whatever
  has been configured as the busy text.

  Selected users can be set up to see confidential events for other
  users.  Thus the head's PA might need to see events involving the head,
  including confidential information.

* Add invisible staff

  Similarly, it may be desirable for the schedules of particular members
  of staff not to be generally visible - e.g. perhaps the headmaster.

  A flag has been added to the Staff record - visible - which defaults
  to true.  If it is switched off by a system administrator, then
  users cannot ask to see the schedule for that particular member of
  staff.  They can still add that member of staff to events (or at least,
  invite him or her to events) and can see events involving that member
  of staff, but they can't ask to view that member of staff's full
  schedule.

  The system administrator can still give individual users access to
  that staff member's schedule - again the obvious example is to allow
  the head's PA to see the head's schedule.

* Show details of clashes in hover text

  When a user views details of an event, double-booked entities are
  shown in a red box.  Historically the hover text for these items has
  shown simply, "Double booked", but it now includes details of the other
  event or events to which the entity is committed.

* Enhance staff merging code

  Sometimes a member of staff gets entered into Scheduler twice - e.g.
  first manually and then later by being imported from the school's MIS.

  There now exists automated code which will scan for any such member
  of staff and merge the duplicate records.  Staff are considered to
  be duplicates if two of them have the same e-mail address.

* Allow the use of Markdown in Notes attached to events

  Scheduler allows users to add Notes to events giving extra ancillary
  information.  Up until now these have been restricted to just text
  but now the user can use Markdown to format things a bit.

  In particular, URLs will be turned into links.

* Seed data enhanced

  The seed data used to populate the demonstration system at
  https://schedulerdemo.xronos.uk/ has been enhanced in various
  ways - the main one of which is to allow experimentation with the
  API against that system.

* Tests

  The suite of automated tests has been greatly expanded.  In particular
  the API has a complete set of tests.


v1.7.8.1 2019-03-19

* Fix error in daily notifications caused by last update.

  In testing for the next upcoming release, a bug was identified in
  the previous one which prevents the daily e-mail run completing
  sucessfully.  This hotfix corrects that problem.


v1.7.8  2019-03-17

* Upgraded Rails to version 4.2.11.1

  A couple of security issues in Rails 4.2.11 were fixed this week,
  resulting in 4.2.11.1.  Scheduler has been moved to this release.

  Further work in the very near future will see Scheduler converted
  to Rails 5 and a later version of Ruby.

* Moved resource allocation to the main menu

  Resource allocators previously accessed the resource allocation screen
  by clicking on a small 'v' next to the resource's name in the LHS
  column.  This was less than obvious, and made it impossible to access
  the allocation screens from anywhere other than the user's default
  view.

  The access has now been moved to the main menu, under Menu => Allocate =>
  <Resource name>.

* Can now add comments to forms requesting resources

  In processing resource allocation requests, it is sometimes necessary
  to pass comments back to the requester.

  The means has been added for the resource allocator to annotate
  request forms with simple comments.  When adding a comment the
  allocator can make it a simple informative comment (e.g. "Your
  mini-buses will be in the top car park.") or can push back the form
  requesting more details (e.g. "That doesn't seem to be a valid account
  code - please can you check?") thus placing the form back into
  an incomplete state, requiring the requester to fill in more
  information.

  In either case, the comment is immediately e-mailed to the requester
  (specifically, to both the owner and the organiser of the event),
  and in the latter case the form will be consider incomplete again,
  and subject to the usual daily reminders if not attended to.

  Comments can be deleted by the originator, or by a system administrator.

* Increment / decrement links improved

  Some users found difficulty with the simple "+" and "-" buttons provided
  for adjusting the quantity in a request.  The "-" has been changed to
  an ndash, and more space has been put between them and the "x" for
  deleting a request.

* Menu generation code re-factored

  The pop-down menus require some quite complex HTML which had reached
  the stage of being quite unreadable.

  By use of some custom Ruby code, the necessary HTML is now created on
  the fly from code which directly reflects the menu structure.

* More tests added

  Further automated tests have been added to the test suite.

* E-mails with just one section now displayed correctly

  The previous release added the means for a system administrator
  to view all automated e-mails which had been generated by the system.

  In the exceptional case where an e-mail was text only (rather than HTML
  and text as they usually are) it appeared to have no section rather
  than one section.  These e-mails can now be viewed correctly.

  This fixes issue #3 in the GitHub issue tracker.


v1.7.7  2019-03-10

* Highlight resource when the numer requested is changed

  There have been a couple of incidents of people clicking on a quick
  button for a resource and not noticing that each time they do it the
  requested quantity increments.

  The UI now flashes the resource each time the requested quantity is
  incremented or decremented to try to prevent this.

* Individual resources shown in alphabetical order

  On the resource allocation screen, individual resources within a
  resource group are now shown in alphabetical order.

* Resource groups may require staff

  A flag has been added to the ResourceGroup record "requires_staff".
  If set, the system assumes that as many staff will be required for
  an event as there are resources from this group - e.g. drivers for
  mini-buses.

* New e-mail to prompt for staff

  An e-mail has been added to the automatically generated ones which
  will prompt the owners of upcoming events if there don't seem to
  be enough staff for the resources.  It uses the same day count
  and user flag as the existing e-mail which prompts for forms to
  be completed.

* Prompt e-mails sent to both owners and organisers

  The three e-mails relating to resource allocation:

  1. Please fill in your forms
  2. Please re-confirm your request
  3. Please allocate suitable staff

  were previously sent only to the owner of the event.  Now they are sent
  to both owner and organiser.  Individual users can choose not to receive
  them, which is potentially useful for very frequent requesters, or for
  people who enter events on behalf of other people.  In the latter case,
  all the event-enterer needs to do is put the right organiser on the event
  and disable the e-mails for him or herself.  Then the e-mails will go
  to the organiser and not the owner.  (It is of course much better to
  have the organiser do the event entry in the first place.)

  If the same person is listed as both owner and organiser, he or she
  will receive only one copy of the e-mail (or none if the e-mails
  for that user are disabled).

* Allow organisers to react appropriately to above e-mails

  In the HTML versions of the above e-mails, links are provided which
  if clicked take the user directly to the appropriate page within Scheduler
  to action the request.  These links will now work correctly for the
  organiser, even if he or she is not the owner of the event.

* Outgoing e-mails logged

  All automatically generated outgoing e-mails are now logged to the database
  in both text and HTML formats.

* Administrators can view logged e-mails

  A user with admin privileges can view the entire log of outgoing e-mails,
  or filter down to e-mails sent to one particular user.  The text and
  HTML versions of the e-mail can be viewed separately.

* Admin menu re-structured

  The pull-down menu seen by administrators had got rather long - in some
  cases too long for convenient use on a small screen.

  To overcome this, the main menu seen by an administrator now includes
  just one extra item over and above those seen by normal users - a
  choice called simply "Admin".  This then leads to a sub-menu with all
  the old administrator menu options, plus the newly added "E-mails" one.

* Date display in custom allocator views fixed

  In the resource allocation screen, in the 3-day and 4-day views, the
  dates were appearing in American format.  They now appear in the same
  way as in all the rest of Scheduler.

* Forward group membership displayed in allocator screen

  Using the advanced group editing facilities added in the previous release,
  it is possible to specify *future* members of a group.  The resource
  allocation screen is now aware of this and will display the relevant
  lines appropriately.

  Thus, if for instance there are going to be a couple of hired mini-buses
  available for three days next week, the appropriate extra lines will
  appear on the allocation screen.

  This area of code is not yet complete.  It does not check attempted
  allocations to ensure they fit with the availability.  Use with care.

* Staff and pupil e-mails added to FreeFinder listings

  When the FreeFinder utility is used to find free resources in the system
  it is possible to export a list of those found.  This list will now
  include the e-mail addresses of any staff or pupils in the list.

* Fix re-repetition of events with resource requests

  A bug has been fixed which affected events with resource requests which
  were repeated using the event repetition facility.

  A simple repetition of such an event worked fine - copying normal
  commitments, and requests for resources, but not copying any allocated
  resources.

  If however the original event was then edited and the changes propagated
  to the other copies via the repetition facility, any new requests were
  not propagated, but allocated resources were.  The end result was
  a single request on the original event, but with N allocations - one
  to each copy of the event.

  This error in the code has been fixed.

* Fix wrapping code to take account of selected resources

  When a user wraps an event (adds events before and after for set-up
  and clear-up time) the dialogue provides tick boxes to select which
  resources should be added to the wrapping events too.  Typically these
  will be the locations and perhaps the staff, but the user can select
  what is wanted.

  A bug introduced several releases back meant that this selection was
  then ignored and all the resources from the original event got copied
  to the wrapping events.

  This error in the code has been fixed.

* Test suite enhanced

  Many extra automated tests have been added in the areas of group
  membership and event manipulation.

  The tests now make use of FactoryBot to create the right conditions
  for each test.

* Display of resource allocation screen speeded up

  The lack of an appropriate index made the population of the events
  in the resource allocation screen inordinately slow.  Up to 2.6s to
  fetch the events on a busy day.

  By adding an extra index to the database, this has been reduced to
  less than 0.5s.


v1.7.6  2019-02-27

* Added the ability to edit membership records directly

  Scheduler stores not just the instantaneous membership of a group but
  a full record (and even future projection) of its membership.

  The normal group editing facilities hide this feature, but quietly keep
  track of the membership over time.

  This release adds the means for suitably privileged users (a new
  privilege bit in the user record) to edit the membership records directly.

  For more details on using this facility, see the Advanced User Guide
  at https://xronos.uk/advanced


v1.7.5  2019-02-21

Mostly adding e-mails relating to resource requests

* Added additional styling to try to stop Gmail turning the header
  text blue

* Tidied day loading e-mail slightly

* Added new database fields to cope with e-mails prompting users to
  fill in forms and to re-confirm requests.  Users can opt out of
  receiving these, although the default is for them to be in.

* Allow users to turn the new flags off and on

* Allow the system administrator to configure when prompting e-mails
  will be sent.  Separate thresholds (number of days) can be set for
  each resource group.

* Tidied up editing of groups in general.

* Added daily job generating e-mails nagging users to fill in their
  forms.

* Added daily job generating e-mails asking users to re-confirm their
  bookings.

* Added staff initials to the hover text for each event in the resource
  allocation screen.  This means that provided the events are entered
  properly - with the drivers shown as being involved in the event - then
  the resource allocator can see who the drivers are without having to
  click into the event.

* Added a new screen which allows users to re-confirm or cancel their
  upcoming bookings.  The prompting e-mail contains a link which will
  take the user directly to his or her screen, making the process
  quick.

  Users can only re-confirm a booking once it is within the configured
  re-confirmation window.  This is to prevent users simply re-confirming
  them as soon as they enter them (possibly months ahead) then forgetting
  about them and defeating the whole point of having the re-confirmation
  process.

* Corrected journal entry created when a user decrements the number
  of a resource required.  It previously said "down from 3 to 4" where
  it should have said "down from 5 to 4".

* Added code to create a journal entry when the user implicitly increments
  a request.  This happens if the user tries to add the item a second
  time to the event.

* Journal re-confirmation of requests.

* Added e-mails to the resource administrator which are sent if a user
  amends a request after resources have started being allocated to that
  request.  Sends an e-mail if the user increments, decrements or cancels
  the request.


v1.7.4  2019-02-10

* Provide an e-mailed summary report of resource loading looking ahead.

  The overnight reports now include one specifically tailored for
  resource groups where there are requests for resources from a pool -
  e.g. minibuses or mobile phones.

  Each time the daily job is run, the system looks ahead by a configurable
  number of days, and analyses the requests for each configured resource
  on a day-by-day basis.  It identifies peak loading times and any overload
  times, then e-mails a summary report to all configured administrators
  of the resource.  Overloaded dates are highlighted.

  Each resource can also have a configured "wrapper time" expressed in
  minutes.  By default this is 0, but if the number is increased then the
  analysis will take account of this time before and after each request.

  Thus, if a wrapper time of 15 minutes is set, then two events will be
  considered to overlap if they are less than 30 minutes apart - 15 minutes
  from each event.  This is to allow time for switchover of resources.

  The report also lists events for any of the pooled resources which have
  been created outside the request/allocation system.  These would typically
  represent such resources being unavailable - e.g. a mini-bus being serviced.
  The loading calculations above take account of such events when working
  out if there is a shortage of the resources.


v1.7.3  2019-02-04

* Provide download of form data for resources

  Many resources require the requesting user to complete a form providing
  additional information about the request.  Each of these forms can
  be viewed individually in association with the corresponding event.

  This release adds the means for the administrator of the resource
  (and anyone with general permission to view forms) to download a spreadsheet
  (CSV) file containing all the form data for a specified period.  The
  default period is 1 month, but any other interval can be chosen.

  The report is accessed by clicking on the corresponding item in the
  user's left hand column, then on the "Reports" tab, and then on the
  Generate button down at the bottom.  The dates can be amended before
  clicking on the button.

  The generated report will be downloaded automatically to the requester's
  computer, and can then be opened in the spreadsheet package of choice.


v1.7.2  2019-01-28

* Allow events imported from ics file to be given to a user

  Scheduler has long had the ability to import a batch of events from
  an ics file.  Up until now, these have always ended up as system
  events - no owner.  This release adds the ability to specify a user
  at the time of import and the imported events will then belong to that
  user.

* Wash out colour of request if forms outstanding

  On the resource allocation screen, it is now possibility to distinguish
  waiting requests which have forms outstanding.  Requests with forms
  outstanding (waiting to be filled in) will be shown in a washed-out
  version of the configured colour, whilst requests with their forms
  completed (or with no configured form) will be shown in the full
  colour.  This makes it possible to tell at a glance whether the form
  is done without having to click on the request.

* Requests now control events in the same way as commitments do.

  If some requested resources for an event have been allocated, the
  requester can no longer change the timing of the event.  This is
  the same behaviour as already existed for approved commitments.

* Pending forms on requests contribute to "Permissions Pending" total

  The count in the top bar of a user's screen now includes any forms
  which the user needs to fill in.

* Dean Close-specific import code brought up to compatibility with this
  release of Scheduler


v1.7.1  2019-01-21

* The "awaiting attention" count shown next to the word "Menu" in
  the top bar now includes resource requests which the user is
  authorized to handle.  Thus, the total number of, say, mini-bus
  requests outstanding can be seen at a glance.  The number is
  broken down by individual resource in the pop-down menu.

* The corresponding menu item allows a listing of such requests to
  be seen.

* Clicking on the date of such an item takes the user directly to the
  resource allocation screen on the right day.

* As allocations are done on the resource allocation screen (or un-done)
  the count at the top of the page updates immediately.

* Multi-day timed requests appear correctly.

  Requests for mini-buses etc. can be seen in the main schedule screen,
  but in the case of one lasting more than one day they were appearing
  as a long vertical stripe.

  They now appear at the top in the "all day" area, in the same way as
  commitments.

* Requests no longer greyed out.

  Requests on the main screen now appear in their configured colour rather
  than a washed out version of it.

* Journalling implemented for requests

  The journal component has been enhanced to keep track of requests and
  their administration.  Entries exist for:

  * Request entered
  * Request cancelled
  * Request incremented
  * Request decremented
  * Resource allocated to request
  * Resource de-allocated from request

  All the usual journalling information appears on these entries.

* Don't nag about rejected invigations to people.

  The existing system for requesting a resource (like a room) which
  has an administrator sends e-mails if the request is rejected.  This
  makes sense for a room - if you can't have that room then you need to
  change your plans and the system will keep reminding you daily until
  you remove the request.

  The same facility however can be used to invite a person to a meeting.
  In this case it makes sense to send a single e-mail should the person
  decline the invitation, but not to go on about it.  It makes perfect
  sense for the invitation to remain in the system, documenting:

  1. That he or she was invited
  2. The reason the invitation was declined

  Scheduler now distinguishes between requests for things and invitations
  to people.  The latter will now, when declined, generate a single e-mail
  but not the daily reminders.

* The "awaiting attention" count at the top of the screen will no longer
  include declined invitations as described in the previous point.


v1.7.0  2019-01-13

  This release adds a major new facility - Resource Groups and the means
  to request items within them.

  For certain resources within a school, the need is to request one of a
  generic resource, rather than a specific item.  If you want the theatre,
  then you want the theatre, but if you need 2 mini-buses then it doesn't
  generally matter which 2 you get as long as they work.  It's up to
  the administrator of mini-buses to decide who gets each one.  Other
  things like mobile phones can be handled in the same way.

  Resource Groups exist for this purpose.  Create a Resource Group
  called "Mini-bus" (make it a singular name - it will be pluralized when
  needed within the application) and then one Service entry for each
  actual mini-bus.  For each of the individual entries, make sure the
  "add directly" flag is unset (or users will be able to add individual
  mini-buses directly to their events) and then add all the individual
  mini-buses to the "Mini-bus" group.

  Each time a user tries to add "Mini-bus" to an event, it will generate
  a request for a mini-bus, which the administrator can then fulfill by
  selecting from those available.

  Resource Groups can also be nested.  You can have one called "Mini-bus"
  which contains two other Resource Groups called "Small mini-bus" and
  "Large mini-bus", with the actual individual mini-buses then being members
  of these two inner groups.  A request for "Mini-bus" can then be satisfied
  by members of either inner group, whilst a request for one of the inner
  groups can be satisfied only by one of its own members.

  The administrator of mini-buses should be given the "Controls" flag
  for these groups in the usual way by a system administrator.

  Full documentation will follow in the advanced user manual.

  This release is not yet feature-complete, but the basic processing
  works and it is being made available in order to generate feedback.

  Individual release points:

* The "event show" and "event edit" dialogues have been tightened up
  to use less vertical screen space.

* Cloning has been moved from the "edit" dialogue to the "show" dialogue
  and made much more versatile.  Multiple clones can be created in one go.

* Event repetition has also been enhanced, allowing date limits on what
  will be amended in a repetition.

* Resource Groups have been added to the system.  Whenever a Resource Group
  is requested for an event it will cause the addition of a Request
  rather than a Commitment

* Individual users can be set as controllers of Resource Groups, giving
  them access to a drag-n-drop screen to do resource allocation.  This
  screen is currently accessed by clicking on the "v" next to the resource
  group's name in the left hand column.  (This will probably change.)

* The controller of a resource can also be given "edit" or "sub-edit"
  permission for all events requesting the resource.  Provided this permission
  has been granted, the events can be edited directly from the allocation
  screen.

* Requests and their corresponding commitments are displayed in the "show
  events" dialogue.

* Adding a Resource Group to an event in the "edit event" dialogue causes
  a Request to be created, or if a corresponding request already exists,
  causes the quantity to be incremented.  The quantity can also be
  adjusted using nudge buttons on the item listing.

* Resource Groups can be assigned to Quick Add buttons and to pre-allocation
  tick-boxes.  Note that in the case of the Quick Add button, clicking the
  button does not cause the button to disappear add it would for a normal
  resource.  Instead a second click can be used to increment the quantity.

* FullCalendar has been updated to version 3.9.0.


v1.6.1  2019-01-03

  There are no changes to the application functionality in this release,
  just updated gems.

  A "bundle install" step will be required after fetching this new
  release onto an installation of Scheduler.

* Upgrade gem omniauth-google-oauth2 to version 0.6.0

  Google have announced that they will start switching off Google+
  functionality this month, part of which was used by this gem in
  effecting authentication through Google.  The new version of the
  gem avoids using any Google+ calls.

* Upgrade rails to 4.2.11

  An advisory for activejob 4.2.10 was issued last month.  It doesn't
  actually affect Scheduler (because we don't use activejob) but whilst
  upgrades are happening...

  CVE-2018-16476

* Upgrade rack to 1.6.11

  Likewise there was an advisory for rack, which again doesn't directly
  affect Scheduler (which does not circumvent the standard escaping
  functionality) but for completeness...

  CVE-2018-16471


v1.6.0  2018-11-18

* Add views to the main user interface

  Each user can choose a list of items to look at in the main schedule
  screen.  Internally, Scheduler calls these "Concerns".

  Some users build up a vast list of concerns down the left hand side
  of the screen, switching them on and off as required.

  This release adds the concept of a "View" to the main screen.  Each
  view consists of a collection of concerns of the user's choosing.
  Having created some concerns the user can switch between them quickly,
  saving the need to keep adding and removing individual concerns from
  what is being viewed.

  Each user's existing concerns form what is called the "Default view"
  for that user.  From this point the user can create as many other
  named views as is desired.

  To manipulate views, click on the text which reads "View: ..." at the
  top of the list of concerns on the LHS of the screen.  It's just next
  to the existing and similar "Filter: ..." text.  This will being up
  a dialogue box listing the user's existing views and allowing new
  views to be created.

  To create a new view, simply type a name in the box on the right hand
  side of the dialogue and click on the create button.  For convenience
  the creation code can automatically copy over the currently visible
  concerns from the previous view, and if desired remove them from the
  source view.  This means that a user, having got the screen showing
  a chosen set of resources as required, can quickly create a matching
  view for exactly those resources, rather than having to create the
  view, then add resource concerns to it.

  By default the "Copy existing visible concerns" flag is on, but the
  "and remove from source view" flag is off.  Adjust as desired using
  the check boxes provided.

  View can be renamed or deleted from the same screen.  Deleting a view
  will throw away all the concerns attached to it, but will not affect
  any of the underlying resources.  (The user's view of the resources
  will go - not the resources themselves.)

  A user might choose for instance to have a view called "Maths teachers"
  looking at all the maths teachers, or a view called "Mini-buses" looking
  at all the mini-buses.

  
v1.5.3  2018-11-04

* Upgrade two dependencies to deal with advisories

  Two of Scheduler's dependencies - loofah and sprockets - had security
  advisories outstanding.  Given the way Scheduler is configured, neither
  of them had any actual effect, but the packages have been upgraded anyway.

* Send e-mail for each approval

  Scheduler has always sent a notification e-mail when all the requests
  for an event were approved.  It now sends one for each individual
  approval so the requester has a better idea of the state of the
  event.

* Remove reference to SchoolBase in e-mail

  The cover clash e-mail contained a hard-coded reference to SchoolBase.
  It now picks up the right MIS name from the system configuration.

* Remove reference to Other Half in e-mail

  The e-mail about student absences referred to "lessons or Other
  Half activities".  It now says just "lessons or activities".


v1.5.2  2018-10-07

* The stupidest reason for a new release (2nd time of happening)

  Failed to include the new version number file in the previous release.


v1.5.1  2018-10-07

* Fix group search facility in group listing screen

  The group search facility added in the previous release wasn't
  working quite correctly, in that not all the groups listed on
  the "All groups" pages could be searched for.

  Specifically, these pages are accessible only to admin users,
  and whilst the page would list all current groups, the search box
  would find only system groups (those with no owner), public groups,
  and groups belonging to the user doing the search.  Private groups
  belonging to people other than the current user would appear in
  the listing but not in the search box.  Fixed.

* Add listing of deleted groups

  When a group is deleted in Scheduler it doesn't actually get removed
  from the database.  This is so that historical events still show
  up correctly.  The group is flagged as no longer "current", and
  has an end date store in its database record.

  A new menu option has been added for admin users:
  
    Menu => Groups => All => Deleted

  which will allow deleted groups to be listed and searched through.

* All deleted groups to be re-instated

  In the deleted groups listing, each group has a "Reinstate" button.
  Clicking on this button will restore the group to being "current"
  and remove the previous end date from its record.

  It's membership will be the same as it was on the day it was
  deleted - that is all elements which were members on the day of
  deletion will be restored as members.  Any elements which were
  removed from the group before the day of deletion will not
  be re-instated as members.


v1.5.0  2018-09-27

This release starts turning over the ground in preparation for the
facility to administer groups of resources - termed Resource Groups.
Typically these will be things like Mini-buses, or mobile phones.

* Add Resource Groups as a type of group within the system.

  Only system administrators can create and edit Resource Groups.
  They cannot currently be added to events.  This is a temporary state
  of affairs until the full request and approvals mechanism is put in place.

* Add "Add directly" flag to Services.

  The existing Service records (used for things like Catering or Parking)
  gain a flag "add directly" which defaults to true.  The idea is to allow
  extend slightly the use of these records to cover both services and
  other resources (like mini-buses) which people may request for events.

  Each physical mini-bus will have a Service record, but with the new
  flag set to false.  This will mean that people can view the mini-buses
  and what they're doing, but not add them directly to events.  Instead
  they will use the Resource Group request mechanism outlined above.

  With this release, it is possible to start entering such resources
  into the system.

* Improve listing and editing of Groups.

  The main Group listing screen has improved pagination, and gains a
  search box so that it is now possible to jump straight to the desired
  group, rather than trying to guess which page it is on.

* Go back to correct listing after editing group.

  For system adminstrators, there was a slight problem when editing groups
  in that at the end of the edit the user would always be taken back
  to the listing of *all* groups in the system, regardless of where the
  edit had been invoked from.  The user will now be taken back to the
  right listing, and the right page of a paginated listing.

* Full editing of group membership.

  Previously it was possible to add, for instance, a service to a group
  but then there was no way to remove it again.  The group editing code
  has been enhanced to understand all extant entity types.

* Unify pagination across the whole system.

  Several different styles of pagination were in use.  Now there is
  only one.

* Improve formatting of some buttons.

  Some action buttons have been corrected to bring them into line
  with the standard style.


v1.4.5  2018-09-14

* Enhance Pass cover import to cope with merged lessons.

  When consecutive lessons have been merged, and then cover is arranged,
  extra processing is needed to match things up.


v1.4.4  2018-09-09

* Merged lessons to take common part of name

  Many (most) MISes make the unwarranted assumption that each lesson involves
  only one teacher.  Schools end up creating several parallel lessons
  to record all the teachers involved - commonly for sport, but also
  for other subjects.

  The MIS loader in Scheduler tries to correct this by merging lessons
  according to certain criteria, one of which is that the names should
  match.

  It is however possible for site-specific code to override this and merge
  lessons even when the names don't match.  Eg SPORT10A and SPORT10B.
  The merging code will now use the common part of these two names - SPORT10
  for the resulting merged lesson.

* Correct merging of consecutive lessons in school-specific code.

  Code was added in the school-specific area to merge consecutive
  lessons and one particular school.  However, it modified an array
  whilst iterating through the same array, which Ruby doesn't like.
  Fixed that.


v1.4.3  2018-09-08

* Fix to identifying week letters for recurring events

  Week letter identification (week A or B) used to be done in various
  different ways at different points in the code.  To DRY things up
  and make them more resilient, a class was added some time back which
  does the work on behalf of any bit of code which needs it, improving
  both robustness and efficiency.

  The recurring events loaded however was missed and was still using
  its own very naive method, which resulted in events not being loaded
  when the week letter events weren't exactly as it expected.

  The recurring events loader now uses the specialist module to do
  this work.


v1.4.2  2018-09-04

* Enhance import of legacy calendar data

  The importer for legacy calendar data has been enhanced to try to
  match up locations in ICS files with the locations which the system
  knows about.

* Fix problem sorting mixed entities

  The previous release added sorting of timetables before printing, but
  in the case of a group with mixed entities (e.g. staff and pupils) in
  the same group, the sorting did not work.

  This release fixes that.  Entities are first sorted by entity type
  in the following order:

    * Properties
    * Subjects
    * Staff
    * Pupils
    * Locations
    * Groups
    * Services

  and then within a single type they are sorted by name.

  In addition, pupils are sorted by year group and then by name.


v1.4.1  2018-09-03

* Allow the merging of consecutive lessons from MIS

  A situation arose where all the lessons in an MIS had been loaded
  as half-lessons, leading to everyone getting very messy timetables.

  Add the means for the importer to merge consecutive identical lessons
  to reflect reality.

* Add timetable functionality to Pass-based systems

  The previous release allowed timetables only for systems importing
  from iSAMS.  This release adds the facility to systems importing from
  Pass.

* Sort timetables when printing

  When printing a whole group of timetables, they will now be sorted
  in a sensible order.  For pupils this is by:

  * year group
  * family name
  * given name


v1.4.0  2018-09-02

* Add the means to view and print timetables (as opposed to schedules)
  for individual pupils, staff, rooms and general resources.

  Scheduler usually concerns itself with a dynamic view of what is
  actually happening within the school.  It displays what *is* happening
  this week, rather than what would be happening in an ideal week.

  Sometimes however it is useful to be able to print off an old-fashioned
  timetable for each individual, unifying the view of all their
  regularly scheduled events.  Typically these will be:

  * Lessons
  * Preps
  * Activities

  Scheduler achieves this by loading an idealised timetable cycle
  (a week or a fortnight to suit the school) into a past date
  in its database (default start: 2006-01-01) and then generating
  a timetable using current set membership (on the day of printing) but
  these otherwise ancient events.

  The system admin can control which classes of events get included in
  the timetable by editing the Event Category records.  Only those with
  the "timetable" attribute will be included in printed timetables.

  Timetables can be printed either for individual resources, or for groups
  of resources (e.g. form groups).

  To print a timetable for a resource, add the resource to the list of
  things which you are viewing - coloured boxes down the left hand side
  of the screen.  Then click on the coloured box for the required item,
  and then on the "Timetable" tab in the page which appears.

  For singular resources (anything other than a group) a single "Print"
  button will be found there, whilst for Groups, there will be two
  more buttons - "View member timetables" and "Print member timetables".

  After installing this release, a fresh run of the MIS importer is
  needed to populate the ideal week/fortnight.  After that, the usual
  nightly run will keep it up to date.


v1.3.6  2018-09-01

* Stop new locations from MIS getting two element records

  When the MIS sends through details of a new location, the loader
  handles it by creating a new location alias, which in turn causes the
  creation of a new location.

  The changes in v1.3.3 had a knock-on effect which caused the new
  location thus created to acquire two element records.  This was
  caused by the Entity#update_element method being called twice.

  That method has now been fixed so it's perfectly safe to call it twice
  in quick succession - as it should be.


v1.3.5  2018-08-22

* Add the name of the data source to location alias listings

  When deciding whether or not to amend or delete a location alias it
  can be useful to know which data source it relates to, if any.
  This information is now shown in the listing of location aliases,
  and in the edit screen for a location alias.


v1.3.4  2018-08-22

* Fix cancel button on location alias editing screen

  The same screen is used for both creating and editing a location
  alias.  As it can now be invoked from different places the cancel
  button works dynamically and re-directs you back to where you
  came from.  For one instance where the screen was invoked for
  editing (not creating) the button wasn't set up correctly and so
  didn't take you back.  Now fixed.


v1.3.3  2018-08-21

* Fix issue with updates to location aliases

  Location aliases can affect the element name of the locations to
  which they are attached.  A couple of hooks were missing, so that
  although creating a new location alias would cause the element name
  to be updated automatically, amending or deleting an existing alias
  would not.  A dummy save to the corresponding location was needed
  to get the change to take effect.

  This release fixes this problem and all amendments to location aliases
  will have the required effects immediately.

* Allow edit and deletion of locations

  Oddly, there was no way within the GUI to edit or delete existing
  location records.  You could create them, but then you were stuck
  with them.

  The underlying code and screens existed, but they were not linked
  from anywhere.  Fixed.

* Prevent existing location being set from active to inactive

  Once a location (or indeed, any entity within the system) has been
  set to active it acquires an element record and can be involved in
  events and groups.

  Subsequently changing it to inactive would delete the element record,
  and as a consequence all the historic information about that item.
  It is therefore not allowed through the GUI.

  If a location no longer exists then its "current" flag should be set
  to false.  This will prevent it appearing in future searches, but
  will preserve historical information about it.

  (The active flag exists to cope with gash data (e.g. non-existent
   members of staff) being fed through from an MIS.)

* Easier maintenance of location aliases

  Each location can have zero or more location aliases.  Previously
  location alias editing was done from an entirely different screen
  from location listing.

  With this release, you can do almost everything from the location
  listing - amend existing aliases and add new ones.  From the location
  listing, click on the name of any alias in order to amend it.

  The effects of the amendments are shown immediately.  If a location
  alias goes from having "display" set to false to having it set to true,
  it will immediately move to a different column in the location listing,
  and the location's element name will be updated.


v1.3.2  2018-07-20

This release comes to you from the depths of rural France!

* Dispose of old flags in Commitment record.

  The state of commitments was originally controlled by a collection of
  flags.  These were replaced some time ago by a single status field, but
  the old flags still existed for conversion purposes.  They have now
  been deleted.

  The corresponding conversion methods have been replaced with stubs
  which will raise an exception if invoked, pointing the user back to
  the necessary software version for conversion.

* Remove redundant fields in Membership record.

  Two fields existed in the membership record - as_at and role_id.
  Neither has ever been used, although they did have intended purposes
  originally.  They have now been removed.

* Enhance PreRequisite processing.

  Pre-requisite records were originally added to allow a configurable
  set of resources to be listed on the event creation screen.  Users
  could tick the ones which they wanted, and then those resources would
  be auto-added as soon as the event was created.

  They were subsequently used to provide Quick Buttons on the event
  editing screen - a dynamic set of buttons which allow certain resources
  to be added with a single click.  The set of buttons changed so that
  once a resource was attached to an event, the corresponding button
  would no longer appear.

  This release adds additional flexibility.

  * Each PreRequisite record now has two extra flags - pre_create and
    quick_button.  These control whether that record is used for each
    of the two purposes.  Each record can be used for one or the other,
    or for both.  (In theory you can create such a record which has
    neither flag set - it would do nothing.)

  * A system setting has been added in the main settings dialogue -
    max_quick_buttons.  This takes a numeric value.  If it is set
    to a value greater than 0 then it limits how many quick buttons
    will be displayed at once.  As buttons are used, more, lower
    priority buttons slide in to take their place.

    It is thus possible to define more buttons than would comfortably
    fit on the screen, and have just the highest priority ones
    appear to begin with.

  * It is also possible to change the colour of quick buttons according
    to the type of resource.  By default they are all a sort of
    pale blue, but by editing the file:

    $SCHEDULER_DIR/app/assets/stylesheets/tweakqb.css.scss

    it is possible to set different colours for each type of resource.
    Guidance on how to do this is provided in that file.

    After editing the file, it is necessary to compile it, with:

    $ cd $SCHEDULER_DIR
    $ export RAILS_ENV=production
    $ rake assets:precompile


v1.3.1  2018-06-25

* Enhance import of cover from Pass

  The cover records in the accessible Pass database tables are a little
  curious.  Even Pass itself fails to print an accurate report from
  them.  Improve the smarts in Scheduler's importer to try to make
  more sense of them.

* Fix to error in handling end date of repeating events.

  If a repeating event was entered with the last occurrence set to be
  on a term-time Monday, and if the repetition period was also set to
  end on that Monday, then the last instance of the event got missed
  out.  This was an error in the code for identifying week letters over
  a period of weeks.

  The WeekIdentifier class was fetching all the week letter events
  from the database, but forgetting that the end date needs to be
  specified as an *exclusive* date.  The week letter event for the
  week in which that final Monday fell thus got missed out, and the
  WeekIdentifer object later erroneously reported that the Monday
  in question was in a holiday week (no week letter), resulting
  in the missing instance of the event.

* Improve display of tutor groups.

  With the advent of release v1.3.0, schools can choose what name
  to refer to tutor groups as - the default of "tutor group", or "form
  group", or "form", or whatever they want.  Internally they're still
  known as tutor groups, but the school's choice of name is used
  when displaying to users.  More code has been amended to take
  account of this choice.

  Similarly, in some schools tutor groups are associated with houses
  and in some they're not.  This too is now a system setting, and
  when set to "not", the code won't try to display house information
  for tutor groups.


v1.3.0  2018-06-17

* Add support for importing timetable, staff and pupils from WCBS Pass.

  Scheduler uses its own database to store the events which it displays,
  but it makes sense where possible to avoid double entry.  It therefore
  has a utility to import such information as it can get automatically
  from the school's existing MIS.

  Previous versions supported importing from either SchoolBase or
  iSAMS.  This version adds the ability to import from WCBS Pass as
  well.

  The importer is split into three layers:

  *  Generic code - by far the largest bit.
  *  MIS-specific code
  *  School-specific code

  That last section handles fine detail like how the school refers
  to year groups, ("3rd year" or "Year 9") etc.

  This release adds a new set of code in the "MIS-specific" layer,
  and has resulted in some moving around of existing code which was
  found to be in the wrong layer.  The interface between layes has
  also changed slightly.

  The code has been extensively tested to ensure that existing
  supported MIS layers are not affected.

* Additional settings within Scheduler

  The settings section within Scheduler has had some new fields added
  to allow more things to be tweaked to suit individual schools.  The
  default values in each of these fields have been chosen to give the
  same behaviour as existed before the fields were there.

* Installation

  In addition to the usual steps for installing a new release, it
  may also be necessary to re-link the school-specific code files
  as part of installing this release.  A script is provided for this.

  $ cd $SCHEDULER_DIR
  $ cd lib/import/school
  $ ./linkup <School name>


v1.2.3  2018-05-23

* Fix a typo in the approvals notifier.

  In the exceptional case where an e-mail is needed for an event which
  has neither owner nor organiser, we go for the first member of staff,
  but the line for doing this had a typo in it, resulting in the run
  stopping.


v1.2.2  2018-05-17

* One tiny further change to the seed data.  Correct a typo.


v1.2.1  2018-05-15

There are no changes to the application or import utilities in this release.

* Tweak the seed data to take account of the changes in the last release.
  The seed data is used for new installations, and for the Scheduler
  demonstration system.


v1.2.0  2018-05-14

This was originally intended to be just a minor point release but
it ended up with some small database changes, so promoted to a
major point release.

* Fix problem of warning message from clash checker.

  The clash checking code was producing a regular warning message
  about events flagged as having clashes but having no explanatory
  note.

  This turned out to be due to the addition of note loading in the
  recurring events loader.  The nightly data import was stripping
  off the notes created by the clash checker, and then the clash
  checker was putting them back.

  The nightly data import of recurring events now removes only notes
  which it has itself created.

* Return error status for invalid ical requests.

  For a long time, Google has been repeatedly requesting invalid
  ICAL feeds.  Presumably people have guessed at the URL and got
  it slightly wrong.  Previously we have returned a small file
  containing an error message, but now we return an error status
  (410 - gone) instead.  This is documented as meaning "Do not try
  this URL again." so perhaps it will stop the requests.

* Permission bit to view unapproved commitments.

  Where someone has requested a resource for an event, but the
  request has not yet been approved, the event is not generally
  visible in the context of the resource.  Thus, for instance,
  events do not appear in the school's public calendar until they
  have been approved by the relevant person.

  The only people who have been able to see the event have been:

  * The requester
  * The approver
  * System administrators

  who see them greyed out.

  A new permission bit has been added to user records so other
  users can now be granted this permission too.
  
  Note that just having the admin flag set no longer gives this
  visibility.  You need the new bit set.

* All day events in recurring events file.

  Previously there was no way to load all day events from the
  recurring events file.  Now you can do it by specifying:

    starts: :all_day

  There is then no point in specifying an end time.

* Prevent the entry of 0 recurring events through the GUI.

  Previously it was possible to use the GUI to enter a set of 0
  recurring events.  Create an event on, say, a Monday.  Set
  it to recur in a date range which doesn't include a Monday,
  and hit Create.  The original event would be deleted, and
  the database would be left with an EventCollection record
  with 0 attached Events and no way for the user to delete it.
  (The system admin can delete it through the admin menus.)

  Now the recurring event code checks before attempting the
  repetition that at least one event will result.  If it won't
  then it refuses to do the repetition.

* Fix bug in recurring event deletion.

  If the system admin attempted to delete a recurring event set
  from the admin menu (Menu => Models => Events => Recurring)
  an error message was produced.  This has been corrected.

* Recurring events in holiday weeks handled better in GUI.

  If a user enters event in a term time week and then sets it to
  repeat, the repeater defaults to setting it to repeat only
  in term time weeks (although the user can change this).

  If the user enters an event in a holiday week, the repeater
  now defaults to having it repeat in term time and holiday
  weeks, which is probably more what the user is expecting.

* Improve message when deleting one event from a repeating set.

  If a user attempts to delete just one event from a recurring set
  they will now get a message pointing it out.  They can still go
  ahead and delete it if they want to.

* Fix error when deleting user.

  A typo in the event collection code led to an error message on
  attempting to delete a user.  Fixed.

* Find free now uses period times from the database.

  In the Find Free dialogue, the user is offered some short
  cut buttons to fill the start time and end time fields quickly
  with actual period times.

  In the original implementation, these times were hard-coded
  to suit the first school using it.

  The times are now derived dynamically from a database record which
  can be edited by the system administrator in the usual way.  It is
  the same kind of record used for the background periods which
  are displayed on screen.

  It is necessary to create and configure a new set of period
  definitions when this update is applied.

* Fixed recurring events README to make it clear that the order is important.

  A problem arose where the fields in a recurring events YAML file were
  sorted into alphabetical order.  This prevented the import working.

  The README has now been updated to make it clear that the order
  is important.

* Title text is now a system setting.

  Scheduler displays a title at the top left of the main screen.  By
  default it says just "Scheduler", but it can be changed to suit
  individual schools.

  To date, the method of setting it has been via environment variables,
  but this is inconsistent with how everything else is set.

  The relevant texts have now been moved to a database field.

  There are two texts - one for the public view of the system and one
  for logged on users.

  As part of the update process, any texts currently defined via environment
  variables will be copied automatically into the new database fields.

* Some dependency packages have been updated in response to
  security advisories.


v1.1.2  2018-05-04

* Keep last good iSAMS XML file for when the iSAMS API fails.

  The iSAMS API now seems to have ground to a complete halt.  Even making
  several small requests it times out each of them separately.  Whilst
  iSAMS try to solve their problem, this release implements an extra
  workaround.

  Not all the data which we get from iSAMS comes through the API.  We
  also do some direct database access to get things like cover and
  activities, which are missing from the API data.  These calls still
  work, and it's quite important to have up-to-date cover information
  in Scheduler.

  The importisdatamulti script has been enhanced.  Each time it
  successfully gets a full XML file through the iSAMS API it saves a
  copy of it, and then each time it fails it will fall back to using
  that copy.  This allows the rest of the processing still to run, meaning
  we can get some useful information out of iSAMS.

  Each time the Scheduler importer uses and old data.xml file, it will
  send an e-mail to "monitors".  Set up a suitable list of people in
  the system's /etc/aliases file to receive notifications.


v1.1.1  2018-05-02

* Workaround for deficiencies in the iSAMS API

  The iSAMS API has been getting steadily slower and slower, to the point
  where it is timing itself out.  It seems to have an internal timeout
  set at 35s, and if the request takes longer than that then it returns
  an error message and not the requested data.

  To being with, this happened only on Thursdays (!) but incidences have
  been increasing and iSAMS themselves seem to lack the technical expertise
  to fix it.

  As a workaround, the request sent to the iSAMS API has been split into
  several smaller requests.  The output from these is then combined into
  a single file (data.xml) for processing by Scheduler's import utility.

  To use the workaround, it is necessary to set up several API Keys in
  iSAMS, which between them contain all the necessary data.  A suggested
  split is as follows:

  * Everything except PupilManager and TeachingManager
  * PupilManager
  * TeachingManager

  although it may be necessary to sub-divide the PupilManager requests
  further as that's where the very slow processing seems to be.  It
  would be possible to move some elements of that module into the
  first batch, which seems to have time to spare.  The Scheduler
  utilities don't care how many chunks there are, as long as all the
  data get included eventually.

  To use the workaround, two changes are needed after installing the
  new software version.

  Edit ~/etc/isauth to add a new line:

  APIKEYS='<key1> <key2> <key3>'

  for however many batches you have set up.

  Then change your Scheduler user's crontab to invoke utils/importisdatamulti
  instead of utils/importisdata.

  The separate batches of data coming from iSAMS are stored in individual
  XML files, which for security are not named directly after the API keys.
  Instead, an md5sum of each key is generated and that is used as the
  file name.  It is thus possible, knowing the key, to find the right file,
  but it isn't possible to work from knowing the file name to regenerating
  the key.


v1.1.0  2018-04-22

* Incorporpate prep timetable

  This release adds the ability to incorporate the school's entire prep
  timetable into the data imported from the school's MIS.

  Generally speaking, prep timetables are not produced in a format
  friendly to the end user.  Each member of staff and pupil needs to
  analyse the timetable and work out how exactly it affects him or her.
  This is a terrible waste of time, and can be quite difficult for
  some pupils.

  Scheduler now does this for you, producing a tailored list of preps
  for each individual in the school.

  When a lesson is scheduled to be used for setting a prep, Scheduler
  makes two alterations to it as it is loaded.

  1.  The name of the lesson has " (P)" added to it.
  2.  The property "Prep" is attached to the lesson.

  The first of these changes is to make clear the existence of the prep
  immediately the lesson is viewed.  It is done in this way (rather than
  as a flag) because it will thus feed through to the portable
  devices (phones etc.) of each individual.  There is no facility
  in the ical spec to allow the passage of arbitrary separate flags.

  The second change means that it is possible to get reports on what
  preps are scheduled on any particular day.

  The file defining the prep timetable needs to be prepared in YAML
  format, and is stored as $SCHEDULER_DIR/import/modifiers/Preps.yml

  As a knock-on from this work, the prep timetable now reappears in
  Markbook (which has had this facility for a long time) meaning it
  is possible to print off individual pupil timetables incorporating
  all the prep information.


v1.0.0  2018-04-19

* Repeating events through the GUI

  The most significant new feature in this release is the addition of
  the means to add repeating events through the GUI.  The capabilities
  here are much the same as those provided before by means of YAML
  files, but instead the criteria can be entered through a dialogue.

  The whole process is significantly more complicated than having
  repeating events in a normal calendar program because of Scheduler's
  structuring of events.  It doesn't just have an event with a name -
  it has a list of associated resources, and each event can be found
  and displayed through any of its resources.

  The process for setting up a repeating events is as follows:

  1) Create an original event in one of the slots where you expect
     to have the repeating event.  Save it to the database.
  2) Tell the system how you want it repeated, entering suitable
     criteria:
     
     * Beginning and end date
     * Which days of the week
     * Which weeks (A, B, holidays)
     * When in the month (first Thursday, penultimate Wednesday, etc.)

  3) Effect the repetition

  Once the events have been repeated they exist as standalone events,
  albeit under an umbrella record (known internally as an EventCollection).

  Note that, if the original event from which the repetition is done does
  not fit the repetition critera - e.g. because it is on a Tuesday and
  the criteria specify every Monday, Wednesday and Friday - then as
  part of the propagation process the original event will be deleted.

  The user can edit any of the resulting events independently of the others,
  and that event will then stay slightly different from the others, unless
  and until the repetition process is repeated.  The user can pick any
  of the events in the set from which to repeat the repetition, and that
  event will then be used as a model for all the others.  Any individual
  edits done to any of the others will be lost at this point.

  Thus, if it is realised after a set of repeating events has been created
  that an extra resource is needed, that resource can be added to any
  one of the individual events, and then the change can be propagated
  automatically to all of the others.

  Events can be used as a prototype for repetition only if they have
  an owner - events owned by the system (e.g those loaded from an MIS
  or from YAML files) cannot be repeated.  Similarly, for an event to
  be repeated across multiple days, it must itself be contained within
  one calendar day.  Events spanning more than one calendar day can't
  be used as a prototype for repetition.

  Documentation for this new facility can be found in the User Guide
  at https://xronos.uk/repeating.html

* Users can delete individual events in a set, or delete the whole
  repetition.  If an individual event is deleted and then the repetition
  step is repeated, the deleted event will reappear.

* An extra information page has been added for system administrators
  to view repeating events - Menu => Models => Events => Repeating.

  From here it is possible to view all repeating event sets along with
  their statuses.  The admin can also choose to delete a whole set
  of repeating events.

* Extra code has been added to the request notification logic.  Some users
  insist on getting an immediate e-mail every time a request for their
  resource is entered into the system (or cancelled).  The repetition code
  was in danger of flooding these users with e-mails.

  The relevant code has thus been enhanced to batch up such requests and
  send them all as one e-mail.  Thus if someone requests the library
  every day for a year, it will result in one e-mail listing all the
  requests, rather than 365 e-mails.

* Journalling code has likewise been enhanced so once can see what changes
  were effected as part of a repetition.

* As this is potentially quite a powerful new feature and open to abuse,
  an extra user permission bit has been added controlling access to it.
  Only users with this permission bit set can use it.  As always, the
  bit can be set by way of a UserProfile.


v0.29.5  2018-03-21

* Upgrade omniauth to version 1.8.1

  On doing final testing of the previous release after packaging it,
  it became apparent that although omniauth was working fine, it
  produced a warning message on the console.  Upgraded to the latest
  version to get rid of this.


v0.29.4  2018-03-21

No changes to the Scheduler software itself but...

* Upgrade ominauth to version 1.3.2

  A vulnerability notice was issued for Omniauth 1.2.1 as previously
  in use.


v0.29.3  2018-03-21

* Use longer name in relocation report.

  In a printed report, locations were being identified solely by
  their friendly_name, which could potentially be confusing.

  The report now uses each location's display_name (which includes
  the friendly_name) for added clarity.


v0.29.2  2018-03-15

* Really stupid reason for a release - to change the version
  number.

  In preparing the previous release, I failed to commit the
  updated version number file to the release, resulting in
  it still being the old one.  Because the release has been
  pushed out, I need to do a fresh release just correct the
  version number, but of course that then means I need to update
  the version number again!


v0.29.1  2018-03-15

No changes to the Scheduler core code, but...

* Allow notes and organisers to be specified on events loaded through
  the YAML recurring events mechanism.


v0.29    2018-03-15

* Add the ability to wrap events.

  It is sometimes necessary to put additional time round an event to
  allow for setting up and clearing away.  This is not part of the actual
  event (as would be listed for instance in a public calendar), but is
  necessary behind the scenes.

  It has always been possible to put in extra events for this purpose,
  but this release adds a new feature to speed the process.  Anyone with
  (at least) permission to sub-edit an event will find an extra link on
  the "Show event" dialogue - "Wrap".

  Clicking this link will produce a fresh dialogue offering the means to
  create two new events - one before and one after.  The new events will
  have descriptive names derived from the original event, and default
  durations which can be set in the system configuration.  Each of
  these can be adjusted and the events can be turned on and off individually.

  The user will also be presented with a list of the resources attached
  to the original event, with tick-boxes to select which should be
  attached also to the wrapping events.  By default, staff and locations
  are carried over, but properties, services, pupils and groups are not.

  Having made appropriate choices, the events are created when the
  user clicks the "Create" button.  Clicking the "Cancel" button will restore
  the previous dialogue.

* Correct processing of approval of cloned events.

  The new facility above makes use of cloning code which was already in
  the system.  In the course of development, it was noticed that the
  existing way of bringing over approvals wasn't quite right.  The
  code simply assumed that any approval previously granted would be
  needed again on the cloned event.

  This isn't quite right, because it might not be the same person doing
  the cloning as the one who originally created the event.  If the
  person doing the cloning is an administrator of a resource then
  permission is not needed, even though the original creator might
  have needed it.  Likewise, if the original event was created by someone
  who didn't need permission, then the code would assume the clone
  didn't need permission either.

  The cloning code now goes through the full evaluation of whether
  permission is needed or not - relative to the user doing the cloning.

* Send immediate e-mails where configured.

  Likewise, the cloning code did not send immediate e-mails about
  resource requests to administrators who had asked for them.  It now
  does.

* Add new journal entry type.

  Cloning an event has always been included in the event's journal.
  This release adds a new journal entry type, identifying events which
  have been created as part of the wrapping process.

* New system settings.

  To support the wrapping process, three new fields have been added
  to the system settings.

    Default set-up duration
    Default clear-up duration
    Default eventcategory for wrapping events

* Improved immediate resource request e-mails.

  The e-mails which are sent to resource administrators who have
  requested immediate e-mail notification (rather than using Scheduler's
  own interface) have been improved with more information about
  the event.

  A button has also been added to the HTML version of the e-mail
  allowing direct navigation to the appropriate approvals page.


v0.28.12 2018-03-08

* Adds quick-add buttons

  When a user first starts creating an event, he or she may be presented
  with a list (administrator configurable) of things to think about adding
  to it - things like parking requirements, or the public calendar.

  Once the event has been created, this list was no longer accessible, because
  it was a check-box list and that doesn't make sense in the context of
  general event editing.

  This release adds a new feature - Quick Add Buttons.  The same list
  of preferred items is used to generate some buttons below the usual
  "Add resource" field.  Clicking on one of these will immediately add
  that resource to the event, without the user having to type its name.

  The list of buttons auto-updates, so if a resource is already attached
  to the event, there is no button to add it again.

* The icon for approving/approved events has been changed from a plus
  sign on a green background to a tick on a green background.  This has
  been done simply by replacing the icon file, so it may take a little
  while to become evident on some browsers due to caching.  A shift-refresh
  will speed the process if desired.

* The feature added in v0.28.9 to allow suitable users to view forms
  let them see all forms - even blank ones.  They are now shown only
  forms which have had some data entered.

* The event editing form has been tightened up slightly (fields moved
  closer together) to make it easier to use on a small screen.  Note that
  on a very small screen, the quick-add buttons mentioned above will
  disappear to save space.

* A real "current" flag has been added to the Property and Service models.
  Previously these had a fake flag which was always set to true.

  This flag controls whether the item is in current use - can be added
  to new events and viewed in the main screen.  Items which pass out of
  use (e.g. staff who have left) stay in the system for the historical
  record, but don't appear in pop-down lists etc.

  The addition of this flag means it is now possible to deprecate old
  properties and/or services if they are no longer needed.  E.g.
  if the Parking service has been merged into Porters, then the current
  flag on Parking can be set to false to prevent anyone adding it to an
  event in future.


v0.28.11 2018-03-06

* Fix listing of event categories.

  Version 0.28.8 added the editing of user concerns, but inadvertantly
  broke the listing of event categories.  Two view helper methods
  with the same name, but marginally different signatures.

  (Incidentally, Rails helpers used to be private to a controller.
   It seems that now they're not - all helpers are shared between
   all controllers.)


v0.28.10 2018-03-02

* No actual code changes - just the README.


v0.28.9 2018-03-02

* Allow more users to view forms.

  Prior to this release, only users involved in the approvals
  process (requester or approver) could view each corresponding
  form.

  This release adds a new user permission bit - can_view_forms.
  If this bit is set - either in the user's profile or in the user's
  own user record - then the user can view any form from the event
  display dialogue.  (Click on an event in the calendar view, then
  click on the form which you want to view.)

* Add extra "Back" button to form view.

  Some of the forms in use are quite long, and the existing "Back" button
  was at the bottom meaning that the user had to scroll down each time
  in order to exit the form.

  An extra "Back" button has been added at top right, to allow forms
  to be viewed and then closed more swiftly.


v0.28.8 2018-03-01

* Greatly improve concern editing by system admin.

  The process for the system administrator to edit users' concerns
  has always been a bit basic.  This release adds proper facilities
  for that.  A system admin can now add, edit and remove concerns
  for users all in one place.
 
* Better listing of concerns when viewing a user.

  In the display of a user, the concerns listing moves to a separate
  tab of its own to facilitate the above change.  The listing now includes
  all the flags from each concern, not just a select few.

* New privilege bit on concerns.

  To reflect usage elsewhere in the system, a new "subedit_any"
  privilege flag has been added to the concern record, matching the
  existing "edit_any" flag.  Users with this bit set on a corresponding
  concern will be able to sub-edit any event involving the corresponding
  resource.

* Correction to ability to change times.

  In a rather odd mis-feature, users with the edit_any flag set for a
  resource could mostly edit the events, but they could change the times
  only if the user was also the owner of a resource (any resource -
  not just the target one).  Just plain wrong - the test has been
  corrected.

* Tidy up appearance of cancel buttons.

  Often a screen will have a "Save" button and a "Cancel" button, and
  behind the scenes the "Cancel" button is really just a link taking
  you back to the page which you were on before.  These looked nearly
  the same, but not quite - the text of the button went white only
  when you hovered over it, whilst the "Save" button had white text
  all the time.  Fixed.

* Spurious debug messages remove.

  Quite a few debug messages - at both the client and server end - have
  been removed.


v0.28.7 2018-02-25

An interim release with a few requested enhancements.

* Re-locate lessons to rooms which appear busy

  It is sometimes necessary for an administrator to effect a lesson
  re-location even though the target room seems to be occupied already.
  E.g. in order to do a round-robin of swaps, or to merge two lessons.

  As of this release, anyone with the "relocate lessons" permission bit
  set will get two lists of rooms in the pop-down menu - first the free
  rooms, then the non-free rooms, clearly highlighted as such.

  Ordinary users re-locating their own lessons will continue to be offered
  only rooms recorded as being free.

* More colours for the concerns down the LHS.

  Each time a user adds a new concern in the column down the left
  hand side of the screen, it is allocated a colour.  Users can change
  the colour but they usually don't.

  The program had a limited list of available colours (14) and once all
  those were in use it created all further concerns with a colour of grey.

  This release adds more colours to the fixed lists, plus a random colour
  generator so that all new concerns will now be allocated distinct colours.

  Some users have a surprising number of concerns (49 in one case!) meaning
  the column extends right off the bottom of their screens, and a large
  number of them are grey.  These can be tidied with the following commands.

  $ cd Work/Coding/scheduler
  $ export RAILS_ENV=production
  $ rake improve_colours:all_users

  This task will go through all the user records, changing any grey concerns
  to a distinct colour.

  It might be worth checking that users know that they can delete concerns.

* Resource administrators to view forms from event dialogue

  A new link has been added to the "show event" pop-up window, allowing
  administrators of resources to jump straight from there to the corresponding
  form.

  To preserve the user's state, the form will open in a new tab.  Clicking
  the "Back" button in the form will close that tab and return the user
  to the previous dialogue.

  This is one of several possible ways of doing it.  Deploying it to see
  how users react.


v0.28.6 2017-12-26

Still tidying up.

* Remove LetsEncrypt directory

  This contained various support files for getting HTTPS certificates
  from Let's Encrypt set up.  The standard tools for Let's Encrypt
  are now much more mature and the use of them is documented in
  the Scheduler Installation Guide at https://xronos.uk/install
  so these are now redundant.

* Make iSAMS database extractor tool fully environment driven.

  The iSAMS database extractor tool has always got some of its settings
  from the program environment, but now it gets all of them this way.

  This has the advantage that neither the program source, nor the
  script for invoking it, needs to be edited to suit a particular site.
  The only configuration needed goes in ~/etc/isauth.

  A new sample isauth file is provided in the support directory.  It
  will need editing before installation as ~/etc/isauth.

  Make sure you install it with no read access for other users
  on your system - "chmod 600 ~/etc/isauth".

* Show Ruby and Rails versions to administrator.

  To provide an easy means for the administrator to check that a
  live installation is running in the right environment with the
  correct versions of Ruby and Rails, the main application screen now
  includes this information for anyone logged in as an administrator.

  Hover your mouse over the software version number at bottom right to
  see the Ruby and Rails versions as well.

  This information is available only to administrators.

  
v0.28.5 2017-12-21

Add more directories to facilitate new installations.

* Previously, users were expected to manually create directories
  under import/isams.  There was a README there saying what was needed
  but the directories weren't.  This release includes these empty
  (except for a .keep file) directories.

* Likewise the directory import/ForMarkbook is created automatically.

* Files whichsystem and isauth in the support directory updated.


v0.28.4 2017-12-19

Further tidying up of installation and demo system.

* Upgrade mysql2 gem to version 0.4.10

  Testing showed that the old version (0.3.16) was incompatible with
  the latest MySQL, as used on Debian 9 systems.  The new one works
  fine with Debian 8.

* Add a pupil to the demo users

  Users of the demo system can now log on as a pupil too.

* Pupil user profile allows event creation

  The default pupil user profile now allows event creation.  This will
  not affect existing systems, only new installations.

* ical feeds require UUIDs by default

  Earlier versions of Scheduler did their ical feeds by element
  number - e.g. /ical/21.  These are small and predictable which
  is potentially insecure.

  The current version expects them to be done by UUID, so things
  like /ical/UUE-937a658f-0ed8-4b44-a78d-faf30f4d520a.  Much harder
  to guess.

  A configuration setting controls whether the old version will still
  work.  This setting now defaults to allowing UUID access only.
  Again, existing systems will not be affected - only new installations.

 
v0.28.3 2017-12-18

* Upgrade to Ruby 2.3.6

  In the spirit of moving on to later versions of things, this release
  updates the application to use Ruby 2.3.6.

  There are no actual code changes - just an environment change
  followed by a lot of testing - but it is slightly more complicated
  to install.

  The usual upgrade process (in the application directory) is:

    * export RAILS_ENV=production
    * Checkout release
    * bundle install
    * rake db:migrate
    * rake assets:precompile
    * touch tmp/restart.txt

  For this one though, we are changing Ruby version, which means a new
  gemset and thus some extra steps.  It's probably best to shut down your
  web server (and the application) entirely for the duration of the
  upgrade.

  The first step is to install the new version of Ruby, and whilst this
  takes a little while, you can do it before shutting down your web
  server.  Log in as you scheduler user and type:

  $ rvm install 2.3.6

  It will probably need to compile from scratch, but it should need
  no further intervention from you.  Once that has completed, stop
  nginx:

  $ sudo systemctl stop nginx

  Then move into your scheduler application directory and do the following:

  $ export RAILS_ENV=production
  $ git pull
  $ cd ..                   \ Important step
  $ cd scheduler            /
  $ gem install bundler
  $ bundle install
  $ rake assets:precompile

  That gets the application basically ready to run, but you need to tell
  various other bits about the new version of Ruby.

  Under ~/.rvm/environments and ~/.rvm/wrappers you will find two
  symbolic links (set up at installation) which point to the right version
  of Ruby to use.  Remove them and set them up again with:

  $ cd ~/.rvm/environments
  $ rm scheduler
  $ ln -s ruby-2.3.6@scheduler scheduler
  $ cd ~/.rvm/wrappers
  $ rm scheduler
  $ ln -s ruby-2.3.6@scheduler scheduler

  Finally you need to tell Passenger (the component which runs Scheduler on
  behalf of Nginx) to use the new Ruby version.

  In your nginx configuration files for the Scheduler installation, change
  the definition of "passenger_ruby" to point to 2.3.6 instead of 2.1.10.

  You should now be in a position to restart Nginx and access your
  installation of Scheduler again.

  $ sudo systemctl start nginx


v0.28.2 2017-12-17

* Fix problem with seeding demonstration database.

  The code for seeding a demonstration database was using a sub-class
  of a Hash to hold default event category settings.  This turned out
  to be incompatible with the way Rails 4.2 handled them.

  Now uses a real Hash.


v0.28.1 2017-12-13

* Upgrade to the latest point release of Rails 4.2

  Continuing on the theme of upgrading the packages on which Scheduler
  depends, this release takes us up to the latest point release of
  the 4.2 series - 4.2.10

* Upgrade jquery-rails to 3.1.4

  Likewise, brought up to latest version.

* Re-work Notifier model.

  The Notifier model was going behind the scenes a bit in ActiveRecord
  with the result that it failed testing after upgrade to Rails 4.2
  Updated to work again.

* Upgrade rails-autocomplete

  An intermittent slightly odd bit of behaviour has been noticed
  in rails-jquery-autocomplete.  It doesn't stop it working, but it
  just looks slightly odd.  Updated to latest version (1.0.3) in
  case that helps.

* Change mailers to use deliver_now

  The Rails ActiveMailer has a function called deliver() which is
  deprecated.  It is replaced by deliver_now() which does the same
  thing.


v0.28   2017-12-11

* Upgrade to latest point release of Rails 4.1

  Pushing the software to GitHub highlighted the fact that the version
  of Rails in use was a little out of date.  The main change in this
  release is to update to the latest point release of Rails 4.1

* Update tests for new data structures.

  The last couple of releases have added new data structures.  The automated
  tests have now been updated to take account of these.

* Remove spurious log messages.

  A couple of unnecessary log messages had been left in the UserProfile
  code.  Removed.

* Tidy repository

  Some unnecessary files had been left in the repository.  These have
  been removed.

* Add README.rdoc

  The application now has a very basic README.rdoc in its root directory.


v0.27.3 2017-12-07

* Sort locations attached to event in ical feed.

  The application has never made any guarantees about the order in
  which locations will be listed for an event.  However, it became
  apparent that events in the ical feed were having their locations
  listed in a completely different order from how they were being displayed
  on screen, which caused confusion.

  This release adds a sort to the ical feed generation so that multiple
  locations attached to an event will now be listed in the order in
  which they were attached to that event.


v0.27.2 2017-12-05

* Simply add a version number to the bottom right of the main screen.


v0.27.1 2017-12-05

* One extra addition to the demo system seed data.  Put "Covered"
  on the cover lesson.


v0.27   2017-12-05

* Addition of user profiles

  The major new feature in this release is the addition of User Profiles.
  Previously each user has had an individual set of permission bits
  and a change in policy for permissions would have required each user
  record to be edited individually.

  The system now has new records called User Profiles, which serve to
  carry a set of permission bits.  Each user is linked to one User Profile
  and inherits the permissions specified there.  In addition, user records
  have their own sets of permission bits which can be used to override
  those in the corresponding profile.  Thus, for instance, a user can be
  linked to the "Staff" User Profile, but have the Admin permission bit
  set in addition.  Overrides can work either way - adding or removing
  a permission bit.

  On upgrading to this release, all user records will be upgraded
  automatically to the new method of working.  All users will have the
  same permissions which they had before, achieved where possible
  by inheriting from their user profile, and otherwise by explicit
  settings on the user record.

  Three User Profiles are created by default:

  Staff - for users who match a Staff record
  Pupil - for users who match a Pupil record
  Guest - for users who don't match any record

  The Staff User Profile has the following permission bits set:

    * Editor (can create events)
    * Add resources
    * Add notes
    * Groups
    * Public groups
    * Find free
    * Add concerns
    * Roam

  which are the same permission bits which staff were given before.
  The Pupil and Guest User Profiles have no permission bits set.

  A member of staff who previously had "admin" and "editor" set
  would now get the editor permission by dint of being linked to the
  Staff User Profile, but would get the "admin" bit set on the individual
  user record, because the profile does not confer that.

  Similarly, a pupil who previously had the "editor" bit set on his
  individual user record would still have it set after the conversion
  process, because otherwise he would not have that permission.

  Changing the permissions on a User Profile will affect all its
  linked users immediately, except those who have an override set
  for the corresponding permission bit.

  More User Profiles can be created, amended and deleted as required by
  a system administrator and the original three can have their permission
  bits amended, but these three can't be renamed or deleted.

* New users link to User Profile records

  As well as existing users being converted as described above, all
  new users logging on to the system will have their user records
  linked to appropriate user profile records.

* Seed data updated to match

  The seed data for new installations have been updated to match the
  new records.

* New demo login method

  A system in demonstration mode now allows direct login by suitably
  configured users, removing the need for a Google login.

* Remove spurious menu item

  Ordinary users were getting an item on their menu called "Day shape".
  It didn't do anything because they didn't have the necessary permissions,
  but it just shouldn't have been there at all.  Removed.


v0.26.4 2017-12-04

* Fix loss of menu on mobile devices.

  A problem was noticed recently in that you could no longer log in
  on mobile devices.  This had been caused by me tidying up the code
  in an earlier release to improve the tightness of the display.

  I missed out one crucial item, resulting in the problem.  Now
  re-instated.


v0.26.3 2017-11-24

* Split "editor" permission flag in three.

  Previously there has been a single flag on the user record indicating
  whether a user has been allowed to create and edit events.

  There are now two more - can_add_resources, and can_add_notes.

  A user with simply the "editor" permission bit can create events, but
  can't choose to add resources to them.  Having created the event, he or
  she is thrown straight back to the event display.  It is assumed that
  the user will be configured with some auto_add resources, typically
  his or her own staff or pupil record (usually pupil).

  The can_add_notes flag controls whether a user can add notes to existing
  events.

  Existing user records which previously had the "editor" bit set will
  be converted to have all three of these set as part of the automated
  upgrade process.

  For new user records, staff will get all three set, whilst pupils will
  by default get none set.

  All new users will now have the auto_add flag set on their own record,
  setting them up to use this mechanism.  This might also help with new
  staff users who tend otherwise to create events with no resources at all
  attached.

* Re-designed listing of event categories.

  The Eventcategories listing page had grown over the years to the point
  where it didn't convey useful information.

  A completely new design has been implemented, which renders the
  information much easier to see.  It's a bit experimental, but as it's
  visible only to administrators it seems a good place to try it out.

  Pagination has been added to cope with having lots of them.

* Selective listing of event categories.

  It is now possible to choose to list only current event categories,
  or only deprecated event categories.

* Corrected count of permissions pending for resource approvers.

  The count shown at the top of the screen for resource approvers included
  all pending requests for the resource, even those where the requester
  had yet to fill in a form.  The count now excludes requests which
  still need a form to be completed, making it more meaningful for the
  resource approver.

  Requests where a form needs to be filled in still appear in the
  requesters count of things which need doing.

  
v0.26.2 2017-11-21

* Adds more detail to the page used for printing request forms.

  Once a user has filled in a form requesting a service it is useful
  for the service provider to be able to print a page for the records.

  This release adds a bit more detail to that page, so they can have
  all the necessary information about the event in one go.


v0.26.1 2017-11-21

Mainly updating the seed data used for new installations and the demo
system, but two very small functional changes for running systems.

* Being a resource administrator and being able to edit forms are two
  separate permission bits.  However, before this release it was
  necessary to have the "form editing" permission bit in order to
  attach a form to a resource.  It is now possible to do it merely
  by being the owner of the resource.  It is thus possible to give
  people permission to use a form, without also letting them edit it.

* A very small bug which couldn't actually arise in a running system,
  but could when setting a system up.  If the prompt text for the
  event creation dialogue was left as nil, then the code for saving
  the system settings raised an unintended exception.  Not a validation
  error - an error in the logic.  Fixed.


v0.26   2017-11-19

This release implements the concept of Busy and Non-busy event categories.

These are needed so that people can have events in their schedules without
the said events causing them to appear busy.  The obvious example is
the standard "Date - other" event category.  It may well be desired to
push such a date into the schedule of various pupils as being noteworthy,
but without it meaning that said pupils are going to miss lessons on that
day.

* Add a busy flag to the Eventcategory record - defaults to true.

* Add code to the Eventcategory editing stuff to allow the flag to
  be edited.

* Enhance Commitment#commitments_during to allow the specification of
  eventcategories to exclude from a search.

* Propagate the previous change up through the call tree.

* Enhance the general clash checking code (the code which puts red dots
  onto lessons) to take account of non-busy events and ignore them.

* Likewise with the code for checking cover clashes.

* Likewise with the code for checking invigilation clashes.

* Make the Freefinder module (used for finding free resources of a given
  type) aware of the flag.  This affects both explicit use of the Freefinder
  (from the top menu) and the allocation of invigilation slots.

* Make the "double booked" code (which puts red boxes around double-booked
  resources) observe the flag.  Non-busy events never cause the red box
  to appear.


v0.25.1 2017-11-17

* Hotfix for exam invigilation modification

  It was discovered that if you set up an exam invigilation cycle with
  the wrong group of invigilators, then changed the default group
  it was not enough to re-generate the events to get the group changed.
  You had to delete all the room records and start again.

  This hotfix ensures that the "regenerate" code does now notice the
  new default group and applies it to all the events.


v0.25   2017-11-12

This release pulls together four separate pre-releases (pre1 to pre4)
plus some final extra changes.

New in this release:

* Rationalise checking of user permissions.

  Various user permissions were being checked in a slightly ad-hoc
  way through the application.  They have all been moved into a single
  module.

* Visitors not to see tentative commitments.

  Visitors to the site (either not logged in, or logged in but unknown)
  can see only events which are flagged as being publicly visible (by
  having a Property with "public" set attached to them).  However, once
  they have sight of such an event, they can click on it to see a limited
  amount of additional information.  This used to include locations for
  which the commitment had not yet been approved.  This release hides
  such locations.  Visitors can see them only after they've been approved.

* Visitors not to see approval status.

  Similarly, when visitors are shown such approved resources, they no
  longer see the approval status - the resource is just there.

* Resource approvers to fill in forms.

  Users who have control of a resource - those who approve the requests
  of others to use them - do not generally need approval themselves.
  However, if said resource has a form attached, it makes sense to give
  even an approver the opportunity to fill it in.

  If a resource approver attaches his or her own resource to an event,
  and if said resource has a form attached, then the request will no
  longer acquire automatic approval.  The approver thus has a chance to
  fill in the form before approving his or her own event.

* Switch to icon status throughout.

  All instances of coloured backgrounds to show resource status have
  been removed.  It's now all done with icons.

* Allow "noted" status from event dialogue.

  The new "noted" status can now be entered by approvers from the
  event dialogue.  Previously it could be done only from the event listing.

* Put styling on all HTML e-mails.

  All the e-mails generated by the UserMailer now have Scheduler styling.

* Remove spurious debug messages.

  The overnight e-mail run to notify approvers about pending requests had
  some spurious debug messages left in.  Now removed.

* Fix bug in handling of permissions for relocations

  A bug was introduced in v0.25-pre2, whereby relocation requests for
  controlled resources (rooms which need approval) skipped the approvals
  process.  This has been fixed in this release.

* Fix count of actions where user has approval without completing form.

  It's just possible that an approver will approve a request even though
  the requester hasn't filled in the form.  In this case, the form should
  not be included in the requester's count of "things to do" because
  he or she no longer has access to it.


v0.25-pre4 2017-11-10

* This time, it really does seem to manage to get the e-mail header
  to look right when viewed in Gmail.


v0.25-pre3 2017-11-08

A couple of tweaks to the CSS on the re-worked e-mails to try to
cope with Gmail.  (Gmail does not pass things through unadulterated,
with the result that things look different inside Gmail from outside.)

* The header has a link to Scheduler.  This is meant to have white text
  and no underline, but in Gmail it gets blue text and an underline.
  Made the selector more specific to try to override Gmail's amendments.

* In the listing of pending approvals, the buttons over on the right
  hand side cascade inwards if their is a short list of individual
  requests for a resource.  Added a "clear" specifier to the parent
  div to try to prevent this.


v0.25-pre2 2017-11-07

Further polishing of the new features.

* Use icons on the event approvals listing.  These will be retro-fitted
  to all the other places where the status of a resource request is listed.

* Addition of "Noted" or "Hold" option for requests.

  It has become apparent that there are circumstances where resource
  administrators need to say, "Noted, tell me more" in relation to a request.
  This can be something as simple as a request for a visitor badge when
  the name of the visitor isn't yet known, or it can be a proposed
  dinner, where approximate details are known, but not yet the final
  version.  It is nonetheless good for catering to receive an initial
  request as early as possible.

  It is now possible for resource administrators to click a "Noted"
  button on a request (along with the existing "Approve" and "Reject")
  which puts responsibility for it back in the requester's court (the
  approver stops getting e-mails).  It is then expected that the
  requester will finish off the details, at which point the request
  will move back to a "Requested" state and the approver will once again
  be prompted to accept or reject it.

  This process can be repeated as often as necessary.  The approver can
  include a message with each "Hold".

  Hold events are journalled as normal, including any reason given.

* The underlying implementation of request statuses has been changed from
  a collection of flags to an enum.  This makes the processing clearer.

* The form responses gain a status field, so it can be seen when the
  form has been partly filled in and the approver is waiting for more
  information.

* E-mails have been re-worked to use a certain amount of formatting,
  and to add buttons allowing users direct access to Scheduler to take
  action on the points being raised.  Not all e-mails have been done yet -
  only those relating to event approval - but they are being pushed out
  to get user feedback.

* Requesters whose requests have been rejected will now get a nightly
  e-mail to prompt them to do something about them.  This is to prevent
  them just sitting in the system for ever.

* The listing of requests for a resource now has additional links.

  * Owner's and Organiser's initials have hover text giving the full name,
    and if clicked on allow the sending of a direct e-mail.

  * Clicking on the name of an event will open the event modal dialogue.

* If a user amends an event from the pop-up dialogue over an event listing
  (either the requester's listing or the approver's listing) then the
  listing will refresh when the dialogue is closed.

* If an event has approved commitments, the normal requester loses the
  ability to re-time the event.  This is to prevent ordinary users making
  casual changes to, for instance, the public calendar.

  Privileged users (e.g. DJD) can still change the timing of the event,
  the idea being that if one wants to change the date/time of a calendar
  event, one e-mails DJD and he does it (if he approves the change).

  The new feature in this release is that should DJD change the timing
  of an event in this way, all the other approvals which it might have
  automatically revert to a "Requested" state, and need to go through
  the approvals process again.  As always, this event is journalled.


v0.25-pre1 2017-10-23

This is a preparatory release to be installed at Abingdon to allow final
polishing of some new features, which are:

* Forms to enable requirements to be specified when requesting resources
  for events.

* Journalling of edits to events.

  All manual edits to events are now journalled.  The journal can be
  viewed by system administrators.

* Configurable prompt message on event creation dialogue.

* Configurable list of highlighted properties and services on event
  creation dialogue.

* Improved menus for event approval and requirement specification.

  The old "Approvals" menu has been replaced by a heirarchy of menus
  whereby a user can see events for which he is responsible, and
  resource approvers can see lists of all events requesting their
  resources.  Approvals can be done from the event dialogue as before,
  or directly from the event listing.  Forms can be viewed and filled
  in from the event listing.

* Active counts of things requiring action for all users.

  All users now get a count of things requiring their attention in their
  top level menu.  As they work down through the menu, the location of
  each item is highlighted by a count on each individual one.  At each
  level, the count on the sub-menus will add up to the count on the
  parent menu.

  Counts are updated automatically when the user does something which
  affects them, or after 10 minutes if someone else does something which
  affects that user.


v0.24.8 2017-10-02

Two small bug fixes relating to the creation of repeating events.

* Limit staff to current staff.

  The YML files defining repeating events identify staff by means of
  their initials.  If a staff member has left and then another member
  of staff arrives with the same initials, the old member of staff
  will tend to be found first, before the new one.

  The selector for finding staff has been changed from:

     Staff.find_by(initials: "...")

  to:

     Staff.current.find_by(initials: "...")

  It thus becomes impossible to define a recurring event involving
  an ex-member of staff, but...

* Delete recurring events on days which now have none at all.

  Although the loader deletes recurring events which have been removed
  from the YAML definition files, a logic error in the code meant that
  it completely ignored days which had no events on them at all.  Thus
  if events were created via YAML files, and then deleted from those
  files leaving no events at all on that particular day, the events
  in the database never got deleted.

  The loader now processes *all* days, regardless of whether the
  files define any events on those days.


v0.24.7 2017-10-01

* Include room information in meetings coming from iSAMS.

  It has been pointed out that the importer taking data from iSAMS
  installations was not bringing over room information.  I must
  have just missed the fact that it was there in the meeting records
  when I implemented it.  This release corrects that ommission and
  meetings now get their rooms.

  iSAMS produces one meeting record per person at the meeting, each
  with all the other meeting information duplicated.  Scheduler merges
  all of these into a single event, and will take the room information
  from any record which has it.  In practice iSAMS seems to include
  the room information in all the records of a meeting, or none of them.


v0.24.6 2017-10-01

* Merge lessons coming from iSAMS with more than one teacher.

  iSAMS can't cope with lessons which have more than one teacher.
  (SchoolBase has exactly the same limitation.)  In practice, lessons
  with more than one teacher do occur.  The best you can do in iSAMS
  is to make multiple simultaneous lessons with all the same information
  apart from the teacher.  On detecting an instance of this, the
  Scheduler importer will then merge them back into the single event
  which they in fact are.  The test is:

    Same timing
    Same group of pupils
    Same lesson name
    Same room

  Apart from thus recording what is happening more accurately, this has
  the knock-on advantage that you don't then get an apparent clash for
  pupils who have two apparent lessons simultaneously.

* Assign cover to merged lessons correctly.

  When storing cover information, iSAMS records who is doing the cover,
  but not who is being covered.  It can get away with this because of
  its assumption that there is only one teacher for a lesson.  It knows
  which lesson is being covered, and therefore infers which teacher it
  must be.

  Once multiple records for the same lesson have been merged as described
  above, this assumption no longer holds.  The importer therefore keeps
  track of all the original part-lessons which have been merged, and thus
  assigns covers to the correct covered teacher.


v0.24.5 2017-09-12

* Add in file accidentally missed from the last release.

  A file - lib/import/misimport/miscover.rb - was accidentally missed
  out from the last release, which caused covers to stop flowing from
  iSAMS to Scheduler.  This release simply includes the update version
  of that file which should have been in the last release package.


v0.24.4 2017-09-05

* Allow re-location to be done more than once in the same dialogue
  session.

  Once a lesson had been re-located, the re-locate link disappeared.
  This release re-instates it.

* Remove spurious debug message.

  A debug message was accidentally left in the last release.


v0.24.3 2017-09-05

* Group re-located lessons using a new property.

  In v0.23, a new facility was added whereby individual lessons could
  be relocated by users into different classrooms.  This release
  adds a new property - "Re-located" - which will automatically be
  added to all lessons so re-located.  It is then possible to view
  them or report on them as required.

* Make sure lessons can be re-located after editing.

  It's not a normal workflow, but there was a small bug in the
  re-location code.  If a user first edited an event, and then went
  back to the display screen, the re-location link no longer worked.
  It was necessary to close the dialogue and re-open it in order to
  do a re-location.  This bug has been fixed.

* Reports now understand covers/re-location

  The reporting code used to list cover staff and lesson re-locations
  simply as more resources on the event, without indicating their special
  status.  It now displays staff covers as "ABC (covering DEF)" and room
  re-locations as "G112 (normally G111)".

* The seed data for a new system has been enhanced to add the "Covered"
  and "Re-located" properties.


v0.24.2 2017-08-27

No changes to the application itself - just to the data importer.

* Cope with new staff not fully set up in iSAMS.

  One new member of staff had not been fully set up in iSAMS but
  nonetheless had been used as a form tutor, which caused the import
  utility to trip up.  Now copes with this situation.

* Cope with week letters missing from iSAMS.

  For schools with a two week timetable, iSAMS holds a record of
  which calendar week gets which of the two weekly timetables.  The
  importer uses this information to populate individual schedules.

  If that information is missing from iSAMS, the importer will now
  look at Scheduler's own database for events in the "Week letter"
  category, and if found will use that information instead.


v0.24.1 2017-08-25

* Fix to handling of conversion from timed to all-day

  The previous release introduced a change to edge-cases when converting
  existing events from being timed to being all-day.  Unfortunately the
  same change introduced a bug in the creation of new all-day events -
  they all ended up one day short.  This release fixes that bug.


v0.24   2017-08-07

* Configurable properties to show to new users

  When a new user registers on the system, the practice to date has been
  to include automatically all public calendars on the system as his or
  her immediate concerns.  For students (who can't add or delete concerns)
  this then becomes their fixed list of concerns.

  This release adds a little more flexibility, in that each Property
  within the system acquires two flags, controlling whether that Property
  will be included as an automatic concern for new staff or pupil users.

  It is thus possible to have a calendar which is not public, but is
  automatically shown to all new staff users, and not pupils (or vice
  versa).

  When this release is installed, all existing public calendars will
  get both these bits set, and from then on the system admin can set
  them as required.

* Correct display of edge case of timed multi-day events.

  If a timed multi-day event began at a time other than midnight and ended
  at exactly midnight, it was displayed as one day too long.  Now
  corrected.

* Improved handling of conversion to/from timed/all-day events.

  When a user changes an event from being timed to being all-day, or
  from being all-day to being timed, the default behaviour is now
  less surprising.

* New support file - setupmysql

  A new file has been added to the support area to help in the
  creation of MySql databases in a new installation.

* Import of iCal files

  Early versions of Scheduler included the means to import a set of
  calendar data from an old calendaring program which exported them
  as a CSV file.  Since the old calendaring program has gone away
  (its maker ceased trading a long time ago) this facility was disabled
  a while back.

  In this release, a similar facility is added in which allows the
  import of iCal files from Google Calendar.  It is thus possible to
  move over a whole existing school calendar from Google Calendar,
  allocating it an event category + property and getting it into
  Scheduler.

  Note that this is intended to be done on a one-off basis.  It
  includes no means to do an in-place update of such events.  If it's
  run a second time then all the events brought in in the first run
  will be deleted and re-created, losing any edits done to them
  subsequently.

  The facility is available only to the system administrator.


v0.23   2017-07-31

* Room covers (or lesson relocation)

  There are two common scenarios where a lesson needs to be re-located.

  1. The teacher wants to move to an ICT room or other specialized location.
  2. A lesson needs to be moved from its normal room to free that room
     up for another function.

  This release adds provision for users to make such relocations quickly
  and easily, and automatically prevents them choosing a room which isn't
  free.

  Lessons can be re-located by the teacher of the lesson, or by a
  specially privileged user of the system.  An extra privilege bit
  has been added to the user record for this purpose.

  To relocate a lesson, click on the lesson in the normal display,
  and then on the "Re-locate lesson" link.  This link appears only
  for users with the appropriate authority as described above.

  After a short delay (1-2 seconds) a pop-down menu is populated with
  a list of all the rooms which are free at the required time.  Selecting
  one and clicking OK will cause the lesson to be relocated.

  If the selected room requires approval, the usual process will be
  enforced, including e-mails if the administrator of the room has
  requested them.

  The same dialogue can be used to remove a re-location and revert the
  lesson to its original room.

  The mechanism implementing this behind the scenes is exactly the same
  as that used for cover for teachers, although it may not be immediately
  apparent to end users that they're really the same thing.

  The system adminstrator should set up a two-tier layer of groups
  to indicate which rooms can be used for cover.  Typically something
  like this:

  Cover Rooms ->  Able Building  -> A11
                                    A12
                                    A13
                  Baker Building -> B11
                                    B12
                                    B13
                  ICT rooms      -> ICT-A
                                    ICT-B

  A group of groups of rooms.  Once the "Cover Rooms" group exists, it
  can be configured for this purpose in the system settings.  Until that
  configuration is done, the "Re-locate lesson" link will not appear for
  any user.


v0.22.2 2017-07-31

* In the area of pre-formatted iCal feed URLs.

  For people (staff and pupils) a variety of feed options are offered,
  but for other elements there was just one.  This release changes that
  to two - one with breakthrough events and one without.  It's
  conceivable that either might be required by end users.


v0.22.1 2017-07-31

  Two small fixes

* Further fix to the auto-update of the pending requests count.  It turned
  out the permission checking was wrong, meaning that although the
  feature worked, it worked only for admin users.  Now corrected so that
  it will work for anyone.

* The consistency check in the Commitment model was slightly wrong, in that
  any time a Commitment record was validated, it caused the corresponding
  Event and Element records to be validated too.  This was caused by a
  misunderstanding about the meaning of the declaration of the relationship
  between the two.  There is no reason for the Commitment model to be
  attempting to validate the other two, so the relevant declaration has
  been removed.


v0.22   2017-07-25

* Issue a warning for events with no resources

  The most common mistake which new users make is to create an event
  but give it no resources at all.  They are then puzzled as to why
  no-one can see it.

  The system will now display a large warning message as soon as they
  save an event with no resources.

* Warn if rooms or people are double-booked.

  Similarly, the system now checks whilst a user is adding resources
  to an event, and highlights any people or locations which are explicitly
  double-booked.  That is - have a direct commitment to an overlapping
  event.

  This feature won't pick up indirect commitments - via a group - so
  it won't tell you if the student you want is in a lesson.  This is
  too computationally expensive to perform on the fly, but the existing
  flagging of clashes should pick these up and put a red dot on the
  lessons.

  The main purpose of this is to point out to people that the ICT room
  (or whatever) which they've attempted to book is already booked
  by someone else.


v0.21   2017-07-21

* Provide ical feeds by UUID

  Originally, ical feeds were specified by staff initials, then later by
  element ID allowing feeds to be taken for any element, not just staff.
  This is slightly insecure in that element IDs are allocated sequentially,
  so any reasonably small integer would result in some sort of feed
  although it was impossible to predict what you'd get.

  This release adds a random UUID to each element record and ical feeds
  can now be requested by UUID as well.  For security, the system administrator
  can choose to turn off the previous methods, meaning only the UUID one
  will work.  Guessing a UUID is pretty much impossible.

* Pre-formatted ical feed URLs.

  Since UUIDs are long and potentially very boring to type, the system
  now also provides pre-formatted feed URLs which can be copied to the
  user's clipboard and then pasted into whatever calendar program is in
  use.  These will be found on each element's "Concern" page - accessed
  by clicking on one of the coloured boxes down the left hand side of
  the page.

  Several different URLs are provided for each item, allowing them to get
  all their events in one go, or split out such things as cover and
  invigilation.  This means they can choose to display these items in
  a different colour from their normal events.

  Additional system settings have been provided to allow the system
  adminstrator to set the base URL to use, and whether the URLs should
  begin "http:" or "https:".

* Split concerns page into tabs.

  With the addition of the URLs to the existing page about each Concern,
  the length of the page became excessive.  It has been split into several
  tabs to make it easier to use.


v0.20.6 2017-06-30

* Display staff initials on invigilation (and other) events.

  At the request of Abingdon School, it is now possible to switch
  on the display of staff initials for events in the main calendar
  display.  This is done on a per-concern basis and defaults to off.

  Note that it will display only staff directly connected to the event.
  Staff indirectly connected by way of a group membership will not
  be included (far too computationally expensive).
  
  The primary function is to enable a quick view of who is doing
  each invigilation slot, but it may also be of use to students wanting
  to see who is teaching each lesson.

  To switch on, click on the relevant concern in your left hand column
  and tick the "List teachers" box.  You can also set it to default to
  on by clicking on your user name (top right) and ticking the box
  there.  Any new concerns you create will then have the box pre-ticked.

* Fix to auto-update of pending requests count.

  The URL used to auto-update a user's pending request count was slightly
  wrong, meaning it worked only if the user was on the main screen.
  This has now been corrected so it will work anywhere.

* Fix to testing environment.

  The request notification code implemented in the previous release had
  an edge case which cannot arise in the development or production
  environments but can be triggered in the test environment where things
  are potentially done out of sequence.  Specifically - attempting to
  update an event without first starting to edit it.  This led to one
  test failing.  The code has been fixed so the test no longer fails.


v0.20.5 2017-06-21

* Add reply-to to invigilation e-mails.

  The system generates e-mails to warn people when they have invigilation
  slots.  Some users reply to these without thinking, which has no useful
  result if it goes to the system.

  Added a reply-to field so that such replies will go to a real person.


v0.20.4 2017-06-20

* Notify impatient users of request cancellations.

  Some time ago a facility was added whereby users who control resources
  could request instant e-mails each time someone put in a request for
  that resource.  It's an opt-in facility, controlled by a flag in
  the user record.

  This release adds the means to notify the same users if a pending
  request is cancelled - either because the requester deletes the
  individual request, or because the whole corresponding event has
  been deleted.  Note that this happens only for requests which have
  not yet been approved.

  It is controlled by the same flag in the user record, so you can't
  choose to have one and not the other.

  Note that the notification e-mails are sent out only at the end of
  an event-editing session.  A user can add and remove the same resource
  as often as he likes during one edit and no e-mails will be sent.
  Only when the user clicks "Update" does the system send either
  kind of e-mail.

* Update pending request count in the main screen.

  Resource administrators get a count of outstanding requests, "(4)"
  and the like in their top menu bar.  Until now, this was updated
  each time they interacted with the application, but not otherwise.

  This release adds a 5 minute update.  Every 5 minutes the front end
  polls the back end to see if the count has changed, and if it has then
  it updates the display.


v0.20.3 2017-06-16

* Remove date/time from heading in invigilation notification e-mail.

  It was unnecessary and confusing.  Removed.


v0.20.2 2017-06-09

* Add an indicator of the time.

  A long-standing request that turns out now to be very easy.
  Add a little red line showing the current time.


v0.20.1 2017-06-07

* Fix settings dialogue.

  A small error was discovered which got into the system at v0.19.
  It prevented the system administrator from accessing the global
  system settings dialogue.  This release fixes that problem.

  
v0.20   2017-06-06

* This release implements filters in the main schedule display.

  Users can now choose to reduce what they see by filtering out events
  by event category.  If they have any filter in effect then a red marker
  appears at top left to remind them that it is on.

  Administrators can also add in event categories which would not
  otherwise be visible - those with the visible flag not set.  In a
  default installation this is just the "Hidden" event category.
  This can be useful in order to track down inivisible events belonging
  to another user.

* The sort order for multiple events at the same time has been improved.

  Prior to the last release, concurrent events were displayed in alphabetical
  order.  In the last release this was changed to have them displayed in
  order of the relevant resource.  Now both are used - they are sorted
  first by resource and then alphabetically.


v0.19   2017-05-22

* The main change in this release is that the version of FullCalendar
  used has been updated to the latest available - 3.4.0.  Previously
  Scheduler was using 2.0.2.  This has enabled various other enhancements.

* When events are being viewed for multiple resources, the left-to-right
  ordering has historically been by alphabetical ordering of event title.
  This can lead to a less than clear display.  From this release, the
  left to right ordering is dictated by the resource involved, so resource
  A's events will always be to the left of resource B's events, etc.

* It is now possible for the system adminstrator to enter period times in
  the system and for these then to be displayed to individual users as
  background events (pale shaded areas) on the display.  More than one
  set can be entered (e.g. for a main school and a junior school) and
  each user can choose which to see.

* If a user has period times switched on and the user then tries to
  create a new event within a configured period - either by clicking
  within a period or by dragging a resource onto the calendar - then
  the default times for the new event will now default to the period's
  times.  Clicking and dragging to create a new event with duration is
  not affected and will continue to work as before.

* The framing of the calendar has been tightened up and the user should
  no longer find that there are two simultaneous scroll bars.  The calendar
  resizes as far as it can to fit the user's chosen window size.

* A new view is available in the calendar display.  Called simply "list"
  it provides a nicely formatted list of all the chosen events in a month.

* The automated test suite for the application had fallen rather behind
  developments.  It has been updated and now runs without error.


v0.18.6 2017-04-09

  Two small fixes

* Handle duplicate staff initials in ical feed.

  It is possible to request an ical feed for a member of staff by
  specifying either the staff member's element ID (the preferred
  way) or for reverse compatibility with an earlier implementation,
  by specifying the staff member's initials.  The latter failed
  if the school configured two members of staff with the same initials.
  The system would always pick the first such member of staff, which
  generally would be someone who had left.

  The database query has been enhanced to specify "current: true"
  in addition to the existing criteria, so as to pick the later
  member of staff.

  This has the side effect that it is no longer possible to get an
  ical feed for an ex-member of staff by means of his or her initials.
  If you really need that, then use the element ID.

* Re-position invigilation flag in some views

  When handling invigilation slots, the system shows the status of
  each slot with a little red/yellow/green flag.  In some views this
  ended up in a less than ideal place.

  This release adds view-specific code to position the flag to be
  visible in each view, and as far as possible, not to cover up other
  information.


v0.18.5 2017-04-30

  Still drawing together strands and tidying up.

* Update the seed data used for new installations and the demo system
  adding items to enable the demonstration of the full facilities
  of resource requests.

* A new flag on the reporting page allows control of whether or
  not entries should end with a full stop.

  When the legacy calendar data were imported into Scheduler in its
  first school, the entries were rather a mess.  Some had a full stop,
  some didn't, and at least one ended in "  ."  (Two spaces and then
  a full stop.)  To produce a consistent report for printing, the
  reporting code massaged all the entries to end in a single correctly
  positioned full stop.

  Now Scheduler is in use in another school, and they would prefer
  not to have the full stop, so it's now a configurable item on
  the report generation page.  Once you've made a choice it will
  be remembered and used by default on subsequent runs.


v0.18.4 2017-04-30

  Quite a bit of code tidying has been done in this release to
  facilitate the imminent migration to the latest version of
  FullCalendar.

  Code for preparing events and sending them to FullCalendar in
  the front end used to be spread between the Event model and the
  Events controller.  It has now all been moved to a Service Object
  and unified.  The number of entrypoints in the JavaScript module
  which drives FullCalendar has been greatly reduced, and the code
  has been simplified.

  Actual changes visible to the end user are:

* When a resource attached to an event requires approval, it is also
  possible for the resource administrator to set up what is called
  a Prompt Note.  This prompts the end user to provide additional
  information relating to the request - e.g. ancillary information
  about catering.  In previous releases, the software did not
  always set this up correctly.  Provided the user simply added the
  resource to an event then all was well, but if the user dragged the
  resource onto the calendar, or set up the resource to auto-add to
  new events then the note did not get added.  It now gets added in
  all circumstances.

* Such notes are now visible only to the requester and the resource
  administrator unless the requester chooses to make them more
  generally visible.

* Scheduler allows the user to set up two kinds of events - timed
  events and all-day events.  All-day events appear across the top of
  the display and last an integer number of days.  Timed events appear
  in the main area of the display and have a specific start and end time.

  It is possible to enter a timed event which lasts more than one day.
  E.g. starting at 08:30 on Monday 1st, and running to 16:30 on
  Tuesday 9th.  Until now this resulted in a vertical coloured block
  running through every day's display for that period.  More than a
  couple of these made the display look very messy.  This has not been
  a problem at Abingdon because multi-day events have always been
  entered without times (or perhaps, users learned to do that to keep
  the display clean).

  At Dean Close school however, it is desired to put the events in with
  times, and so Scheduler's display code has been made a little more
  intelligent.  Where a timed event lasts more than one day it will be
  displayed in the all-day section of FullCalendar's display (at the
  top) but with the start time pre-pended to the first part of
  the event's display.  Thus for the example above, the event would
  appear as running from Monday to Saturday in the first week, with
  "(08:30) " before its name, and then from Sunday to Tuesday in
  the second week, without the extra time field.


v0.18.3 2017-04-27

  Another two tiny fixes to problems which became apparent during
  testing of currently ongoing development work.

* When a user is creating an event, the date/time fields provide
  a pop-up box allowing the information to be entered by means of
  clicks etc.  (Or the date/time can be entered simply by typing text.)

  When editing an existing event the same facility should be available
  but wasn't.  This release re-instates that missing functionality.

* It is possible that a user will try to add a concern to the left
  hand column even though the relevant item is already there but
  un-ticked.  In this circumstance the natural thing for the program to
  do is simply to tick the existing item and update the display.

  This is what it now does.


v0.18.2 2017-04-26

* A hotfix to a typo in the UserMailer object.

  All attempts to confirm requests for resources were failing because
  of a typo (missing letter) in the user mailer.  This release corrects
  that problem.


v0.18.1 2017-04-22

  Some more tidying up following on from yesterday's big tidy up.
  The tidier things get, the more obvious the remaining items become.

* Each installation needs its own secret key for securing the sessions
  between browser and server.  This is a long pseudo-random hex string
  generated using the command "rake secret" in the application's root
  directory.

  Up until now, each installation has had its unique secret edited into
  the file config/secrets.yml, which is the wrong way to do it.

  From this release, the secret goes in ~/.profile, and the config/secrets.yml
  file picks it up from the environment, meaning that the same file
  can be used on all installations.  This is how it should always have been
  done.

* The file utils/checkclashesahead existed in a slightly different
  (corrected) form on Abingdon's installation but not in the main
  repository.  Pulled back into the main repository.

* Likewise the file lib/import/school/permitted_overloads.rb on
  Abingdon's installation differed from the main repository.  Pulled
  back in.


v0.18   2017-04-21

* Improved the iSAMS data import code to cope with more than one school.

  The original implementation of Scheduler imported timetable data
  from a single-school MIS called Schola.  It did this by taking
  all the individual staff and pupil timetables and from them
  reconstructing the complete timetable and set lists.

  The next implementation imported data from SchoolBase by means of
  direct access to SchoolBase's database tables.  This version of
  the importer still exists, but it's a single large (5100 line)
  Ruby program.  It would need tweaking to work for a different school.

  The next requirement was to import timetables from iSAMS and the
  opportunity was taken to re-write the importer as a modular
  implementation.  It now consists of 41 separate Ruby source
  files plus a few specific to each school each of which does
  a separate specific task.  They are split into three hierarchical
  groups in separate directories:

    * General code regardless of MIS (18 source files)
    * iSAMS-specific code (23 source files)
    * School specific code (varies - 3 - 7 files)

  There remains the task of taking the SchoolBase importer mentioned
  above and adding it in to this new structured implementation.

  Although the code above was always intended to work with more than
  one school, the acid test came when it was time to install it at
  its second school.  Overall the results were good, but a small
  amount of cleaning up was required.  Some code was in the iSAMS
  area which should have been in the School area, and a false
  assumption (that the three-letter abbreviation of Thursday is
  always "Thu") came to light.

  This release pulls together all the tweaks into a version which has
  been tested to work well at both the current iSAMS-using schools.

  When doing a new installation, or installing this release for the
  first time, it is necessary to go into the directory:

  ~/Work/Coding/scheduler/lib/import/school

  and type "./linkup <School name>" in order to pick the right
  school-specific code files.


v0.17.5 2017-04-14

* And do exactly the same for the LetsEncrypt config files


v0.17.4 2017-04-14

* Ignore the LetsEncrypt log files

  Continuing the theme of tidying things up, the only thing which
  changes here is the .gitignore file.  It now specifies that the
  contents of the directory LetsEncrypt/logs should be ignored, although
  the directory itself should be kept.


v0.17.3 2017-04-14

A bit of a drawing together of a few loose strands.

* Don't complain about inconsistent data from the iSAMS database.

  It's becoming steadily more apparent that the iSAMS database lacks
  basic consistency constraints.  We're getting membership records
  for pupils which are apparently currently active, even though the
  corresponding groups are currently inactive.  Stop complaining
  about them.

* In the course of testing the above, an instance of a hard coded
  path was found in the script which invokes the import process.
  An appropriate environment variable already exists, so the script
  was amended to test for it and then use it.

* The seed data used for setting up new systems and the demo system
  has been enhanced to include information relevant to invigilation.
  For the demo system, a period of suspended lessons is created to
  allow the feature to be demonstrated.


v0.17.2 2017-04-10

* Add the means to edit the number of invigilators per room.

  Previously one set a default number of invigilators for an exam
  cycle and this propagated to all the invigilation slots.  Each slot
  could then be amended individually, but there was no way to do it
  for all the slots in a room.

  It is now possible to set a default for the exam cycle, which will
  be copied as the default for each new room record but can be amended
  in the course of creating the room record, or later.

  If the number for a room is altered after the actual invigilation
  events have been generated then a re-generation of the events will
  alter the individual invigilation event records provided:

    1. The individual record has no invigilators allocated
    2. The individual record has not been set to 0.

  The idea is to preserve information which has been actively entered,
  whilst allowing bulk changes where possible.

* Fix a bug whereby events which were moved did not change name.

  In the original implementation, all invigilation events were called
  simply "Invigilation".  This was later changed to "<Room no> Invigilation".
  Thus one would have, for instance, "M116 Invigilation", the idea
  being to make it really obvious to the end user where he or she
  was meant to be.

  If however a set of invigilations were moved to a new room, the
  name did not change.  The event would continue to be called
  "M116 Invigilation" even though it was now in M115.  This release
  fixes that problem.


v0.17.1 2017-04-06

* Add the means to check for events clashing with invigilation slots.

  These can arise either because the exams administrator has over
  ridden the list of free staff being offered, or because other
  events have been added since the invigilation slots were populated.

  The report can be displayed on screen, or e-mailed users flagged as
  being exam adminstrators.  The latter can be done automatically as
  part of the overnight processing.

* Exam processing has been renamed as Invigilation processing, since
  that's what it actually deals with.  As a result, the documentation
  is now at:

    https://xronos.uk/invigilation.html


v0.17   2017-03-22

* This release implements a major new feature - exam invigilation.

  For details on how to use it, see the on-line documentation at:

    https://xronos.uk/exams.html

  When installing this version, it is necessary to migrate the
  database (rake db:migrate) re-compile the assets (rake assets:precompile)
  restart the application, and then edit the system settings to add
  the system's domain name and source e-mail address.


v0.16.1 2017-02-27

There are no code changes in this release, just a change to this
release notes file and the version number.  One item got missed
from yesterday's release notes file.

* Re-check user records at login to see if they match a known person.

  Up until this release, when the system encountered a new user logging
  on it checked to see if the user's e-mail address matched that of a
  staff member or a pupil.  If it did then the two were linked and the
  user was treated as a proper user.  Otherwise it was treated much the
  same as if it wasn't logged on at all.

  A problem arose from this, in that it could happen that a user logged
  on before the corresponding staff or pupil record had been created.
  The user record would be created without a link, and would be treated
  ever after as a guest.  It was necessary to delete the user record
  and let it be created again in order to establish the link.

  As of this release, guest users are checked every time they log in to
  see whether a matching staff or pupil record has sprung into existence.
  If it has, then the two are linked, and the user changes status from
  being a guest to being a proper user.


v0.16   2017-02-26

* Adds support for creating a new installation from scratch.  After
  initialising an empty database, seed data will provide the minimal
  records needed to get going.

* Allow multiple public calendars.
  Previous versions assume that just the calendar called "Calendar" is to
  be public.  This worked fine at Abingdon School, but Dean Close School
  want three public calendars - main school, prep school and pre-prep
  school.  The system now allows an arbitrary number of public
  calendars, and which ones are public is controlled by a flag on the
  relevant property.

  If an installation has 0 or 1 public calendars then the display shown
  to non-logged-on users will be exactly the same as before.  If there
  are 2 or more public calendars then even users who aren't logged on
  will get a column down the left hand side where they can pick which ones
  they want to see.  They still can't add or remove anything from this
  list, but they can switch them off and on.

* The login method to be used is now configurable.
  There is a new item under the Settings menu allowing different kinds
  of login to be used.  The default remains "Google login" which was
  the only one before.  The only new one which has been implemented
  is "Demo mode", which allows anyone with a Google account to log in.
  This is used on the demonstration system.

* It is now possible to choose a preferred colour for the public
  calendar(s), instead of it/them always being green.


v0.15.4 2017-02-15

* Remove spurious column in user panel at LHS.


v0.15.3 2017-01-18

* Allow recurring events to be specified on the first Wednesday, second
  Thursday, last Friday etc. of a month.  Also allow events to be specified
  outside term time.

  For full info, see import/recurring/README


v0.15.2 2017-01-09

* Improve diagnostics when parsing recurring event files.

  One of the diagnostic messages produced when an error was found in
  a recurring events file was difficult to understand when taken in
  isolation.  This release improves the wording to make it clearer.


v0.15.1 2017-01-05

* Fix suspension status of assembly shared between year groups.

  The code to suspend lessons based on the suspension records in the database
  was looking at only the first group of pupils attached to the event.
  This was fine for lessons (where there is just the one group) but
  produced a slightly erroneous result for assemblies.  The obvious
  example was the 4th + 5th year assembly on 16th January, which was
  suspended because of the 5th year mocks.

  The code now checks *all* the groups attached to the event and suspends
  the event only if all the affected year groups have a suspension record.


v0.15   2016-12-22

* Show membership records for groups.

  The membership of groups has got quite interesting, in that iSAMS makes
  an attempt to handle the duration of memberships for activity groups
  (but not other groups).  Unfortunately, it throws away historical
  information so a certain amount of caution is needed in the data import.

  To enable a clearer view of what exactly is going on, element display
  for groups now shows not just the current and historical members, but
  also all the individual membership records (on a separate tab) so one
  can see the detail of what is going on.  Some OH groups now have
  *future* members - members who will be in the group when the new term
  starts.

  This has involved a complete re-work and simplification of all the
  panels in the element display screens.

* Clash checking has been enhanced in two ways.

  1) The events to be checked are now driven by a flag on the
     eventcategory record, where previously they were hard-coded to
     be Lesson and Other Half events.

  2) Suspended (non-existent) events are not clash-checked, but it
     was possible for an event to be clash-checked - and acquire
     a note and flag - and then later to be suspended.  The code will
     now spot such an event and remove the note/flag and the next clash
     checking run.

* It has become apparent that the iSAMS database can become inconsistent
  in the area of cover records.  Currently it contains nearly 300 cover
  records with no corresponding lessons.  The importer now reports
  merely a count of such records rather than logging each one individually.
  (If you want them logged individually, remove the --quiet switch from
  the invocation of the utility.)

* An error has been fixed in the area of Other Half groups which were
  loaded from iSAMS with an end date already in place.  On the appropriate
  date (the day after the indicated end date) the groups should have been
  marked as no longer current in Scheduler.  This was not happening and
  the loader has been corrected so now it does.


v0.14.1 2016-12-13

* Gnashum, frashum, Dick Dasterdly.  One little unwanted <br> snuck through.


v0.14   2016-12-13

* Add a multicover flag to staff records.

  Under certain circumstances, one wants to be able to assign the same
  person (possibly not a real person) to do more than one cover at the
  time, or do to a cover when apparently involved in something else.

  This release adds a multicover flag to the staff record.  Anyone
  with this flag set will not generate warnings if over-committed for
  cover.

* Updated permitted_overloads.rb

  The permitted_overloads.rb file in the system was heavily out of
  date and thus ineffectual.  This new one does more useful work.


v0.13.2 2016-12-01

* Correction to previous release.

  The previous release was checking the value of the active for each
  member of staff as calculated by the loader.  It should have been using
  the value stored in the database.  It is possible for the former to
  be false and the latter to be true (but not the other way around) as
  indeed does happen when a member of staff doesn't really exist but
  needs to be covered.  This is used for setting up Invigilation.


v0.13.1 2016-11-30

* Add an extra check on cover of inactive staff.

  iSAMS doesn't really understand the concept of invigilation, so it's
  been done by setting up dummy lessons with dummy members of staff and
  then arranging cover for them.  The dummy members of staff weren't
  active, which caused the cover importer to trip over the relevant
  records.

  Said members of staff now are flagged as active, but this release
  fixes the importer so it won't have the same problem in future.


v0.13   2016-11-29

* Removed "New user" button from user list screen, since it didn't actually
  work and it's not how users are created.

* The dialogue box on the top of the left hand column in the main scheduler
  screen now auto-submits when the user selects a value.  It's not obvious
  to the casual user that this is implemented as a form (with just the
  one visible field) so some were baffled as to how to submit it.

* In the event editing screen, the field to add resources to the event
  now has an "Add" button to the right of it, for those who prefer to have
  something on which to click.

* A significant re-work of the facilities for looking up user records,
  including the addition of a "Search" box in order to jump straight
  to a particular user.


v0.12   2016-11-21

* Added edit_all_events and subedit_all_events to user records.

  Two new flags on the user record which can be set and cleared by
  administrators.  The former allows a user to edit any event in the
  system as if he or she was the owner.  The latter works similarly
  except it confers only sub-editing capability - as if the user
  was the organiser.


v0.11.2 2016-11-18

* A little wrinkle arose in the iSAMS data import this morning.  A new
  node has been added to the Day node under the Week specifications.
  Nodes are nested as follows:

    <Structure>
      <Week>
        <Days>
          <Day>
            <Periods>
              <Period>


  but the new node has been added in parallel to Periods and with the
  name <Day>, giving:

        <Days>
          <Day>
            <Day>
            <Periods>

  which isn't invalid XML, but is more than a little odd.  The loader
  was looking inside <Days> for <Day> and finding it more than once.

  The XML import code has been tightened up to ignore the inner <Day>
  node (which has a completely different meaning from its parent).

* In the course of diagnosing the above problem, a left-over debug
  message was found in app/models/element.rb and removed.


v0.11.1 2016-11-17

* A slight error in the previous release meant that ordinary users could
  no longer create events.  Once they'd created them, they could edit them,
  but they couldn't put in the minimal information needed to create them.


v0.11   2016-11-17

* Added the means for event organisers to be enabled as sub-editors.

  Because Abingdon's live database contains a lot of events - particularly
  calendar events and sports fixtures - which have been entered by one
  individual rather than by their organisers, a means is needed to allow
  the organisers to attach team lists to the events.  Such lists are
  easily generated in iSAMS and then migrate over to Scheduler automatically.

  This release adds the facility whereby the individual listed as an
  organiser can do minor editing of the event, even though he or she
  does not own it and would not otherwise have permission.  Changing
  the title or time is not permitted, but adding and removing resources
  (except those subject to the approvals process) is.

* An extra batch job has been added to look further ahead when checking
  for lesson absentees.  It is intended to be run in the evening and by
  default looks ahead by 2 weeks, and then processes 4.  This means it
  will always slot in just after the main job which process 2 weeks.


v0.10.4 2016-11-16

* Fix a bug in the group loading code, whereby a public group was not
  correctly flagged as being available to all users.

* Add a maintenance method to fix the 8 groups currently in the system
  which have this problem.


v0.10.3 2016-11-15

* By the use of a cache, the clash checking processing has been speeded
  up by a factor of approximately 4.  This means it now easily fits
  in the available time slot.

* The overnight run now defaults to processing 2 weeks - the current
  week and the following one.

* All day events now show as "all day" in the clash check reports, rather
  than as "00:00 - 00:00" as they did before.

* There is an extra option on the clash check utility "--ahead N" which
  allows it to be run N weeks ahead.  By default and without this option
  it starts with the current week.

* A small fix has been applied to the code which selects notes for display.
  Normally this is done simply on the basis of whether a user is staff,
  pupil or other, but some users (those who approve commitments) can get
  to see extra.  A slight error in the d/b query code (an INNER JOIN which
  should have been a LEFT JOIN) meant that in exceptional circumstances
  such users failed to be shown the odd note which they should have seen.


v0.10.2 2016-11-12

* At Niki's request, changed the default for staff to have permission
  to create public groups.  Ran a command line task
  ("User.set_initial_permissions") to give all existing staff this
  permission bit.


v0.10.1 2016-11-11

* The sole change here is to this release notes file.

  The double-booking code can also notify staff by e-mail of clashes
  which have been identified.  By default it doesn't, but staff can
  choose to receive notifications in three ways.  There are new flags
  on the user record, and they edit them by clicking on their name
  on the top right of the screen in the usual way.  Admin users can
  also edit them on behalf of other users.

  a) Immediate notification.

     The user gets a notification at the end of the clash-checking run
     of anything which has changed and affects his or her lessons.

  b) Daily notification.

     The user gets a daily e-mail of upcoming clashes.

  c) Weekly notification.

     The user gets a weekly summary e-mail of upcoming clashes.


v0.10   2016-11-11

* Add a favicon.ico file with something in it, plus similar files for
  Apple devices which want an icon for their desktops.

* Checking and flagging double-booking of students.

  This is a major new feature which was always intended to be one of the
  main points of Scheduler.  Provided you store all your schedule information
  in one central place (Scheduler) you can then automatically flag up
  apparent double-bookings.  This in turn means that staff can potentially
  be told automatically when individual students are going to be missing
  from their lessons.

  The processing is fairly compute intensive (1-2 hours to process 1
  week of data) so needs to be run overnight.  Cron jobs are included to
  do the work.

  Where such clashes are identified, the affected lessons are flagged with
  a red marker in the main Scheduler display.  Clicking on the lesson
  will then display full details of who is likely to be missing and why.
  This information is visible to staff only - pupils will see neither
  the red marker nor the explanatory note.

  Scheduler can work only on the information which it has.  Music lessons
  for instance are not entered into Scheduler and so will not be handled
  by the clash checker.  As soon as they are entered, they will be checked
  in the same way.

  There are also currently some false positives caused by inaccurate
  data having been entered - e.g. on Thu 17th Nov, an all-day event has
  been entered entitled, "Product Design in Action, Warwick University".
  Unfortunately, it has been entered as involving the whole of the sixth
  form which it probably doesn't.  As for any trip, a custom group
  should be created in iSAMS, and then attached to the event.  Once this
  becomes the normal way of working the clash information will become
  fully accurate.  The existing analysis of this event is still useful,
  because it will at least flag the existence of the event to teaching
  staff.

  The flags should also serve to polish and correct the Other Half
  activity lists.  Quite a few pupils seem to be booked for two
  simultaneous OH activities.


v0.9.1  2016-11-10

* A hotfix for a problem which wasn't causing any issues from the users'
  point of view, but which led to errors in the log file.

  When a user is adding resources to event, he or she can potentially
  send back an empty field, or an invalid name, for the selected resource.
  This was leading to an error in the back end, because it did its checks
  in the wrong order.  Nothing appeared out of place to the user, but
  it made for a messy error log.

  Now checks for non-existent elements before attempting permission
  checks.


v0.9    2016-11-04

* Just one extra feature.  Administrators can now edit users' concerns
  through the GUI, rather than having to fall back to the command line.
  This is generally used to give (or take away) extra permissions
  for the user relating to an item - e.g. to give a user control
  of events using a specified resource.

  To use this, go to Menu => Users and choose Show for your required
  user.  This will give a list of his or her current concerns, and then
  you can click "Edit" next to the one which you want to change.

  Note that the names of a couple of flag fields in the underlying
  database are slightly misleading.  In the database, these are called
  "owns" and "controls".  They work as follows:

  "owns" means the user approves requests for a resource.  Any resource
  with one or more such user will need to go through the approvals
  process when requested.  In the GUI, this is labelled as "Control"
  because that's what the user is really doing.

  "controls" is an extra permission bit, intended for maintenance of
  events.  If a user has this bit set on a concern, then he or she can
  edit any event which uses that resource.  This appears in the GUI as
  "Edit any".


v0.8    2016-11-03

* As noted in the release notes for v0.7, the improved visibility of
  group membership in that release led to the detection of a long standing
  problem.  Where pupils are removed from the school in iSAMS, but not
  from their corresponding groups, then later removals failed to
  propagate into Scheduler.

  The algorithm for removing pupils from groups in Scheduler has now
  been corrected, and it will remove them even if they no longer
  appear in iSAMS's list of current pupils.


v0.7.1  2016-10-28

* Purely cosmetic change.  Puts resources for an event in the event
  display screen back into columns.


v0.7    2016-10-28

* It is now possible to view all locations which have an administrator.
  Use Menu => Models => Locations => Owned to get a list, each of which
  can then be viewed in detail.

* Subjects are now loaded into the Scheduler database as objects which
  can be displayed.  All lessons, teachers and teaching groups are linked
  to their corresponding subjects.  It is therefore possible to display
  all the lessons for a particular subject in the calendar view, or to
  generate a report for any chosen subject.

* Teaching groups are now linked not only to their subjects, but also
  to all their teachers, meaning you can see who teaches each group
  without having to scan the group's schedule.

* Added general display facilities for all elements, allowing detailed
  information to be obtained on any student, staff member, room etc.
  This facility is available only to members of staff - not to pupils.
  The display pages link together, so you can look at a teaching set, then
  at any of its students, then at any of his OH groups, etc.  Access to
  this linking is controlled by a flag (can_roam) on the user account.
  This flag is currently set to true only for users identified as staff.

* The above general display can be accessed either by clicking on an
  element being monitored in the left hand column and choosing "Full details",
  or by clicking on any event, and then on an element being used by that
  event.  Un-privileged users (e.g. students) can view only their own
  personal details.

* A long-standing bug in the iSAMS API means that it is not possible fully
  to reconstruct the timetable from the information therein.  Lessons
  taught by form group (tutor groups in Abingdon's case) cannot be linked up
  to the corresponding group without some extra information from outside.
  The way this has been handled in the past was simply to link the lesson to
  the tutor group, but this has led to steadily more problems.

  Lacking a fix from iSAMS (and they have indicated very forcefully that they
  have no intention of fixing it) a better workaround has now been implemented.
  The missing information is now re-constructed and all the missing teaching
  groups (with names like "1M Ma") are generated internally as part of the
  data import process.  They can then be treated as full teaching groups,
  with all the necessary ancillary information.

* The "active" flag in the iSAMS d/b for OH groups seems not to be used.
  All groups have it set to false all the time.  The loader has been enhanced
  to ignore it and instead to a date-based calculation to decide the active
  groups.

* The iSAMS database seems to lack basic integrity checking, in that pupils
  who have left the school can still be listed as members of groups.
  The loader was already correcting this as part of the loading process,
  but because of the sheer quantity, it now doesn't complain about them
  unless the --verbose option is given.

  At a late point in testing, one extra result of this was noticed.  Where
  a pupil has left the school and iSAMS has removed him from the pupil
  lists before removing him from his sets, the loader now copes fine but
  there remains a logic error in the loader - because the student became
  an ex-student *before* leaving his sets it then doesn't remove him from
  his sets on subsequent runs.  The reason for this is fully understood
  and it will be corrected in the next release.  It was too late to add
  it to this one.  The problem is a long-standing one and just hasn't been
  noticed up until now, because it wasn't so easy to check the exact
  membership of groups.

* Eras have acquired a short name, for ease of display in tabs.


v0.6.2  2016-10-21

* Hotfix to fix display of unapproved events.

  Code was added in v0.2 of the software to allow requesters to see
  events in the context of a requested resource even before the
  request was approved.  Users were getting confused by not being
  able to see them.
                   
  Unfortunately this led to a display problem in the case of one very
  edge condition, resulting in an event not being displayed.  This
  release fixes that problem.


v0.6.1  2016-10-12

* Hotfix to restore missing file.

  I accidentally deleted a file in the previous release.  It is used
  solely for fetching data direct from iSAMS's database, so didn't
  show up as missing until this morning's data fetch.

  Now restored from previous commit.


v0.6    2016-10-11

* Add an extra field to OTL's timetable export file.

  OTL requested an extra column on the CSV file of timetable events
  which is auto-generated for him each night.  This contains the
  period number for each event, enabling the whole lot to be sorted
  into chronological order.

* Suppress warning message about invalid student IDs.

  The iSAMS database lacks basic integrity checking for students who
  leave, with the result that they can have left the school but still
  be listed as members of certain groups.  The warning messages for
  teaching groups were suppressed in an earlier release.  This one does
  the same thing for OH groups.


v0.5    2016-10-04

* No code changes at all.

  This release exists solely to test the migration to the new source
  repository - repository.xronos.uk


v0.4    2016-10-02

* Import utility can now set staff records to active

  The importer has always taken a very conservative approach to changing
  the "active" flag on records.  Historically it has set it on
  a best-effort basis, and then never changed.  This has led to one slight
  problem, in that staff get added in an incomplete fashion to iSAMS
  (resulting in a record in Scheduler with active set to false) and then
  don't automatically change when the record is completed.

  This became apparent when Helen K Whitworth was assigned a cover,
  and it turned out she had no timetable in Scheduler because she wasn't
  active.  On investigation, 6 other members of staff (mainly SHSK, or
  peripatetic teachers) were in the same position.
                        
  The method now is to allow the flag to be changed from false to true,
  but never the other way around.

  NEVER change a record's active flag from true to false!


v0.3    2016-09-30

* Suppress a warning message generated by the iSAMS => Scheduler import
  utility when a tutorial involves no teaching staff.

* Add students to the list of resources which can be associated with
  a tutorial.

* Add a new utility - utils/checkrecurring - which can be run after
  changes are made to recurring events in YAML files.  It uses exactly
  the same code as the import utility, but doesn't effect any changes
  and runs in only a few seconds.  It checks for both badly structured
  YAML, and unidentifiable resources.

  As it stands, the utility reports the files which it is checking.
  If the traditional UNIX philosophy of keeping quiet unless something
  goes wrong is preferred, then edit utils/checkrecurring and add --quiet
  to the invocation of the utility.


v0.2    2016-09-28

Changes:

* If a user has a resource selected for display but currently disabled -
  that is the tick-box is unticked - then adding the same resource a
  second time will cause it to be displayed.  This is because when a user
  has a lot of resources selected, he or she may not notice that the
  required one is already there.  The requirement is clearly to show
  it, so show it.

* Reduce notification e-mails.
  The system generates daily e-mails to approvers of resources reminding
  them about pending requests.  When checking for pending requests, the
  system was previously including rejected requests which could lead to
  empty reminder e-mails.  Now only generates e-mails about genuinely
  pending requests.

* Improve display of pending requests.
  Before a request for a resource has been approved, it does not appear
  in the general display for that resource.  Thus, if for instance someone
  has requested that an event be included in the calendar, it doesn't actually
  appear in the calendar until DJD has approved it.  It is however visible,
  greyed out, to DJD and any other approver.

  This led to a bit of confusion, in that the requester too couldn't see it
  in the context of the requested resource.  He or she could see it as
  one of "My events", and in the context of any of the other resources
  used, but not in the context of the one awaiting approval.  Unfortunately,
  some users were turning off all their display except for the requested
  resource and then getting puzzled at not being able to see the event.

  The rule now is: a pending request for a resource will be displayed in
  the context of that resource to:

    Approvers of the resource
    Admin users
    The original requester

* Various chronological development notes have been added in the notes
  directory.



v0.1    2016-09-26

The first release done under the GitFlow convention.  Very many things
happened before this release, but for calibration the last such change
was:

* Dump the entire timetable to a CSV file for analysis by OTL.