-
-
Notifications
You must be signed in to change notification settings - Fork 824
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dev/core#2684 Fix filters tpl in civi reports to permit more than one table in a grouping #20820
Conversation
(Standard links)
|
This requires / works with civicrm/civicrm-core#20820
test this please |
So far so good, just noticing it does seem to rearrange the filters on the contribution detail report, almost into virtual accordions. Not necessarily bad just checking it's all still working. |
@demeritcowboy yeah - that's why I haven't added it to any core reports - it just is a way to see what it does |
I mean even without the additional patch for seeing the accordions, a stock install with this PR applied has different order/grouping of filters on that report. |
Hmm - the ordering should be according to the grouping key - else that key shouldn't be set. But we shouldn't be showing changes in the use or otherwise of accordions in core |
{assign var="counter" value=1} | ||
{foreach from=$filters item=table key=tableName} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor thing: Because there's no more tableName, down on line 37/31 it doesn't like it. Also 42/36.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks - updated
I think it's ok function-wise it's just what it's doing is putting anything with a different 'grouping' key into its own |
@demeritcowboy yeah I believe that was the original intent of the 'grouping' parameter - it was just poorly implemented |
If you want to address the missing tableName above I'm ok to merge this. |
… table in a grouping
I think I fixed it |
jenkins retest this please (api.v4.Action.CreateWithOptionGroupTest.testWithCustomDataForMultipleContacts) |
jenkins retest this please This is a new one:
|
Yeah - it's popping up a bit now thought! |
test this please |
Fail still seems unrelated but let's see what happens api\v4\Action\CreateWithOptionGroupTest::testWithCustomDataForMultipleContacts |
Back to just the unrelated sqlmode failure |
Overview
This fixes the handling of 'grouping' in civireport table definition to do what it was seemingly intended to do - but didn't
Before
If you attempt to assign more than one table to the same 'Grouping' in the report you wind up with duplicate accordians rather than one accordian with one header & both tables in it . You can also wind up with broken html in some cases
After
In this example the Contact, phone and email tables are all grouped as 'contact'. Note the PR doesn't make this change to any core reports - but this PR in extended reports uses it eileenmcnaughton/nz.co.fuzion.extendedreport#490
-
Technical Details
In 'classic' CiviCRM fashion we were assigning an array of 'filterGroupings' and separately an array or filters and trying to cross reference them in the tpl layer to figure out when to open and close the accordians. This switched to only using the 'filterGroupings' array and adding the values from the 'filters' array into that array at the php layer - leaving a single iteration at the tpl layer
Comments
To test this make the below changes - note I'm not including this change or any change that actually changes output in this patch (and I don't necessarily see us changing any core reports) - but by applying the patch it can be seen the filters can be directed to go in an accordion