seantis.reservation 1.4.0

Plone addon to reserve stuff in a calendar.

Not a replacement for Outlook or Google Calendar, but a system to manage reservations on the backend and to provide them on the frontend.

Update to 1.2.0

Warning: The seantis.reservation release 1.2.0 changed a lot internally, which is why you can’t directly upgrade from seantis.reservation releases prior to 1.0.12 (September 27th, 2013) to the 1.2.0.

If you do have such an old release, install seantis.reservation 1.1.5 first, run all upgrade steps, and then install 1.2.0.

Introduction

Originally developed together with the municipality of Zug, Switzerland this Addon aims to combine differing reservation systems into one flexible solution.

It does so by providing a way to deal with the following usecases:

• Manage meeting rooms in a company. Users reserve the rooms themselves without an authority confirming/denying their reservations.

• Manage nursery spots. Parents apply for a spot in the nursery for their kid. Someone at the nursery goes through the applicants and decides who gets the spot. Parents may add an application to the waitinglist.

• Manage community facilities. Citizens see the availability of facilities online and call the municipality to reserve a facility. The management is done internally (maybe through an already existing software). The addon is only used for display.

Screenshots

Build Status

Test Coverage

Latest PyPI Release

Requirements

• Python 2.7

• Plone 4.3+ ( Plone 4.1 and 4.2 had to be dropped, sorry )

• Linux / Posix ( Windows may or may not work )

• Postgresql 9.1+ ( Older versions DO NOT work! )

• 1024MB+ RAM

seantis.reservation is tested using IE8+, Chrome, Firefox. IE7 is not supported! Note also that IE8 and IE9 only work right if the Plone site is in production mode. The reason for it is that those browsers ignore every stylesheet after the 32th. In production these stylesheets are merged.

Note that we also rely heavily on javascript as the calendar shown for reservations is rendered through javascript. If your requirement is to run without javascript then this is not the droid you are looking for.

Showcases

• St. Thomas Adventure Tours

Limitations

These are the things seantis.reservation currently doesn’t do, or doesn’t do well:

• Multilanguage. It is perfectly fine to run seantis.reservation in the language of your choice, though you might have to do some translations for yourself. However, you might find the ability to run the site in multiple languages (where the language is set on a per-request basis) to be lacking or with rough edges. It should mostly work but we cannot guarantee it or tell you that we tested this well.

• Timezones. We currently do not store a timezone with the resource. Therefore comparing different resources of different timezones is a no go.

• Recurrence. Though it is possible to create reservations with simple daily recurrence, it is not possible to modify them, so if you create 1000 recurrences and you make a mistake you have to delete all or adjust them each.

Installation

The setup instructions assume an Ubuntu / Debian Server installation as well as basic knowledge of Plone.

Install required packages

sudo apt-get install git-core
sudo apt-get install libxml2 libxml2-dev
sudo apt-get install libxslt1.1 libxslt1-dev
sudo apt-get install python2.7 python2.7-dev python-virtualenv

Install Postgresql

Run the installer

sudo apt-get install postgresql-9.3
sudo apt-get install postgresql-9.3-dev

If 9.3 is not found try 9.2 or 9.1.

If the dev package cannot be found try

sudo apt-get install postgresql-server-dev-all

Create a database user (replace your_password with your own). This password is needed later!:

sudo -u postgres psql -c "CREATE USER reservation WITH PASSWORD 'your_password'"

Create a database for your plone site. Each plone site should have its own database with the same name as the plone site id. Here we’ll later use ‘reservations’ as the plone site id:

sudo -u postgres psql -c "CREATE DATABASE reservations ENCODING 'UTF8' TEMPLATE template0"

Grant the required privileges to the reservation user

sudo -u postgres psql -c "GRANT ALL PRIVILEGES ON DATABASE reservations to reservation"

Install Plone

Download the buildout configs to the folder which will hold your Plone installation.

wget -qO - https://raw.github.com/seantis/seantis.reservation/master/buildout/buildouts.sh | bash

Or if you don’t have wget (like on OSX):

curl https://raw.github.com/seantis/seantis.reservation/master/buildout/buildouts.sh | bash

Edit your database connection settings in the database.cfg file.

nano database.cfg

Usually you would want to use the following setting in the database.cfg. Be sure to change your user and password to the values entered above in the “Install Postgresql” step.

