Work in progress

Introduction

This document describes the contents of the subversion repository found at http://svn.civicrm.org/php. The "php" stands for Physician Health Program, not php the programming language.

Note there is a folder in the 2.2 branch in the main repository at CRM/Case/xml/configuration/physicianhealthbc, but it is out of date.

Editting Suggestion It would be nice to have an overview of how to use the invoice functionality. For example, explain if it is for invoices issued or received by the organization using CiviCRM. Maybe a short install recipe to set up a system to use the functionality. There are several organizations that are interested in this functionality and will try to make use of this I bet. Joe Murray, Dec 23, 2009

Custom templates

The custom_php and custom_templates folders are some local customizations as described at Customize Built-in, Profile, Contribution and Event Registration Screens.

Under the Case folder is a customized open case form, but it is obsoleted by CiviCRM 3.0 which has customizable Create New... screens via profiles.

The custom searches under the Contacts folder may be useful. The activity tags search is hardcoded to use a custom field we have - you would need to change the ID.

There's a "cheque requests" feature that has a very specific use case so it may not be useful to others as is. Also there are some hardcoded references to custom data. The files are:
sql/Invoice.sql
This creates another table in the database and sets up some accounts (in the accounting sense of the word).
sql/upgrade/*
These were for some one-time things. You don't need them if you just use the current Invoice.sql
CRM/Activity/*
This uses the feature where you can insert content into activities by naming the file the same as the name of the activity type, but see limitation in CRM-4936.
So it expects there to be an activity type called Invoice.
It also expects the custom fields to be as named in the Invoice.sql file.
CRM/Report/Form/Activity/Invoice.php and corresponding template
You need to add a report template for it in civi. It selects all the invoices that haven't had the report run on them yet.
CRM/Report/Form/Activity/Invoice/*
These are the files that when zipped make up an .odt file which can be opened by, e.g. MS Word 2007 SP2. The content.xml file has some smarty variables in it that get filled when you run the report.
CRM/Contact/Form/Search/Custom/ChequeReconciliation.php
After the Invoice report is run and the cheques submitted for payment, this report and the resulting form is then used to reconcile against the official records, like reconciling a bank statement.

CRM/Report/Form/Activity/ActivityFields.php
This provides access to all the custom fields for all activity types, and allows you to filter on them too. At the moment it doesn't do error-checking that the user selected combinations that make sense.
CRM/Report/Form/Contact/Demographics.php
This allows you to report on custom fields for contacts and the open case form and some built-in demographic data. It should also work without CiviCase.
CRM/Report/Form/Case/TimeSpent.php
This is a time spent report using the duration on activities. It should also work without CiviCase.

Drupal

The drupal folder contains some custom modules:

radiusauth: Based on the LDAP integration module it's how we log in using key tokens. We're using the product from CryptoCard but it's the same concept as RSA SecureID. Read the README in there if you're planning on using this since it was a quick and dirty modification of the LDAP module.

physicianhealthbc: At the moment is just a custom dashboard to display activities in a way that's more in line with how we want to see them. When 3.0 is available there will also be a customFieldOptions hook for autocomplete fields that we'll use to look up from a custom table of LOINC codes.

XML

The xml folder contains our civicase xml config files that go in CRM/Case/xml/configuration.

The .mysql and .php files are out of date and were used during the initial development phase when it was useful to be able to reload the database often. But of interest might be how we worked around the problem of setting the settings stored in config_backend in the civicrm_domain table to be portable across installs. See the .php and .mysql files for details.