Agenda
- Should we rename Household to Family (refer to mail from Bob S to crm-dev regarding this)
- Address storage ("delivery line + blob" vs. "line 1, line 2, line 3...")
- Primary Organization Contact (Andre), Primary Address (Aaron). The same issue has cropped up in different contexts. In both these cases, the organization / individual needs to have one entity to take action on. Whats the scenario where we need multiple "primaries" and how do we handle them? If we agree on 1 primary contact / organization, why does it make sense to keep this relationship somewhere else?
- Other changes that you would like at the physical level (andre)
- (possible item if time allows...) Follow-up on the 'interest area' / 'tagging' thread from the past few days and evaluating whether the current entities in the Data Model (groups, relationships and extended properties) cover a majority of use cases.
Meeting Summary and Outcomes
Attendees: Howard Johnson, Andre Molnar, Bob Schmitt, Dan Robinson, Donald Lobo, Dave Greenberg
We covered items 1-4 on the agenda above. Based on the range of input to date, our current thinking on these items is:
Household as Super-type
Although Household/Family could be modeled as another type of organization, we will retain the super-type distinction for it's utility in communications addressing and fund-raising functionality. For a more detailed argument on this check http://lists.caltha.pl/pipermail/crm-dev/2005-February/000147.html
Household vs. Family
We believe that the Household entity can be used to model both physical households (including 3 unrelated people living at the same address), as well as 'families' (in whatever manner an organization may wish to define or limit them). We will retain the data object name 'Household' - but provide usage examples and relationship types for both 'physical households' and 'families'. Note that relationships are independent entities from Contacts. So an organization treating the ContactHousehold as a family unit, would still need to add relationship information between the various individual entities.
Organization Types
We are tentatively adding a generic hierarchical categorization capability to the data model which will allow organizations, (as well as individuals, households, and groups) to be assigned to one or more categories.
For organizations, this could be used to label them as 'Company', 'Non-profit', 'Governement Entity', etc. We will provide a set of built-in categories for this purpose (although they will be modifiable).
NOTE: We are implementing this as 'categories' rather than 'types' or 'sub-types' because typing implies modifying or extending object properties. We will also be evaluating this approach relative to the Drupal taxonomy model to see if there are additional concepts we should be adopting.
Physical Data Model Changes
Andre Molnar has posted specific recommendations for modifying the physical data model, and we will be reviewing them and discussing further w/ him.
Storage of Address Data
We will add granularity to the data model in support of use cases like "walk lists" which require it (esp. storing street number separately - and AS a number). The objective will be to support maximum granularity in storage while minimizing data entry burden and supporting data acquisition from sources that do NOT have the same level of granularity. We are considering adding: StreetNumber, StreetName, StreetSuffix, UnitType and UnitNumber as additional fields in the address table. This will allow applications which have the above detailed information to store such detail without additional parsing overhead.