dsn postgresql+psycopg2://user:password@localhost:5432/{*}

This will use the database with the same name as the plone site id. So if your plone site’s id is demo (i.e. being served unter localhost:8000/demo), then the database name will be assumed to be ‘demo’ as well.

Download the boostrap script

wget https://raw.githubusercontent.com/seantis/seantis.reservation/master/buildout/bootstrap.py

Again, alternatively with curl

curl https://raw.githubusercontent.com/seantis/seantis.reservation/master/buildout/bootstrap.py > bootstrap.py

Create a virtual environment

mkdir reservations
cd reservations
virtualenv -p python2.7 .

Bootstrap your environment

python2.7 bootstrap.py

Run the installation (and get that coffee machine cracking)

bin/buildout

If everything went well you may now start your instance

bin/instance fg

Running Tests

The tests are run against a Postgres Database. Seantis Reservation uses testing.postgresql, which will automatically setup a temporary database using the local postgres server.

That means that a Postgres server version 9.1+ should be installed for the tests to work. If that’s the case, you can run the tests as follows:

Run the development buildout

python bootstrap.py
bin/buildout -c develop.cfg

Then run the tests

bin/test -s seantis.reservation

Creating a Reservation Plone Site

Create the Site

Having started your instance, navigate to the plone root:

http://localhost:8080

It should say ‘Plone is up and running’. On this site click “Create new Plone site” If you used the develop.cfg the username and password are “admin” and “admin”.

Obviously you do not want to use develop.cfg in production!

On the “Create a Plone site” form, you should enter name and title of your plone site, followed by checking the box of the following Add-On:

Seantis Reservation - for default plone theme

Having done that, click “Create Plone Site”

Create Resource Folder

On your freshly minted Plone Site, click on “Add new…” and choose “Folder”. Use any name you like.

Add a Resource

In the newly created folder, click on “Display” and choose “Resource Listing”.

This will turn the folder into a view designed for displaying Resources.

After changing the view click on “Add new…” and choose “Resource”. Enter any name you like.

You should now see a calendar in which you can create allocations that may be reserved. One level up, in the folder view, you may add more resources and compare them. Of course there is more to learn, but this is the basic setup of the Seantis Reservation module.

Data Structure

To really understand seantis.reservation it is important to understand a few core concepts:

Resource

Resources are Dxterity content types who display a calendar and interact with the core of seantis.reservation. They are heavy on the UI side of things, while being nothing more than a foreign key in the database.

Allocations

Everyone familiar with Outlook or Google Calendar knows that one can just click on an empty spot and add a new reservation.

In seantis.reservation this is not the case. In this module, a spot that may be reserved must be marked as such first. This is called an allocation.

The idea is to allocate time which may be reserved. It is like declaring time that should be managed by reservations. Outlook and Google Calendar implicitly see all time as allocated and under their management.

One reason for this is the fact that only through limiting the available time we can calculate meaningful utilization numbers. Another reason is that some periods of time may be overbooked, other times may not, or generally speaking: some timeperiods are different than others.

Allocations therefore define how periods of time may be reserved. They may not overlap for any given resource and they are independent of Plone and part of the SQL database model.

Reserved Slots

When reserving an allocation or a part of an allocation, reserved slots are generated. They ensure that no reservation is ever granted twice by accident.

Reserved slots may start every 5 minutes. At 5.35 or 5.40 for example, but not at 5.36 or 5.39. When reserving 45 minutes of an allocation, many reserved slots are spawned and aligned. Their primary keys then ensure on a low level basis that no overlaps occur.

For a much needed example:

Resource: 1234
Allocation: 09:00 - 10:00

=> reserve 1234, 09:30 - 10:00

Reserved Slots:
    1234 09:30
    1234 09:35
    1234 09:40
    1234 09:45
    1234 09:50
    1234 09:55

=> try to reserve 1234, 09:30 - 10:00 again

Reserved Slot 1234, 09:30 already exists

Of course there are a number of optimizations to ensure that we don’t generated millions of reserved slots. But this is basically it.

Reservations

Reservations exist in two states: Pending and Approved.

Pending reservations are reservations on a waitinglist. Users have submitted them, but nobody has confirmed them. They have therefore no reserved slot associated with them.

