One of the challenges with CRM parties is the common requirement that a party belong to multiple types.
It's all plain sailing to start with: a party is either a person or an organization. But below that it all gets complex. Consider a person in different use cases:
- Church CRM: a person may be a member, a volunteer, a preacher (see http://groups.drupal.org/node/142079)
- Political party CRM: a person may be a constituent, a party member, a representative.
- Small business CRM: a person may be an employee, a customer, a lead, a contact for a business relationship (eg a supplier)
Furthermore, a person may move in an out of different types as time passes.
It seems to me that the entity type system doesn't match well with this:
- it's hard to change entity types
- an entity can't be of multiple types at once
- there's no hierarchy of types
What we have, rather, is more the way that Drupal users can have multiple roles. But I don't think that overloading the role system with this is a good idea. For starters, parties are not necessarily users. Also while permissions certainly come into play here, it's more about what kind of data parties can have.
I was pondering what to call these, and I came up with 'hats'. As in the definition: "A particular role or capacity that a person might fill", and as in the expression "wearing several hats". This doesn't seem to be uniquely British, so that's a good thing (see http://en.wiktionary.org/wiki/hat#English).
So what we have as I see it is:
- multiple profile2 entities of different types. I visualize these as different sheets of paper in the folder for that party. Or different pages in a passport. And in the Drupal UI, different tabs on the party page.
- multiple hats, which determine things like:
- which profiles the party may have
- who can edit the data
- who can view the data
- how other modules interact with that party
Thoughts?
Comments
Yautja_cetanu and I were
Yautja_cetanu and I were literally talking about this yesterday.
So as far as I understand it, the Genus kinda which Profile types the party can have and Permissionsy stuff, but exists as meta data on the Party. Is that correct?
We would also want to filter views and things by Genus, so we need to implement a filter somewhere. If this were a special 'field' on the party that would be pretty easy. What other interactions would the Genus have a say in? If using panels, you would want it to be possible to have a different page layout for every Genus, and I suppose you might want different path-auto settings for every genus as well. (So it looks like I've answered my own question with "anything that deals with types needs to know how to deal with hats"
What would happen if hat A and hat B both allowed the Party to be connected to a Profile type C. Would the party need two ProfileC's? If so, how would we know which one belonged to which hat? Would a party need 1 of the profiles and the hat "share" them?
My question would be
My question would be...how far away have things moved from this model:
http://groups.drupal.org/node/89779?
In my mind, "hat" and "genus" are basically synonymous.
Not sure why you'd want a different page layout for every Genus...simplicity and consistency so the users can find what they're looking for every time they open the application.
I'm not sure I want to like this, but...
I certainly can't come up with something better, not to mention it makes me like the term "party" a bit more. Going over it in my head, the concept of a "hat" seems relatively easy to explain to different types of users. Also, if it necessary to develop an icon, there would certainly be no confusion.
I've been going through some of the other discussions regarding entity vs profile2 and I can't stress enough how important it seems to be able to attach (and later detach) multiple profiles to a party/contact entity. For example, consider a non-profit organization, a school in this case, where all of the members of the Association are parents. The Board is composed of parents elected by the Association, as well as a few members that are appointed by the Board from the surrounding community. When a parent is elected to the Board, you don't want to remove their Parent profile, as there may be multiple processes in place tied specifically to their role, excuse me, "hat", as Parent. However, as Board member they would need access to an entirely new bundle of rights. This is, of course, just one very specific example, but as you noted above, virtually every organization is going to have similar issues.
I guess what I'm not hearing is the compelling case for NOT using Profile2 and converging on this approach.
That's a really good use
That's a really good use case! Thanks!
Me and Rob have spent quite a
Me and Rob have spent quite a bit of time trying to make sense of "hats" compared to genus.
There are a couple of issues we're trying to figure out:
1) How information is displayed (Tabs on a user page, etc)
2) How people are categorised in an abstract sense (teacher vs student), which is hats or genus potentially
3) How permissions are dictated (Maybe could be see as how things are seperated at an architecture level?)
So for example we may have 2 people in an IT organisation. One is a "Developer" the other is a "Systems guy"
1) Both will have the tabs "Personal information" and "Work" that should probably be seperate
2) Both will wear different hats, "Developer" and "Systems Guy" which will dictate what information appears in the work field. But they will also both wear the same hat "Employee" which dictates some common information in the Work Tab.
3) Permissions stuff:- This is the more complicated bit. The developer may have some fields that they should change themselves such as "Preferred IDE" but may have other sets of fields that a project manager is supposed to edit such as "Current Client they are working with". They are allowed to see this information in the work tab but just not edit it. Whereas the Systems Guys will have all the fields in work editable themselves.
I feel like me and rob are diverging a little here. We're treating the profile2s as bundles of data that can be put within tabs. It seems like you and the original architecture are treating profiles2 like the tabs themselves. (Essentially whereas for you profile2s are sheets of paper in a folder. For us Profiles2 are sheets of paper, with the tabs being dividers in a folder).
The main advantage of this is that "Work" tab can be dynamic depending on your hats, but also have things in common depending on hats.
It also means that if permissions are applied to the profiles2 then they can be granular to the level of sets of data. It also seperates out how things are displayed to how things are handled by Drupal. The main issue is that it adds another layer of complexity (The Tab) and means you'll have many more profile2s to deal with for permissions. Me and Rob have just started working in this direction, but I don't think we fully understand the actual use-case of why this added flexibility (if it even does add flexibility) is important.
I'm just going to also throw this out: http://drupal.org/project/field_group These may be able to achieve something similar to what we're currently doing with profile2.
So the idea with genus was it
So the idea with genus was it was basically inheritable bundles.
You'd have a 'parent' type, and then a 'board member' type would inherit the same fields.
With the genus model, an entity is probably still only of one type.
The hats idea is a more flexible approach, as the use cases discussed above seem to show. It probably supplants the genus idea, but never say never ;)
The original architecture was one profile2 per tab. and you're right, that is probably not sufficient.
I think what we need for the Party UI is an updated version of the Drupal 6 user tabs API, where any module could declare it had a category (== a tab) to provide. But a much better version of that API (which was a nightmare to work with!!!).
Then: