Adding PTP's Canvass and PhoneBank Report to CiviCRM

Background and Demo

Check the blog post from Alice. Also check the PTP demo

http://ptp.dharmatech.org

username: demo
password: demo

Testing Feedback

Issues about address parsing:

• Address parsing works great when you add a new address, and when you run the command line script to parse addresses for existing addresses.   But when you do an import for new contacts, where the global settings -> address settings -> street address parsing box is already checked, you have to run the script again after you do the import.   This does impact usability if you plan on using the address parsing feature.   Is there a way to get the script to run after an import is run and the street address parsing box is checked?   Is this a usability issue or a "bug"?  OR at least allow users to import address elements into the parsed address fields?   I can see why you may not want to automate the script after an import, because it may blast out existing parsed addresses that my have been "fixed" in the existing data (similar to why the "greetings script" isn't automatically run after an import)

Reopened CRM-5450. We should parse street address data during import if parsing flag is TRUE. dgg

•    Looks like it works now with latest update - street address is parsed during import when parsing flag is true (alice)

Issues about Walk list and PHonebank List reports:

(Note:  The Phonebank list was not complete finished, but ideally should match the same look (other than the Odd/Even, and street names page breaks which pertains only to the Walk List.)

• Won't fix. dgg When clicking on Preview PDF button on the Walk list and Phonebank list reports - we get the following memory error.  We tried bumping up the memory to 64M, then 128M, then 256M, then 512M, and we still get this same error.  A workaround that we can live with if pdf generator is an issue that can't be fixed in timeline:  we can just keep the Print Preview Button to view the html and print from that.  We can also advise folks that if they need a PDF version, then can use something like cutepdf or other 3rd party pdf generator to create it.   The Preview CSV is working fine and we definitely want to keep that.

• • Error from Walk list:
    • Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 88 bytes) in /home/members/progressivetech/sites/engage.ourpowerbase.net/web/sites/all/modules/civicrm/packages/dompdf/include/style.cls.php on line 490
  • Error from Walk list:
    • Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 1966080 bytes) in /home/members/progressivetech/sites/engage.ourpowerbase.net/web/sites/all/modules/civicrm/packages/dompdf/lib/class.pdf.php(2219) : eval()'d code on line 5914

• Looks like this has been fixed in latest XML (1/14/2010). dgg In Walk List - one of the status codes is incorrect, it should be "WA"  not "WN" Actually - the issue about WA vs. WN is not about the option values, but actually in the Walk Report itself, when you generate the report - the status codes here are just actual text.  Can you check the report? Unless you have a new XML file that was created today on 1/14/2010 - if so, then we'll need to reload the new XML file.   Done

• In Phone List:** the Date in the Header/Title, should appear on a separate line below the Title
  • If possible, so to match the Walk list, "Other Name" (from Constituent Info - Individuals), should also appear below the Name in the same Name field box

