Published
Friday, August 26, 2011 - 09:18
Written by

We had a good discussion that came up because we were discussing a change being made to lower the barriers that currently exist for evaluators of CiviCase. We thought it would be good to write down some things:

  • Regardless of where the data is stored, everybody wants a way to edit it through the admin pages.
  • Files are useful because existing tools can be used to handle revisions, more easily manage staging and production differences, multiple items can be edited quickly, and configuration settings can easily be shared.
  • Files can be a problem because you don't always have write access on the server, although this can be managed.

 

In terms of where we are now and where we could realistically get to by the end of the sprint, the options were:

  • Remove the duplicated info that's in the database (case types, activity types, etc) and have the files be the sole source of configuration.
  • Something in between where those are still defined in the database, but the system intelligently deals with new entities it sees in the files.
  • Move everything into the database so that everything is consistent, and then think about it some more.

 

For the moment it will at least do the minimum to have the sample config work when you enable CiviCase.

Comments

I'm a fan of the Drupal features model, ie intelligently stored in both.  The Dev->Staging->Production move can be quite tricky sometimes and this would make it better by allowing developers to add "settings and new options" to dev that can get ported to the production system in a VCS (ie SVN, Git, etc...).

anything that moves civicrm closer to the features (config in code with DB overrides) model is a HUGE win as far as I'm concerned :)

 

i'd prefer code over DB if i have to make the choice - i know this can be a bit daunting for beginning civicrm configurators but it is a HUGE win for anyone who wants to be responsible about deployment.