Ajax calc not triggering on 2nd and subsequent repeated group

[bggann]

I have a form with repeated groups where I have a calculated field that is displayed to help guide the user in filling out other fields.

The calculation is based on placeholders in the main group.

Basically the calculation is (simplified)
$start = "{maingroup___hours_start};
$stop = "{maingroup___hours_stop};
$hours_worked = $stop - start;

This calculation is used in the main group and _also_ in the repeated groups.
It is re-calculated, I'm not using the results of a previous calculation - and the calculation works fine.

--------
The problem is that the ajax trigger that causes the calculation update is not firing when I add a repeated group.

The first repeated group works - when you select the start and stop time, the hours_worked is calculated and displayed in both the main group and the 1st repeated group - just fine.

But - when I add a repeated group, the hours_worked field is not re-calculated - it is blank. If I go back up to the main group, and change the start or stop times, then the calc runs in all displayed groups, but the calc does not run on add-group.

Thinking that I may need to force a re-calc, I added a required field in the repeated group as a "watched" field in the repeated group calculation. However, it is not triggering the calc either.

The weird thing is that this worked up till very recent changes to one of the forms (not to Joomla or Fabrik). It still works on my dev site.
Both are running 3.8.6 (joomla) and 3.8.1 (fabrik).

NOTE: On the working site, the calc field in the repeated group is a "child" of the calc field in the main group - though the underlying database field is different. In the non-working site, that was the same. Thinking that might be the problem, I broke the parent/child relationship so that the calc in the repeated group is independent. No help.
Thoughts?

-bg

 

[cheesegrits]

Can you point me at the form.

-- hugh

 

[bggann]

Okay - I've got it running in a sandbox for you so that it does not run any potential of interfering with the live site (which is quite busy given the fires)
Under my sites - go to the "training....." site. The user name and password there will give you both front and backend access as SU.
You'll know you are on the right site because the color scheme is pink and the backend menu/header is pink/red. The live site is blue.

To see the problem
Log in.
Menu
- Add Aircraft Use Report/Add MMA Log

In the form, look in the middle of the first (non-repeated) group.
See 'Pilot duty stop'
Change that the hour value to 11, 12, 13 or 14.
You will see AJAX calculation of "Pilot Extended hours" to reflect 1, 2, 3, or 4
Essentially the extended hours is the number of hours past 10 that the pilot worked - limited to max of 4. Pilots cannot work more than 14 hours in a day - so cannot get more than 4 extended hours.
--> This is working.

Scroll down to the first repeated group.
- About 3/4 the way down, you will see "Pilot Extended Hours" - it should be the same as the one above. It is the same calculation code.
--> This is working. If you change pilot duty hours above, it changes.

Add a repeated group (green +)
In the new repeated group you will see "Pilot Extended Hours" but where it should be displaying the number of hours, it is blank.
- If you go up and change the Pilot stop time in the main group - both displayed groups will update - but if you add a new group, it does not fire.

---------
In the back end.
The relevant elements are:
Group: Daily Log MMA, element daily_log___pilot_extended_hours (id 876)
Group: Aircraft Cost Allocation MMA, element daily_log_7_repeat___pilot_extended_hours (id 879)

Both of these do the same calculation.
Both use the same php script (you'll see the require once)
These were parent/child elements (876/879). I broke that link trying to fix this, so they are both parents now. But that gives you a basis for the code is the same.

I've copied the .php file that is included into the images/samples/php directory which is accessable from the backend media manager. seat_scripts.php. The is not the one that is running of course, but it is an exact copy. I don't think the problem is there, since the calc runs fine when triggered. If you need to get to that file, I'll get you cpanel access.

-bob

 

[cheesegrits]

Hmmm.

Well, there is a kind of logical existing "fix" for this, which is to set "Calc on load" to "Yes" for the calcs in repeat groups.

It's one of those cases where it's not entirely clear cut what should happen to calcs when you add a repeat group. By default, they just behave like any other element, which is they get the default value (in this case, blank). No other elements in the group will set themselves to any other value. So there's no reason to really expect that the calc would automatically adopt different behaviour.

Calcs have a setting for "Calc on load", which (if set) triggers the calc when our "attachedToForm" method runs for it. Which fires in two places - when the form first loads and the elements are added to it, and when elements are added to a new repeat group.

So setting "Calc on load" fixes your issue, in that the it'll calc when the repeat group is duplicated. But ... they will also re-calc themselves when you load a form to edit it. Which isn't a huge propblem, they'll wind up with the same values they would have had anyway, it just means you've got a lot more "activity" when loading the form.

If that's OK, then we're done - I set calc on load for this one, and it works. if you don't want it calc'ing on load, but do want it calc'ing on a repeat being added ... I'd have to add YAFO (Yet Another Option) to the calc element, for "Calc on repeat". Which may have to be a little but of billable work.

-- hugh

 

[bggann]

Thank Hugh,

Just realized this reply was never posted - not sure what happen.
I'll thought about the calc on load - I would not want to do that for some fields because I don't want calc on load. Some records (in the past) were calculated using rates that changed. If you open one of them, I want it to reflect the old rate. But these particular fields are only there for "information", so that should be fine. It does solve the problem.

Bob

 

[cheesegrits]

OK.

We call it "Calc on load", but it's really "Calc on attach to form" ... which happens a) for existing calc elements when a form is loaded, and b) for calc elements being added to the form when creating a new repeat.

-- hugh