When unlinking an ir.model, all the ir.model.constraint linked to this
ir.model must be removed to avoid to call unexisting model.
The ir.model.constraint records, are created with module = the module where the related field
has been declared. But when unlinking the ir.model in function _module_data_uninstall, the related
ir.model.constraint to remove were chosen according to the removed modules. So with models
declaring constraints on inherited fields, some problems occured because the model could be removed
and not all the related constraints.
opw:716032
In f65475d6 one2many fields of default view in a form view were propagated
to the ORM so the value received from an onchange was not empty.
These new steps test this on a tree view embedded in a form view, or a
tree view originating from a default view by testing onchange adding row
or updating values of a one2many.
In a form view, when a field onchange lead to a change on a x2many,
there was two different behavior:
- if the x2many had an embedded view (eg. a tree view inside a form
view) the onchange would notify that it expected the x2many field in
this embedded view to be changed and handled the changes correctly.
- if the x2many had a default view, the onchange ORM would not be
aware the x2many could be modified and would not sent the changes
back causing blank or not updated x2m lines and error on save.
---
Two solutions were birthed to solve the second point:
=> PR #10557 = solving everything
With this PR the onchange in the ORM is aware of every fields in the
current view (even field in a x2m in a x2m in a x2m in a form view) and
if any of these are change the javascript gets back the value of the
fields present in the view.
This PR has currently not been merged by fear of changing too much and
anyway could only be done in master.
=> PR #12249 = if no field for x2many, send its form view fields
With this change, if the ORM onchange is not aware of the fields in the
x2many widget to returns, all the field in the x2m default form view are
returned.
This was merged in bbdf960 but introduced a number of other issue:
- in most situation the x2many is represented by a list view, which may
have fields missing of the form view, so the original is still present.
- the view used may differ from the default form view in other way
(depending on value in context or other possibilities).
- the form view could have fields not present in the form view which
could end up in `write` on fields which should not be written to.
---
This commit reverts bbdf960 and adapts a small part of #10557 so the
x2many with default view works as an embedded x2many. For more than one
level (eg. a x2many in a x2many) this would still not work but it is
only solvable by a PR such as #10557 which could only be targetted for
master.
With this commit:
- the list of fields sent to ORM onchange is computed at the first onchange
- the fields from a x2many field default view is sent for onchange
- the initial onchange on record creation is delayed to when x2many are loaded
closes#12249, closes#15336, closes#15890fixes#11236, fixes#12249, fixes#15129, #15419
opw-705965 opw-716095 opw-715619 opw-710440
Purpose
=======
Setting a currency rate is not user friendly. I struggle to find my way. Should be obvious in currency form
Specification
=============
- Accounting > configuration > currencies > there should be a default fiter displaying only active currencies
- Remove "View Rates" action button
- Add one stat button "Rates" which open the currency rate list view, also allow to create new currency rate(here do not open form view just editable=bottom in list)
We sometimes use in Odoo a One2many field with an inverse Integer
field instead of a usual Many2one.
This allow for example in several instances to have a "Many2one" which
can be reference from several models, eg:
Model Ranking:
name = String field
res_id = Integer field
res_model = String field
Model Toy:
rank = One2many [inverse: Ranking -> res_id]
[domain: res_model == Toy]
Model Tool:
rank = One2many [inverse: Ranking -> res_id]
[domain: res_model == Tool]
This enable us to have a shared feature between otherwise unrelated models.
But there was several issue when searching on these One2many:
1) if the Integer Many2one was not stored (eg. it came from an inherits) on
the searched model, this could lead to an error.
2) when we searched:
- by IDs (rank in ['55']) with at least one id not respecting the domain
- by IDs with a negative operator
- with a negative operator on unfound string (rank != "no rank has this")
- with a false value (rank = False)
we would not apply the One2many domain (eg. res_model == Toy) and thus
possibly getting Toy 3 errenously because a Tool 3 was found without
the domain being applied.
This fix modify the search on One2many and for:
1. if the inverse is an Integer not stored field instead of Many2one
manage it.
2. if the field is an Integer field instead of Many2one and there is a
domain on the One2many: apply the domain on the inverse model found.
So only some search on One2many with a domain whose inverse field is an
Integer could be impacted.
This would also be nice to have for all One2many with a domain but the
probability of it being useful versus risk for performance is not judged
high enough.
opw-710508
The method `write` calls `env['res.lang']._get_installed`, which is ormcached.
After activating a language with `write`, one must invalidate the ormcache.
When unlinking an ir.model, all the ir.model.constraint linked to this
ir.model must be removed to avoid to call unexisting model.
In stable version, the right fix would be to put an attribute ondelete=cascade
on the field model of ir.model.constraint.
In 10.0, the ir.model.constraint are created with module = the module where the related field
has been declared. But when unlinking the ir.model in function _module_data_uninstall, the related
ir.model.constraint to remove were chosen according to the removed modules. So with models
declaring constraints on inherited fields, some problems occured because the model could be removed
and not all the related constraints.
opw:716032
If the company currency is not active (that should not happen but nothing
prevents it, probably happening with some CoA installation), the variable
company_currency_format is undefined and an error is raised.
Closes#15799
- Install accounting module
- Create new tax, keep note of its ID
- Go to Settings > Technical > User-Defined Defaults
- Change the value of 'taxes_id' to the ID of the tax created
- Create a new product => crash
The issue is that the value of 'taxes_id' is saved as a string, not as a
list. Therefore, once retrieved, it crashes.
opw-709906
During installation of demo data and while running tests, the
system should not actually connect to a real SMTP server.
This allows installing new demo/test databases on a system
with no working SMTP server.
Simplifies the code and makes sure we are calling the connect()
method in the same way we do for normal deliveries, and that
all parameters are processed in the same fashion.
For the purpose of fighting spam, many abuse/spam-fighting
services provide redacted message IDs. Because we use a UNIX
timestamp as the prefix for all message IDs, a redacted
message ID of the form 1234XXXXX@domain.com is generally
useless to find a `flagged` message's origin, because it
matches most of the messages sent that day.
Narrowing it down with the help of the approximate time
of delivery does not help much, as there will still be
dozens/hundreds of possible matches on a busy server.
By swapping around the random token and the timestamp in
the message ID, we should improve the uniqueness and
"greppability" of our message IDs, once redacted.
Work around performance issue when sending large mass-mailing:
1. Processing a large email queue would crash with MemoryError.
-> The queue agent will now browsing the emails 1 by 1 during
delivery to avoid filling the memory.
-> The agent will not select more than 10k emails per delivery.
The delivery rate can be increased by waking it more often.
2. Reopening a connection to the SMTP server every time is slow.
-> ir.mail_server.send_email() now accepts an extra `smtp_session`
optional parameter. When passed, that session will be used and will
not be disconnected after the delivery. The queue processing agent
prepares batches of emails to be sent to the same outgoing mail
server, and uses a persistent smtp_session to avoid the multiple
reconnection.
To account for MTA that would refuse to process a large number
of emails in the same session (that should be rare), a system
parameter can be used to set the batch size (default: 1000).
3. As a bonus, the ir.mail_server.connect() method is now
responsible for resolving the actual mail server parameters,
rather than having half of the logic in the send_email() method.
Warning: this commit drops support for "maildir:/" format in
outgoing mail servers hostnames. This feature is deprecated,
unused, untested, and was meant for debugging only.
When an automated action triggers for an action of a public/portal
user session, the server action is executed with the session
credentials. As of 4a18d5744e
only employees can access model fields, including the model name,
so a temporary sudo() elevation is necessary to find the model name.
The `model` and `record` action context parameters are however still
provided with the credentials of the session, not the super-user.
Purpose
=======
When using Studio and adding a many2one field for example, it will be easier for a non technical user to find the model res.partner under the name "Contacts" than under the name "Partners".
Odoo Translation Bot