Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DBForeignKey scaffolding uses wrong parameters to create SearchableDropdownField #11294

Closed
2 tasks done
johannesx75 opened this issue Jun 27, 2024 · 1 comment
Closed
2 tasks done
Labels

Comments

@johannesx75
Copy link
Contributor

johannesx75 commented Jun 27, 2024

Module version(s) affected

5.2.13

Description

Auto-scaffolding for has_one form fields creates an instance of SearchableDropdownField by passing:
SearchableDropdownField::create($this->name, $title, $list, $labelField)

The signature for the SearchableDropdownField constructor expects:
string $name, ?string $title = null, ?DataList $source = null, mixed $value = null, string $labelField = 'Title'

So the call is missing $value. This leads to $value being set to $labelField, which is 'Title'.

Not a big deal, since the scaffolding will set the value later again. But it leads to warnings in the php log:

Could not determine value in SilverStripe|Forms|SearchableDropdownField: :getValueArray()

Since this is also affecting my idea for a solution of #11293 I'll create a separate fix and pull request for this issue.

How to reproduce

Given ModelA has_one ModelB and ModelB has_many ModelA:

  • Open ModelB in Model Admin
  • Go to the ModelA Tab
  • Click on Add new Model A

Check Error Log.

Possible Solution

add null as value when calling SearchableDropdownField::create

Additional Context

No response

Validations

  • Check that there isn't already an issue that reports the same bug
  • Double check that your reproduction steps work in a fresh installation of silverstripe/installer (with any code examples you've provided)

PRs

@GuySartorelli
Copy link
Member

GuySartorelli commented Jul 8, 2024

Reopening because it needs to be fixed in 5.x-dev separately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants