odoo/odoo#204011
Created by fw-bot
Statuses:
- legal/cla: Contributor License Agreement check
- ci/runbot: Odoo Test Suite
- ci/upgrade_enterprise: Test upgrades for enterprise master
- ci/template: Contact runbot team on discord for help.
- ci/style: Optional style check. Ignore it only if strictly necessary.
- ci/security: Required security check. Can only be ignored by security team.
- label
- odoo-dev:saas-17.4-15.0-fix-form-data-for-values-mou-426396-fw
- head
- 87dd4cd64a8d5e058d33b8109f0d3ffd758499bf
- merged
- 6 months ago by Website, Outagant Mehdi (mou)
| odoo/odoo | |
|---|---|
| 16.0 | #166565 |
| 17.0 | #203995 |
| saas-17.4 | #204011 |
| 18.0 | #204027 |
| saas-18.1 | #207698 |
| saas-18.2 | #207727 |
| saas-18.3 | #208131 |
| saas-18.4 | |
| 19.0 | |
| master | #208155 |
[FW][FIX] website: prevent the removal of the form's default values
Steps to reproduce [17.1]:
- Add a property field to a job application in the backend.
- Go to the linked website job application form (in edit mode).
- The property field is inaccessible.
To be able to access the new property field in the application form, the
job_id value of the related job record needs to be specified by
default. Unfortunately, these values are removed before accessing "edit"
mode:
Starting from 1, a fix was added to clear default values coming from
data-for attributes when the form is edited (at cleanForSave()) to
prevent saving it with changed default values.
Since the code from 1 can also remove default values set by the user,
a new fix (see 2) updated this implementation to ensure that only
values from auto-fill and data-for fields will be removed (this time,
when the form public widget is destroyed [3]).
The behaviour from [3] will always unlink the data-for values in edit
mode, and as a consequence, the related property fields won't be
correctly retrieved.
The goal of this commit is to fix this behaviour by excluding data-for
values from the reset in [3]. An extra check will be added to be sure
the form won't be saved with updated default values if it already has
data-for ones [4].
Important: The diff from 5 made the email_to field as an exception
for the data-for/prefill priority system and only used the data-for
value if nothing has been configured by the user (it also used the
data-for value if what was configured by the user is the dummy default
email: info@yourcompany.example.com). That's why we need to
exceptionally allow saving the default value added by the user in the
check from [4] to preserve the same behavior.
Following 6, The email_to value won't be kept in edit mode to
prevent breaking its dynamic behavior.
Forward-Port-Of: #166565