Fundraising tech/Chores

This page will list the repetitive and / or reactive ongoing work that members of the fr-tech team need to do.

• Checking damaged message table
  • In CiviCRM, go to /damaged
  • Look at the stuff from this week
  • If the error looks like a database lock, please requeue the message
  • If it's a new type of failure, please create a phab ticket
• Following up on incoming failmail
  • Update the Failmail zoo if it's something common
  • File phab tasks with details of what we need to do so it stops failmailing.
  • Email team letting them know it's been documented
• Log checking
  • On our centralized logging box, scan through the error logs from today
  • Create phab tasks for any errors that are unexpected/new
  • (errors generally should not be expected)
• Deployments
  • CentralNotice (not for long)
  • CiviCRM
  • Payments-wiki
  • SmashPig
• Check on audit incoming directories
  • If they are getting really full, figure out why
  • Either move out stuck files or run in --make-missing mode
• Check on stuck recurrings - select * from civicrm_contribution_recur where contribution_status_id=14
  • If there are a lot of them, figure out what broke. Try to get them going again, making sure not to double charge folks.
• CiviCRM Upgrades
  • Download latest civicrm code and swap out our civicrm folder with it. We usually upgrade to the rc version rather than the formal release - that usually saves us from re-applying some patch or other we have locally & the benefits of being a bit closer to master outweigh in my mind the marginal additional testing it gets during the rc period. Since we have inhouse dev I think we can err on this side.
  • As of 5.24 we should not need to apply any patches over core (but we will need to disable the core extension sequentialcreditnotes). However we will need to check each upgrade that any patches applied to our repo since the last upgrade have merged upstream. It's pretty recent that we got back to stock civi - 5.24 will be our first actual 'stock deploy' so from then on the git log between versions should show anything we did between versions
    • Current hacks
      • We've had to hack around the requirement for > PHP 7.0. in drupal/civicrm.info:7, drupal/civicrm.module:44, composer.json:45, ./CRM/Upgrade/Incremental/General.php:45.
      • We have commented out the requirement for contribution_id in api/v3/PaymentProcessor.php:148.
      • Deleted "Completed" from inactive statuses in CRM/Contribute/BAO/ContributionRecur.php:954.
  • Test the upgrade script on frdev.
  • Merge the submodule commit into crm's deployment branch. Use the regular deployment procedure. Then on the civi box, in the drupal directory, run: drush civicrm-upgrade-db
• Vagrant updates
  • Create a task for any persistent issues with vagrant, especially if they're coming up in standup
  • Try to fix it (if less than an hour or sprint allows)

Fundraising-tech Operations

• Process AIDE review
  • On the frav host, run aiderator review. Preferably, do this daily to make the diffs easier.
  • Review the updated changes for each host and approve.
  • If unsure about changes, get clarification from other members of the team.