What makes Party Special - (particularly with crm_core in mind)

Hi zulfierken,

I've been working with rlmumford who has worked quite a bit on party. We're actually working with a client that is managing people who are doing a specific course at university which I suppose is close to school management.

Another client is requiring CRM and for this client I'm going to have to decide whether its best to use crm_core, party or a hybrid of the two. Obviously my personal feeling is I prefer party cause I've been involved in it but I need to objectively consult here and so we're putting together a document comparing the two interanally to present it to our clients. Currently crm_core definitely has more polish and whilst party provides more flexibility, the question is whether party's flexibility actually matters?

Regarding a roadmap.

The biggest thing we're working on is getting party labelling to operate correctly. We are actually using party on a site that went live yesturday and so we will certainly be making sure our website works and keeps all its data. But we can't test it in every situation and can't garantee it will work for you, we can just tell you how we did it.

In terms of features once labelling is finished we'll be focusing on party mail and party activities. These are kind of bolted on features that won't effect the core of party much.

We are planning to develop a seperate crm package from crm_core at the moment for largely political reasons. We (party people + crm_core people) have talked quite extensively in the past and its just easier to work on your own thing, we may merge in the future if it makes sense to but party and crm_core have been built from the ground up in fundamentally different ways. (CRM_core uses entities as is, and uses bundles for contact types, party makes a kind of wrapper entity that collects lots of different drupal entities including user onto the party entity. This sort of allows you to dynamically change your contact types)

Will post more when I've written this document.

So the first question is what makes crm_core special

- A very simple UI to do useful things (like add fields)
- Very easy to grok as it pure drupal most of the way
- A large company behind it and growing momentum (videos, other organisations joining with it, a student system based on it) https://github.com/csumb/drupalStudentCRM

So What makes party special?

- Parties can have multiple types (sets of fields) and party types can change over time.

Is that right? As far as I can see that is the main inherent advantage of party? I feel like party may have advantages when it starts integrating with other stuff (like customers, or facebook).

Now my understanding is that really a new "type" is just a collection of fields that can be attached to a party or not. A Student will have a student ID but a teacher will have a national insurance number.. I do this this is an advantage of party but I think not everyone will want it. So could we make a module that sits on top of crm_core and does the same thing.

This is an example of how I think it could be done:
- Make it so that contact entities in crm_core have all fields attached to it (student ID and national insurance)
- Make a taxonomy term for our hats (teacher, student)
- Use Conditional Fields to only show fields depending on their hat in the edit contact form
- Make a different view for teachers and students that only show the fields that are relevant to the particular hats.

Isn't that Hats built on top of crm_core? What else makes party special?

I think that's pretty much described it.

What we've tried to get into party at the lowest level is two things that to me are a pretty important aspect of working with data about people:

- contacts change over time
- contacts can be more than one type simultaneously

So a volunteer can later on become an employee and gain those fields, or be both at the same time, for instance.

Thanks alot for your comparison zulfierken!!! Thats really helpful! So it seems like there are 2 advantages:

1) Party allows you to use your own entities from your own modules to store information about a contact rather then having to work with the entities the module provides. (Eg Customer entities from commerce)
2) Party allows your contacts to have multiple contact types and change types arbitrarily.

Hi - checking to see if anything since your last review. Also, please do you have any links for the demo?

Hi zeezhao! thanks for the interest.

The demo online is hideously out of date now - I'm going to try and get something up soon. I did a live demo of building a site with Party at the Brighton Drupal Camp last weekend and I think that was recorded. As soon as the video is online I'll put a link here for you.

Thanks. Will await video link.

Not sure there is any point keeping this open...