Weird relation manager CreateAction behaviour
My relation manager's create action is constantly trying to put audit_id as (1), instead of the id of the audit (17) for which the agenda is being created. I have never ever encountered such an error and I have no idea what I am doing wrong.
Can someone help me out?
Here is the DB error:
SQLSTATE[23503]: Foreign key violation: 7
ERROR: insert or update on table "agendas" violates foreign key constraint "agendas_audit_id_foreign"
DETAIL:
Key (audit_id)=(1) is not present in table "audits".
(Connection: pgsql)
SQL:
insert into "agendas"
("title", "description", "date_from", "date_to", "audit_id", "updated_at", "created_at")
values
('gfdsgfds', 'fsdgdsfgds', '2025-10-06 16:59:40', '2025-10-22 16:59:42', 1, '2025-10-01 14:59:45', '2025-10-01 14:59:45')
returning "id"
7 Replies
How did you define that relation?
Just a regular relation manager, if that's what you are asking.
Audit model has many agendas
Agendas belong to audit
I think I am doing everything fine, where do I even look for cause for such a behaviour of forcing (1) as a foreign key
Yeah, look good to me.
Can you try without reusing
AgendasTable::configure($table)
and just a simple table with CreateAction
?Returned it to this:
And the table definition below, maybe it will help.
I still get the same error, it wants to put (1) as audit_id, where it should read from the parent audit...
Can you please try without
AgendasTable::configure()
. Just a plain simple table with the CreateAction
Aha, yeah it still causes the same thing.
I think I’ve found a clue, because the same issue is happening in another one of my resources (the Program resource).
Here’s the situation:
I have Process and Audit models.
Audit has a Filament resource, but Process does not.
In my Program resource, I’ve defined two relation managers:
AuditRelationManager
ProcessRelationManager
For Audits, since the model has its own resource, I’ve split out the form and table definitions into AuditForm.php and AuditsTable.php. That way I can reuse them wherever I need — for example, inside the AuditRelationManager of the Program resource.
But when I do this, the issue appears:
New Audit records (created via the relation manager in the Program resource) always end up being attached to the program_id = 1, regardless of which Program I actually have open.
Similarly, with Agendas (another model with its own resource), new records always get attached to audit_id = 1. If a record with that ID doesn’t exist, I get a foreign key violation error.
On the other hand, for Processes, which don’t have their own resource, everything works correctly. The form and table are defined directly inside ProcessRelationManager, and new processes are created under the correct Program that’s currently open.
So it seems like the problem only happens when I have a dedicated resource for the model that is going to be a relation manager.
I have also tried just defining the AuditForm and AuditsTable inside the relation manager's respective methods, but still same shit happens.
Why does this happen?@Dennis Koch
@Dan Harrin maybe you can know since you know this inside out....sorry for tag