CiviCRM Community Forums (archive)

Hi all,

Some report filters cannot be set by URL parameter; when these filters have default values, this can cause surprising changes in report output.  This looks like a bug, but I'm not sure the best way to approach a fix. 

An example:

The report "Donor Report (Detail)" by default shows donations with "completed" status, and for each donation the country value is a clickable drill-down link that filters the report by that country.  So you can click on "United States" and filter the report to show only donations from US contacts.

But when you click that link, the status="completed" filter is not passed on, so the drill-down report shows donations from US contacts, with ANY status.  That's not so bad, if you're watching the QILL criteria carefully, but now it gets stranger:

If you now click a button that reloads the report -- say, the "Preview Report" button in criteria, or the "Go" button on the pager -- without modifying the criteria at all, the report will apply both filters: country="US" and status="Completed".  So, although you didn't change the criteria, the criteria have changed, and so the report numbers have changed, too.

What's going on here? There are a couple of oddities:
1. When the drill-down link is clicked, the default status="completed" filter appears to be set in the Report Criteria section, but it's not actually affectign the report output.

2. The drill-down link doesn't pass along the status="completed" filter; I'm not sure if it should, but if it did, we would expect it to fix the problem.

3. Stranger still, even if it did pass that filter in as a URL parameter, the report wouldn't apply it.  From looking at CRM/Report/Utils/Get.php, it looks to me as if report filters must explicitly be defined with a 'type' value (one of CRM_Utils_Type::T_INT, CRM_Utils_Type::T_MONEY, CRM_Utils_Type::T_STRING, CRM_Utils_Type::T_DATE, CRM_Utils_Type::T_DATE, or CRM_Utils_Type::T_TIME) -- and if they're not, they cannot be set with URL parameters.

So right now, it happens that the applied filters change just by advancing the report pager.  But I'm not sure what solution to suggest.  Any thoughts?

Thanks,
Allen

I think how it works currently is if url has some filters, report filters are ignored.

Yes, a method is called that clears all the existing filters and uses only what's in the URL.

But as we proceed with go / preview button report criteria is considered.

Right.

Fix would be to also adjust / reset report criteria per url on the first render. Wanna give it a try ?

Sure, I'm ready to submit a patch, but can you clarify what you mean there? You mean, the fix would be to start with the saved/default report criteria, and then only change those that are specified in the URL?

- A.

Hey there,

Yep, that sounds great Lobo. I can work up a patch for that.

One more thing we should discuss is whether it's proper to have all current criteria (meaning, the criteria that are active on the page, regardless of whether they've been saved or not), passed along with the drill-down link.  Currently that's not happening.

For example, say I open a report instance and add a new filter criteria (last name contains "sh"), then click "Preview".  The report applies that new criteria.  But when clicking the drill-down link, that new criteria is lost.  Should it be lost, on the notion that only saved criteria are persistent in that way?  Or, should we anticipate that the user is expecting the drill-down to continue in the current context, meaning that the unsaved criteria should persist also?

- A.

I was thinking the way to do this would be to add those "Preview" criteria to the drill-down link as URL params.  Is that feasible?