Hi,
any help appreciated here.
My situation:
I want to show a child"table" (which is actually only a view in the database) below the details of the record.
Ok, this is no problem.
Now, the master record can not be deleted if some other record is shown in the child table (as both tables are linked in AG using the look-up fields).
I do not want to allow AG to delete a record if it has child records...
How can I make AG ignore records in certain tables?
Is there a way to check specific tables for child records, using AG functions?
Otherwise, I suppose, I will need to write my own code in the hooks/before_delete function:
Check is a child record exists in child-table A, child-table B and in my child"view" C. If nothing exists in childtables A and B, I can simply go ahead and remove (set to null) the field which is used in the lookup für child"view" C if there is any and continue the delete operation. If anything in childtables A/B exists, I can skip checking child"view" C as AG will not allow to delete anyways.
Any other ideas / suggestions?
Olaf
Delete record: Ignore only specific "table"
Delete record: Ignore only specific "table"
Some postings I was involved, you might find useful:
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
Re: Delete record: Ignore only specific "table"
Hi,
just thought about it: Or the other way around ... allow deletion even IF child records exist and write my own code to prevent deletion if a record in in childtable A or childtable B. This might actually be a lot easier.
What do you think?
Olaf
just thought about it: Or the other way around ... allow deletion even IF child records exist and write my own code to prevent deletion if a record in in childtable A or childtable B. This might actually be a lot easier.
What do you think?
Olaf
Some postings I was involved, you might find useful:
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
Re: Delete record: Ignore only specific "table"
Good morning, Olaf,
the built-in functionality mimics SQL's ON CASCADE DELETE functionality which is available in most relational database systems nowadays.
You are completely right: If you enable cascading delete, deleting a master record will delete child records of all related tables. If you need more detailed rules for deleting or keeping related records or for denying delete of master record, you will have to write custom SQL in your hooks according to your specific needs.
Just want to mention:
Whenever you delete using custom SQL, don't forget to clean up the membership_userrecords table after successful delete. That table holds information about record-ownership. For data integrity reasons there should not be any record in membership_userrecords-table pointing to a non-existent record in any data table. In other words: After deleting a record using SQL, always delete the related record in membership_userrecords.
Best,
Jan
the built-in functionality mimics SQL's ON CASCADE DELETE functionality which is available in most relational database systems nowadays.
You are completely right: If you enable cascading delete, deleting a master record will delete child records of all related tables. If you need more detailed rules for deleting or keeping related records or for denying delete of master record, you will have to write custom SQL in your hooks according to your specific needs.
Just want to mention:
Whenever you delete using custom SQL, don't forget to clean up the membership_userrecords table after successful delete. That table holds information about record-ownership. For data integrity reasons there should not be any record in membership_userrecords-table pointing to a non-existent record in any data table. In other words: After deleting a record using SQL, always delete the related record in membership_userrecords.
Best,
Jan
Kind regards,
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
AppGini 24.10 Revision 1579 + all AppGini Helper tools
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
[code]...[/code]
blocks for better readabilityAppGini 24.10 Revision 1579 + all AppGini Helper tools
Re: Delete record: Ignore only specific "table"
Hi Jan,
thank you for your input. My "problem" is, that I show a childtable - which is indeed not a table, but a view, so that view pulls values from the record and AG uses this column to attach my childrecord to the master When I set the colum to a simple textfield with the actual value that should be seen there - AG does not use this as a child anymore and thus does not attach it to the main record .... well, I better attach an image for demonstration (below) The situation seems to me like the question "who was first - the chicken or the egg?"
Your mentioning of taking care of membership_userrecords is good. I actually create more records myself without listing them there ... I guess I might take some more precautions
My solution is actually writing some custom code which tests for childtables A and B. If there is nothing, any reference from child"view" to the master record is removed and the delete executed.
Olaf
thank you for your input. My "problem" is, that I show a childtable - which is indeed not a table, but a view, so that view pulls values from the record and AG uses this column to attach my childrecord to the master When I set the colum to a simple textfield with the actual value that should be seen there - AG does not use this as a child anymore and thus does not attach it to the main record .... well, I better attach an image for demonstration (below) The situation seems to me like the question "who was first - the chicken or the egg?"
Your mentioning of taking care of membership_userrecords is good. I actually create more records myself without listing them there ... I guess I might take some more precautions
My solution is actually writing some custom code which tests for childtables A and B. If there is nothing, any reference from child"view" to the master record is removed and the delete executed.
Olaf
Some postings I was involved, you might find useful:
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
Re: Delete record: Ignore only specific "table"
Hi Olaf,
in your specific case, when using a view "as" child table, the built-in cascading delete should fail for those views. In MASTERTABLE_dml.php file I cannot see any check for views. This means, on delete, AppGini handles any modeled child-table as if it was a database table.
So - as mentioned before - you will have to write your own code for deleting child records of only certain tables using SQL and you should remove the related membership_userrecords entries for data integrity.
Inserting records by SQL:
As long as this inserted data is only administrative data like changelog or auditing, this should not be a problem, because admin will be able to see those records anyway. But as soon as you want other users to see those dynamically created records, you will have to insert a reference into membership_userrecords. This can be done using SQL or using the AppGini-built-in set_record_owner()-function in PHP.
Best,
Jan
in your specific case, when using a view "as" child table, the built-in cascading delete should fail for those views. In MASTERTABLE_dml.php file I cannot see any check for views. This means, on delete, AppGini handles any modeled child-table as if it was a database table.
So - as mentioned before - you will have to write your own code for deleting child records of only certain tables using SQL and you should remove the related membership_userrecords entries for data integrity.
Inserting records by SQL:
As long as this inserted data is only administrative data like changelog or auditing, this should not be a problem, because admin will be able to see those records anyway. But as soon as you want other users to see those dynamically created records, you will have to insert a reference into membership_userrecords. This can be done using SQL or using the AppGini-built-in set_record_owner()-function in PHP.
Best,
Jan
Kind regards,
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
AppGini 24.10 Revision 1579 + all AppGini Helper tools
<js />
My AppGini Blog:
https://appgini.bizzworxx.de/blog
You can help us helping you:
Please always put code fragments inside
[code]...[/code]
blocks for better readabilityAppGini 24.10 Revision 1579 + all AppGini Helper tools
Re: Delete record: Ignore only specific "table"
Hi Jan,
thank you.
Olaf
thank you.
Olaf
Some postings I was involved, you might find useful:
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view
SingleEdit - Prevent concurrent edits on records; Field Permissions; Column-Value-Based-Permissions; Custom (error) message; Audit Log; Backup your database; Two Factor Authentication; Block brute force (failed) logins; Add 2nd SAVE CHANGES button; Place a search on details view