When 'Group and Compress' is activated in a view, the bulk operations checkboxes will stop matching up to the right rows. It seems to be because the bulk operation field adds placeholder text (i.e. <!--form-item-example_field--X-->, where X is the row number) to the field output, which gets replaced much later with the actual checkboxes. When Views Aggregator Plus re-sorts/compresses the result set it isn't updating the associated placeholder text, which causes the problem.
Without making larger changes to how bulk operations handles this, the only solution I could come up with is just looking for a BulkForm or ViewsBulkOperationsBulkForm field in the view and regenerating the placeholder text based on the new row indexes. That's what the attached patch does.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | views-aggregator-support-bulk-operations-3040814-12.patch | 1.43 KB | jordik |
| #11 | view_aggregation_with_patch.png | 120.46 KB | jacobbell84 |
| #11 | view_aggregation_no_patch.png | 123.95 KB | jacobbell84 |
| #11 | view_no_aggregation.png | 112.38 KB | jacobbell84 |
| #7 | views-aggregator-support-bulk-operations-3040814-7.patch | 1.12 KB | jacobbell84 |
Comments
Comment #2
jacobbell84 commentedAttempting to fix code styling issues
Comment #3
jacobbell84 commentedComment #4
tr commented"Failed to Apply" because your patch has DOS line endings instead of Unix line endings.
Comment #5
dinesh18 commented#2 patch added again with the fixes
Comment #6
tr commentedTabs aren't allowed, and your patch introduces a syntax error into Table.php
Comment #7
jacobbell84 commentedThanks TR, I believe I converted the newline characters over to unix format for this patch.
Comment #8
jacobbell84 commentedComment #9
jordik commentedTested VBO version 8.x-3.2 with the latest dev version of Views Aggregator.
The checkboxes seem to work without the patch.
Is there something I am missing?
And beyond that - what is the use case of having bulk operations on aggregated (overwritten) values?
Comment #10
jordik commentedComment #11
jacobbell84 commentedHi JordiK,
I updated to the latest dev release (and 3.2 of VBO) and can still reproduce it on my side. Let me see if I can explain better, as it's a somewhat complex use-case. My specific use case is the registration listing for an events implementation. Each registration can have a primary registrant (the person actually signing up for the event) and 0 to many guests. On that registration listing screen the client wishes to see all the registrants for a given registration. I currently accomplish that by doing a join on a registrant table. They also need the ability to send out email alerts to them (In case of cancellations and what not), which I'm accomplishing by a custom views bulk operation action. If I don't do any sort of aggregation, the view will look like the screenshot below:
Not ideal because only the primary registrant has an email address, so the client would need to filter out all the "guest" records manually, otherwise multiple emails would go out since the bulk action is based on the registration id, not the registrants. I think views aggregation makes sense in this case, because the only fields being overwritten (the registrant information) don't matter, as all I'm concerned with for my custom bulk action is the registration id. If I set the registration id to be the "group and compress" column and set the name/registrant type columns to be "Enumerate *" it will look like the screenshot below:
Visually it's exactly what I'm looking for, but you can see the checkboxes stop half way down the page. I believe it's because the ID of the checkbox is based on the row number and not the actual entity id. So even though the column being compressed (The registration ID) are identical between the two rows, the checkbox is actually different between the rows. Because the ID numbers of the checkboxes are now greater then the actual rows in the system, the admin stops rendering the checkbox early. The patch above corrects the IDs so that they match the rows properly again, which produces a result like the screenshot below:
Comment #12
jordik commentedThank you @jacobbell84 for this explanation.
I could reproduce the issue. The patch provided solves it.
I added some very minor changes to it (use statement and comment) and re-rolled it to the new dev version.
Comment #14
jordik commentedCommitted.
Comment #15
jacobbell84 commentedThanks for the quick turn-around!
Comment #17
jacobbell84 commented