Skip to end of metadata
Go to start of metadata

Phase 1 in CiviCRM v2.1

Nestable groups

  • Search Optimizations
  • ACL Support
    • Nested ACL Use Cases
    • Note: For all these scenarios, it should not always be necessary to specify ACL's individually on each nested group. There should be a default permission inheritance which can be overridden when needed. This can get complex with the graph nature (as opposed to hierarchy) of the nested groups.
      1. Basic scenario – National group U.S. PIRG has two sub-groups, CoPIRG (Colorado) and MASSPIRG (Massachusetts). CoPIRG and MASSPIRG each have sub-groups called CoPIRG Mailing List and MASSPIRG Mailing List. U.S. PIRG also has a sub-group called National Mailing List. This group has the CoPIRG Mailing List and MASSPIRG Mailing List groups as direct children. CoPIRG staff should only have permission to see contacts in the CoPIRG group and down. Same with MASSPIRG and the MASSPIRG groups. National staff should be able to see everything, but some staff should only be able to see arbitrary groups within the graph.
      2. National mailing list – The national organizations' mailing lists are a composition of all the state organizations' mailing lists plus one of their own (for folks in states where there is no state group). This is setup via nested groups. Certain national staff should have access to the entire list, at all levels, for every national org. Staff in each state should only have access to their state's list. Certain staff should have access to one national list, at all levels, but not to the others.
      3. Multi-org data separation – Once multi-org is in place, default ACLs should keep data separated so that a user in one org cannot see any data generated by another org until/unless they are given adequate permission to do so. This should especially apply to groups, so that groups (at any level) on which someone doesn't have view permissions, should not show up anywhere for them.
  • CiviMail Support
  • Ability to import a contact into one or more groups
  • Implement nestable group hierarchy as a dojo widget (dijit.tree?)
  • Add configurable list for "reasons for removal" to group membership

Standalone

  • Configure ACL data set for standalone. Allow public pages to be viewed by anonymous users
  • Build standalone test suite
  • Enable standalone to work when not connected to the internet, i.e. cannot validate with an openID server

Web Services

Would be ideal if all fields that aren't in there now could just be custom fields and the web service API would let us post data to the custom fields.

  • CiviContribute
    • Need to be able to store the following for contributions
      • Membership status – contribution either creates a new member or not, or renews a membership or not
      • Contributor contact data – nothing fancy here, just standard contact fields
      • Employer and occupation fields – these are required for certain types of contributions in the U.S., not sure what the best way to store this would be, custom fields is simplest I suppose--can you store things to custom fields via the web service API?
      • Contributor's spouse's contact data – same contact fields, but must setup spouse relationship and put in household
      • Amount
      • Payment method – cash, check, credit card, eft, custom definable?
      • One-time vs. recurring contribution
      • Payment method details such as account number (will only store enough to identify the account, not full credit card or bank account numbers), expiration date, credit card type (Visa, Mastercard, etc.)
      • Date and time
      • Source code – i.e. an identifier of the appeal that caused them to give OR could record this in the activity section
      • Also need to be able to record this as an activity and link them somehow
  • Test cases for the APIs can be seen here
  • Activities
    • Need to be able to store the following for activities (typically these are online "actions" like emailing decision-makers, signing petitions, writing letters to the editor of their local paper, etc.):
      • Basic contact info – name, phone, email, mailing address
      • Derived contact info – 2 state and 1 federal legislative districts, ZIP+4, other custom fields we derive using external data services
      • Activity type – should be able to define custom list--basic types are: email decision-maker, sign petition, report phone call, send letter to the editor, donate money, volunteer, attend event, join as member
      • Message – this is the message the action-taker sends to the target
      • Target(s) – should create contacts representing targets if they don't exist already, should create a relationship or some other link to the target indicating the type of action they took with them
      • Source code – i.e. an identifier of the appeal that caused them to take action
      • Date & time of the action
      • External ID – i.e. id of the page in the CMS where the action form lives
      • Campaign – should link to the campaign in whatever form makes sense for the campaign system we'll be developing later on
      • Mailing(s) – should link to mailings that sent people to this action
  • Test cases for the APIs can be seen here

Performance and Scalability

  • Fast Search (need some metrics here)
  • Ability to handoff 250K emails / hour to a bank of SMTP server. This will involve multiple jobs being processed simultaneously
Labels
  • None

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.