• When running the walk list, the "Odd/Even" indicates Odd or Even street numbers incorrectly, i.e. for those street numbers that are odd numbers, the "Odd/Even" indicates "Even"; for those street numbers that are even numbers, the "Odd/Even" indicates "Odd"
• The Walk list report is not page breaking properly whether you choose to print from the Print Preview version, or from Preview PDF.  Page breaks should occur between Odd or Even street numbers within street names.  In addition, there's a blank first page in both versions of the report. The tables also should not break in the middle over a page break - I can show you an example on our test site if you want to see.
• The Phonebank list report is not page breaking properly, each page should share the same title/headings, and tables should not break across page breaks. There is also a blnak first page
• There should be page numbers on every page on both reports
• The Title in the Walk list should also include the Group / Smart Group Criteria (see mock ups or the report still exists on https://demo.ourpowerbase.net, username: demo, password: demo), e.g. "Group is equal to: Spanish Speakers"  - and would appear centered below the Date.   This Group/Smart Group Criteria should also be the same for the Phonebank list.
• In the Walk List, the custom field, Constituent Info - Indivduals: Other Name  (field used for non-european characters / indigenous names), needs to appear just below the NAME (also see mock ups or https://demo.ourpowerbase.net) in a separate line, in the Name column, when you choose the Print Preview, or the Preview PDF buttons.  Development wasn't finished on the Phonebank list, but the Other Name should appear below the Name as well.
• In the Walk list, The ID column field should be wider, to be able to accomodate longer characters for the ID (and eventually for use as a barcode).  The width of the ID column in the Phonebank list looks fine.
• Searching Criteria issue for both reports, which I've only been able to recreate once in a while (most times happens when right after I log in to  CiviCRM and then try to run the reports right away:  When using the Group critera on either report and I select "is equal to" a particular smart group, at times only 1 record is found (when I know there's more).   So , I check the search again, using Search -> Find Contacts, then enter the smart group, and the records are found successfully.  then when i go back to try the group criteria in the reports again, it will work fine.

Issues about Custom Fields:

Both of the below issues are caused by the same bug. See the 'reopen' comment in CRM-5553. dgg

Issues about Activity Types: "Door Knock" and "Phone call" and custom data groups: "Walk List Responses" and "Call List Responses":

• When I try to add a new Activity for "Door Knock" or "Phone call" for a contact, I do not see the Walk List Responses or Call List Responses.   When I checked the custom data group set up for Walk List Responses or Call List Responses, at first glance, it looks like the activity types  "Door Knock" and"Phone Call" are indicated.  In order to make it work, I had to go and reset the settings for Walk List Responses and Call List Responses for Activities to use "Door Knock" and "Phone Call", respectively.  I noticed that when I went in to the settings, these activities weren't selected.  This should be working on the initial install of CiviEngage without requiring the user to have to reset the Activity types use to "Door Knock" or "Phone Call"  for these custom data groups.

Issues about custom group Event Campaign Details:

• like the Activity Type issue above, when I create an Event, with the Event Type of "Campaign", I do not see the custom data fields associated with the custom data group Event Campaign Details.   When I look Administer -> Customize -> Custom Data, at first glance it looks like Event Campaign Details shows that the event type "Campaign" is indicated.   I would have to reset the settings for Event Campaign Details to use "Campaign" to display these custom fields.   Like Activity Type above, this should be working on the initial install of CiviEngage without requiring the user to have to reset the event type to "Campaign" Details for this custom data group.

Issue about Walk List Responses and Phone List Responses Custom fields:

• Updated field names in XML (the import fix is too big for this stage in the release). dgg When doing Activity Imports for Door Knock or Phone list, can't decipher which Q1 through Q4 fields to map import data to.  Is it possible when mapping to show mapping fields (similar to way it is handled when importing contacts) such as Q1 :: Walk List Responses  and Q1 :: Call List Responses ?   Otherwise I can just rename the the labels to something line Walk List Q1, Walk List Q2, etc., and Call List Q1, etc., which then means updating the xml file
  • okay so updating the field names in the XML makes sense how about:  Walk List Q1, Walk List Q2, etc., and Call List Q1, Call List Q2, etc. ? Done

Issue about Demographics custom group:

• The Demographics tab with our custom group should be hidden when viewing a contact record.  Lobo saw this during demo in Boston.

Issues about Profiles:

• Fixed 1/14/2010. dgg Need to rename Profile name "Update Core Info" to "Update Constituent Info"  to keep consistency of naming conventions - so need to update xml file
• otherwise profiles are working!

Tasks

CiviCRM Team:

• • Make needed changes to Address Schema based on the PL/WL reports and Pub 28. Walt, you should be able to use the mod function for odd/even:
  • Incorporate Changes from Blog Post (CRM/Report). This should include making sure that an individual report class can over-ride the parent class buttons array - since for these reports we may want to link the "special formatted" output to the "Print Preview" button and remove the "Print PDF" button. (NOTE: Alternatively, given that the current setup where Print PDF outputs the "specially formatted HTML" is only required for sites with non-Western alphabets - we might retain both buttons and actually create a PDF of the "special formatted HTML" for those sites that can use it ??)
  • Investigate adding custom fields to demographics via a hook. Potentially also see if we can do this for Communication prefs.
  • ? (or PTP task?) Implement view-only (PHP) custom field to set campaign source code for event participant records based on event source code (custom field).
  • Figure out / implement distribution mechanism for the "package" (custom fields, report code and templates, report defs in DB, activity types, ???).
  • Figure out how to deal with "editing address fields" issue

PTP

• • Upgrade to CiviCRM 3.1.*
  • Remove unneededed custom fields, demographic stuff once the above is done

Dharmatech

• • Use XML export to spit out the custom field def's required for the reports, and get those to Civi team. (A dump of the activity types would also be helpful).
  • Upgrade reports to 3.1.* and make changes based on schema
  • Potentially help QA / Unit test CiviCRM team's changes to address schema