Skip to end of metadata
Go to start of metadata
  • Define basic contact info in core data model for individuals, households, and organizations. Data model should be compatible with relevant standards (i.e. vCard, Chandler, ???).
  • Support 1 : n contact locations for each contact, and multiple communications targets (phone/email address/im) for each location. Identify preferred communication mode and location.
  • Record/display relationships of various types between individuals, between individuals and organizations and between individuals and households. Roles are also modeled as relationships (e.g. "Dana Smith is a Board Member of My Organization" is implementated as a "Board Member" relationship between and individual and an organization). Standard relationship types will be included by default, but may be extended or modified. Examples include:
    1. parent/child, sibling...
    2. member of household (family)
    3. employee/employer, member of...(contact_organization)
  • Contact Search (simple keyword and 'advanced' - contact property-based - searches). Allow users to save search definitions for future use.
  • Provide user interface for defining unlimited custom fields ("extended properties") for contacts and locations. Extended property definitions will include data type, input and display characteristics, and validation rules. Extended properties my be grouped into logical 'sets'. (This feature will be enhanced to support extending any data object at some point.)
  • Log user and date/time for all data modifications. Provide versioning and rollback mechanism - allowing undos of insert/update/delete transactions.
  • Flexible data import, allows user to map external data columns to standard and extended properties in the application and define duplicate handling rules.
  • Export data to CSV files (any subset of records, depending on permissions).
  • Create and manage contact groups (lists). Two types of groups are supported:
    1. static : an arbitrary set of contacts, membership in the group is not driven by any property of the contact
    2. query : membership is controlled by a matches to a saved search (query of contact properties). A static group may be created from the results of a saved search.
  • Provide public APIs (initially via PHP function calls):
    1. retrieve contact, location and relationship data
    2. insert/update/delete contact, location and relationship data
    3. retrieve contact group data
    4. insert/update/delete contact group
  • Provide "contact action" registration API which allows other applications to link actions to a contact or group of contacts (e.g. made pledge or donation, volunteered for..., signed-up for event, received newsletter, etc.). NPO-CRM will display categorized summaries (history) of these actions and store callbacks. Users can navigate from a "contact action" to the registering application in order to view details, and/or do work with the action item.
  • Record/display contact-related tasks (open and completed). (this feature may be removed from core set ??)
  • Record/display contact notes. (this feature may be removed from core set ??)
  • Support contact-level view/edit permissioning. (We are also considering field-level permissioning.)
Labels:

Creative Commons License
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-Share Alike 3.0 United States Licence.