Difference between revisions of "Membership Application"

From OSGeo
Jump to: navigation, search
m (drupal notes mostly so i remember this page exists and i'm meant to be thinking about it)
m (Possible drupal implementation of this: added notes on my custom field work)
Line 27: Line 27:
 
== Possible drupal implementation of this ==
 
== 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? ;)
+
* 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.

Revision as of 09:48, 15 August 2006

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.

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.