Approved reservations are reservations who are associated with reserved slots and are therefore confirmed and binding.

Note that it is possible in the UI side of seantis.reservation to go from pending to confirmed automatically. This is called auto-approval.

FAQ

Why is Database X not an option? / Why does Postgresql < 9.1 not work?

seantis.reservation relies on a Postgresql feature introduced in 9.1 called “Serialized Transactions”. Serialized transactions are transactions that, run on multiuser systems, are guaranteed to behave like they are run on a singleuser system.

In other words, serialized transactions make it much easier to ensure that the data stays sane even when multiple write transactions are run concurrently.

Other databases, like Oracle, also support this feature and it would be possible to support those databases as well. Patches welcome.

Note that MySQL has serialized transactions with InnoDB, but the documentation does not make any clear guarantees and there is a debate going on:

http://stackoverflow.com/questions/6269471/does-mysql-innodb-implement-true-serializable-isolation

Why did you choose SQL anyway? Why not use the ZODB? Why not insert your favorite NoSQL DB here?

• If a reservation is granted to you, noone else must get the same grant. Primary keys and transactions are a natural fit to ensure that.

• Our data model is heavily structured and needs to be validated against a schema.

• All clients must have the same data at all time. Not just eventually.

• Complicated queries must be easy to develop as reporting matters.

• The core of seantis.reservation should eventually be independent of Zope/Plone.

Why / How is my allocation colored? My allocation is green, but it should be orange/red!

Basically colors are assigned to events based on their availability:

75-100% : Green / Available

1-74% : Orange / Partly Available

0% : Unavailable

The availability is calculated by taking the total time available and dividing it by the time reserved. If an allocation is set to be approved automatically (the default) a 0% availability also means that no new reservations can be made.

If an allcation is set to be approved manually, there’s automatically an unlimited waitinglist. Reservations to that waitinglist can be made at any time - unless the allocation setting is changed - and the number of people in the waitinglist is shown on the allcation itself.

Changelog

1.4.0 (2015-12-02)

• Move styles from plonetheme.onegov to this package. [lknoepfel]

• Visual redesign of the overview calender. [msom]

1.3.0 (2015-10-27)

• Integrates latest libres release which switches to serialized-only queries. [href]

1.2.0 (2015-02-10)

Warning: The seantis.reservation release 1.2.0 changed a lot internally, which is why you can’t directly upgrade from seantis.reservation releases prior to 1.0.12 (September 27th, 2013) to the 1.2.0.

If you do have such an old release, install seantis.reservation 1.1.5 first, run all upgrade steps, and then install 1.2.0.

• Moves the core to a new, plone-independent Python Module (Libres). [href]

1.1.5 (2014-09-23)

• Changes export/report/latest permissions on the actions to reflect the actual permissions needed to open these views. Fixes #164. [href]

• Fixes last day not being included in the monthlry report. Closes #163. [href]

• Adds email template validation. Closes #156. [href]

• Fixes export error when using a unicode character in the resource title. Closes #165. [href]

• Spell email as ‘E-Mail’ in German - always. Fixes #166. [href]

1.1.4 (2014-08-18)

• Fixes allocation search not working correctly with partly available whole-day allocations. Closes #162. [href]

1.1.3 (2014-08-15)

• Fixes wrong times being used for whole day reservations in the search. [href]

• Changes search view to be way more ajaxy, giving the impression of a speedup. [href]

• Adds the ability to delete allocations found when searching. Fixes #161. [href]

1.1.2 (2014-08-12)

• Adds the ability to change the times of certain reservations. [href]

• Correctly deals with group-allocations in the search view. [href]

• Disable the reservation button if no selection is made in the search view. [href]

• Adds the ability to change the email address of a reservation. [href]

• Ensure that the session data is never shared between browsers, even if the same user is logged in. [href]

• Disables unload protection on search form. [href]

• Adds the ability to remove parts of a reservation (timespans). [href]

1.1.1 (2014-08-06)

• Fixes a bug where reserving a heterogenous group of reservations would sometimes lead to wrongly reserved spots. [href]

• The availability of partly available allocations in the search view is now limited to the time selected in the search. [href]

• Correctly aligns the time in the search view. [href]

• The search now defaults to ‘available allocations only’. [href]

• Reservation dates are now always shown correctly in the manage view. [href]

