Quick Tour 2 - Application: Membership Database

This tour continues on from Quick Tour 1 - Application: An Intranet Directory, showing a different application this time: a membership database

The Database

Below is the membership database at the top level:

Unlike the intranet application in tour 1, there are other specialised object in this application. The important ones are "Contacts" (members, donors, supporters, etc.) and "Branches", the latter being the main form of group in the organisation. All other groups are placed in "Other Groups". "Addresses" are treated a separate entities, since contacts can share an address, and they can also be used by other objects such as organisations. Other important areas are "queries" and "templates" that we will look at below. "Outbox" is simply a container for mail merged documents. "Elections", "Electorates" and "Organisations" contain other specialised objects that will not be discussed here.

Contact Information

The summary view of a contact (in this case, a member) is show below:

There are links to groups that this member is in and also there physical address (and postal address if present). Note also a sub-folder that contains fee and donation payment and payment schedule information.

There is a lot of information associated with a contact. We illustrate some below (note the various tabs at the top):

Its not shown above, but the "Website" and "Password" form areas can be used to control access to the members' website. Also, placing a member into certain groups (located in the "Other Groups" area), such as "Database Operators", can imbue them with extra privileges, such as the ability to view and manipulate the membership database. This particular application doesn't have LDAP export like the intranet application in tour 1, however it would easy to add it.

A final point about contact details is that the edit form automatically records which details where changed, and by who and when, providing an audit trail for the database.

Address Information

Note that international addresses, and other location information are catered for. Potentially, the data recorded could be extended to allow some interesting GIS applications.

Payment Information

Payments include membership fee payments, donations and other arbitrary payments. An operator can record payments, but note that the database is not an accounting package. It has been proposed to add basic accounting with QIF (("Quickbooks" format) export in the future to allow membership fee payments to be imported into popular accounting packages such as Gnucash and Quickbooks. There is also no web payment gateway integrated into the applications at this stage.

Payment schedules (shown below) are used for regular payments. The membership fee payment schedule, which must be present for each financial member, plays an important roll in the automated parts of the membership workflow. The key piece of information used by the membership workflow is the the "Next Due Date". This is used to automatically place members in the "Due" or "Overdue" states (ClockServer has been used underneath to facilitate this).

Membership Workflow

The application can support complex customised membership workflows. Any contact (eg. a donor or supporter) can be made into a member, and visa versa. Below we show the organisations's membership workflow in two parts: the initial membership application phase:

and the ongoing membership cycle:

In the workflow above, the green transition arrows show transitions that occur automatically under certain conditions, such as membership fees becoming due. The "xyz_notified" states are states which a member is put in by the operator after a letter has been sent to them to notify them of their status. To achieve this easily, pre-prepared queries and mail merges are used to generate notification letter (see further below).

Branch Information

Branches are much the same as other groups that we saw in tour 1, although the managers are named differently:

An extra "Listing" tab is used to list information that branch managers are allowed to access:

Queries

The system wouldn't be much of a "database" without queries. Stored queries are provided under the covers by Plone smart folders. Although not as powerful as, say, SQL queries in a generalised database, with careful design of indices and metadata, these queries cover the use cases in that a membership database operator would normally encounter.

This application has a large range of criteria, name criteria, location criteria, due dates, groups membership, skills, interests, status, etc. that can be used to find contacts, addresses, and other types of object. As with any smart folder, these criteria can be combined together to achieve quite complex queries. Below is a simple example for locating all contacts that have expressed an interest in human rights.

Mailing Features

The system was designed to fulfil an number of (snail) mail related requirements. For example, members due for renewal who had not opted for automatic payment needed to be contacted by mail. To do this, we built letter and mailing label template facilities and a mail merging feature to generate the letters and mailing labels and export them to appropriately formatted PDF.

Templates are based on ordinary Plone "pages", with string formatting for the variable fields. Such templates can be edited in Kupu through the web, and may include text styles and graphics:

In this application, the variable names are predefined. The open source version may need to have a more flexible system than this.

Each query has a "Mail" tab. Returning to one of our previous queries:

The available letter templates and mailing label templates are detected and shown. Note that only contacts returned by a query are used in the mail merge. Generating the letters and mailing labels for the contact returned by the query is simply a matter of selecting the templates. If only one letter is to be sent to multiple recipients at each address, check the "Bundle Co-Located Mail" check box. This will then only generate a single mailing label per household. A set of rules is used to format the content of multi-recipient mailing labels in a succinct and friendly manner.

The generated letters are in fact a Plone page initially:

You could even go in and edit the page to put a personal message to some recipients if desired. The document can then be exported to PDF as this screenshot from Acroread shows:

In fact, the PDF is double-sided and ready for printing, but I haven't shown the other column that contains just blank pages.

Similarly, the mailing labels are exported to PDF in sheets suitable for printing onto pages of labels, as per the mailing label template that you selected:

Conclusion

This application is currently in use by the organisation and has replaced their Microsoft Access database. I can report that they are very happy with the results.

-- ENDS--