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.

• Biographical - information about the users interests, company, organisation affiliation, etc.
  • Personal photo - Image
  • Areas of interest - Text
  • Link to personal web site - Text URL
  • Link to personal blog RSS - Text URL
• Location - general information about where a user lives
  • Address - Text (Private)
  • City/town - Text
  • Country - Text List
  • Latitude - Decimal
  • Longitude - Decimal
• Location - current information about where a user currently is (...later update via GeoRSS, auto "stream" position)
  • Address - Text (Private)
  • City/town - Text
  • Country - Text List
  • Latitude - Decimal
  • Longitude - Decimal
• 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 (What is this good for? People 'joining' committees shoudl go through a more thorough process making sure we don't end up with committees everybody is interested in any nobody does anything. Additionally at the point of first contact it will not be clear what a committee does by just knowing the name - imagine what would happen to FunCom)
  • Sponsorship interest - Checkbox
  • Send me info - Checkbox
• must be more... (really? All the rest should just go to the Wiki user page, there people can do whatever they want)

Who to Build

The application may be built by Amr Mostafa in PHP on Drupal. The application is being treated as a responsiblility of WebCom (though it is sort of on the boundary between webcom and SAC).

A Trac ticket for status tracking lives at:

http://trac.osgeo.org/osgeo/ticket/90

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.
  • I am interested in providing security mechanisms that allow people to specify who may see what of their perosnal information (privacy) via WFS and a ticket system and to allow accessing their own data and only their own data via WFS-T.

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.