The form view product.template.common.form is common for product.product
and product.template Then the active_id could not be used by default for
the field product_tmpl_id.
opw:670779
A Phantom BoM can have service products which can create tasks.
Somehow the code did not use the _need_procurement function that was there before
to check if it needs to create a task.
When using the left/riht arrow to switch of record
in a form view,
the rendering of the `char_domain` widget was done too
early, before all fields are ready / set, and if the
domain of the previous record could not be applied
on the current record, it leaded to a traceback.
This revision introduce a new deffered,
because I coudln't find one that was doing
what I was looking for:
- `is_initialized` is a defferred which is
resolved when the form view has finished
its rendering for the first time
- `reload_mutex` is a mutex used only when reloading or
switch to left/right record.
While the one needed in this case is a deferred
which is resolved when the record has finished
being rendered, wether when its when coming
from the list view to the form view (and it's
not the first time the form view is loaded,
e.g. list view -> form view -> list view -> form view, another record),
or on the switch of left/right record.
opw-671594
The field help on an ir.actions.act_window is a translatable html field.
When a value is set, it is processed by the `html_sanitize` method to make sure
only valid HTML content is present in the database.
In sanitization, xml line break tag `<br/>` is converted into html tag `<br>`.
Before revision 6c8e53a0, `xml_translate` method was using XML parser for html
fields. Line break was then exported as `<br/>`.
Since this revision, it is using a proper html parser and line break is exported
the same way as it is stored in the database, with a `<br>`.
When translating html value, the content is split per meaningful block and
recomposed based on the msgsrc value. Due to the change of parser, translations
exported before 6c8e53a0 contains `<br/>` tag inside the msgstr and could not
match any block in splitted content (which contains `<br>`).
Correct the .pot with valid tag.
Do not change the xml content of help message as it should still be XML inside
the data files.
opw 671477
Before 3959afc the `node` tested would be the selection containing node,
but since then it may have been a `<br/>` which has some damaging
effects: now entering double enter at the end of a list, quote or code
block doesn't end this block.
Testing the use case corrected by 3959afc, the said change seems to have
no effect so this commit reverts it.
opw-667618
When a "Drop Shipping" route is used on a product, the origin document
is duplicated on the PO created. This is because in this case,
po_rec.origin and procurement.origin are the same.
opw-671039
Since 27a7cab52b, it may happen that the
stock.history view contains duplicated id (mutliple quants with
different lots for a single move).
Regroup serial numbers in order to keep a unique id per row.
opw-669349
Specifying the partner_id in the search does not give the same
result as the portal_sale module, which actually lists all the
SOs/Quotes/Invoices where you or anyone from your company is the
partner_id. To make the backend and frontend listings consistent,
let the ACL and ir_rules do their job (these are defined in the
portal_sale module).
When creating work center, a resource.resource record is created.
Then a member of group_mrp_manager is allowed to create resource.resource record.
opw:671218
Edge >=12 throws an error (code 800a025e) when calling the select()
method on an input element that is not currently part of document and
has a non-empty value.
When adding a paymentline a "change:selected_paymentline" event gets
triggered which in turn triggers the focus_selected_line function before
the actual paymentline gets rendered.
opw-671426
`account.move.line.company_id` is a related
to `account_id.company_id`
`account.bank.statement.company_id` is a related
to `journal_id.company_id`
Any attempt to set the `company_id` value
when creating or writing records for these models
will result to the update of the value in
the related record (the update of `company_id` in the
`account.account and the `account.journal`), which
will result in the update of the `company_id` value in all
records in which this related record is used
(in all `account.move.line` where this `account_id` is used,
in all `account.bank.statement` where this `journal_id` is used).
In other words, the more a database had `account.move.line`
or `account.bank.statement` records, the more
it took time for the pos sessions to be closed.
To force a company for an `account.move.line`
(`account.bank.statement`), you must just
set the correct `account_id`(`journal_id`)
in the first place.
For instance, for the `account_id`, passing
`force_company` in the context ensure to choose
the `account.account` from the right company
property.
See
`local_context = dict(context or {}, force_company=company_id)`
which is set in `_confirm_orders` just before calling
`_create_account_move_line` which retrieve
the account from the
`property_account_receivable_id` property.
opw-671362
Odoo Translation Bot