[18.0][web_widget_dropdown_dynamic][FIX]: propagate required prop and value dissappearing after losing focus when used in list view

[Rad0van]

I noticed inconsistent rendering behavior between this module and standard Selection field when using required="True"

The standard Selection field when required="True" renders the options without any blank line in the list:


When required="False" the Selection provides empty value as well:

However web_widget_dropdown_dynamic always adds blank line to the list even when there is no value selected even if required="True":

This comes down to propagating required property which this fix addresses and thus brings web_widget_dropdown_dynamic to be visually aligned with standard Selection widget.

I was also using a list view of one2many inside a form with selection field using web_widget_dropdown_dynamic widget noticing strange behavior: selecting an option works fine but when the field loses focus, the value dissappears. However it is saved into the database. When loading the form the value is not there either, onl;y when clicking the field.

The web.SelectionField template has two rendering paths:

• Edit mode: uses options + value → <select> renders correctly with the chosen option
• Readonly mode: uses this.string → <span t-esc="string">

FieldDynamicDropdown extends Component directly (not SelectionField), so get string() was never inherited. When an editable list row loses focus and switches back to readonly display, this.string is undefined — OWL renders an empty span. The value is still in the record (hence "saved into database later"), but the readonly display renders blank.

Fix: Added get string() to FieldDynamicDropdown that looks up the label for the current value from this.specialData, matching the same logic as SelectionField.string but working with the dynamically-fetched options. With the help of Claude added a test for this as well.

[Rad0van]

Seems I have messed up the branches. My first PR was done on 18.0 branch which is not the proper way and I didn't notice I did this one on top of it. Any suggestions what to do? Redo both? Merge them into one? Or?

[hbrunn]

your first commit message has a type

[hbrunn]

Seems I have messed up the branches. My first PR was done on 18.0 branch which is not the proper way and I didn't notice I did this one on top of it. Any suggestions what to do? Redo both? Merge them into one? Or?

keep this PR and close the previous one, seems nobody reviewed this anyways

[Rad0van]

Seems I have messed up the branches. My first PR was done on 18.0 branch which is not the proper way and I didn't notice I did this one on top of it. Any suggestions what to do? Redo both? Merge them into one? Or?

keep this PR and close the previous one, seems nobody reviewed this anyways

Did as you proposed.

[hbrunn]

looks like you undid the required commit though. please squash commits in the end to have one for the prop, one for the string property+test, one for contributors

[Rad0van]

looks like you undid the required commit though. please squash commits in the end to have one for the prop, one for the string property+test, one for contributors

Should be OK now I hope.

[hbrunn]

I can live with you having squashed everything to one commit, but please fix the typos in the commit message

[Rad0van]

I can live with you having squashed everything to one commit, but please fix the typos in the commit message

Oh, stupid me. I didn't properly read what you wrote - one for prop and one for the rest. Sorry. Fixed the typos.