Membership Application

Requirements

OSGeo needs a web based mechanism to let people join the foundation as members. This application needs to capture name, userid, password, postal address, email address, and a lat/long location. We would like the membership userid and password to be pushed into LDAP for a general user class (giving update access on wiki, etc).

We also would like to be able to present a limited amount of information on a public "map of members" possibly just location and name.

It would be nice if we could push or associate the user with a userid in the CN infrastructure, but this is by no means critical.

The application also needs to have a mechanism for a member who joins to make a payment to be a "Supporting" member.

We might also want an easy mechanism for new members to subscribe to the announce and discuss lists.

Some fields should be set as private, so that anonymous users cannot read them, or so that only authenticated users can.

Information Fields To Capture

Setting up user profile fields allows users to enter information in a private or public way and then having the CMS access this information for services or views of lists of members, etc. When information is displayed, i.e. via a query that an administrator sets up, various fields can be used to filter and sort information.

• Location - general information about where a user lives
  • Address - Text (Private)
  • City/town - Text
  • Country - Text List
  • Latitude - Decimal
  • Longitude - Decimal
• Sponsorship - expressing interest in sponsoring or having someone get in touch with them
  • Send me info - Checkbox
  • Donate now - ??
• Community Signup - a way of showing which areas of the community they are interested in following. Could be tied to CMS to help focus content on their personal start page or to sign them up to certain services/mailing lists.
  • Choose mailing lists - Checkboxes
  • Choose committees of interest - Checkboxes
• must be more...

Who to Build

The application would be a service under the responsibility of SAC. It has been proposed that it might be built to use Mapbender for the mapping component, and that Benjamin Thelen and Astrid from CCGIS would be willing to assist in building it. Frank Warmerdam is also willing to do some work on this.

Architecture

• The low level SAC authorization mechanism is LDAP based, so if we want to use that to provider users access to stuff like Wiki's, we will need to push new registrations into LDAP and use it for all password authentication.
• It seems reasonable to keep the bulk of the information in a PostGIS database. Easy to map from, easy to update, well supported by lots of stuff.
• It has been suggested that WFS access be provided to this data; however, I am nervous about this due to privacy concerns. At the very least I think this should be restricted to location, name and OSGeo userid.

Possible drupal implementation of this

• our test drupal install already is reading / authing against LDAP. writeback may involve a shift to OpenLDAP away from Fedora directory server? drupal is mysql oriented though there is postgres support in contribs for it - but do we need that - or can we just store WKT in a text field? ;)
• The drupal portal includes customisable fields in the user registration process. I've added lat/lon, country and a blog url as examples and know how to hit them from PHP queries. These should be elementary to grab direct from mysql and other scripting languages. So I think the user profiles and registration process is going to be robust enough to capture information and allow users to choose items, e.g. having a checkbox for committees they are helping with, etc.