User should be able to define bundles similar to the content types for nodes. - Copy most of model stuff
within model type somehow set how to get the standard label for widgets

Comments

chriscohen’s picture

chriscohen commented

+1 for this.

I think the most basic one would be "Individual" representing a single real human being. Others might include organisation and household, and possibly others.

Is there scope for subtypes, such as individual/child, individual/student, individual/employee, etc? Each of these might potentially have different fields.

I think the CRM core (and immediate focus) should be on providing the individual, and introduce others as a secondary concern.

Another small question: is it vital that a CRM has an "individual" type? Could a CRM exist without one? This decision might affect where this code ends up.

rlmumford’s picture

rlmumford
Primary language English
Location Manchester
commented

yautja_cetanu and I chatted about this.

- We're gonna try and get party types working.
- Make a Individual party bundle and field it.

rlmumford’s picture

rlmumford
Primary language English
Location Manchester
commented

So we probably need to fire up the discussion on this a bit more. Entity api doesn't support sub-types out of the box :/ so theres not really much scope for it. We could maybe fake it by categorising our bundles (using taxonomy?) or naming are bundles in a particular way (for example individual:child, organization:non-profit) etc. I'm not sure if the benefits of sub types outweighs the cost of development to be honest.

One of the things I think we do need with types (particularly when working with profiles) is:
What profile types can they have?
How many of those profile types can they have? (A family party might have many personal profiles but an individual will only have 1 for example)

what do people think?

joachim’s picture

joachim commented

Subtypes would be a big thing to develop -- see this core issue too #100925: Add "OO" bundle inheritance features.

It was discussed at Copenhagen, and we came up with the idea of a module that lets sub-types inherit the fields of their parents. Presumably we'd use the same kind of functionality as Features does to bake fields into types automatically.

> (A family party might have many personal profiles but an individual will only have 1 for example)

That's probably not the best way to store the data. Rather, a family would have relationships (or reference fields?) to multiple individuals.

rlmumford’s picture

rlmumford
Primary language English
Location Manchester
commented
Title: Party Types » What Party Types Should Exist

So we now have Bundles and Hats. Which is our answer to ChrisCohen's sub-types. We do need to have a discussion about what bundles we have though.

At the moment we have Individual and Organisation.

What about 'Household'? Or 'Lead'?

joachim’s picture

joachim commented

I don't like 'lead' because a lead can change into something else. Party types should be immutable.

rlmumford’s picture

rlmumford
Primary language English
Location Manchester
commented
Version: » 7.x-1.x-dev
Status: Active » Closed (duplicate)

Marking as a duplicate of #1557848: Drop Party Bundles Altogether [BADCampUK Discussion Outcome]