You are browsing a read-only backup copy of Wikitech. The live site can be found at wikitech.wikimedia.org

Fundraising/Roadmap: Difference between revisions

From Wikitech-static
Jump to navigation Jump to search
imported>Ejegg
No edit summary
 
imported>Ejegg
No edit summary
 
Line 1: Line 1:
We want to make our software easier to maintain and develop, and more accessible both to new developers on our team and to other organizations.
We want to make our software easier to maintain and develop, and more accessible both to new developers on our team and to other organizations.


We want to move as much business logic as possible from DonationInterface to SmashPig. The obvious opportunities for this migration are when we rewrite a payment processor integration. The Amazon, Adyen, and Ingenico integrations all have moved a fair amount of business logic out of DonationInterface. DLocal (nee AstroPay) and PayPal integrations still manage all the business logic in DonationInterface code. We are planning to rewrite the PayPal integration in the first half of 2022.
We want to move as much business logic as possible from DonationInterface to SmashPig. The obvious opportunities for this migration are when we rewrite a payment processor integration. The Amazon, Adyen, and Ingenico integrations all have moved a fair amount of business logic out of DonationInterface. DLocal (nee AstroPay) and PayPal integrations still manage all the business logic in DonationInterface code. We are planning to rewrite the PayPal integration in the first half of 2022. Once PayPal business logic is in SmashPig we can rewrite the PayPal pending transaction resolver and completely remove DonationInterface as a dependency of our CiviCRM install. That will then let us remove the WmfFramework shim from DonationInterface and simplify some code.


SmashPig has some homegrown features that are mostly handled by external libraries in modern applications. We should tear out the homegrown implementations and use a more modern approach to
SmashPig has some homegrown features that are mostly handled by external libraries in modern applications. We should tear out the homegrown implementations and use a more modern approach to
Line 10: Line 10:
We want to make configuration consistent and understandable across our codebases. DonationInterface and SmashPig each have a way to define defaults for configuration values that can be overridden on a per-processor basis. These two approaches should be harmonized. We should also make it easy to test the trickier parts of our configuration such as donation routing to ensure that we get the results we expect.
We want to make configuration consistent and understandable across our codebases. DonationInterface and SmashPig each have a way to define defaults for configuration values that can be overridden on a per-processor basis. These two approaches should be harmonized. We should also make it easy to test the trickier parts of our configuration such as donation routing to ensure that we get the results we expect.


We need to move any CiviCRM custom code that interfaces with drupal 7 to instead interface with CiviCRM APIs. This will be an opportunity to clean up and modernize code while we are at it.
We need to move any CiviCRM custom code that interfaces with drupal 7 to instead interface with CiviCRM APIs. This will be an opportunity to clean up and modernize code while we are at it. In particular:
* Damaged message display needs batch delete / requeue and better search
* Audit parsers need better recurring handling, less wasteful log searching
* Large donation notifier and exchange rate updater should be totally generic & shared with other Civi users
 
Our current banner impressions stats collector and pageview counter is built on an inappropriate framework. We have a replacement (FRUEC) but need to switch over to using it and verify that the stats are still correct.

Latest revision as of 00:36, 29 April 2022

We want to make our software easier to maintain and develop, and more accessible both to new developers on our team and to other organizations.

We want to move as much business logic as possible from DonationInterface to SmashPig. The obvious opportunities for this migration are when we rewrite a payment processor integration. The Amazon, Adyen, and Ingenico integrations all have moved a fair amount of business logic out of DonationInterface. DLocal (nee AstroPay) and PayPal integrations still manage all the business logic in DonationInterface code. We are planning to rewrite the PayPal integration in the first half of 2022. Once PayPal business logic is in SmashPig we can rewrite the PayPal pending transaction resolver and completely remove DonationInterface as a dependency of our CiviCRM install. That will then let us remove the WmfFramework shim from DonationInterface and simplify some code.

SmashPig has some homegrown features that are mostly handled by external libraries in modern applications. We should tear out the homegrown implementations and use a more modern approach to

  • logging (replace with monolog)
  • monitoring/failmail
  • dependency injection (maybe Symfony containers)

We want to make configuration consistent and understandable across our codebases. DonationInterface and SmashPig each have a way to define defaults for configuration values that can be overridden on a per-processor basis. These two approaches should be harmonized. We should also make it easy to test the trickier parts of our configuration such as donation routing to ensure that we get the results we expect.

We need to move any CiviCRM custom code that interfaces with drupal 7 to instead interface with CiviCRM APIs. This will be an opportunity to clean up and modernize code while we are at it. In particular:

  • Damaged message display needs batch delete / requeue and better search
  • Audit parsers need better recurring handling, less wasteful log searching
  • Large donation notifier and exchange rate updater should be totally generic & shared with other Civi users

Our current banner impressions stats collector and pageview counter is built on an inappropriate framework. We have a replacement (FRUEC) but need to switch over to using it and verify that the stats are still correct.