The Drupal user system should be used to manage registered users of the CRM system and CivicSpace website. These users could include
- Anyone viewing, editing, creating, or otherwise managing individuals and other objects
- Anyone posting content to the website
Other tasks should be left as unauthenticated as possible. Various strategies to ensure that a person is who they say they are, without using a password, can be used; such as confirming by sending unique URLs in emails. These tasks will usually produce contact data. They include:
- Signing a petition
- Telling friends about a page
- Creating a voter bloc
- Subscribing to an email list
- Donating to the organization
- RSVPing for an event, and volunteering
New user accounts
Every new user account is an opportunity to gather contact information. The implementation of this will mostly live in the crm_user() function (http://drupaldocs.org/hook_user).
This information is already found in the profile module. A good demo of the profile module is drupal.org itself. For example, everyone in the Ukraine is listed at http://drupal.org/profile/country/Ukraine .
US zipcode information is proposed to be in a separate module which is used to associate zip codes with content and users and then search by location over it.
This existing contact information needs to be associated with the proper fields in the CRM system so the data may be retrieved from the $user object as managed by other modules and saved in the CRM database. Any additional contact information should be collected by the CRM module directly by adding the remaining fields itself.
A admin interface will be needed for
- Specifying which fields the user will see.
- Specifying which fields are the same as fields added by the profile module.
User registrations are confirmed by logging into the site using an auto-generated password. The email address should be treated as unconfirmed until this action happens. Between registration and login the data could be cached outside of the CRM tables or store in some labeled way.
A complete individual record can be assembled using all of the data collected. The saving process should involve finding duplicates and updating an existing individual or creating a new one.
Some "this is the same person" assoiation between the new or updated individual should be made with the user. This data should be exposed to the user both when viewing the user and the individual. This data is probably best stored in an additional column in the drupal users table.
Updating user accounts
The most common case is simple. Collect the data from the various form elements from the CRM and Profile modules and then update the individual object which we know is the same person as the user.
In the conitact module we store the data that the user entered separately from any data which overrides that. A few people have mentioned that this is weird. A better way would probably be only storing data in the CRM module and updating the profile module fields for the user when the individual is updated.
Problems arise in the edge case of the user changing their email address. This action is not confirmed by email so there is no guarantee that the new address is valid. Any ideas?
And the edfe case has an edge case too. What if the user changes thier email address to that of another user. Any ideas?
