Skip to end of metadata
Go to start of metadata

PLEASE NOTE - this approach has been superseded by another one - follow the link below. So the proposed developments here will not be pursued.
http://wiki.civicrm.org/confluence/display/CRM/Course+directory+in+Civi+++Alpha+International+approach

In order to use the CiviCase module in some different ways to its current conceived use, Alpha International would like to sponsor a number of enhancements for inclusion in a future CiviCRM release. We have drafted sketchy outlines for these below for comment, and enhancement, by others. They are in a rough order of priority for us. We will also flesh them out as we see comments and do further thinking ourselves.

High level overview of Alpha International needs

Alpha International supports and promotes Christian organizations (primarily churches) around the world in the running of The Alpha Course (an introduction to christianity) (and variants such as Youth Alpha) and other related courses such as The Marriage Course. Over 40,000 courses run in more than 160 countries supported by over 40 Alpha offices. As well as the churches themselves, we have a network of advisers and teams that support the churches with practical help and advice.

Apart from the general management of individual and organizational contacts for a number of general business purposes we have a specific need to record instances of courses of all types running around the world.
Courses are run by organizations and individuals who are part of our volunteer network, but they choose to run them and are completely responsible for those courses. We want to be able to communicate with the people involved and also publish a directory on our website ('Find A Course') that allows someone interested in attending to be able to identify and make contact with a course near them. But we do not run or control all these courses, nor do we track the attendees and outcomes.

Objects to be tracked:
• Course
• The hosting organization(s) of the course - normally just one, and normally just a church (but can vary - Student Alpha Course might be hosted by a University, Prison Alpha, by a prison chaplaincy, etc.)
• The venue - to allow that information to be searched for and published for potential attendees (not all courses are held at the premises of the hosting organization - e.g. churches club together to run a course at the local library)
• The course administrator(s) - normally one, but sometimes a married couple
• The course leader
• Optionally: The church leader for the hosting organization of the church
• Optionally: The adviser for the course/Team supporting the course

Properties for each object (rough list):
• Course instance - type, date they first registered with us, course name, denomination, website address, language, student friendly, published in directory or not, dates that the course has & will run
• Hosting organization - type, contact details, denomination, other people associated with the church/org (staff, members, etc.), other courses running there
• The venue - address, contact phone number and email for potential attendees
• Course administrator, course leader, church leader, adviser - contact details, involvement in other roles (organizations or teams), in other courses

Workflow(s) for adding and updating object data:
• Internal admin: - we receive a letter from a new course start-up or a new admin with updated details, we are called by an admin or leader to notify new course or changes, we receive an email notifying us of a new course or updates, a mailing cover sheet is returned to us with marked updates on. These all need processing in the admin screens.
• Admin/leader self- service updates on web (near-term requirement - not available today) - possibly triggered by mass email to prompt for updates
• Local adviser/team members self-service updates they know about for courses in their patch/team (longer term requirement)

Output streams:
• 'Find A Course' functionality on website allows a member of the public to search for courses of a specific type and denomination in a specific geography (town, postcode, country, etc.) and then find out contact details (email contact form, phone number), venue location details, and course running dates
• Internal ad-hoc enquiries for course listings, based on a diverse range of criteria (can be location, course type, denomination, status, date of course, etc.) with the full range of information about the course, the associated individuals and their contact details, or the hosting organization details
• Internal ad-hoc enquiries for people associated with courses based on a range of criteria (location, role, participation in previous events, resource purchases history) with full contact information for them, details of the role on the course and basic course information (type, name, attributes)
• Generation of statistics about the number of courses broken down by location, type, denomination, date of set-up

Example data
Attached is a document showing:

  • example of course data held in our current system (you will see this is a little clumsy, if at least comprehensive)
  • example of outputting a flattened set of data for a course in our current system (relating to requirement 5 below)
  • example of the course directory entry on our website
  • example of how we have tried to hold the equivalent set of data in Civi as it stands

1. Organisations in Case [already in development]

At present, the CiviCase module is designed and coded around individuals being the client of cases and being associated with cases through 'Case Roles'. For a number of applications of the Case module in different situations, it would be necessary for the Case module to correctly handle organisations as clients or associated entities through 'Case Roles'. This leads to two highly inter-related developments.

Organisation as client

At present the code allows the creation of a Case with client as organization. But the workflow does not allow connection of anyentities through Case roles. It ispossible to select a role and the individual you wish to associate. But this selection/assignment is not actually saved onto the case record.

Development is required so that when a case has an organisation as its client, and the case role defined in the 'Relationship types' admin area with the contact type B as organisation (contact type B is relates to the case client), then the code behind 'assign case role' should correctly allow for the case client (the B end of the relationship) to be an organization. The workflow remains unchanged, but the role assignment is correctly saved and displayed.

Organisation as Case Role

At present, the 'Assign Case Role' code always searches individual contacts, and not organisation contacts. Relationship types can be set up that should join in organisations.

But the code still searches individuals.

