Sorry that the regular meetings have died out a little, things have gotten busy :D We had a small ad hoc meeting about labellling entities.
In less detail I think when we have sorted out labelling we'll be able to release a basic CRM system. After that I think I'll try and push more maybe slightly less regular monthly meetings again.
Here is my write up:
Random Adhoc CRM meeting
David Connerth - wanting to get more involved
Clare Lindey - wants to try and understand CRM stuff
Joachim- hanging out
Rob Mumford
Andrew Belcher
Jamie Abrahams
Had a conversation about Party Labels,
Most entities have a field that acts as a label. This is useful for things like views or especially autocomplete widgets.
However a "Party" doesn't have an obvious label that is consistent. The first would be the name. But then some leads don't have a name yet, some parties will just be the e-mail, some will just be a number.
So we discussed the idea of having a party label that could take different labels (So look to the name first, then e-mail, etc) and then an "anonymous label"
Joachim: Fatal Flaw: The "anonymous" label that would be idea is using the entity ID as its label for example "Party 4". But the problem is that when you save an entity you don't know its ID.
David connert hand Joachim: Discussed making a plugin system but thought that acutally Tokens is good.
Mumford: We think we want the plugins to go in order. So that you can fallback onto different fields.
Joachim: This suggests a set of plugins that can be dragged and dropped to find its order
Andrew: Bit more complicated. You want reuse some of those plugins. So really you want to reuse tokens in each plugin and then reorder that.
Disscussed how saving for the first time is definitely really difficult.
Mumford: Entities have controllers that do things like "Save, Load, View". Every time the party controler is used (when it is saved) it throws things to a plugin system.
Joachim: Maybe we need to look at lazy loading in controller?
Belcher: You don't want to be firing this every time you save, when the entities that they have been fired off haven't been changed. the Plugins get fired when the attached entities get saved.
Every time you save the party, the party will want to make sure.
Jamie: Talked about how can make it so that it stops at the first label.
Mumford: Lazy loading attached entity controllers.
Mumford: If you split the label generation from entity save. This could help.
Solutions:
1) Label generation to happen after Save
2) Different "Label plugins" can happen in a specific order
3) Multiple "Label Plugins" that use collections of Tokens
4) When I edit a party. It looks for the first plugin that gives it a label.
5) We a UI to make this. That is exportable.
6) Default is "Party + Party ID"
7) PartyLabelUnset = Default label that happens on entity create
Multiple configurations of one plugin needs to be done
Want to lazy load attached entities
Rob is going to focus on building this
David Connerth is going to go and try and build the UI for it and making it work with tokens.
David Connerth wants to get Unit Testing into it.
David Connerth will make a test for the labels.
Background stuff:- Newsletter research is happening with activities
Discussion of "Party Mail"
Jamie: Do we use simplenews? My definition:
1) Newsletters- Individuals opt into it and then rechieve regular updates
2) Party Mail - Website chooses who to send to and send it to
Joachim: Simplenews might have an API behind it that will do 2).
Template Newsletter and every month it gets sent out - simplenews scheduler
Jamie: Tracking Bounces is a big thing. Is that in simple news?
What about "batching process" if I'm sending to lots and it breaks half way through.
Andrew: Might need to look at something like php mailer.