Problem with repeated groups, records deleted after submit form

R

ronhon

New Member
Hi guys,

First let me tell you, you built a great tool. However I think I ran into a serious bug.

I made a form with editable repeating groups. I made a pre-filter on the list to only show records that are not referenced by a third table, Like ?repeatedgroup.PK NOT IN Select FK FROM third table?.

When I open de edit screen with the repeating groups don?t change anything and press the submit button, all records that were filtered out by the Pre-filter, are deleted.

After I noticed this, I put a Restrict constraint in MYSQL on the FK of the third table to the id of the repeated group id. When I try now to open and submit de form I get an error:

?SQL=DELETE FROM repeated group table WHERE repeated group.FK = main table.id and ! ( repeated group.id IN (13,4,6,7,3,2,23))?, which are only the id?s of de repeating group records that are displayed. So only the displayed records are excluded from deletion and the records that are not shown would be all deleted if the constraint was not there.

Can you please fix this or tell me how I can work around this?
 
I can confirm this behaviour.

I think you could discuss if it is a bug in case of a repeated group (it's saving exactly the data you are seeing in the form and this data is "belonging" to the record) but it is really a problem in case of a "normal" repeated join: here, too, it's deleting the joined (prefiltered) record (even if "delete joined records"=no, so the joined record would be kept in case of deleting the parent record).
Same behaviour if you are deleting a group: it's deleting the complete joined record (which may be used/joined to somewhere else).
I think it should only clear the foreign key.
 
Hmmmm.

The issue with repeats being pre-filtered out is something we've never thought about, and I can tell you this is going to be an absolute bitch to resolve, and may be impossible.

When you submit a form with repeat joins, for each repeat group (join) we write out the joined data from the form, collect the PK's for those rows we wrote out, then do a query that can be summed up as "delete joined rows who's PK is NOT in the list we just made of repeat data from the form".

So if you filter out joined data from the form, so it doesn't get submitted with the form, it's going to get deleted. Offhand, I really can't think of a way round this, given the way we currently do things.

The only way I can think of would be to maintain a list in JavaScript of the rows which got actually removed by the user, and submit that with the form, and use that for deleting joined data, rather than the "if it isn't submitted with the form, delete it" approach.

And that's not going to be a trivial change, which will take a lot of testing.

it is really a problem in case of a "normal" repeated join: here, too, it's deleting the joined (prefiltered) record (even if "delete joined records"=no, so the joined record would be kept in case of deleting the parent record).
Click to expand...

Not entirely sure what you mean. Can you re-explain that one?

Same behaviour if you are deleting a group: it's deleting the complete joined record (which may be used/joined to somewhere else).
I think it should only clear the foreign key.
Click to expand...

Hmmm. That's going to take some thinking about.

We're going to need Rob on this one!

-- hugh
 
Can you re-explain that one?
Click to expand...
Ignore the prefiltering, it's the same effect if you are deleting a repeated group.

Setup: listA joined to listB (repeat=yes, delete joined records=no)
listB has a FK (e.g. dbjoin element) to listA, so some records pointing to e.g. listA-record1

Editing listA-record1 will show the repeated group with the joined listB records.
Deleting one group will not "disjoin" the record of listB (i.e. clear the FK) but delete the record from listB.

With a prefilter is additionally "special" because you don't delete the repeated group actively but it's just not showing up.
 
OK, let's ignore the pre-filtering this for now, as that's a very specific issue.

So your contention is that if "delete joined rows" is set to No, and you delete a joined group, it shouldn't delete the joined row? Simply un-relate it by emptying the PK?

-- hugh
 
The solution that troester suggests will be of great help for me. Thanks for the effort you put in this, I hope you decide soon how to implement this. Thanks, Ronald
 
Well, we had a long internal discussion about this, and came to the conclusion that this is just one of those things Fabrik doesn't do. We have to draw the line somewhere. The work involved in solving this one would be considerable, and it's a corner case which only affects a tiny number of Fabrik users (well, to be honest, you are the first person to ever run across this issue).

So we're simply going to have to say that pre-filtering is intended to filter ONLY rows from the parent table, and that Fabrik's behavior of deleting any related data not submitted with the form is just the way it is.

You may be able to work round this with some PHP form submission handling. Off the top of my head, I'd say an onBeforeProcess hook, which queries the database for any related rows which may have been pre-filtered out, and inserts them in to the form's submitted data to they don't get zapped, would probably be the best approach. Depending on what element types you have, this could either be very easy, or "distinctly non-trivial".

Meanwhile, we will modify the pre-filter tooltip and Wiki to make it clear that pre-filters should only filter out parent rows, NOT related data. Or that if they do, the consequences will have to be handled with custom submission code.

Apologies, but there are only 24 hours in a day, and we have many other issues which affect most Fabrik users we need to resolve, and simply don't have the resources to handle this kind of low impact, high cost work.

-- hugh
 
Hi Hugh, it's not the answer I hoped for but I thank you for the quick and clear response. I found another way out; I removed the pre-filter and made a form template that only shows the delete button when the repeating group is not referenced by the third table.
 
I hate saying "No", so thank you for understanding, and I'm glad you found a workaround.

BTW, it might be better to do the hiding of the delete button in JavaScript rather than with a custom template. Simply because custom templates become a long term maintenance issue, as we do occasionally have to introduce changes to templates, which can induce "bit rot" in custom templates which were derived from them. Of course, JavaScript has it's own set of issues, but it's usually more obvious when we've changed something that may affect a JS script, that when a template change causes a custom template to misbehave.

Anyway ... as I said, thank you for understanding. We may yet change the way we do related row deletion, as it's possible this may be causing issues in other usage cases. But it's something we are going to have to tread very carefully with, as any changes to truly "core" code like this require a LOT of thought, and a LOT of testing!

-- hugh
 
You must log in or register to reply here.

Useful links

  • Create a Fabrik Account (Downloads)
  • Create a Forum Account
  • Fabrik Wiki
  • Fabrik 4 Changelog /Install /Upgrade
    • We are in need of some funding.
    More details.

    Thank you.

    Members online

    No members online now.
    Total: 214 (members: 0, guests: 214)
    Back
    Top