As part of the 2.1 release cycle, we are working hard to simplify and streamline the codebase wherever possible. The intent is to increase performance, reduce the number of bugs and make the code easier to understand and maintain.
As part of this effort, we are considering the elimination of two "features" which create (potentially) unnecessary complexity in the code, AND which we believe to be infrequently used...
Store Data for Multiple "Domains" in a Single Database
The current data model allows you to create and maintain separate "data silos" ("domains") in a single CiviCRM database. This concept was derived from Drupal's multi-site table-prefixing model - although it uses foreign keys instead to link each domain's dataset.
Over the past few releases, we have seen quite a few use cases where larger hierarchical organizations want to control access to subsets of their data - based on a user's departmental or regional affiliation and/or role. However - the current domain model does NOT address this issue - since data in each domain is completely separate and there is no concept of hierarchy, inheritance of permissions etc.
We have yet to hear of a use case for the current multi-domain data model that couldn't be handled just as well with separate database instances. Given that keying all data by a domain_id adds a layer of complexity to the code and to queries - we are seriously considering eliminating the feature in 2.1.
If you are currently running multi-domain installs - i.e. you've got more than one record in you civicrm_domain table and multiple instances of civicrm.settings.php which "point" to different domain ID's - please let us know ASAP by commenting here. Include some background on your install - with an explanation of why you've chosen to use the multi-domain option.
Organizations as Drupal Users
Several releases ago we introduced a hack which allows Drupal user records to be created "as Organizations". Normally in a CiviCRM-enabled Drupal site, an Individual contact record is created and linked to any newly registered Drupal user. However, passing a special parameter to the Drupal registration form (ctype=Organization) changes this behavior - and an Organization contact record is created instead.
This "hack" was an attempt to handle situations where "our members are organizations". In reality, "organizations" do not interact with websites - people who work in organizations do that. AND creating an "organization user" implies multiple people sharing login credentials - not a good practice.
In 2.1 we have implemented a different approach which we think is better - allowing individuals to signup and renew memberships "on behalf of an organization". Using this approach, one OR multiple people can have a permissioned relationship with an organization - which also allows them to view and update information about the organization. You can read the
detailed specifications here, and information on the new
permissioned relationship model here.
Given the improved "solution" in 2.1 -
we are planning on eliminating the ctype=Organization hack. If you are currently using this technique - please let us know ASAP by commenting here. Include a description of how the new 2.1 features do (or do NOT) meet your requirements.
Comments
I used this in one install a few years ago and found it was not worth the trouble and have not done so since. I recommend simplifying by dropping this feature.
I think the other hack is also best done away with as suggested.
I take the point that multiple databases can happily replace domains - We use domains. Does anyone have smart ways of migrating away from this model?
We have a client with some Drupal user accounts that represent organizations for use with a custom module. Didn't know about this hack before this blog post, but it would be useful have Org Users associated with Org contact records.