salesforcefoundation / npsp Goto Github PK

• Is this something we can automatically redirect?
• What's the cleanest way of doing this?

• UDR schema ported to Contacts & organizations

• This is a large story and will need to be broken down into smaller stories
• Existing Household__c data including custom fields, should be transferred to mapped custom fields on the Account

- Naming exclusions on the Contact level (npo02_SYSTEM_Naming_Exclusions__c) should be transferred

If we add a TDTM tab to Cumulus, but not the app, I would think that would be good enough. then the user can create views, sort, etc using standard salesforce functionality.

• Use groups to control recipients

• Household account model support implemented
• Code streamlined to support 1x1/bucket models
• new test cases written

BUILD FAILED
/var/lib/jenkins/workspace/build_Cumulus_feature.xml:8: FAILURES:
Test failure, method: npe03.RecurringDonations_TEST.insertOpportunities -- System.DmlException: Insert failed. First exception on row 0; first error: CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY, RD_RecurringDonations: execution of AfterInsert

caused by: System.QueryException: No such column 'Last_Payment_Date__c' on entity 'npe03__Recurring_Donation__c'. If you are attempting to use a custom field, be sure to append the '__c' after the custom field name. Please reference your WSDL or the describe call for the appropriate names.

Trigger.RD_RecurringDonations: line 86, column 1: [] stack (npe03)

Test failure, method: RD_RecurringDonations_TEST.closeOppForOpenEndedRecurringDonationQuarterly -- System.AssertException: Assertion Failed: Expected: 5, Actual: 6 stack Class.RD_RecurringDonations_TEST.closeOppForOpenEndedRecurringDonationQuarterly: line 716, column 1

Total time: 8 minutes 22 seconds
Build step 'Invoke Ant' marked build as failure
Sending e-mails to: [email protected]
Finished: FAILURE

• Steps for creating a Jenkins run job to automatically run tests on pushes to branches

DoD:

• A push to any branch triggers a job in Jenkins

• npo02 contains only labels, objects, custom settings
• Pages, classes and triggers removed or deprecated in npe4
• tabs will need to be evaluated

• AccountViewOverride (which was originally in C&O but should be in Cumulus) modified to handle Household Account redirects to the Household Management Page

• npe4 contains only labels, objects, custom settings
• Pages, classes and triggers removed or deprecated in npe4
• tabs will need to be evaluated

• Implement Salesforce1 style controls for the Household Management page

• git hook script on checkout to run deployTools pointed at dev's org.
• install script to setup tools against a local repo
• prompt for credentials or cache locally?
• prompt for credentials
• estimate this story assuming deployTools story is complete

• npe3 contains only labels, objects, custom settings
• Pages, classes and triggers removed or deprecated in npe3
• tabs will need to be evaluated

• Manage Households UI ported to Cumulus
• UI works using a Household Account Recordtype

• If an automatic merge is not possible, notify the developer (potentially via a Pull Request in Github?)

• FieldSets should be used for maximum functionality
• existing list settings will need to be removed

Consider redesign over incremental improvements.

• Investigation:
  • Deploy tools should work with existing Github repository and integrate with
    Jenkins and Cumulus workflow
  • https://git.soma.salesforce.com/wguan/deployTools

• Certain Recurring Donation Oppty behaviors are non-deterministic due to date off-by-one issues

• Port existings Households data
• Handle custom Household fields
• Remove or convert existing 1x1 or bucket account model accounts

- Identify items to notify users to modify workflow, reports, email templates, validations rules, etc.

• Recurring Donations tests were failing at end of month and first of month
• Scheduled Jenkins job staggered at key times throughout the day to catch common time based issues (research)

-Investigate code ported to Cumulus and dependencies on npo02 objects are removed from the existing code

exceptions during batch and future calls never get reported to the user interface, so we need to have our code log these, so we can find out about them.

• Will need to deal with recursive insert of Relationship object
• Includes triggers on Campaign Member and Contact that are utilized based on dynamic settings defined by the user

Sysadmin should have the option to select multiple ways of being notified when an error occurs, these ways could include:

• Email
• Log-Only

• Chatter
  (Much of this can be pulled from Recurring Donation)

  Initial page design implemented in Sprint 8.

• Looking for initial pilots over next month
• Extra developer resources as part of the program to write tests

• All Affiliations functionality is duplicated in Cumulus
• All Affiliations tests run successfully in Cumulus
• All Affiliations tests reside in their own classes
• All Affiliations classes conform to Cumulus naming standards
• All triggers in Affiliations are deleted or emptied
• All Cumulus tests will be modified to point to new Affiliations base classes
• All API versions bumped up to v28

