Steps to reproduce:
- Install "Sales" module (for test purpose)
- Change company name to `בונז " ור מונד` (notice the double quotes)
- Go to "Settings > Users & Companies > Users"
- Select any user and then click on "send an invitation email" button
- Go to inbox and check the email
Issue:
No email received (at least not in main inbox).
Cause:
The email is not received in main inbox (Gmail or Outlook might flag
them since email from is not well parsed) because the `email from`
value is not escaped properly (by escaping the double quotes).
Solution:
Instead of using the company name (that is not escaped) and email to
build the `email from` value, use the company email_formatted value
instead (and fallback on user mail if not available).
opw-3097910
closesodoo/odoo#114534
X-original-commit: 0c4cb5e3cc2758cb27e94ecbbcfaa734ba5a50eb
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Steps to reproduce:
- Go to Contact-Configuration-Countries
- Remove the code of a country
- Create a new contact
- Select the country from which you deleted the code
- Put any vat number starting with country code you deleted
Issue:
Traceback
Cause:
in `_run_vat_test` we want to `country.code.lower()` -> country code does not exist
Solution:
Prevent the user to delete a country code by making the field required.
sentry-3923412146
closesodoo/odoo#113207
Signed-off-by: William André (wan) <wan@odoo.com>
The test TestWithholdingAndPensionFundTaxes::test_pension_fund_taxes_export
was expecting the xml to contain a tag `<RiferimentoAmministrazione>` while
this tag is optional if there is no description set, which is the case here.
We thus removed this tag from the expected xml.
closesodoo/odoo#113236
Related: odoo/upgrade#4359
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Taxes have a `description` field that has been hijacked to
represent tax label on invoices. We want the description field
to be used for its original purpose, thus created a dedicated field
`invoice_label` in which we transferred `description` content.
We also make description translatable.
This is part of the Tax Taxonomy 2 rework.
Task: 3052677
Part-of: odoo/odoo#113236
This commit allows the user to choose which quants to reserve from stock
and the quantity to reserve from each quant, making reservation much more
flexible from the picking form.
In addition, the `reserved_uom_qty` of stock.move.line
is now editable in views to allow for users to change the qty reserved
by existing move lines. When editing the reserved qty, if quantity is not available,
it will reserve only what is available..
closesodoo/odoo#106006
Taskid: 3090913
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
This commit adds a check to avoid forcing a write on the sml
even if the putway location is the same on the sml, which
avoids unnecessary additional costly _gather() calls during the quant updates in the write
Taskid: 3090913
Part-of: odoo/odoo#106006
This commit fixes a couple of issues linked to relational fields:
- When previewing a file with relational fields/ids, they were not
correctly mapped to their respective fields in the selects, the fields
were also not correctly mapped in the arguments given for the import.
- The select label was also only showing the name of the last sub-field
while it should show the full path ("External ID" vs "Company / External
ID").
- Some errors were not correctly displayed: wrong field name, not in a
column when it should be.
Task ID: 3210337
opw-3203704 + opw-3192403
closesodoo/odoo#114490
X-original-commit: 871690afdc2ce4da2770a144cc4fc5ed038e6f73
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit: if a different `web.base.url` is set with
`web.base.url.freeze`, during the first synchronization of Google
calendar it will show a mismatch URL error. The problem is that we
send the `redirect_uri` based on the `web.base.url` in the
`_get_authorize_uri` function.
The solution is to use the request root URL instead.
opw-3175539
closesodoo/odoo#114482
X-original-commit: 8f94f2ec864bdb54e3deb9b853a2720c5c92f592
Signed-off-by: Arnaud Joset <arj@odoo.com>
Signed-off-by: Pedram Bi Ria (pebr) <pebr@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In this commit, we will remove:
- groupedBy because the api is weird, we don't want to handle type abbreviations.
- getAggregableRecords because it is only used in one place.
In this commit, we will also convert canQuickCreate to utils and we will
move it to kanban because it is the only view that uses it.
Part of Task: 3179751
closesodoo/odoo#114459
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
ValueError "Invalid field slide.slide.partner.survey_scoring_success in leaf
('survey_scoring_success', '=', True)" .
it occurs because the domain field in gamification.goal.definition is not updated
when we uninstall the model.
we add the uninstall_hook in website_slides_survey where we replace the domain.
sentry-3779856181
closesodoo/odoo#114353
X-original-commit: abc662e3b190c58794eaf62ed7850439f9ebfd50
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
If an user tries sending a invoice using an invoice address and a
delivery address through snailmail, it would result in a traceback.
This is due to the invoice address record not having a name.
closesodoo/odoo#114227
X-original-commit: eceb23b1835b3d039759eb7431950f221ac1fb6e
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The main goal of this commit is to simplify, uniformize and remove
unused props. The props removed are : options, attrs and className.
The readonly prop is uniformized with the one in the fields api. It will
now allow the use of readonly as modifiers on the widgets, as it's
already the case on fields.
This commit also uniformize the parseWidgetNode with the parseFieldNode,
the widget doesn't receive on props the rawNode anymore but a widgetInfo
as is the case for the fields.
Part-of task-id 3179751
closesodoo/odoo#114188
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit, is part of a series of commits that aim to simplifie the
concrete fields API.
In this commit we will remove value prop from concrete fields. Now each
field will directly use this.props.record.data[this.props.name] to
access their value, As a consequence of this, the name props need to be
mandatory.
task-id 3179751
closesodoo/odoo#113495
Related: odoo/enterprise#37464
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
__Description of the issue this PR addresses:__
The first character of a Tax ID from Albania is a letter representing the decade in which it has been issued. The letter M represents the current decade. (This pdf explains in details how it is formated: https://www.oecd.org/tax/automatic-exchange/crs-implementation-and-assistance/tax-identification-numbers/Albania-TIN.pdf).
Currently the way Albanian Tax IDs are validated is through the python library [`python-stdnum`](https://pypi.org/project/python-stdnum/).
However, the regex that is used to validate them has not been updated since 2017. (I made a PR in its repo https://github.com/arthurdejong/python-stdnum/pull/402 to fix that).
The code from this commit is inspired by the one from that library, but the regex includes the letter M.
__Current behavior before PR:__
(`base_vat` must be installed)
By going to Settings > Users & Companies > [A company]:
- Set the country to Albania
- Set VAT/Tax ID to “M12345678T”.
=> Error message
closesodoo/odoo#114488
X-original-commit: f0b6e4ccd8f7402a5d70b9d60d91e463073e5bde
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Step to reproduce:
Edit documents layout in general setting to add logo and background
select multiple documents (more than 5) e.g. Inventory> delivery slips
print all documents.
Bug:
background and logo missing on the last documents because the pages
were printed before the browser had time to render them
Fix:
wkhtml2pdf has a default delay of 200 ms (--javascript-delay)
increasing the value will allow large document to load
opw-2951594
closesodoo/odoo#114512
X-original-commit: ac2df93eb3f08696189d010bdfa4187e02a94576
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Steps to reproduce:
- Install `Contacts` module
- Create 3 contacts with the same name
- Archive one of the contacts
- Go to list view
- Edit search filter to display archived and non archived contacts
- Select the 3 created contacts
- Open `Action` menu and click on `Merge`
Issues:
- Archived partner is set by default as destination partner.
- Archived partner is not displayed in the list of partners to merge.
Cause:
- The default destination partner set is the last record of the record
set returned by `_get_ordered_partner` (where `Archived` partners
are the last ones in the record set).
- The field `partner_ids` does not allow archived records.
Solution:
- Sort the partners to have the archived ones on top (since we took
the last one).
- Set `active_test` to False in the context of the partner_ids field.
opw-3205577
closesodoo/odoo#114508
X-original-commit: 8d0cec6844b248d3787bd7d6b8868d930d25e38c
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps to reproduce:
- Create a new journal Bank
- In Sequence, find the 'New Bank Check" and edit it so the sequence can be 10 number digits long
- Create a Vendor Payments with the the New Banck and Check as a method
- Click on Print a check
- Set the check number to 2147483648 and validate
- Create a new payment with the check method
- Click on Print a check
Issue:
Error is raised
Cause:
As for https://github.com/odoo/odoo/pull/112832 there is a second check in order to increment the check number
opw-3140973
closesodoo/odoo#114496
X-original-commit: 531147bb5fad6372c3742bc061f78687f7f11e5b
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Before this commit:
- When a color index is greater than 55, the CSS class applied does not
have a matching style.
Only 56 CSS classes have a matching style: from 0 to 55.
To reproduce:
- Go to Calendar, edit an event and add an attendee having an id greater
than 55. When displayed, the event does not have a proper color.
It has the default FullCalendar color instead.
After this commit:
- The colors will cycle through 55 colors, from color 1 to color 55.
(Color 0 being the value for "no color", which is some kind of gray)
closesodoo/odoo#114491
X-original-commit: eda4e12202a1bf6459009b41313f9af4b4dc326b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Steps to reproduce the bug:
- Go to the website and edit a page.
- Make sure there is enough content to be able to scroll the page.
- Go to the "Theme" tab and disable the "Show Header" option.
- Click on the footer and enable the "Scroll Top Button".
- Click on "Save".
=> Clicking on the "Scroll To Top" button does nothing.
The "Scroll To Top" button is an anchor with its `href` set to `#top`.
By disabling the "Show Header" option, the header is removed from the
DOM and there is no existing element with `id=top` anymore. To fix
this, the `scrollTo` function has been patched in order to be able to
receive selectors as arguments. In the '#top' and '#bottom' case, those
positions are known and always the same (either at the top of the
document or the bottom of it) so there is no need to have the header or
the footer present in the DOM in order to be able to scroll up to those
positions.
Now that the `scrollTo` function is able to scroll to the top or the
bottom of the page even without header or footer, those two positions
can always be suggested as internal link anchors during link edition.
opw-3133464
closesodoo/odoo#114472
X-original-commit: 6ae5d73332d5413495cc25e28cba86f8be18b570
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
RATIONALE
Currently email layout choice is done in code and is not controllable through
any user interface. In this commit we prepare improvements in template
management by allowing to choose the email layout directly from a given
mail template. As number of layouts is going to grow better be able to
choose the right one.
SPECIFICATIONS
Add a field on template to propagate email layout choice directly on
template and propagate it to the composer, then post/notify process.
We can now choose directly on a template which notification layout should be
used in conjunction with this template. Composer model already holds a field
'email_layout_xmlid', used in various places in code to give a specific
layout to use when sending notifications emails e.g. SO email layout. This
can now be specified directly from the template itself. It allows to
customize the look and feel of notifications without having to do it
explicitly in a given code flow.
Computation is coming either from template, either reset. When having a
template with a value set, set it on composer. When removing the template
reset it.
Currently no standard template uses it as this task targets mainly a code
cleaning that began with the composer code cleaning. It targets the near
freeze to have the base code updated once, then functional templates will
make use of it (hopefully).
Note that currently notification layout is still not supported at composer
level for mailings. It is simply ignored when generating outgoing mail
records. This will be improved soon.
Global followup of odoo/odoo#107356 / Task-2088884 (Mail: Use editable
computed stored fields in composer).
Prepares code for Task-3046371 (Mail: Better Language Support in Composer)
see odoo/odoo#106177 .
Task-3186426 (Mail: Support notification layout in template / email composer)
closesodoo/odoo#114462
Related: odoo/upgrade#4404
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
We have a lot of hits without any forum_origin which will raise an
error 500 because this parameter is required. But because this params is
not into the controller but received as a get parameter, it will match
the controller and return an error 500 instead of a beautiful 404.
Some controller like 'open_partner' redirect to this url without the
parameter forum_origin too, leading in a 500 in all cases.
Better for uX to have this param, but not critical to display the page.
The only negative impact will be to have a 'Back' button that return to
this new default value '/forum'.
closesodoo/odoo#114461
X-original-commit: 991d1c430f2c9bb0d2b2d7ac8f75338eafd2aced
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Before this commit, in the forum post form view, the answers one2many
field is not aligned properly.
* open a forum post from website
* click forum post in the top bar (near edit button)
* forum post form will be opened
After this commit, the field will be displayed properly.
closesodoo/odoo#114433
X-original-commit: 5d8db1e1715cef36468681f59da55c780ae67a55
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit, the model's record had two similar functions: isNew
and isVirtual, this commit will remove the isVirtual function to only use
the isNew one.
closesodoo/odoo#114431
Part-of: task-id 3179751
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When a portal client changed the quantity of an optional product on a
quotation while being in the portal the unit price of the product
was recomputed and we lost the unit price defined by the user on
the backend.
After this commit this issue will no longer occur.
opw - 3178262
closesodoo/odoo#114425
X-original-commit: bcd1a5820fe8250f50b4dc360ed1d0d48ae76b1c
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Missing sudo for portal user on Invoice list.
When portal user go to his portal, to display the list of the invoices
we compute the url via get_portal_url that will call this method
`is_purchase_document` and got a traceback due to missing permission.
Now we call it with sudo to bypass the Access Right error without leaking
any extra information since it is casted as boolean later.
`get_portal_url` -> `record.access_url `-> `_compute_access_url`
account:account.move `def _compute_access_url` -> `filter(is_invoice)`
account:account.move `def is_invoice` -> `is_sale_document or is_purchase_document`
hr_expense:account.move `def is_purchase_document` -> `return bool(self.expense_sheet_id) or super()`
closesodoo/odoo#114424
X-original-commit: 01a91419f906bd8d9248e6376a0246b667218ca2
Signed-off-by: Jérémy Kersten <jke@odoo.com>
1. Install [Studio], [Accounting] on Apps
2. Enter [Accounting]
- Click the Studio icon second to left on the top right corner
- [Edit Menu]
- [NEW MENU]
- Fill in e.g.`Test`, select [Existing Model], Model: Payment Methods
- Click the icon on the right, check it is `account.payment.method`
- [SAVE & CLOSE]
- [CONFIRM]
- [CLOSE]
3. Click on `Test` menu created next to [Configuration]
- [NEW]
- Type in all info, click to Save
- Error is thrown
Desired: block users from creating a `payment.method` by all means
Impacted versions: 14-master
opw-3148453
closesodoo/odoo#114408
X-original-commit: 59ea0e9802fc9cf98bab8fbdc065d9b5fc023ac7
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Lee, Hansun (hale) <hale@odoo.com>
When following recurring meeting are imported through google calendar
synchronisation, it happens that a meeting get unexpectedly
duplicated in Odoo, what will in turn duplicate the event on google
and send invitations to all the existing attendees.
As calendar.recurrence.calendar_event_ids is a One2many field,
the update using self was setting the base_event_id's recurrence_id
field to the last record of self recordset. Due to this, the event
will not be considered to filter out the existing_ranges in
calendar.recurrence._reconcile_events function.
Therefore, a calendar.event will in turn be created using the same
start and end datetime as the base_event_id of the calendar.recurrence.
OPW-3143680
closesodoo/odoo#114392
X-original-commit: d1587758ac642b0181e660ea48222385d01098e3
Signed-off-by: Arnaud Joset <arj@odoo.com>
Until now, if you search for /shop/Desk for a new link, you will not
have any result.
Now we search that it match *shop*desk* so /shop/custom-desk-12 will
match.
closesodoo/odoo#114357
X-original-commit: 84a407e744b7bacab43a0213ab52002a49c5d623
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Jérémy Kersten <jke@odoo.com>
issue: When creating a sale order, with a service that involves the creation of a project, with analytic accounting activated, the default analytic account is not the default one set in the settings of the Project app.
Steps to reproduce the issue :
- activate analytic accounting in the Accounting app.
- in the settings of the Project app, set the default analytic plan to any value but the first one.
- create a product in the Sale app, with a product type 'Service', that involves the creation of a 'Project'.
- create a sale order with the product
- go in the analytic accounting menu in Accounting app
-> the analytic plan is not the one set by default in the settings of the Project app.
closesodoo/odoo#114302
Task: 3169483
X-original-commit: e801b3fa1bbc31713375cc669c6d47b32b175f53
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: hupo-odoo <hupo@odoo.com>
When we added tables on a floor plan from the floor screen,
the tables stacked one upon another which was confusing and annoying.
Now the table will be added on a free place on the floor plan.
We also rename the tables: they are no more called "T1", "T2"
but "1", "2",...
closesodoo/odoo#114282
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Odoo does not have much in terms of payment protection; you can create
payments to any account you want without many checks.
This changes it by requiring users with the right groups to trust an
account before allowing it to be used for payment methods requiring.
Also adds some warnings on the bank account view, and checks at the time
of creating a payment.
Task id # 3210415
closesodoo/odoo#114278
Related: odoo/enterprise#37789
Related: odoo/documentation#3737
Related: odoo/upgrade#4397
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
This field has been introduced in
https://github.com/odoo/odoo/commit/c68600cc5397700df4f40095c27723a2b1f90a22
The reason why is not really clear, given the commit message.
But, it looks completely unused nowadays.
We can therefore safely remove it.
In addition, this will save a lot of transferred data to the web client,
as currently all the fields of an action are read when the web client
loads an action,
including this one, which contains a long xml content.
For instance, with just base and the contacts modules installed,
to load the action of the Contacts menu,
it goes from 5.51kB to 1.05kB.
closesodoo/odoo#114041
Related: odoo/upgrade#4390
Signed-off-by: Rémy Voet <ryv@odoo.com>
Apply propagation mechanism to Manufacture rules,
except the ones from the mto rule.
Also fix some _find_global_route having missed route's rename.
closesodoo/odoo#107952
Task: 2907698
Related: odoo/upgrade#4342
Related: odoo/enterprise#34963
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Purpose
=======
Allow to search properties fields.
For now, the properties fields are meant to be used with the search bar available in views, so everything was simplify as much as possible for this feature.
Technical
=========
Relational properties
---------------------
We can not search on relational properties using the rec name, or using one of their fields.
The following domains do not work
```
[('properties.partner_id', 'ilike', 'alice')]
[('properties.partner_ids', 'ilike', 'alice')]
[('properties.user_id.name', 'ilike', 'bob')]
[('properties.user_ids.name', 'ilike', 'bob')]
```
Instead, we should give the ids
```
[('properties.partner_id', '=', 55)]
[('properties.partner_ids', 'in', 55)]
```
IN operator
-----------
The "in" operator is used to either search specific tags / many2many
values, either doing a "OR like" condition on "non-array" value.
It can be used if the left or the right side is not an array
```
[('properties.my_char', 'in', ['a', 'b'])]
[('properties.my_tags', 'in', 'a')]
```
But it can't be used if both side of the condition are array, because
it will require to check type in SQL (which is technically possible,
but add extra complexity, so for now we keep the feature as simple as
possible).
So the following domain is not supported.
```
[('properties.my_tags', 'in', ['a', 'b'])]
```
Instead we should use the "OR" operator
```
['|', ('properties.my_tags', 'in', 'a'), ('properties.my_tags', 'in', 'b')]
```
Tags / many2many - "=" operator
-------------------------------
Tags and many2many have to be searched using the "in" operator.
So the following domain will return unexpected results and raise a warning.
```
[('attributes.mytags', '=', ['a', 'b'])]
```
The reason is that we don't want to dynamically check the type in SQL,
and so we need the "in" domain operator to know what to do in SQL.
Task-2980121
closesodoo/odoo#101901
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Add the properties fields in the search bar and allow to search
properties fields values.
Technical
=========
If the "active_id" is in the context, show only the properties
of the given definition record. Otherwise, show all properties
of all definition records.
Because fetching the properties definitions cost a SQL query and a RPC
call, the properties definition are fetched only if we unfold the
properties field (so it has no performance impact until we ask
explicitly to search a property).
Task-2980121
Part-of: odoo/odoo#101901
Co-authored-by: Polymorphe57 <dam@odoo.com>
Purpose
=======
Allow to search properties fields.
For now, the properties fields are meant to be used with the frontend
top bar filter on views in a later commit, and so everything as been
kept as simple as possible for that particular use case.
Technical
=========
Relational properties
---------------------
We can not search on relational properties using the rec name, or
using one of their fields.
The following domains do not work
```
[('properties.partner_id', 'ilike', 'alice')]
[('properties.partner_ids', 'ilike', 'alice')]
[('properties.user_id.name', 'ilike', 'bob')]
[('properties.user_ids.name', 'ilike', 'bob')]
```
Instead, we should give the ids
```
[('properties.partner_id', '=', 55)]
[('properties.partner_ids', 'in', 55)]
```
IN operator
-----------
The "in" operator is used to either search specific tags / many2many
values, either doing a "OR like" condition on "non-array" value.
It can be used if the left or the right side is not an array
```
[('properties.my_char', 'in', ['a', 'b'])]
[('properties.my_tags', 'in', 'a')]
```
But it can't be used if both side of the condition are array, because
it will require to check type in SQL (which is technically possible,
but add extra complexity, so for now we keep the feature as simple as
possible).
So the following domain is not supported.
```
[('properties.my_tags', 'in', ['a', 'b'])]
```
Instead we should use the "OR" operator
```
['|', ('properties.my_tags', 'in', 'a'), ('properties.my_tags', 'in', 'b')]
```
Tags / many2many - "=" operator
-------------------------------
Tags and many2many have to be searched using the "in" operator.
So the following domain will return unexpected results and raise a warning.
```
[('attributes.mytags', '=', ['a', 'b'])]
```
The reason is that we don't want to dynamically check the type in SQL,
and so we need the "in" domain operator to know what to do in SQL.
Task-2980121
Part-of: odoo/odoo#101901
Purpose
=======
Do not modify the cache in order to improve the performance when we
read in batch. Instead we create a new batched method "convert_to_read"
that check existence in batch, and generate a dict with the result.
Now, all the properties field checks (many2one existence, selection option
still exists, tag value stiff exist, etc) and done in "convert_to_read".
It means that doing `record.properties` won't do all those checks.
Having the batched field fetch at the convert_to_record required too
many changes for the scope of this task, so "record.properties" having
the cache values unchecked is an acceptable tradeoff currently, hence
we batch convert_to_read.
Task-2980121
Part-of: odoo/odoo#101901
Before this PR, all this localisation was written in Mongolian, but all the localisation have to be written in english and then translated back in the native language. This PR correct that.
closesodoo/odoo#113465
Task-id: 3166094
Related: odoo/enterprise#37442
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
It was impossible to install a CoA in the UI because the selection field
didn't have any possible values. The cause was that when we tried to
fetch the values for `account_templates`, the `contains_field` was
returning True even though `get_records` was not returning anything.
Reproduce:
* Create a new company
* Go to Accounting Settings
* Select a fiscal localization and save
opw-3212601
closesodoo/odoo#114164
Signed-off-by: Laurent Smet <las@odoo.com>
Nasreddin Boulif (bon)