As in 13.0, the default terms and conditions must be translated in the lang of the partner
PS: In the first computation, narration will be equal to the narration in the lang of the user.
So it was not changed when setting a partner.
The narration must be computed in the lang of the partner.
Writing on payment_ref triggers function _synchronize_to_moves and a write on partner_id was made.
In the write function, function modified was called
https://github.com/odoo/odoo/blob/15.0/odoo/models.py#L3850
And it lead to add the field narration in self.all.tocompute
https://github.com/odoo/odoo/blob/15.0/odoo/api.py#L758
Meaning that the next time it read the field narration, the function _compute_narration was called.
So it reset narration to False
opw:2726012
closesodoo/odoo#85775
X-original-commit: 6d9745e63fec20a7e967f00a428db9109c992bcf
Signed-off-by: Simon Goffin <sig@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
This commit introduces the "useWowlService" hook. This hook allows
Owl components that use the legacy env (not the one of the
webclient for instance, typically called the "wowl" env) to access
services from the wowl env. Its API is the same as the classical
"useService" hook.
closesodoo/odoo#85769
Signed-off-by: Géry Debongnie <ged@odoo.com>
The signature of the _load_module_terms was changed at ac63556e23 to
pass explicit parameters instead of values hidden in the context
The previous code used working on a copy of the context when modifing
the 'overwrite' key. This was no longer the case after ac63556e23.
In case multiple languages are updated at the same time (as when a
module is updated), the 'overwrite' value is set to True after the
first loop.
To reproduce:
1. Create empty db with language English and without demo data
2. Activate languages fr_FR, fr_BE and fr_CH
3. Install module "note"
4. Now change in the fr.po the msgstr for this msgid:
"By sticky note Category" -> "Par catégorie de note collante FR"
and in the fr_BE.po the msgstr for this msgid:
"By sticky note Category" -> "Par catégorie de note collante BE"
5. Now update the module note without overwriting translations
(--i18n-overwrite option not set)
Observed behaviour:
The translations are overriden
opw-2760359
closesodoo/odoo#85768
X-original-commit: 37b98d413debabcd966718b2834d34f349e3cfbc
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Retroactive fix for an issue in 15.0+
In 15.0+, importing an invoice with an inactive currency will raise
a traceback. Before this it was handled by not setting the correct
currency on the invoice if not active.
With this change, we'll raise an error instead of creating an invoice
with the wrong currency.
closesodoo/odoo#85678
X-original-commit: 14c61c2563efeed1ca14294da32e2eb6d1855c5b
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
- enterprise: https://github.com/odoo/enterprise/pull/24914
Following new policies in terms of product design-language, this commit
will partially revert 546477d reducing the number of `oi` icons.
It will also improve rendering when icons are rendered at our default
font-size (13px), avoiding blur effects when icons use thin lines.
Since fontAwesome will coexists with `oi` longer than expected, the
commit will also review size utility-classes in order to get consistent
result when used in conjunction with fa's ones (notably `fa-lg`).
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#85651
Related: odoo/enterprise#24914
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit will adapt website's topmenu icons in order to be a
consistent with the backend.
It also solves a minor layout issue for '.o_menu_brand' that was
rendered incorrectly in enterprise.
Part-of: odoo/odoo#85651
Following new policies in terms of product design-language, this commit
will partially revert 546477d reducing the number of `oi` icons.
It will also improve rendering when icons are rendered at our default
font-size (13px), avoiding blur effects when icons use thin lines.
Since fontAwesome will coexists with `oi` longer than expected, the
commit will also review size utility-classes in order to get consistent
result when used in conjunction with fa's ones (notably `fa-lg`).
Part-of: odoo/odoo#85651
The accounting date and the related warnings were in some cases not
being set properly. This change aims to improve that by displaying
warnings in the view and updating the date on post instead of raising
user errors.
This will mostly affect sell documents.
Task id #2778958closesodoo/odoo#85744
X-original-commit: 51ddb870d346ff61a6ae36c8c3b545eaca9736cb
Signed-off-by: William André (wan) <wan@odoo.com>
As of now, the discount field is either only shown in
debug mode or if the sale module is installed and a
setting is set in sale.
This field should be shown in the view, and not depend
on a setting from another app.
This is especially true as it could be filled by the ocr
or when uploading from an edi, and it would be inconsistent
if the user couldn't display it.
Task id #2758965closesodoo/odoo#85737
X-original-commit: eb1a77753debdb034ad00ce10d908f4b9ee264ad
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
whith France localization, deleting a journal created by POS
leads to two errors.
first one is just a typing error.
second one is an infinite loop caused by calling super().unlink()
from methods marked with the api.ondelete
opw-2750852
closesodoo/odoo#85719
X-original-commit: 4961dd251211776a9661f27acda3c3e4dfedc50a
Signed-off-by: Simon Goffin <sig@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
According to the spec, the PrezzoUnitario should be the unit price
without the taxes. If we use taxes included, this can be problematic.
That is because there is another rule that says that the PrezzoUnitario
* Quantita - Sconto should be within 0.01 precision of the PrezzoTotale.
So, with taxes included and a price unit only rounded to 2 decimals, you
easily go out of that limit.
The solution is to increase the precision on the price_unit (6 decimals
should not cause side effects and precise enough for most cases)
and to do the calculation differently by calculating it again from the
price_subtotal on the invoice line.
Task id: 2764978
closesodoo/odoo#85718
X-original-commit: 82f2794a2aee8492cbd36d8ab4d8a62c9665789d
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
When users have same groups, implied_ids can be done in batches,
reducing write operations considerably.
Testing done:
800 users groups_id (all have same groups_id in the end) updated using
old code: took ~10s to complete.
With this improvement, it takes ~1.5s
closesodoo/odoo#85712
X-original-commit: 81994ea628cb492fef4e62c496d4ea1ab55d9a7e
Signed-off-by: Raphael Collet <rco@odoo.com>
If an installed module is only present in the dependency graph through a new,
uninstalled dependency, it was not be selected for upgrade when updating the
`base` module (c.q. `--update all`)
closesodoo/odoo#85704
X-original-commit: 6c80e7cfeafaaa4fb7c0d93cbe94c66068fc3170
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Since 4911a26d2c, `_check_barcode_uniqueness`
flush the default `_order` of `product.product` models (via many2one in the `_order`
of `product.packaging`). It creates a bottleneck (take > 10 minutes ) when we populate
(medium size) the `product.template` during `set_barcode_variant`.
Force the order to be trivial and simplify the domain with a 'in' instead of
multiple OR.
closesodoo/odoo#85687
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
1. Create a PO from Indian vendor [DEMO], confirm it, receive the products.
2. Go to Accounting app, manually create the vendor bill:
- select the Vendor [DEMO]
- in auto-complete field select the one created at 1.
Traceback will raise because the field l10n_in_company_country_code
was removed from account.move in
17610e8ca9
opw-2745052
closesodoo/odoo#85501
X-original-commit: ffbfdde4b5b4cd791e866341a31cdf5e8aeb27e3
Signed-off-by: William André (wan) <wan@odoo.com>
Currently, if we have both customer and assigned partner names,
they are displayed in a single line separated by an arrow icon.
However, if we have long customer name, arrow icon and assigned
partner name are not visible on card.
This commit improves the display of names by making a few changes
- breaking the line before the arrow icon
- displaying both customer and assigned partner name with text overflow
- adding a tooltip on customer and partner names
- improving tooltip on the arrow icon
taskID-2763930
closesodoo/odoo#85264
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The field prefetching mechanism was poorly customizable. Before this,
we could only tell if a field was prefetched with other fields or not at
all. We have no way to inform the framework, like: "When I need data of
that field, prefetch these other fields, which are likely be used in the
same transaction".
From now on, the `prefetch` attribute is used as a grouping key for
prefetching fields. When a field is fetched, all the fields with the
same value for `prefetch` are taken for prefetching.
For example, consider a small set of fields that are rarely used, except
for one flow A using them. You want to prefetch those fields only in
the flow A, and you want to fetch them in a single query. With the new
feature, simply set `prefetch=A` for some string `A` on those fields,
and they will be grouped for prefetching.
closesodoo/odoo#85220
Signed-off-by: Rémy Voet <ryv@odoo.com>
Issue
-----
When website is installed, the rendering of template uses a side effect
of the ORM cache (cache shared between sudoed env vs non-sudoed env) and
the fields prefetching feature to work correctly.
The `self.visibility` in (`_handle_visibility`, website/ir_ui_view.py)
is done in sudo mode, then it will fetch all prefetchable fields and put
them in the cache (that will be read in non-sudo mode in the render of
the template). Another example of issue related to this:
https://github.com/odoo/odoo/pull/83341.
Because of this, the fields of mixin `website.seo.metadata` were forced
to be prefetchable (the default for translate is to be not prefetchable
since https://github.com/odoo/odoo/pull/82896), which causes a useless
LEFT JOIN on "ir_translation" in most of business flow.
Fix
---
Remove the `prefetch=True` on mixin fields, and add a extra read to fill
the cache in case of website rendering. It also allows to read these
fields at the same time.
Part-of: odoo/odoo#85220
When we read data of one record, the method `recompute` (`_fetch_field`
-> `_read` -> `flush` -> `recompute`) can take more than 40 % of the
time of the `_read`, due to a huge number of recordset creation (from
`records_to_compute` and `records & recs`). Avoid that waste of time by
postponing the test on records.
For example, on a database with modules crm, mrp, purchase, website,
sale_management, reading the prefetchable fields of the current company
took 1.45 ms ± 60.3 µs, and now takes 1.17 ms ± 110 µs (more than 20%
speedup).
closesodoo/odoo#83818
Related: odoo/enterprise#24645
Signed-off-by: Raphael Collet <rco@odoo.com>
Part-of: odoo/odoo#85220
Notifications have now a new look and SCSS has been cleaned up
accordingly. This commit is part of v16 overall restyle (task-2704984).
task#2719037
closesodoo/odoo#82524
Related: odoo/enterprise#23580
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Currently, we lint and auto-format non-legacy files in web. The tool
that we use for this linting and formatting unfortunately does not
propagate any linting errors except for parsing errors. This means that
it's possible to commit files of which we know in advance that they will
break CI. This commit simply relints the files in a standalone manner
after they've been formatted, so that if there is a linting error, the
commit will be aborted.
It is still possible to commit non-conforming code (eg to save work in
progress before switching branches) by committing with the --no-verify
git flag
closesodoo/odoo#85727
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before, it would give a traceback when we would have a product.supplier_info
with the same code and partner used for multiple products. This way, we
avoid this traceback.
opw-2703669
closesodoo/odoo#85725
X-original-commit: d7b35bb60d84eb587d82a3d9da24e39e8a42af9d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>
With owl2, the `el` of components if no longer available. One must
use a t-ref instead. However, higher order components don't have
their own html element. This was the case of the View component.
However, it makes sense for this component to be the owner of the
view root element, which was previously owned by the Layout.
This commit refactors the View/Layout architecture s.t. the root
element is now owned by the View, and simplifies/generalizes the
Layout in the process. The Layout is no longer tied to the notion
of views, and can thus be used in client actions as well.
closesodoo/odoo#85639
Related: odoo/enterprise#24903
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Michael (mcm) <mcm@odoo.com>
Co-authored-by: Samuel Degueldre <sad@odoo.com>
*crm, project
With owl2, the `el` of components is no longer available. It still
works in Odoo on LegacyComponent, which has been introduced to ease
the switch from owl1 to owl2, and we're now incrementally removing
it.
With this commit, the action scrolling helpers no longer rely on
component.el, meaning that views using them (through the hook
`useSetupAction`) no longer need to extend LegacyComponent.
More specifically, we move the action scrolling helpers from core/
to webclient/actions, as those helpers make no sense outside the
context of actions (and thus are unnecessary in the frontend).
Tests have been adapted as well.
Part-of: odoo/odoo#85639
DateTimeString should have an attribute format="102" (date is of the form: AAAAMMJJ)
as specified in the factur-x documentation.
opw-2767359
closesodoo/odoo#85604
X-original-commit: c367ae0df23ce6a826cdb487b92d25dff3e78963
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
*crm, project
With owl2, the `el` of components is no longer available. It still
works in Odoo on LegacyComponent, which has been introduced to ease
the switch from owl1 to owl2, and we're now incrementally removing
it.
With this commit, the action scrolling helpers no longer rely on
component.el, meaning that views using them (through the hook
`useSetupAction`) no longer need to extend LegacyComponent.
More specifically, we move the action scrolling helpers from core/
to webclient/actions, as those helpers make no sense outside the
context of actions (and thus are unnecessary in the frontend).
Tests have been adapted as well.
closesodoo/odoo#85631
Related: odoo/enterprise#24902
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, when we need to get all SOL linked to the project.
That is the SOL linked to the project and also the SOL linked to all
tasks of this project.
Technically, a fetch is made to get the SOL of the project, a fetch to
get all tasks of the project and then a fetch to get the SOL linked to
all tasks fetched, finally the union is made to avoid having duplicate
sale order items in the recordset
(`self.sale_line_id | self.tasks.sale_line_id`).
This way could be a performance issue if the project contained many
active tasks and so the project update could take more and more time to
compute the sold items shown in the right side panel of project update
view.
This commit does a query builder to fetch the SOLs linked to the project
and its active tasks to avoid doing the prefetchs.
part of task-2710808
closesodoo/odoo#85660
X-original-commit: 0734f4e
Related: odoo/enterprise#24918
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Before this commit, the translation is not done in lazy, so for each
stat button shown in the right side panel of the project update, a query
is done to find the correct translation based on the language of the
user. It means, the translation is costly and need to be done in lazy to
reduce the time for the translation of those stat buttons.
This commit uses the `_lt` to translate in lazy mode those stat
buttons. By doing that, the execution time is reduced from 750 ms to 250 ms.
X-original-commit: 95fe018
Part-of: odoo/odoo#85660
Co-authored-by: Yannick Tivisse <yti@odoo.com>
Co-authored-by: Laurent Stukkens (LTU) <ltu@odoo.com>
To generate an e-faktur
1. Settings > Users & Companies/Compagnies:
- Create a new company ‘ID Indonesia’:
- Set the state (e.g Yogyakarta (ID))
- Set the country ‘Indonesia’
Accounting:
2. > Customers > e-Faktur
- Set a range of numbers (which are supposed to be assigned by the
Indonesian government);
3. > Configuration > Settings
- Fiscal Localization: select the Indonesian package
4. > Customers > Customers
- Create a new res.partner:
- Set the country ‘Indonesia’
- Check ‘ID PKP’ field
- Under ‘Accounting tab’: set both accounting entries (Receivable +
Payable)
5. > Customers > Invoices
- Create a random invoice with the res.partner set in point 5. as the
Customer
- Confirm the invoice
- Action > Download e-Faktur
---
When validating the e-faktur users will see the error
Import Faktur Error ETAX-30005 : Error Objek Mapping
This occur because E-Faktur standard update from 3.0 to 3.1
A column 'KODE_DOKUMEN_PENDUKUNG' is now mandatory
opw-2753810
closesodoo/odoo#85696
X-original-commit: 3f0db73ef7c51c7365afbc7604ea66fa6765e6e7
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Currently, when someone adds a quiz on the slide content from front-end
and clicks on the 'Set Done' button, `werkzeug.exceptions.Forbidden`
error is raised which shows the full stack trace to the end user.
This commit improves the behavior by raising UserError instead and
thus displaying nice error instead of the full stack trace.
taskID-2380233
closesodoo/odoo#85694
X-original-commit: 5dfd5dd50fa8cd3f023ba7fa0c2fc4b52f9c5650
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Previously when going to a contract from the contract history, studio
was disabled, because it could not find a action xml id attached.
TaskId-
closesodoo/odoo#85690
Signed-off-by: Kevin Baptiste <kba@odoo.com>
When using the odoo app,
`request.httprequest.user_agent.browser` is `False`,
instead of a string expected.
Therefore, `capitalize` cannot be called
```
2022-03-02 09:44:01,267 1321846 ERROR dle-test1 odoo.addons.saas_trial.models.res_users: 2fa by email failed
Traceback (most recent call last):
File "/home/odoo/src/custom/trial/saas_trial/models/res_users.py", line 267, in _send_totp_mail_code
return super()._send_totp_mail_code()
File "/home/odoo/src/odoo/saas-15.1/addons/auth_totp_mail_enforce/models/res_users.py", line 95, in _send_totp_mail_code
'browser': request.httprequest.user_agent.browser.capitalize(),
AttributeError: 'NoneType' object has no attribute 'capitalize'
```
closesodoo/odoo#85684
X-original-commit: 5a87db453fcfd750934d1a1d62c00d93ad01c0e1
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
To reproduce the issue:
1. Storable product with MTO and manufacture route
2. On your warehouse set 3 steps manufacture
3. Create and Confirm a SO for this product
Error: The smart button linking the Manufacturing order does not appear
on the MO.
Problem was introduced by [1] and fixed by [2,3]. Moreover, [1] wasn't
deployed on versions >14.0 so there was no need for [2] on these
versions ([3] has been merged on all versions). However, [1] have
recently been deployed on next versions ([4]) so we need to FW [2] too
without disturbing the improvements from [3].
[1] 7ab0ac3e56949e5015bb2dcfd2af34b56dee92c8
[2] 96b56ea350c283d824468c591d42e4aeeada0d69
[3] 475e6b3cb027b3127b8e46fd8c9f90abc35162d7
[4] 7d7976a61d0af41ebb4df2e24ba222f6570f689c
OPW-2778883
closesodoo/odoo#85676
X-original-commit: 8ce61133af600ffec4c43033e64c2460366856ce
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Co-authored-by: Arnold Moyaux <arm@odoo.com>
Co-authored-by: Grazioso Andrea (agr) <agr@odoo.com>
Co-authored-by: Adrien Widart <awt@odoo.com>
ISSUE 01
When adding a product to a sale delivery, another picking is generated
to return the additional product
To reproduce the issue:
1. Create two consumable products P01 and P02
2. Create and confirm a SO with 1 x P01
3. Add 1 x P02 to the delivery and validate it
4. Go back to the SO
Error: Another picking has been generated, it's a return for P02. This
picking should not exist.
When validating the picking, because of the new line, a sale order line
is created with a quantity equal to 0. During the SOL creation,
`_action_launch_stock_rule` is called and checks if a procurement must
be created and processed. To do so, it checks if the SOL quantity (0 in
our case) is the same than the procurement quantity (1 in our case):
https://github.com/odoo/odoo/blob/6a0cbff92141961655a5f3e33abc23a2c5b1045d/addons/sale_stock/models/sale_order.py#L543-L549
Since the values are not the same, a procurement is created and
processed.
The feature that updates the SO when adding some products to the picking
has been introduced by 1f0835a9d01b46b5cc617756f854c25541b644a7 and is
correctly working in 14.0 because the condition (in
`_action_launch_stock_rule`) is not the same:
https://github.com/odoo/odoo/blob/ec5475ee881c5ca2bcc992592bfa4edf12f492df/addons/sale_stock/models/sale_order.py#L572-L574
In 14.0, we check if the SOL quantity is greater than the procurement
quantity. The condition has changed in 15.0 due to a new feature
(bda3225c6cc27bb2c2933eda3cc68c6f9708daf3).
ISSUE 02
When delivering more than sold, a useless SM is generated.
To reproduce the issue:
1. Create a consumable product P
2. Create and Confirm a SO with 3 x P
3. Deliver 5 x P
Error: A new line appears (Demand: 2, Done: 0)
Because the delivered quantity is more than expected, an extra move is
created. Then, the extra_move is merged into the initial one a condition
is respected:
https://github.com/odoo/odoo/blob/6f2ba1e1b40a458e23c8ed712927c44d75d86614/addons/stock/models/stock_move.py#L1603-L1610
Here is the issue: the field `date_dealine` is not copied anymore (see
[1]). Therefore, the condition will never be respected
[1] fb781dcf57
OPW-2716309
closesodoo/odoo#85649
X-original-commit: fabc32c4733bb404e74dc111d80aa1fe1edd4bfb
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Changes made in the commit 27bd6a681037d2794dac2453d7064be3a8d5bb36
apply a white background in every tables and create visual issues
(e.g. the `o_inspector_table` on the right in `documents`).
This commit removes this global rule and applies a `bg-white` only to
the pivot view.
task-2731553
closesodoo/odoo#85642
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Reorder smart buttons on the hr_employee to have them in the following order:
1. Documents
2. Holiday status
3. Time Off
4. Planning
5. Timesheets
6. Equipments
7. Cars
8. Contracts
9. Appraisal
10. Work Entries
11. Payroll
12. Attendance
13. Extra Hours
- Log in the chatter the name of the plan that has been started via the button "Launch Plan"
- When on mobile, open the Time Off Calendar in month view
- When sending a sms without any message, only display Message once in the invalid fields
- Avoid the sms-help info disappearing when clicking on it and there are characters in the body of the message
- Update the tooltip of phone number in the send sms wizard
- Avoid the employee name to be displayed on two lines on mobile if the name is too long. Reduce the font size instead
task-2735679
closesodoo/odoo#83745
Related: odoo/enterprise#23886
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Part of the overall v16 SCSS optimization/restyle (task-2704984).
Additionally, this commit will fix the border-radius of modals that
should be rounded in community.
task-2734531
closesodoo/odoo#83128
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
The public read_group method is used by back-end code as well as RPC calls to receive grouped data.
Most of the time, if the data isn't shown to the user, it doesn't need to be sorted on the names of
the many2one, and can just be sorted on their ID instead, avoiding extra joins in the resulting queries
This is a first commit that will reduce the features of _read_group to the strict minimum necessary
to obtain correct grouped data that is never shown to a user
Task-id: 2479334
Part-of: odoo/odoo#84908
Adds a test that verifies that the grouping with a date aggregate
specifier (the only group specifier supported until now) is working correctly
Part-of: odoo/odoo#84908
reshape a bit the read_group tests by ensuring that:
- creation of user is made in batch
- assertions are always assert(actual, expected)
Part-of: odoo/odoo#84908
If a landed cost is validated for an invoice where items either have 1)
a zero value, or 2) have been partially reconciled multiple times until
it is fully reconciled, validation will fail with a cannot reconcile
error because they are already reconciled.
The fix is to use the `reconcilled` attribute rather than checking for
existence of `full_reconcile_id`.
X-original-commit: 608ed487b61c81e38a5d0b856732a8b94c6df64a
Part-of: odoo/odoo#85621
The FieldWrapper and the owl compatibility layer aren't bullet
proof. They allowed us to write new fields in Owl and use them
below legacy views, but in some tricky situations they can produce
undesirable race conditions. In particular, the FieldBooleanOwl
sometimes produces a crash in tours, making runbot builds fail
randomly.
This commit makes a special case for "boolean" when determining
which field widget/component to use: we always take the legacy
FieldBoolean, s.t. the FieldBooleanOwl is no longer used in
views. This is obviously not the perfect solution, but those
issues are really hard to reproduce in practice (it's rather
a concern for tour tests). Moreover, that FieldWrapper/compatibiliy
layer architecture is about to be removed anyway, as we are
rewritting everything with a top-down approach, including views
and fields.
Runbot build errors: 2158 3232
closesodoo/odoo#85573
X-original-commit: f74f81543c1d899dbb0dc201d26a460fb8ae61ac
Related: odoo/enterprise#24869
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Géry Debongnie