We now have a party label field in the crm__party table, which going by the comments represents the party's full name.
Given all the ways there are of storing names, I wonder whether this is a bit restrictive.
On the other hand, without it, the only thing we have to name a party is the numerical ID which is hardly inspiring or useful.
I can think of several different ways a CRM site may want to label parties:
- full name
- email address
- username, for sites where every party is a user
I think party module should provide a framework where different modules can provide a label, and a configuration option where you pick which one to use.
We could have:
- pick a particular field: name, email address, etc.
- username
- other things I've not thought of yet
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 1299914.parrty.label-plugins.patch | 3.58 KB | joachim |
Comments
Comment #1
rlmumfordI think I aggree with this. My plan is to take some of the work done in crm_profiles module and put it into the crm_party module so that we end up with an api that allows other modules to define "Data Sets" (which at the moment are always profiles 2's or users, but could be facebook data/ civicrm records etc). What we'd end up with is some hooks such as:
hook_data_set_info()
hook_data_set_display($delta)
hook_data_set_form($delta)
And I guess somewhere in that API we could allow the modules so pass certain fields to the party label. We do need a label though, especially if we eventually want to ever have party autocomplete boxes.
Just to make what I was saying about the data set api clearer, crm_profile might implement it like so:
Comment #2
joachim commented> We do need a label though, especially if we eventually want to ever have party autocomplete boxes.
Yes, we do.
But what I am suggesting is that the system for the content of that label be pluggable.
So for example:
crm_party_user provides a label plugin that uses account names. Your CRM site sets this plugin as the label provider. Party autocomplete fields on your site work on account names, and party lists and single party pages show that as their label or title.
Other plugins could work on email address or real name or surname -- though they would need configuration to tell them which field on which entity to use.
For sanity and performance, I think we should keep the label column in the party table, and the label plugin populates that whenever a party is saved.
Comment #3
rlmumfordYeah that works. We'd have to write code so that if the label settings changed it filtered through every party, but that wouldn't be too difficult.
What do you think about the data sets idea?
Comment #4
joachim commentedI started a new issue for that: #1301852: party display: party pieces and data sets. Lots to ponder! :)
> Other plugins could work on email address or real name or surname -- though they would need configuration to tell them which field on which entity to use.
Given label generation should be done with plugins, I've filed #1301854: plugin system too.
Comment #5
joachim commentedHere's the patch I've just committed, for reference.
Needs more work:
- label should be stored in the DB on party creation/update -- currently I'm just doing proof of concept on the party admin page.
- need some actually useful plugins -- currently just a POC returning the party id ;)
Comment #6
joachim commentedNote we now depend on CTools. But since Views does too that's no bad thing.
Also, my patch above seems to have been made by pirates !?!?
Comment #7
yautja_cetanu commentedHave we solved this here: #1498300: Solving the Label Problem?