• Hello Fabrik Community

    Fabrik is now in the hands of the development team that brought you Fabrik for Joomla 4. We have recently transitioned the Fabrik site over to a new server and are busy trying to clean it up. We have upgraded the site to Joomla 4 and are running the latest version of Fabrik 4. We have also upgraded the Xenforo forum software to the latest version. Many of the widgets you might have been used to on the forum are no longer operational, many abandoned by the developers. We hope to bring back some of the important ones as we have time.

    Exciting times to be sure.

    The Fabrik 4.0 Official release is now available. In addition, the Fabrik codebase is now available in a public repository. See the notices about these in the announcements section

    We wish to shout out a very big Thank You to all of you who have made donations. They have really helped. But we can always use more...wink..wink..

    Also a big Thank You to those of you who have been assisting others in the forum. This takes a very big burden off of us as we work on bugs, the website and the future of Fabrik.

Repeat group strange behaviour

Amuleta

Member
I have repeat groups where, when I add more than one group, the previous groups and the new group become confused.
When I add a second new group the first new group I added looses data entered, and the second, third etc. new groups show random records from a previously saved group. This happens in the edit view, before they are saved btw, and happens in the 2 joined lists I have, both fundamental to the project.
 
That's because the 'subject' CDD element on your Progress Reports is set to use "Subject" as both label and value. The value needs to be the PK of the table it is joining to (usually 'id').

So your join should be from an FK (foreign key) pointing to the PK (primary key) of another table. So in this case, progress_reports.subject => subject_classes.id. Which is how you have your List join set up. But then in your progress_reports.subject element, you aren't storing sibject_classes.id, you are storing subject_classes.subject.

-- hugh
 
So the list join (repeat group) is trying to associate rows from the progress reports with 'subject' of (say) 3, but the progress report is storing (say) "English" in 'subject'.

-- hugh
 
No, that's not the problem. If you look at say list 5 data, choose to edit Jades - Agriculture, for example, and see that there are 2 groups already entered. Add another group, fill the form however you like, then add another group and you will see that it will be prefilled with records from one of the previous groups. The student id (a cdd) won't change if you change the student name, and the data in the first group you added has vanished!
 
No, tt's not the problem.

Yes, that is the problem. It may not be the only problem, but it most certainly is why "the data in the first group you added has vanished".

You have created your repeat group by making a repeated join in the list from subjects_classes.id to progress_report.subject. Which means that progress_report.subject needs to be an integer field, which contains the id (primary key) of subjects_classes. The join query generated looks like "LEFT JOIN progress_reports ON progress_reports.subject = subjects_classes.id".

But then in your form, progress_reports.subject is a CDD which you have configured to store the "Subject" (text) not the "id".

This will not work, and will cause all kinds of crazy things to happen when you create, save and edit repeat groups, as you have told Fabrik you are joining those two tables with the 'id' as foreign key, but then you are saving them using something else.

First thing, the Subject element on progress_reports needs to store the "id (RECOMMENDED)" (all caps added for emphasis). In both the original (parent) group/form, and any copies of it.

Second thing, when used in that repeat group on the Student Reports form, it shouldn't be an editable CDD. It should be a hidden field set to "integer". That is the FK element. Fabrik knows which "parent" you are adding that repeat row to (the row for the main table, i.e. the form's rowid), so will automatically set it. In other words, if you are adding a new report to the "Agriculture" form, we know what the "subject" in the repeat needs to be. And Fabrik has to manage it's own foreign keys, otherwise, as we can see, things go wobbly.

This will no doubt have consequences on how your CDD's are set up, and I suspect that's why you elected to use the "Subject" rather than the id.

-- hugh
 
OK. I understand your previous reply now.
With regard to your second reply, you are right of course! That will teach me not to rely on a backup from my server, as I recently did, because theirs was from a point where I was merging another site into this one and before I had made the joins id to id. And it explains why it was working once, then went weird.
I am a genuine novice with databases, but I'm getting there with your help, and will now always read "recommended" as "important". Thank you!
 
Hope I didn't sound snippy.

And I hope it's not too much work to re-build those CDD's.

-- hugh
No it's not too much trouble at all! Thank you for pointing out the ways in which the whole thing was built on quicksand!
It must be frustrating dealing with non-developers in a developer's world :rolleyes:
But now I am rebuilding from scratch and just can't get the joined list to join to another list. So, the problem has actually been there from the beginning, when I obviously found a way in which it seemed to work... until it didn't!
 
Hi.
I've rebuilt the form on firm ground, I believe. Would you be so kind as to have a look at list 6 please? I have entered new mysite details. There's no front end yet so admin access only.
Many thanks
 
Hmmm, you seem to have some issues with missing parent elements. For instance, element 94, subject_name, thinks it's a 'child' of element 84, but 84 doesn't exist.

Did you copy that list/form from something else, and then delete the original, but tell it not to delete "children"?

-- hugh
 
Very likely. I found 4 orphans 91, 92, 93 & 94. I copied list 2, after joining it. And yes I do believe I deleted the repeat group from it. These elements will be unlinked.
The project is still a way from completed, clearly, and my main concern is that list 6 works, as that the one that is going to be put to the test very soon!
Thanks.
 
OK, I'm a little concerned about that, as I can see some potential for "undocumented behavior" when an element thinks it's a child which inherits properties from a parent that doesn't exist. And we should have picked up on that when you deleted those parents. Suggest you edit those, and tell Fabrik to unlink them.

But other than that it looks OK.


Sent from my HTC One using Tapatalk
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top