Author Topic: Defining the contact that custom data applies to in a report (Read 1497 times)

Michael McAndrew · September 21, 2010, 06:55:39 am

Hello there,

Here's a question about reporting that has come up a couple of times for me and I think should be generally useful. It's come up for me in the relation report but I'm asking here in regard to the activity report.

By default the activity report allows you to look at Source Contact, Assignee Contact, and Target Contact.

When you extend it to include custom data about a contact, it assumes you mean custom data about the source contact but I want it to extend custom data about the *target* contact.

I have a hunch this is the more common use case to be honest, but in any case it would be great to know how to change things round.

It isn't obvious to me how the contact that custom data applies to is defined. But maybe it is the contact with the alias contact_civireport? How do I let Civi knoe which contact I want to extend with custom data?

A little bit of advice and instruction on whether I am headed in the right direction and what I should do next would be greatly appreciated

Cheers,
Michael

demeritcowboy · September 21, 2010, 12:37:40 pm

There should be a join in there somewhere that is joining the custom table's "entity_id" on one of the contact table aliases (source contact). Change it to join on the target contact alias instead.

Michael McAndrew · January 17, 2011, 08:09:30 am

OK - finally worked this out and attached is a patch.

IMO it makes much more sense to attach any contact custom data to the target contact (which is outside the organisation and likely to have a load of custom data that wants to be tracked) rather than the source or assignee which tend to be inside the organisation.

I can see the use case for the inside, but my hunch is that 95-9% of people will want to report on custom data of their contacts, not users.

Have filed an issue on this http://issues.civicrm.org/jira/browse/CRM-7396 with patch. Would be great if people can input here to makes sure this is a sensible improvement.

In the patch I have also included custom data on 'contact, organisation and indivudual' by default. Again, IMO, I think that reports are much more useful when the have custom data in them. If it isn't the case already, I propose a convention of including custom data by default, otherwise using any custom data in reports becomes a 'Developer task' i.e. not able to be done via UI alone.

Michael

demeritcowboy · January 17, 2011, 08:28:35 am

The idea is sound I think. Only thing I can see is that because it changes existing core behavior the upgrade path might need some extra code somewhere, i.e. if someone has existing custom data selected in an instance, those selections are stored in the database. If they are based on different contact types or subtypes then one set of custom data might not apply to all contacts and errors will result. Even if they do exist the results will be unexpectedly different than before the upgrade.

Is it better to submit the entire report simply as a new core report?

Rajan Mayekar · January 21, 2011, 12:10:10 am

Hi Michael,

Regarding issue http://issues.civicrm.org/jira/browse/CRM-7396, what if any activity has more than one target contacts?
Attached diff will show the custom data of only first contact, which will look more confusing.

My suggestion is to, instead of display custom data of target contact in Activity report , we can modify the links of target, assignee contacts ( currently it is redirected to the contact summary ) to the Contact Report ( Summary ) instance. So that any user can update that instance accordingly to views the custom data of that contacts.

Rajan

Michael McAndrew · January 21, 2011, 09:22:31 am

Hi Rajan,

Thanks a lot for pointing that out

In this specific use case, the client wants to answer a question along the lines of the following: "how many contacts with this certain attribute have we carried out this activity with". So in fact the report should show a line per target contact.

In this clients case we can pretty much guaruntee that there is one target contact per activity (because that is how they carry out their work) but that won't always be the case and I think the solution here is to change the grouping from civicrm_activity to civicrm_activity_target. Does that sound right / make sense to you?

Michael

Kurund Jalmi · February 03, 2011, 12:43:02 am

Michael,

I think primary use case of this report is to give details about activity, so listing will have Activity + Custom data. For your case you need more information on target contacts ( activity can have multiple target contacts )
IMO it should be displayed as separate rows with it's custom data etc, to avoid confusion, especially when there are multiple targets etc..

So report should be like

Activity 1 info .......
target 1 info .......
target 2 info ......
Activity 2 info
target 1 info .....
Activity 3 info
target 1 info .....

and so on...

My recommendation would be to a develop separate report, rather than complicating current report

Kurund

CiviCRM Community Forums (archive)

News:

Author Topic: Defining the contact that custom data applies to in a report (Read 1497 times)

Michael McAndrew

Defining the contact that custom data applies to in a report

demeritcowboy

Re: Defining the contact that custom data applies to in a report

Michael McAndrew

Re: Defining the contact that custom data applies to in a report

demeritcowboy

Re: Defining the contact that custom data applies to in a report

Rajan Mayekar

Re: Defining the contact that custom data applies to in a report

Michael McAndrew

Re: Defining the contact that custom data applies to in a report

Kurund Jalmi

Re: Defining the contact that custom data applies to in a report