I have a list that is displayed in a module below another list. The list is configured via the module list filters to include only one certain user/facility combination (always one row actually).
I really have 3 issues here - So I'll start with the first (and excuse me for going off on a tangent regarding the other 2).
1. The 'sum' calculations that are being done are misleading - because the calculation is not respecting the list filter. (see attachment: listCalculation.png)
Sure, I can hide that with css. But not only is it incorrect and not wanted (in this case) to begin with - but it seems like a waste of resources to have to do the calculations at all.
Ideally, even if this is fixed to respect the filters, IMO there should be an option included in the list content plugin... 'Do calculations?'. And if 'No' don't even run the calculations code.
The other 2 issues are...
2. The module list is 'ajaxified' - (edited in a popup). If/when that form is saved both the content list and the list in the module have no rows shown.
3. What I'd really like to do is, rather than show that list in the module, show the 'form view' for that one row that is filtered in the list - but using the Fabrik form module content plugin instead.
In trying to solve issue #3, I had a brainstorm the other day to try add an option for using filters to get that one row filtered in the list into a form via the Fabrik form content plugin. (Similar to how you use -1 for user_id and -2 for... I forget what ).
What I wanted to do was - if Row id was '-3', assume that the 'Use key' text contained a comma-delimited list of REQUEST:element pairs which would allow the code to filter the list to include only that row for the form view. (For an example - See attachment: formModuleConfig.png)
E.g. in my attached example...
'mfid' is the REQUEST variable and 'fb_survey_status___member_facility_id' is the element/column that must match the value of mfid. Then, assuming mfid=7, the added WHERE condition filter would be... WHERE fb_survey_status.member_facility_id=7
Those parameters could be used in the query to filter the list to the desired record for editing - and if the query returns an array with a count greater than 1, throw an error message - else just display that record for editing in the form.
I spent the entire day on this the other day - and basically got it working. Except came to realize that the Fabrik code uses that 'User key' value in a few other places - and that turned my brainstorm into a brain fart.
But I would imagine this could be done using a dedicated configuration variable instead. Does anyone more familiar with 'the big picture' here (@cheesegrits) think it's worth the effort - or see any problems with that idea?
I really have 3 issues here - So I'll start with the first (and excuse me for going off on a tangent regarding the other 2).
1. The 'sum' calculations that are being done are misleading - because the calculation is not respecting the list filter. (see attachment: listCalculation.png)
Sure, I can hide that with css. But not only is it incorrect and not wanted (in this case) to begin with - but it seems like a waste of resources to have to do the calculations at all.
Ideally, even if this is fixed to respect the filters, IMO there should be an option included in the list content plugin... 'Do calculations?'. And if 'No' don't even run the calculations code.
The other 2 issues are...
2. The module list is 'ajaxified' - (edited in a popup). If/when that form is saved both the content list and the list in the module have no rows shown.
3. What I'd really like to do is, rather than show that list in the module, show the 'form view' for that one row that is filtered in the list - but using the Fabrik form module content plugin instead.
In trying to solve issue #3, I had a brainstorm the other day to try add an option for using filters to get that one row filtered in the list into a form via the Fabrik form content plugin. (Similar to how you use -1 for user_id and -2 for... I forget what ).
What I wanted to do was - if Row id was '-3', assume that the 'Use key' text contained a comma-delimited list of REQUEST:element pairs which would allow the code to filter the list to include only that row for the form view. (For an example - See attachment: formModuleConfig.png)
E.g. in my attached example...
'mfid' is the REQUEST variable and 'fb_survey_status___member_facility_id' is the element/column that must match the value of mfid. Then, assuming mfid=7, the added WHERE condition filter would be... WHERE fb_survey_status.member_facility_id=7
Those parameters could be used in the query to filter the list to the desired record for editing - and if the query returns an array with a count greater than 1, throw an error message - else just display that record for editing in the form.
I spent the entire day on this the other day - and basically got it working. Except came to realize that the Fabrik code uses that 'User key' value in a few other places - and that turned my brainstorm into a brain fart.
But I would imagine this could be done using a dedicated configuration variable instead. Does anyone more familiar with 'the big picture' here (@cheesegrits) think it's worth the effort - or see any problems with that idea?
Attachments
Last edited:
