Weird repeat group behavior with databasejoin

[PvN94]

I have repeat groups with a databasejoin in them, and when a saved form has 2 or more repeat groups saved, you then add another group, delete the added group and then add a group again the last added group will be filled with the values from the first group, even though 'copy values' is switched to no.

After saving the form all the groups except the one added last (with the copied values) are saved empty.

This happens on multiple forms when the repeat group has a dbjoin element, but not on another form where there is no dbjoin element.

 

[troester]

Which exact Fabrik version?

 

[PvN94]

I installed the latest updates in joomla, which is 3.5.1, and after that did a github update. I did that after the weird behavior was noticed, that was on i think 3.5.0

 

[PvN94]

Any ideas on this?

 

[cheesegrits]

I can't replicate this behavior.

When did you last update from github? I recall fixing some issues with group duplication, but they were a while ago.

-- hugh

 

[PvN94]

Right before i made this post, so october 4th. The behavior was noticed on the live site, then i made a local copy where the behavior was the same. Updated that copy via joomla and then gthub and it stil happens.

Just did another github update and the problem seems to have changed a bit. Now not all groups that existed are deleted, just one or two. And the problem doesn't occur if you have less than 3 repeatgroups in the form.

 

[cheesegrits]

I simply cannot replicate this.

How big are your repeat groups? Do they have a lot of elements in them? The only time I've seen issues with "more than X repeats go wobbly" is when there is a huge amount of elements in the group, and it exceeds PHP's configured maximum for either post data total size, or max inputs.

If this was a systemic problem, we'd be getting lots of reports of it. As you are the only person reporting this, it is probably something specific to your site. Can you point me at an example test page?

-- hugh

 

[PvN94]

Ok, ive added the url to a test page in my profile here under 'admin url'. That will give you a form with a repeat group with a dbjoin. If you click around a bit with adding and deleting groups and then saving you should see the problem.

Edit: Just to add, I discovered today that the dbjoin element does not seem to be the cause, as I noticed the behavior in groups without dbjoin as well.

 

[cheesegrits]

I don't see anything in your profile.

Can you add it to http://fabrikar.com/you/my-sites

-- hugh

 

[PvN94]

Sorry about that, I was looking in my forum profile and couldn't find the my sites option.
I've added it now.

 

[cheesegrits]

I still don't see it.

-- hugh

 

[PvN94]

I've made a screen capture to show what happens.

 

[PvN94]

All right, because no one was able to replicate it until now i thought it was probably something on my site, but I get the same behavior in a completely fresh install of Joomla 3.6.3, with Fabrik 3.5.1.

I noticed that almost always it's the first group that gets deleted, and after looking at the source code it seems that all the new repeat groups that are added after clicking the add button are named the same as the first group. Inside the div.row-fluid you get a div (.control-group.fabrikElementContainer) that has the class 'fb_el_table_name__element_name_0' instead of getting for example 'fb_el_table_name__element_name_4', and then the actual element is correctly named 'fb_el_table_name__element_name_4'.

 

[cheesegrits]

OK, i can't replicate the exact results you are seeing, but have found some weird behavior.

I'm working on it.

-- hugh

 

[PvN94]

Any luck on this so far?

This morning I've encountered an issue that I'm guessing is related to this.
I have a repeat group in the form for a client used for associating employees with the client. The elements are a dbjoin for the client (hidden), a dbjoin for the employee, and a dbjoin for the employees role with the client. When a row is deleted from this group, one other row is also emptied, but the contents from that row are added in the databse to another row, in the same style as with checkboxes. So instead of

cust01   |   emp01    |   role
cust01   |   emp02    |   other_role

I get

cust01   |   NULL    |  
cust01   |   ["emp01","emp02"]    |   ["role","other_role"]

Don't know if this is related, and if so if it's helpful to you.

 

[cheesegrits]

This is proving to be a very difficult thing to debug. I'm narrowing in on the problem, but need to set aside a few hours of quality time to get to grips with it. Problem is, I have to prioritize support for paid subscribers, so this issue isn't yet bubbling to the top of my stack.

-- hugh

 

[PvN94]

No problem, I just thought I'd give you the additional info in case it would be useful.

 

[PvN94]

Friendly bump on this one

 

[cheesegrits]

Not sure it's a big enough issue for me to take out a subscription to have it fixed.

-- hugh

 

[PvN94]

I'm not gettng why you paste a quote from me from another thread, about another issue (a minor ordering bug in a work-in-progress function), into this thread about an, in my opinion, critical bug in the system which ends up deleting data which users do not want deleted.

Or rather, I can think of a reason why, but am having a hard time believing that what I'm thinking of is actually true