Development is required so that the code behind 'assign case role' to use the 'Contact Type A' (individual/organisation) to determine whether to search and assign an individual or an organisation.

2. Custom fields on Case

In v2.2, it is possible to create a group of custom fields for an Activity associated with a Case. These are then made available when you create or edit a Case Activity.

However Alpha would like to be able to add a group of custom fields to the case itself, so that when you create a new case, or manage a case you can see and edit those custom fields.

The group and fields would be created in the normal way and associated with the Case module (new option under 'Used for'). The fields would show in the same style as for other custom fields groups as a separate collapsible section in the 'Manage Case' page - maybe just below the 'other relationships' section?

3. Location link from Case

We would like to be able to create a link to a full set of location information for a case - at the case level (rather than the single location field in the activity that is available in 2.2). We imagine that this is best achieved using entries the loc-block table to join to the address, phone & email tables. In terms of user experience we had imagined that a 'Case Location' link on the main 'New Case' and 'Manage Case' screens would link to a 'Case Location and Contact Information' page that mirrors the 'Event Location and Contact Information' page. This would operate in the same way for the user too.

4. Case search upgrade to include custom fields and location

Once the case link to custom fields and the case location link have been included on the case module we would want to these fields to be exposed to the 'Find Case' page. Possibly this could be done in a similar fashion to the contacts 'Advanced Search' page whereby address fields and custom fields would be in separate expandable sections underneath the main search box.

5. Case/contacts export upgrade to include case roles

Once the search facility can return more complex searches of cases, we would like to upgrade the export capability so that a case search could also export the contact associated with the case through a particular (specified) role type, or a contact search could also export case details of a case associated to the contact through a (specified) role type. [This may need some further expansion if it does not make sense read cold!]

6. Views2 over Case

We would like to develop the Views2 Civi integration capability to include the Case module itself (and associated custom fields).

7. Profile over Case

This requirement needs some further thought. We know that we would like to streamline the data entry/updating of cases to ensure it is easy for infrequent users of the system. We have yet to establish if a custom Case page could achieve this, or whether it might be more effective to extend the 'Profile' capability to cover Case so that we can build streamlined entry/update pages. This might be complex due to the need to operate on case roles, case activities, etc.

Labels:
  1. May 08, 2009

    D D

    Just wanted to comment on #2. We purposely did not have fields at the case level to enforce the concept that the act of deciding what value goes in those fields is itself an activity, or is the result of a set of activities, that should be recorded at the activity level as part of the case story. However there was a phase 2 candidate (that got postponed) where you would be able to specify which of those should get summarized on the manage case screen, which would effectively result in the same thing as case-level fields but without losing the activity detail.

  2. May 28, 2009

    Hi,

    I met with Marcus last week and we had a chat about his requirements and CiviCRM in general.  Here are my opinionated thoughts on how I would model this data.  It's actually an alternative approach that uses organisations rather than cases.  I know this is moving it away from its original focus of this project on CiviCase (so feel free to tell me to but out) but I wanted to outline it here to see what you think.  I hope it is helpful.

    If you were to model this as an organisation, you would still want to add some features to CiviCRM, but not as many as you would need to if you modelled it as a case (in fact 2 to 7 are already possible for contacts).  Another reason why I don't see it as a close fit to cases is that to me cases are in essense about associating activities with contacts, and I don't see any activities in this model.

    If I generalise and simplify Marcus's model, what I come up with is:

    Associate a set of contacts together for a specified period of time in a structured way and define properties about the association

    That sounds like an organisation, right? if a little less permanent.  Here is how I would model it:

    1) The objects associated with the course (which is an organisation) can be tracked via some relationships like

    • Is hosting organisation / hosts course
    • is course administrator / administers course
    • Is course leader / leads course
    • church leader for the hosting organization of the church / [can't think of the reverse for this one right now!]
    • adviser for the course/Team supporting the course [ditto!!]

    2) Some of the properties of each object would be handled using core organisation fields (name, website).  Other properties could be added as custom fields (e.g. type, date they first registered with us, denomination, language, student friendly, published in directory or not, dates that the course has & will run).  Custom fields for other related contacts would be added to that contact record.

    3) The venue can be added as a location (organisations already have this)

    There are ways in which you could enhance the contact / organisation model to improve this.  They include:

    • Ability to define a sub-type for organisations (I see there is already a field for this in the database!)
    • Set relationships to only be available to particular contact sub-types (you can already specify them as only available to a particular contact type)
    • Set custom data to only be available to particular contact sub-types (you can already specify it as only available to a particular contact type) - everyone would love this feature (smile)
    • turn off uneccesary core fields for organisations/contacts, so they look more the kind of contact they are modelling
    • Set up a predefined set of relationships that a certain contact sub-type should have (e.g. all courses should have an administrator) and allow them to be set / created when you create that type of contact
    • Be able to set a limit on the amount of relationships that an organisation can have (an course can only have leader, for example)
    • View relationships on the organisation summary page.

    Sorry to throw a spanner in the works! - what do you think abou this?


Creative Commons License
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-Share Alike 3.0 United States Licence.