bug fix for HasOne,HasMany select in a repeater created in pull https…

[netsco]

Description

Since version 3.3.4 https://github.com/filamentphp/filament/releases/tag/v3.3.4 the update broke selects in a repeater on a form. I locked to v3.3.3 till I had time to look at it and looks like the pull request that was merged #15650 created a problem with HasOne, HasMany in a select in a repeater on a form as is trying to make an update main model instead of the relationship handling the update.

I have added check that the if the data path is less than 1 deep then it runs the new code otherwise it ignores it if it is deeper in the case of it being in a repeater, if there is a better way to check for this let me know and I will amend.

Visual changes

Error on save trying to set id of the record to null on update

Functional changes

• [ x ] Code style has been fixed by running the composer cs command.
• [ x ] Changes have been tested to not break existing functionality.
• [ x ] Documentation is up-to-date.

[danharrin]

Can you please post code in your project that causes this problem? The state path is not necessarily indicative of how deeply nested the relationship is, so I don't understand the change

[netsco]

Here is the partial form schema with the repeater for a ContactResource where the error originates. Works fine on v3.3.3 and before but anything after generates the error. There is no data mutation before save or custom save logic.

Section::make()->schema([
	TextInput::make('company')
		->required()
		->hidden(fn (Get $get) => ContactType::fromGet($get('type')) !== ContactType::Company),
	Fieldset::make('Name')->schema([
		TextInput::make('title')->required(),
		TextInput::make('first_name')
			->columnSpan(2)
			->required(),
		TextInput::make('last_name')
			->columnSpan(2)
			->required(),
	])
		->columns(5)
		->hidden(fn (Get $get) => ContactType::fromGet($get('type')) !== ContactType::Person),
	Repeater::make('companies')
		->label('Companies')
		->relationship('companies')
		->schema([
			Select::make('company_contact_id')->relationship(name: 'contact', titleAttribute: 'company')->label('Company')->searchable()->disableOptionsWhenSelectedInSiblingRepeaterItems()->required()->columnSpan(2),
			TextInput::make('job_title')->required()->columnSpan(2),
			Toggle::make('is_primary')->label('Primary')->inline(false)->fixIndistinctState()->columnSpan(1),
		])
		->columns(5)
		->addActionLabel('Add Company')
		->defaultItems(0)
		->hidden(fn (Get $get) => ContactType::fromGet($get('type')) !== ContactType::Person),
])->hidden(fn (Get $get) => ! $get('type'))
	->columns(1)
	->columnSpan(3),

[netsco]

Hi

I have created a minimal repository showing the issue with a contacts resource https://github.com/netsco/filament-select-issue if you try and use the any of the repeaters for email, tel, addresses and try and save it returns an error in filament v3.3.4 and later but if you set v3.3.3 or previous in composer.json and update it works as expected I checked and I first wrote this initially with v3.2.39.

You just have to add a filament user, I have included the relevant data seeded on migration to be able to create a contact.

Let me me know if you want me provide anything further.

I understand that my fix might not be ideal but can you suggest a better way of checking if the select is in a repeater and I can update.

Thanks,

[danharrin]

Can you please simplify the repository, or let me know exactly which Select or relationship is causing the problem? In your repository there are alot and I'm trying to work out if we can identify relationships that shouldn't be saved, as I think there are situations where saving a select in a repeater would work fine

[danharrin]

I'm going to revert the original PR and probably bring it back in v4, so please submit a bug report with a minimal reproduction when that is released

[jeffegiovani]

I have exactly the same problem im my projects.

An workaround is change ->hasOne() relationships to ->belongsTo() relationships. It's working for me.

[danharrin]

@jeffegiovani no need, update as the original PR that caused the issue was reverted.