1.1 (2014-08-05)

• Adds new search & reserve feature. On each resource, users may search for allocations. Those allocations may be selected and reserved in compound.

  This is a big new feature and 1.1 is meant to be the canary for it. There are certain things which don’t yet work: group reservations are kept out of the search, the compound reservations don’t show up everywhere yet and there are rough edges in the UI.

  If you are not absolutely sure you need this release we therefore recommend to wait for a week or two. We’ll deliver 1.1.+ which will be a more stable and more widely adapted release. [href]

• Hide the timeframes selection in the allocation and search form, inside an icon close to the dates. [href]

• Make sure following the documentation under Ubuntu 14.04 works and clarify some things. Fixes #159. [href]

• Remove resource description from thankyou-page. [href]

1.0.24 (2014-07-16)

• Adds the ability to define green/orange/red thresholds in the controlpanel. Fixes #158. [href]

• Adds the ability to view formdata that cannot be written anymore. This can happen if the custom forms are changed after the data has been written. Fixes #150. [href]

• Limits the width of the day view, to improve the accessibility of the menu. Fixes #157. [href]

• Adds a fast way to switch to another view from the allocation menu. Fixes #153. [href]

• Exceptions occurring in forms now include the correct stacktrace. [href]

• Export filenames now include the year and the month. Fixes #155. [href]

• Adds shading (avilability indicator) to the calendar legend. Fixes #154. [href]

1.0.23 (2014-06-23)

• Adds unicode check/cross marks for approve/deny/revoke, to increase legibility. [href]

• Adds thank-you page shown after submitting a reservation. Each resource may have a custom text which is shown under the thank you note. Closes #138. [href]

• Refetch less agressively to make the interface ‘calmer’. Only actions by the user which change something trigger a refresh now. Clicking on the cancel button of an overlay for example won’t reload the events anymore. [href]

• The date is now correctly localized in all the views as well as the calendar. Fixes #142. [href]

• Renames “Reservation Quota” (eng) to “Number of Reservations”. Fixes #143. [href]

• Availability partitions are now more visible. Fixes #149. [href]

• Allocations which are not completely displayed on the calendar now show correct availability partitions. Fixes #145. [href]

• Correctly handles partly-available whole-day allocations. Fixes #129. [href]

• No longer raise an exception to the user if a nonexistant reservation is removed from ‘your reservations’. Fixes #123. [href]

1.0.22 (2014-06-05)

• Adds new reservation-assistant role which may view but not edit submitted reservation data. [href]

• Fixes overlay js failing if loaded after jquery tools. [href]

• Slims down the session handling code. [href]

1.0.21 (2014-03-26)

• The messages shown when reserving/confirming a reservation have been reworked to be more informative. [href]

• If an overlay fails to load the remote address after a click, an error is shown. [href]

• Email addresses are now verified and stored without leading or trailing space. Fixes #127. [href]

• Shows an error when displaying or submitting the reservation confirm form, if no reservation can be confirmed. Fixes #128. [href]

1.0.20 (2014-02-25)

• Fixes inability to reserve a group reservation. Closes #124. [href]

• Fixes a major Heisenbug occurring in testing using the latest SQLAlchemy release. [href]

1.0.19 (2014-02-05)

• Adds next/previous 30 days to latest reservations report. [href]

• Adds month/year filter to the export. Fixes #101. [href]

• Replaces the export list view with a form where the export type, format and other options can be chosen. [href]

• Improves print style for single reservation view. Fixes #109. [href]

• Adds seantis.reservation specific browserlayer. [href]

• Adds xlsx as output format to exports. [href]

• Adds option to define one global manager email address. Fixes #69. [href]

• Start treating sqlalchemy warnings during tests as errors. [href]

• Adds a link to the reservation to the manager email. Fixes #117. [href]

• Adds the reservation quota to the reservation confirmation mail. Fixes #111. [href]

• No longer send reservee emails to the reservation manager. Fixes #118. [href]

• Richtextfields may now be exported to excel/csv/json. HTML is converted into text when this is done. [href]

• Dates in the excel/csv/json export are now uniformly exported in ISO8601. Fixes #116. [href]

• Reservation data is now stored more transparently. This has no effect for users, but it ensures better data integrity in the future. Fixes #119. [href]

• Integrates seantis.plonetools. [href]

