Rev e37ba61 forward-ported 8.0 revision f02b230 from PR #12379.
This patch introduces extra tests and views for o2m onchange behavior,
including new fields in the test models.
In 9.0 a new convert_to_onchange() mechanism had been
introduced at 9f81c6d
The combination of both requires some adaptation to the
expected results of the new tests and adaptation of existing tests.
The test models in `test_new_api` have an implicit depencies between
models which cannot be express on ORM:
messages depends on participants of their discussion.
So, when editing a discussion, the field `participants` should be
processed before field `messages`. This is not always done because
field processing order depends of the iteration order of a `dict` (which
is undefined in python).
The testing tour `widget_x2many` worked by chance until now.
Adapt the tour to save the participants before the messages.
Commit 358e285 introduces fiscal positions on the PoS. The new taxes
applied should be used in the form view of the pos order lines and in
the detailed sales report.
opw-680796
As explained in 15f27b26, the transaction information should be computed when
hitting the "pay now" button, not at page rendering (e.g. in case of users going
back to previous page).
Stripe do not work as typical providers as it does not redirect to the provider
page but opens a popup.
The route /shop/payment/transaction/<id> needs to be called manually.
Setting NOT NULL constraints on required fields may fail if there are
any row with unset value for this column.
The ORM handle this case by catching the exception raised and warning
user.
However, not commiting the current transaction before, will rollback
changes made before like setting default values or renaming a column.
Some one2many fields have a domain specified
in their definition
e.g.
`mail.thread`.`message_follower_ids`
`hr.applicant`.`attachment_ids`
`project.task`.`attachment_ids`
which is required for the one2many field to make
sense. For the mail thread, it does not make sense
to include the followers of other models with the same
`res_id`.
This domain must be took into account when doing a
'like' search on the one2many field
e.g. Followers contains demo
Otherwise it will include threads from other model
opw-680825
When a product is a kit and a discount is applied thanks to a pricelist,
the discount is counted twice if the invoice is created from the stock
picking.
This is because the pricelist will modify the price unit, but moreover
the discount will be applied a second time by the method
`_compute_price` of the account move line.
opw-676838
Our usage of domain on fields One2many seems to trigger an obscure behaviour on
onchange.
With the following (simplified) config:
Message(models.Model):
_name = 'test_new_api.message'
important = fields.Boolean('Important')
Discussion(models.Model):
_name = 'test_new_api.discussion'
name = fields.Char('Name')
important_emails = fields.One2Many('test_new_api.emailmessage', 'discussion',
domain=[('important', '=', True)])
Email(models.Model):
_name = 'test_new_api.emailmessage'
_inherits = {'test_new_api.message': 'message'}
discussion = fields.Many2one('test_new_api.discussion', 'Discussion')
message = fields.Many2one('test_new_api.message', 'Message')
Steps:
- We change 'name' on discussion, triggers an `onchange()` call
- we ends up filling cache on virtual record (on secondary fields, we calling
record.mapped('important_emails.important'))
- we get a cache miss ('important' field not provided, only 'important_emails' ids,
i.e with no change on existing records)
- we fill the cache, this mark 'important' field as modified
- because of commit 5676d81 and because 'important' is that case is a related (i.e
computed) field we triggers cache recomputation
- as there is no way to recompute 'important_emails' for virtual record (no real
ID) we ends up with empty 'important_emails' generating removal of existing records.
=> Finally changing any value for 'test_new_api.discussion' that trigger an onchange
will always reset 'important_emails' to empty
Fixed by Raphael Collet <rco@odoo.com>, and test by Xavier Alt <xal@odoo.com>.
When user reset master password from web database manager, the
config file is saved.
If server was started in dev_mode the param dev_mode was saved
in openerp_serverrc silently. (in 9 or always in trunk)
Remind: --dev_mode should be never used on a production server.
Do not redefine the view arch but do a proper inherit.
It was a problem as the redefinition removed some fields (headers,..).
It was also a problem if crm_profiling was uninstalled as the redefinition was
not removed.
Closes#12454
New API use a frozendict for context, so when a function in the call
chain is overrided by new API (eg: render function of ir.qweb) the code
now changed by this commit would cause an error.
Instead this code duplicate the context frozendict as a dict removing
the need to set back the intial language in the context.
opw-681167
note: no need for >=saas-11
During refactoring of the field view, parent.model has been replaced by
model_id since it is more elegant. (odoo/odoo@4a60a3)
That was correct when you was working directly from the ir.model.field.
But if you was comming from ir.model -> fields -> 'add an item', the
model_id is unknow in the context of pyeval.
This commit close#12455
The group_lines method didn't make the sum of the quantity field, hence resulting in incorrect results when making product based statistics from the account.move.line records.
Courtesy of Luc De Meyer. Was PR #10551
Odoo add the extra letter "s" to the translated word "Active User".
This is caused by adding "s" at the end of the word directly from the template,
which makes no sense in many language.
This prohibits translators from translating the plural form in any language.
The plural form and singular form of "Active User" should be translate
separately.
Fixes#12469Closes#12470
Use case:
-enable multi currency (use UDS as company currency and EUR as secondary currency)
-create account account in a different currency (EUR)
-create journal for the bank account in EUR
-create a new tax included tax
-create a new bank statement in EUR journal and add one line
-reconcile
-Choose a counterpart with the included tax and click on reconcile
Before the fix:
After reconciliation the amount_currency for tax and expense were wrong.
You could check this in the journal items linked to the bank statement.
Video:https://youtu.be/678rFb4OE2Q
opw:680693
When grouping result the BaseModel method _read_group_fill_results add
the possible groups which had no result.
But, if the order of the group is not consistent, we can get really
wrong results. The code logic is expecting that the grouped result
gotten and the list of groups (returned by _read_group_stage_ids of
crm.lead) is in the same order.
If the _order attribute of the model is not enough specific (as was the
case in crm.stage) the inconsistent order would kill aggregation values
(displaying 0 instead of what should have been present).
opw-680952
Rev. c9e38cae9f made the html sanitizer
stricter, and it will not badly break any attempt at composing
a good-looking mail template.
It will also strip all data-* attributes due to the default
`strict` mode, so any theme/snippets used in the template
will be dropped/crippled after saving.
mass-mailing templates are strictly meant for composing
outbound messages, and never displayed directly in users' Inbox
or published on the website. So there does not seem to be any
strict necessity to sanitize them.
Before this revision, this was not possible to write
`statment_id` on multiple journal items at a time,
as the condition:
`if 'statement_id' in vals and self.payment_id:`
required `self` to contains only one record