Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
- Use the form builder to send an email
- Customize the snippet to include the subject and the body
- Send a mail
=> The subject is not included in the email
This is because the subject is filtered out and considered as a
blacklisted field.
It happens because `mail.mail` inherits from `mail.message`. The field
property `website_form_blacklisted` is set to:
- `True` for `mail.mail`
- `False` for `mail.message`
Since we go through all inherited models, the property on `mail.mail` is
overriden by the property on `mail.message`.
It is actually not necessary to go through all inherited models, since
in the case of `inherits`, we copy the fields of the inherited model to
the target model. The check is simplified by only checking the fields of
the current model.
Based on work of @nla-odoo
opw-748926
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
Improve thank page after the application to a job.
Stop duplicate Magic field, using global fields
Add helper method on website to retreive the last created record
Simplify the API as much as possible, and delegate all the implementation
details to the models `ir.model`, `ir.model.fields`, `ir.model.constraint` and
`ir.model.relation`.
Remove unrestricted "read" access. To make code internally using `ir.model`
work, add a private method `_get` on `ir.model` to retrieve the record
corresponding to a model name, without access rights issue.
Change signature of method `get_authorized_fields` to make it use a model name
instead of a model id. This removes the necessity of a search on `ir.model`.
Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:
- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
translated
The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).
Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).
This commit correct all the external ids tagged as from base or other incorrect
modules.
* blacklist all fields by default
* don't use blacklist in get_authorized_fields which is called to see if
a field can be added to a form, instead only use it afterwards to see
if the field can be written to by the formbuilder. That way
formbuilder can whitelist fields which are actually added to forms
on-demand resulting in a more secure interaction
- Fixed the module name and category in manifest
- Fixed website_form_blacklisted being ignored
- Unauthorized readonly and magic fields
- Reset the form on successfull submit
- Added missing date field
- Added date and datetime validation
Olivier Dony