Make it so app works without CiviCRM

[TheNotary]

Without doing much investigation, I just hit the below error while running a cucumber test in a private branch:

ActionView::Template::Error: uninitialized constant CiviCRM::SUPPORTERS_API_KEY
from /home/kentos/dev/work/web/action-center-platform/lib/civicrm.rb:91:in `base_params'

application.yml doesn't define a CiviCRM in my test env.

[TheNotary]

CiviCRM isn't documented (by me) enough, it actually slipped passed me. I think a PR addressing this should:

• add a civi_crm_ prefix to the related variables in application.yml
• Not involve the service during tests (I dropped in some unless Rails.env.test? a couple month ago to solve this for rspec without ascertaining the nature of the dependency)
• Allow the app to work just fine without a CiviCRM variables configured
• Document how to setup CiviCRM if that's a reasonable augmentation to the app we can anticipate of 3rd party code consumers

[TheNotary]

Obviously affected by CiviCrm: CiviCRM

• SubscriptionsController
• models/ahoy.rb
• models/user.rb

Subtly affected by CiviCrm:

• app/controllers/tools_controller.rb:99
• views/users/show.html.erb:186
• models/ahoy.rb:28

I could patch all the methods in CiviCRM to return nil if ENV['supporters_api'].nil? ... that could take care of the subtleties. And said conditionally could be applied to the above, more obvious stuff.

[mfb]

3rd party consumers will need CRM integration of /some/ kind, so ideally it would be pluggable... :)

that said, CiviCRM is, afaik, the most popular free software CRM so it's not unlikely someone else using this tool also uses CiviCRM.

[TheNotary]

K sounds like in addition to making the CiviCRM references test compatibly, I'm going to have to pick your brain about how CiviCRM is setup/ used/ etc and then flower the readme with these newly discovered wonders :)

[TheNotary]

After touching base with mfb, it looks like the best way to approach this is to first make the CiviCRM sections test-safe (not take place when rails env is test).

There's a separate issue here, that CiviCRM is an assumption made to be what a code consumer already has set up. It would be advantageous to allow code consumers to provide their own plugins for CRM integration. Assuming Hainish is down with this idea and hadn't had other plans, in a separate issue (long down the road) someone should probably make the CiviCRM functionality take on a more modular nature. Specifically, in the first iteration, extract the existing CiviCRM functionality out into a gem, say, actioncenter-civi_crm which when included in the bundle will enable the action center's CiviCRM brand CRM integrations. This leads the way towards adopters being able to choose which CRM they're like to integrate actioncenter into, though actioncenter-civi_crm will likely be the only CRM plugin for a long time.

I've never built a gem like this but have always wanted to: http://guides.rubyonrails.org/plugins.html#add-a-class-method

Right now I want to complete a cucumber testing branch, a role adding branch, allow admins to set users to 'activists', and finally make the app faster so activism is overcome with happiness and they bring about an end to all bad laws once and for all.