• Make sure that the exposure checking method doesn’t trip up if the resource may not be viewed and is therefore None. Fixes #114. [href]

1.0.18 (2014-01-21)

• No longer throws an exception if the allocation cannot be found. Returns a 404 instead. Fixes #112. [href]

1.0.17

• The print link is now shown in the monthly_report. Fixes #33. [href]

• Custom e-mail templates now show a translated template upon creation, if the translation is available. Fixes #92. [href]

• Adds quota to email templates. Closes #41. [href]

• Clarify the received reservations email helptext, ensuring that it’s clear that this mail is sent in all cases. Closes #95. [href]

• Ensures that different logged in users don’t see each others reservations. [deiferni]

1.0.16

• Fixes throttling being triggered on invalid reservations. Throttling should only be active if the reservation is actually made.

1.0.15

• Adds the ability to define pre-reservation script which may trigger validation errors on the reservation form.

1.0.14

• Adds the ability to print single reservations.

• Adds the ability to remove a reservation without sending an email.

1.0.13

• Adds a new ‘latest reservations’ report, showing reservations done in the last 30 days.

1.0.12

• Removing expired sessions no longer results in orphan reserved slots. Existing orphan reserved slots are removed by the upgrade step.

• Exceptions in the ‘your-reservations’ form are now handled correctly, resulting in properly displayed errors.

1.0.11

• The date and start-/end-time are now properly disabled on the form if they may not be edited.

• Fixes ‘continue’ button not working on group forms

• Fixes radio-buttons and check-boxes not showing up on group forms

• Fixes a minor style issue in the teamraum theme

1.0.10

• Fixes ‘your-reservations’ from bugging out if a date before 1900 is entered

1.0.9

• Fixes being unable to confirm ‘your-reservations’ outside the resource.

1.0.8

• Adds a new view for exports which initially offers the existing reservations export and a new ‘compact’ export.

• Adds created / modified columns to reservation exports.

• Having different resources with different formsets no longer leads to errors when trying to do multiple reservations.

• Increases the maximum allocation quota from 100 to 1000

• Fixes typo in English text.

• Improves German texts.

1.0.7

• Removes potentially dangerous orphan removal from settings panel.

• All reservation records stored in Postgres belonging to a certain resource are now wiped if said resource is deleted.

  The exception is the removal of a plone site through the ZMI. Though it is possible to intercept that event it is not entirely save to discard all resources that are part of plone site being deleted. It is namely possible that those have the same uuid as another existing resource of another site.

  To clean these kind of data zombies it might be good to create a tool with which reservations before a given date are wiped or archived.

  This is however not a priority as it is recommended to have a separate database for each site anyway and until there’s a high volume reservations site in existance this won’t ever be a problem. Postgres can handle unused records.

• Stops allocation.mirror_of from potentially being NULL.

• Fixes a bug where reservations could be added to waitinglists on allocations that were not meant to have a waitinglist.

• Fixes typo in German translation

1.0.6

• Adds the ability to edit the formdata of a reservation through the management or the report interface

• Adds the ability to define Manager Formsests which are the same as Default Formsets but can only be edited by someone with the appropriate permission.

  With these formsets and the ability to edit the formdata it’s possible to create simple ways to organize reservations. A manager formset could be added with a checkbox “paid” for example, along a normal formset with the address.

  Each reservation will then have an address filled by the user and a “paid”-checkbox. The reservee cannot see or change this checkbox, but the manager can do so once the reservee has actually paid whatever he was supposed to.

  The initial values of those manager-only fields are defined throught the Dexterity-Schema editor.

• No longer compresses URI.js, fixing javascript errors in the browser

• Fixes missing translations in certain cases (locale.js is now more robust)

• Uses ajax on the monthly report to load reservation changes

1.0.5

• Adds whole-day flag to reservations export

• Adds quota to reservations export

• Adds the ability to show/hide the timetable in the monthly report

• Keep filter state between months in monthly report

• Adds basic support for plonetheme.teamraum

1.0.4

• Fixes German translation typo

1.0.3

• Adds email sent to managers when a new reservation was automatically approved

• Focuses on first input when switching tabs in wizard forms

1.0.2

• Fixes crash in JSON Encoder

1.0.1

• Fixes some tiny issues

1.0

• Initial release