Author Topic: How to accomplish complex fields? (Read 5198 times)

linolium · May 29, 2008, 02:44:01 pm

Hi there,

I am trying to implement an add-on to the CiviMember module. I would like to set up Membership Benefits, with the following properties:

- name
- discount enabled?
- discount percentage

Each Membership Type can have any number of the Membership Benefits enabled or disabled.

I have looked into using the "Custom Data Field" feature, but it looks like this could only work for simple cases where there is no extra information like the "enabled?" property.

I know this may seem trivial and I should just forget about that property, and use "0" for the discount percentage when there is none, but I have some potentially more difficult cases with more fields.

How can I accomplish this? Essentially I need to have a table with some information, and associate one or more row with Membership Types. Do I need to completely hack it into the core code? (i.e. create a file called civicrm/CRM/Member/DAO/MembershipBenefit.php, modify and create a whole bunch of templates, etc.)

Or is there a cleaner way of accomplishing this?

Thanks for your help.

Donald Lobo · May 29, 2008, 04:24:23 pm

1. how would you use the information in membership benefits?

2. if creating a new table, you will need to add stuff to core and extend CiviCRM. In v2.1 we also allow admins to set their own include path, so they can add custom php files (similar to custom template files)

3. To a large extent your design/implementation depends on how you will use benefits. If only on the drupal permissioning side for content, then i suspect u can get away without hacking core.

if you get on irc we can chat a bit more on this

lobo

linolium · May 29, 2008, 10:20:34 pm

Hi Donald,

Thank you for your support. Here is the complete specification document for Benefits that I need to implement. I'll be on IRC from 9 AM to 5 PM PST tomorrow; send me a message if you are around and I will be sure to respond.

http://linolium.mine.nu/storage/specs.doc

Donald Lobo · May 29, 2008, 11:18:04 pm

its a long weekend in NZ, so i'll be travelling and spending time with family. i'll be online sporadically till next tues / wed

lobo

outinsun · September 13, 2008, 10:30:55 am

Quote from: Donald Lobo on May 29, 2008, 04:24:23 pm

3. To a large extent your design/implementation depends on how you will use benefits. If only on the drupal permissioning side for content, then i suspect u can get away without hacking core.

I am considering using CiviCRM. I also would need to support complex fields. Have not actually done anything with CiviCRM yet. Am wondering how difficult it would be to implement complex fields, or for that matter a simple field data type beyond the ones built in. Do I take it right that either would be a matter of hacking and slashing down in the bowels of core?

Donald Lobo · September 13, 2008, 11:46:21 am

you might want to expand what you mean by complex fields. In v2.1 we've introduced the concept of "associating php code with a custom group" which you can use to implement complex fields. You can read more about it here: http://civicrm.org/node/356

lobo

outinsun · September 15, 2008, 09:51:57 am

Quote from: Donald Lobo on September 13, 2008, 11:46:21 am

you might want to expand what you mean by complex fields. In v2.1 we've introduced the concept of "associating php code with a custom group" which you can use to implement complex fields. You can read more about it here: http://civicrm.org/node/356

lobo

Think of it as a struct as opposed to scalar. In addition to knowing that Fred's member number is 12345, I also want to know that he become a member on 1/1/2008, that his membership expires on 1/1/2009, and that his membership level is Platinum. None of these attributes could be computed using PHP code. I may want to have multiple structured fields, so just creating atomic fields called member_number, member_join_date, member_expiration, member_level, while doable, seems crude and inadequate.

outinsun · September 15, 2008, 09:59:25 am

Quote from: outinsun on September 15, 2008, 09:51:57 am

Quote from: Donald Lobo on September 13, 2008, 11:46:21 am

you might want to expand what you mean by complex fields. In v2.1 we've introduced the concept of "associating php code with a custom group" which you can use to implement complex fields. You can read more about it here: http://civicrm.org/node/356

lobo

Think of it as a struct as opposed to scalar. In addition to knowing that Fred's member number is 12345, I also want to know that he become a member on 1/1/2008, that his membership expires on 1/1/2009, and that his membership level is Platinum. None of these attributes could be computed using PHP code. I may want to have multiple structured fields, so just creating atomic fields called member_number, member_join_date, member_expiration, member_level, while doable, seems crude and inadequate.

On second thought, perhaps I have missed the point. I've been looking at custom groups as large-granularity buckets in which to group custom fields. I don't know how scalable the custom groups mechanism is, but I suppose I could create a group called "member" with "number", "join_date", "expiration", and "level" as fields within that group. Can I then do a query which is the moral equivalent of member.expiration? What happens if I want to have two instances of "member" (i.e., a contact is a member of two organizations and I want to track both memberships)? Or am I just abusing/misunderstanding the nature of custom groups?

