Hello,

I'm glad that I've helped and that most issues are solved.

I've tried to see in the backend how this is set up but I couldn't find the form which has that unique GUID stored in the Record_ID field.
Furthermore, I couldn't find the update Integrator rule which has set the update criteria based on Record_ID.

Despite that, I assume what is causing it not to work. How is the Record_ID field filled in? Are you using some code? I assume that when administrator logs in, this filed is automatically erased with some code that you've used to usually fill in this field.
That is why the fields with Record_ID get updated instead of the one of the corresponding user.

Regards,

Mihaela

Hi Mihaela,

Thanks a lot for your reply! I think you are right (and you are right again)! Something could be linked to how Record_ID/GUID was generated. Because it was using PHP to generate a new ID, it might get changed again when we used Breezing Form to update a record! Its code was placed in the form elements of this form, as shown here:

mrkr.io/s/5c49ed264c2e24761a5e17f3/0

I then unchecked the "edit by type" option so that we won't use Breezing form to update a record, so that the Record ID/GUID won't get changed during the update.

This time is seems that an update in the backend CB view won't change values of other records, and it could still update the record of Breezing form records, but it was unable to update the record stored in the separate table still.

Therefore I assume I will need to change the settings for the Integrator?

I must apologize sincerely because the backend URL I provided in the previous post was wrong. It should be:



and the username and password remains the same.

Thank you very much!

Hello,

No problem for the wrong URL. Now I was able to see what was needed.

After doing some testing I came to a conclusion that you need to change some settings in the View and database table.

First of all, in order to be able to update by Record_ID, that field must be marked as Editable in the List View "Edit (Backend)" that you have created for Administrator. This will solve the problem that records with ALL RECORDS without nothing stored in the "Record ID" are updated. When this field in not marked as editable, it saves an empty value for Record_ID field to that database table that you have created.

Furthermore, go to your database table and mark the Redord_ID as UNIQUE if you haven't. This is needed so update wouldn't create new table rows with the same ID.

Let me know whether after you set it up like this it is working properly.

Regards,

Mihaela

Thanks again Mihaela! It works very well when I did a backend editing via Breezing Form (i.e. "edit by type")!


1. However, when I did a frontend editing via Breezing Form, after the form was submitted, I saw a 404 Not found page with the "Saved" message displayed on top. As shown here:
mrkr.io/s/5c4e4877f4b0cf75b842f48d/0

The record saved on Breezing Form Record was edited, but the record saved on the separate data table was NOT edited. Did I miss something?



2. I could remove the record in Content Builder view, and therefore removed the same record in Breezing form. However, it seems that Integrator won't delete the same record if I am doing so. Therefore that record is still being displayed at the frontend. Is there any way to remove that record in the separate table as well (i.e. via Integrator or a custom script)?

Thanks again.

Hello,

1. Can you please explain what you mean by "when I did a frontend editing via Breezing Form", in which way did you edit via BreezingForms? Do you mean in a way that you have "Submission editable by user checked"?

I've tested on my site and in the ContentBuilder view made for Administrator on backend and frontend the editing worked the same with no problems, data was edited in both Joomla database and the separate database I've created.

2. As for the "delete", if I understood you correctly, the problem is that after you delete the record through ContetnBuilder view, that record remains present in the custom database table that you've created. Is that what you wanted to say?
This sentence confuses me "Therefore that record is still being displayed at the frontend.". Even though the integrator won't delete that record from separate table, it should be removed from frontend view.

After some extensive testing I came to a solution that, unfortunately, there is no easy solution to to remove that record in the separate table as well when you delete it in the View. No code can be added in this case, because if for example you'd put it in End submit pieces, it would be executed on form submission, and you would need a code that would run after delete for the specific record that was selected.

You can take a look at this topic crosstec.org/en/forums/37-contentbuilder...-by-bf.html?start=12 regarding the delete issue, but I'm not sure whether this will help since it would mean double deleting (in two views).

Regards,

Mihaela

Hi Mihaela,

Thank you again for your reply!

1. Sorry for the confusion. The "Frontend edit via Breezing Form", actually means a menu item of the CB "List View" type, which selected the view I created for editing (which was already working in the backend): mrkr.io/s/5c4f67cbef645932207deb27/0

The view was set to "checked" for the "edit by type", and that view was for Breezing form, so if a login user clicked this menu item link, he/she will first see a list of all the records he/she created (which is great! we need this!), then he/she can click one of these record to start editing.

If a super user login at the backend, then the record can be edited (including the separate data table's values);

If the author of that record login at the frontend (i.e. you can find frontend login information at the end of this post), only values stored in Breezing form records was edited, and we will see a 404 page after the form was submitted. You can tried it with this link after you login:




Because each user might have multiple records, "Submission editable by user checked" probably won't work as it can let the user to edit his/her very last record only.


2. Understood! We will figure out a way to remove the record then. Unless there is a "delete" rule for integrator... or breezing form.

The reason why the record was still displayed at the frontend, is because that our frontend listing page:



was a customized page that will draw records from the separate data table. Therefore it will keep displaying the record removed from CB view, but remained in the separate data table.

If you need to test #1 above, you can try with the listing page too (so that you can "see" what value was saved to the separate data table);

Thank you very much! Login information pasted below: