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
Dennis Koch
Dennis Koch2d ago
How did you define that relation?
BloodDrunk
BloodDrunkOP2d ago
<?php

namespace App\Filament\Resources\Audits;

use App\Filament\Resources\Audits\Pages\AuditResult;
use App\Filament\Resources\Audits\Pages\ViewAudit;
use App\Filament\Resources\Audits\RelationManagers\AgendasRelationManager;
use App\Filament\Resources\Audits\Schemas\AuditForm;
use App\Models\Audit;
use Filament\Resources\Resource;
use Filament\Schemas\Schema;

class AuditResource extends Resource
{
protected static ?string $model = Audit::class;

protected static ?string $recordTitleAttribute = 'title';

protected static bool $shouldRegisterNavigation = false;

protected static ?string $tenantOwnershipRelationshipName = 'program';

public static function form(Schema $schema): Schema
{
return AuditForm::configure($schema);
}

public static function getRelations(): array
{
return [
AgendasRelationManager::class,
];
}

public static function getPages(): array
{
return [
'view' => ViewAudit::route('/{record}'),
'results' => AuditResult::route('/{record}/results'),
];
}
}
<?php

namespace App\Filament\Resources\Audits;

use App\Filament\Resources\Audits\Pages\AuditResult;
use App\Filament\Resources\Audits\Pages\ViewAudit;
use App\Filament\Resources\Audits\RelationManagers\AgendasRelationManager;
use App\Filament\Resources\Audits\Schemas\AuditForm;
use App\Models\Audit;
use Filament\Resources\Resource;
use Filament\Schemas\Schema;

class AuditResource extends Resource
{
protected static ?string $model = Audit::class;

protected static ?string $recordTitleAttribute = 'title';

protected static bool $shouldRegisterNavigation = false;

protected static ?string $tenantOwnershipRelationshipName = 'program';

public static function form(Schema $schema): Schema
{
return AuditForm::configure($schema);
}

public static function getRelations(): array
{
return [
AgendasRelationManager::class,
];
}

public static function getPages(): array
{
return [
'view' => ViewAudit::route('/{record}'),
'results' => AuditResult::route('/{record}/results'),
];
}
}
Just a regular relation manager, if that's what you are asking. Audit model has many agendas
public function agendas(): HasMany
{
return $this->hasMany(Agenda::class);
}
public function agendas(): HasMany
{
return $this->hasMany(Agenda::class);
}
Agendas belong to audit
public function audit(): BelongsTo
{
return $this->belongsTo(Audit::class);
}
public function audit(): BelongsTo
{
return $this->belongsTo(Audit::class);
}
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
Dennis Koch
Dennis Koch2d ago
Yeah, look good to me. Can you try without reusing AgendasTable::configure($table) and just a simple table with CreateAction?
BloodDrunk
BloodDrunkOP2d ago
Returned it to this:
public function table(Table $table): Table
{
return AgendasTable::configure($table);
}
public function table(Table $table): Table
{
return AgendasTable::configure($table);
}
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...
Dennis Koch
Dennis Koch2d ago
Can you please try without AgendasTable::configure(). Just a plain simple table with the CreateAction
BloodDrunk
BloodDrunkOPthis hour
Aha, yeah it still causes the same thing.
public function table(Table $table): Table
{
return $table
->headerActions([
CreateAction::make()
->label('Add agenda item')
->modalHeading('Add agenda item')
->modalSubmitActionLabel('Save')
->disableCreateAnother()
->icon(Heroicon::OutlinedPlus)
->successNotification(fn (): Notification =>
Notification::make()
->title('Agenda item added')
->body('New agenda item has been succesfully added to the audit.')
->success()
)
->after(function (): void {
$this->dispatch(
'agendas-updated',
[
'eventName' => 'agendas-updated',
],
);
}),
]);
public function table(Table $table): Table
{
return $table
->headerActions([
CreateAction::make()
->label('Add agenda item')
->modalHeading('Add agenda item')
->modalSubmitActionLabel('Save')
->disableCreateAnother()
->icon(Heroicon::OutlinedPlus)
->successNotification(fn (): Notification =>
Notification::make()
->title('Agenda item added')
->body('New agenda item has been succesfully added to the audit.')
->success()
)
->after(function (): void {
$this->dispatch(
'agendas-updated',
[
'eventName' => 'agendas-updated',
],
);
}),
]);
BloodDrunk
BloodDrunkOP23h ago
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

Did you find this page helpful?