Am very much a CiviCRM noob, so please excuse my ignorance.

Donald Lobo · September 15, 2008, 10:43:29 am

Each custom group has an associated dynamically created table with it. Each field in the custom group is represented as a column in that table. As such the custom group/field structure is fairly scalable (IMO). You might want to skim thru http://civicrm.org/architecture/

You can mark various fields as searchable. For custom groups associated with contacts, they appear on the main search form. For other components, they appear in the component section (custom groups on activities/groups/relationships are not searchable). You can also write a "custom search" for your needs

A contact can be a member of 0 or more orgs (i.e. there is a 1..n relationship between memberships and contact), so that fits into the model quite nicely

lobo

outinsun · September 15, 2008, 10:55:47 am

Quote from: Donald Lobo on September 15, 2008, 10:43:29 am

Each custom group has an associated dynamically created table with it. Each field in the custom group is represented as a column in that table. As such the custom group/field structure is fairly scalable (IMO). You might want to skim thru http://civicrm.org/architecture/

You can mark various fields as searchable. For custom groups associated with contacts, they appear on the main search form. For other components, they appear in the component section (custom groups on activities/groups/relationships are not searchable). You can also write a "custom search" for your needs

That sounds very cool.

Quote

A contact can be a member of 0 or more orgs (i.e. there is a 1..n relationship between memberships and contact), so that fits into the model quite nicely

"Membership" was actually just an example of a kind of complex field I might need. However, it occurs to me that I can (as you say) model membership using relationships, and I can (I think) add custom fields to relationships, so I could in fact model the complex member structure from my example using custom relationship metadata. If I have this right, then that is VERY cool.

Nice piece of software, BTW.

Donald Lobo · September 15, 2008, 11:38:26 am

Note that there is a CiviCRM component called CiviMember which manages memberships. Check the docs, http://wiki.civicrm.org/confluence/display/CRMDOC/CiviMember+Admin for more information

i used the word "relationship" in a database context and not in a civicrm context. You might want to use CiviMember to get a head start on modelling memberships

Currently custom groups does not allow multiple values per "contact id" (or the object its extending). This is a feature that will be implemented to some extent in 2.2 (or so we hope)

lobo

outinsun · September 15, 2008, 12:15:01 pm

Quote from: Donald Lobo on September 15, 2008, 11:38:26 am

Note that there is a CiviCRM component called CiviMember which manages memberships.

OK, after some experimentation it looks like Custom Groups will suit my need for structured data quite nicely (ignoring the issue of data specific to managing memberships). The only thing that bugs me is that Custom Field names must be globally unique. I can't have two different groups both of which have a field called "Expiration". Certainly not a deal-killer but it would be nice if field names were scoped.

Donald Lobo · September 15, 2008, 01:20:12 pm

this has been fixed in v2.1

lobo

outinsun · September 15, 2008, 02:04:23 pm

Quote from: Donald Lobo on September 15, 2008, 01:20:12 pm

this has been fixed in v2.1

lobo

Sweet. Thanks.

outinsun · September 15, 2008, 03:17:52 pm

Quote from: Donald Lobo on September 15, 2008, 10:43:29 am

Each custom group has an associated dynamically created table with it. Each field in the custom group is represented as a column in that table. As such the custom group/field structure is fairly scalable (IMO).
lobo

In http://civicrm.org/node/150 you caution against creating more than 20 custom fields per object. Is this constraint still true (the posting is pretty old)? I assume you mean total number of custom fields, across groups? What is the recommended limit on number of custom groups?

CiviCRM Community Forums (archive)

News:

Author Topic: How to accomplish complex fields? (Read 5198 times)

linolium

How to accomplish complex fields?

Donald Lobo

Re: How to accomplish complex fields?

linolium

Re: How to accomplish complex fields?

Donald Lobo

Re: How to accomplish complex fields?

outinsun

Re: How to accomplish complex fields?

Donald Lobo

Re: How to accomplish complex fields?

outinsun

Re: How to accomplish complex fields?

outinsun

Re: How to accomplish complex fields?

Donald Lobo

Re: How to accomplish complex fields?

outinsun

Re: How to accomplish complex fields?

Donald Lobo

Re: How to accomplish complex fields?

outinsun

Re: How to accomplish complex fields?

Donald Lobo

Re: How to accomplish complex fields?

outinsun

Re: How to accomplish complex fields?

outinsun

Re: How to accomplish complex fields?