• npe5 contains only labels, objects, custom settings
• Pages, classes and triggers removed or deprecated in npe5
• tabs will need to be evaluated

for problems that don't have simple reproducible steps, it will be important to be able to look at the org's error log to try to glean useful information about the underlying problem.

• THIS STORY IS DEPENDENT ON OTHER BDE STORIES
• BDE interface/page is available in Cumulus
• BDE is un-installable from existing org (excluding any existing batches that need to be ported)
• BDE list settings are modified into fieldsets for flexibility

We still have ~10 workflows in the Contact & Orgs package. They are currently marked inactive, but they cannot be deleted. We need to decide whether we want to replace these with trigger code, or whether we need to reactivate them again.

This also includes the two default validation rules provided in the template that are on Contact.

Some good info on this issue we should review before making a decision:

Matthew Scholtz (Percolator Consulting)
Random tip for you devs: sometimes having apex triggers and WF field updates on the same object can cause the trigger to fire twice, and the 2nd time it fires it's unaware of what came before. If your trigger is doing something that shouldn't be repeated, like creating records, this can be a problem. This generally bites me like once per year. Good discussion of it here: http://salesforce.stackexchange.com/questions/4979/trigger-behavior-with-field-update and here: http://salesforce.stackexchange.com/questions/109/workflow-rule-causing-trigger-to-fire-twice

David Manelski
Good advice, and frankly a warning against melding both declarative automation (workflow field updates) and triggers together on the same object.

Matthew Scholtz (Percolator Consulting)
Right. But sometimes this is very hard to avoid. For instance, the NPSP has a number of WF rules on Contact that do field updates. So if you write triggers on Contact, watch out for this. Plus you never know when an admin will create new WF in the future, so may be best to inoculate triggers on common objects against this.

• All Recurring Donations functionality is duplicated in Cumulus
• All Recurring Donations tests run successfully in Cumulus
• All Recurring Donations tests reside in their own classes
• All Recurring Donations classes conform to Cumulus naming standards
• All triggers in Recurring Donations are deleted or emptied
• All Cumulus tests will be modified to point to new Recurring Donations base classes
• All API versions bumped up to v28

• All Households functionality is duplicated in Cumulus
• All Households tests run successfully in Cumulus
• All Households tests reside in their own classes
• All Households classes conform to Cumulus naming standards
• All triggers in Households are deleted or emptied
• All Cumulus tests will be modified to point to new Households base classes
• All API versions bumped up to v28
• Includes Opportunity Rollups code moving as is into Cumulus.

NOTE: this Story does NOT include supporting the new HH Account model. It is just getting current feature parity with HH into Cumulus.

• "Clean" org should include all current NPSP managed packages

From the Jenkins build of current dev branch when using Affiliations 1.9, Recurring Donations 2.9, and Relationships 2.9:

BUILD FAILED
/var/lib/jenkins/workspace/build_Cumulus_feature.xml:8: FAILURES:
Error: classes/STTG_AffilationsSetttings_TEST.cls(STTG_AffilationsSetttings_TEST):Not in package.xml
Error: classes/STTG_AffiliationsSettings_CTRL.cls(STTG_AffiliationsSettings_CTRL):Not in package.xml
Error: triggers/Affiliations.trigger(Affiliations):Not in package.xml
Error: pages/STTG_affiliationsSettings.page(STTG_affiliationsSettings):Apex class 'STTG_AffiliationsSettings_CTRL' does not exist

Currently, you see this:
BUILD FAILED
/var/lib/jenkins/workspace/build_Cumulus_feature.xml:8: Failed to obtain result from server within specified time of 200sec.
Execute following command to obtain the results later: ant test -Dsf.asyncRequestId=04si0000000xxxxxxx

You then have to go to the Jenkins server and run the command to see the test failure status.

This will likely require using a shell script to parse the output from the first ant job and running the second to add to the Jenkins console log.

• All C&O functionality is duplicated in Cumulus
• All C&O tests run successfully in Cumulus
• All C&O tests reside in their own classes
• All C&O classes conform to Cumulus naming standards
• All triggers in C&O are deleted or emptied
• All Cumulus tests will be modified to point to new C&O base classes
• All API versions bumped up to v28

We'd like to have some wrapper classes or static utilities that we use over all insert, update, delete, etc., calls to the database, so that a user friendly message can be added to the error to tell them what really failed and how they might resolve it.