USPIRG Project (Phase 2 in CiviCRM v2.2)

Phase 2 in CiviCRM v2.2

• Multi Org Support (Status: Pushed to 2.3)
  • ACL Support for multi-orgs

• Import (Status: Complete)
  • Need to finish the NewImport system and incorporate that
    • Finish CSV DataSource
    • Hunt for and squash regression bugs vs. old Import

• CiviMail
  • Support for multi-orgs (Status: Pushed to 2.3)
    • must support dynamic branding based on the org being sent to (i.e. send one job to several orgs, but the branding is via tokens)
    • must display mailings based on permissions for group / org
    • some users will have permissions on many orgs, so the interface should scale well
      • one idea: have it display only mailings you created / sent by default, with an option to display all mailings (you have permission to see)
        • it should track both who created a mailing and who sent it; if you touch a mailing, it should be added to the default "my mailings" view
      • another idea: have a folder display of orgs that mailings are associated with; if you only have permissions inside one org, you don't even see this; but if you have permissions in multiple orgs, you can navigate the folder hierarchy to find mailings
        • in the case of sending a mailing to more than one org, just associate it w/ all of them
  • will require a new return path system that supports multiple domains (Status: complete except for multi-domain/org aspects)
    • should also be way easier to setup that the current amavis system
    • maybe we can add in a POP/IMAP client library and then you supply the server, login, and password for the accounts you send from and CiviMail checks the account periodically for returning emails it should deal with
    • this would require doing VERP differently; maybe using the localpart+otherstuff@domain.com format that many MTA's accept
  • Allow dynamic querying of the db and include contacts returned by that query (i.e. be able to plugin a zipcode or state etc) - this should work outside CiviMail too (Status: Send/Schedule a mass mailing is one of the actions you can take after doing a search in 2.2; may need to tweak this in a later version to be part of the New Mailing workflow)
    • Need to figure out unsubscribe semantics? should we treat it as optout?
      • This should basically be a segmenting tool, so you start w/ one or more groups/orgs and run a query that segments those lists into the specific folks you want to send to. It should associate unsubscribes with the original group that the list was segmented from and use similar semantics to the auto-branding above (i.e. where a contact comes from more than group included in the mailing, the unsubscribe would go to the same group that the branding came from).
        • Here's an example: Let's say you send a mailing to everyone in the 80218 zip of Denver, CO who is in the Online Activists group of the Environment Colorado organization OR is in the Online Activists group of the Progressive Future organization. For any contact in both, we would need to decide where to direct the branding tokens and the unsubscribe tokens in the message, but it should always be the same result (deterministic across tokens and mailings). Maybe just use the order the groups are included in the segmenting search?
    • Also need to be able to save these and re-use the common ones w/ 1 or 2 values given at "run-time." Like a parameterized smart group, basically. So for commonly recurring mailings, we'd like to start with an already-setup search, but just plug in the zip code or the date to use or whatever rather than having to re-define all the search criteria. (Status: Possible by editing the smart group, but we need to make it work w/ fewer steps / be more intuitive in a future version.)
  • Save & Continue Later should remember which step it was on when you clicked and return you to that step when you Continue. (Status: Pushed to 2.3)
  • Subject should not default to the name of the mailing. The name of the mailing is a string which helps us stay organized internally. The subject line is the most important component of the public "face" of the e-mail. They serve wildly different purposes and should not be the same. We've already inadvertently sent a couple mailings w/ the name in the subject, which looks weird. (Status: Complete)
  • Option to archive old mailings in a separate area of CiviMail so they don't clutter up the interface, but still retain the ability to see / search them in that "archive" section. (Status: Complete)
    • Add an is_archived column to civicrm_mailing and list only unarchived mailings by default in listings
    • Also add an Archived Mailings in the menu which would do the opposite
    • All mailings should be accessed by their direct URLs as they are now

• Improvements to standalone
  • Standalone is getting more traction, and i suspect folks will come back with feedback and modifications needed
  • Upgrading standalone from 2.1 on should be as automated as it is for Drupal and Joomla (Status: Complete)
  • Cron job scripts, web services, and other "extern" utilities need an authentication mechanism. Maybe there's a way to use OpenID for this. Currently I just comment out the authentication part. Maybe we could just restrict which hosts requests are allowed to come from? Seems like this is what OAuth is designed for, but I need to research it further. (Status: Kludge implemented for 2.2, need to implement OAuth for 2.3)

• CiviReport, the Return (Status: Doing 10-20 reports for 2.3; some foundational work done in 2.2, won't be ready for us to start using until 2.3)
  • Not really a new component but some additions to the Search functionality that allow you to create reports via saved searches.
    • Should not need BIRT, Eclipse, or other external tools to define or run reports.
  • Needs aggregation and visual data capabilities (charting / graphing), but should use built-in libraries, not send your data out to Google Charts or any other third-party to generate them.
  • Needs ability to auto-generate and e-mail out certain reports based on a customizable schedule (would benefit from workflow system described above and some of the CiviMail additions described above).

• Search
  • Need to be able to combine custom searches with built-in searches (and other custom searches) in the same search (so the results can be used to create smart groups, for example) (Status: Pushed to 2.3 or later)
  • Need to be able to select more than one state in advanced search (Wes implemented this, but it needs more testing as some potential bugs have been reported by users.)