Steps to reproduce:
- Increase decimal accuracy of product price (eg: to 4)
- Create a product with fifo automated valuation and price of 280.8475
- Confirm a sale order of that product and Confirm stock picking
- Create a return on the stock picking
Bug:
rounding error on the stock valuation
Fix:
do not round unit price on currency rounding
opw-2988071
closesodoo/odoo#110112
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
- Automatically compute the average number of hours per day on
resource.calendar;
- Don't allow to change the working hours of an employee when they have
a current running contract;
- Seperate smart buttons on resources to distinguish Material / Human.
task-3102517
closesodoo/odoo#109768
Related: odoo/enterprise#35718
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit avoids potential concurrent updates if you create 2 users
simultaneously.
The method is called by an override of the method create from res.users.
In production, we have concurrent update because it writes to the group
no matter if someone is to remove or not. And orm will do a query in all
cases to update the write_date, ...
Now we only execute a query if somebody need to be removed.
closesodoo/odoo#111031
X-original-commit: 5a0cf8bc8a9747e18eca5ddd3f135eb0cfcfd13d
Signed-off-by: Kevin Baptiste <kba@odoo.com>
The tax totals computation requires a currency to be provided. When a user removes the currency deliberately and tries to add a line, an uncaught error is thrown.
The currency_id is required, and the user will not be able to save the move anyway.
To reproduce:
New Invoice or Purchase
Clear the currency field
Add a line
Stack Trace
After this PR:
tax totals are computed based on the journal currency or company currency when not available
No task, discovered thanks to #110920closesodoo/odoo#111021
X-original-commit: f74f9bc04ed8f18746eb509f3c8dc598b1618230
Signed-off-by: William André (wan) <wan@odoo.com>
Currently the Spanish address format does not include the province/state.
This change adds the province between parentheses after the zip code and city.
task-3147965
closesodoo/odoo#111012
X-original-commit: 2c31ad84137b3a764116bea6a6d765a2c7d03eb7
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
Signed-off-by: Dylan Kiss (dyki) <dyki@odoo.com>
Since [this commit], a tooltip is displayed on the blocks that can be
dropped in a page so that the user understands that he must not just
click on it but drag and drop the block. Unfortunately, these tooltips
were not well positioned in the email marketing application because the
editor is in an iframe in this application. This commit allows to
position correctly these tooltips.
Steps to reproduce the bug fixed by this commit:
- Go to the email marketing application
- Create a new mail
- Select a template other than "plain text".
- Triple click on a block
=> The tootlip is displayed way too high.
[this commit]: https://github.com/odoo/odoo/commit/a50c09e3b432d7601cd0e02cbbfabe24a67ba70f
task-2777738
closesodoo/odoo#111011
X-original-commit: 42d32a4f40d685e10f2ae4bb678df2009cb4bd21
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since the refactoring of website.visitor with [1] (upsert), the
`access_token` is supposed to be holding the same value as the
`partner_id` when the visitor is linked to a partner:
- Anonymous visitor: no `partner_id`, `access_token` is a hash value
- Partner visitor: `partner_id` set, `access_token` should be sync with
`partner_id`.
`partner_id` is just a stored computed field holding the `access_token`
value if it is an integer value.
There should never be a case where there is a `partner_id` set and the
`access_token` is not equal to the `partner_id`.
For instance, having a visitor with `partner_id` = 4 and `access_token`
= `e4r3ejkj4` is supposed to be impossible.
It would lead to crash, because the visitor is only searched based on
his `access_token`, meaning that when searching for the visitor of
partner 4, none would be found and a new one would try to be created,
raising the `uniq_access_token_id` SQL constraint.
While the `partner_id`/`access_token` sync might seems weird, it is done
to allow the `upsert` use in SQL to improve perfs of this low level
behavior.
It's actually not as weak as it seems as there is only a single entry
point to update the `partner_id` and `access_token`: the authenticate
override of website.
Those fields are not supposed to be changed elsewhere.
Note that modifying the `access_token` would not be an issue as the
`partner_id` is just a stored compute based on the `access_token`.
But it's only true when modifying through the ORM as if you do that in
raw SQL, it won't go through the `api.depends` which is supposed to
recompute the stored computed `partner_id` field.
But something was forgotten during the initial dev: the partner merge
behavior: it does (on top of other thing) auto discover the m2o field
relations that points to a `res.partner` and modify those values in raw
SQL to the new value.
This is obviously wrong regarding the `website.visitor`'s `partner_id`
field, the `access_token` should also be updated, or when possible
visitors should be merged too.
Note that for DB upgrated from previous version to Odoo 16, this is
ensured through the following upgrade script [2]:
```sql
UPDATE website_visitor
SET access_token = partner_id::text
WHERE partner_id IS NOT NULL
```
[1]: https://github.com/odoo/odoo/commit/d348bed1ad9d3d16b295f013f015706be6c07820
[2]: https://github.com/odoo/upgrade/commit/0cedcbf70494dfeddeb5a97c13bf875cb6a86886
task-3148111
closesodoo/odoo#111002
X-original-commit: a87b4142dd4a2c05e3e1885b2c54f5e0d3c7ac47
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Before this commit, while creating a new record, the chatter
was disabled and no interaction on chatter was possible until
the record was fully created by saving it.
This was a problem because it's unclear that chatter requires
the record to be fully created. In earlier versions of Odoo,
we had to click on "Edit" and "Save" buttons of Form view, but
now that edit/read-only mode is no longer explictly managed by
the users, they'd expect to be able to interact with chatter,
even while in the process of creating a new record.
With this commit, when clicking on most actions in chatter, the
record is created. In case the record cannot be created, usual
validation errors are applied.
Task-3132931
closesodoo/odoo#110991
X-original-commit: af442bd8d42acad0cb6a49700fc9ec1934751bf1
Related: odoo/enterprise#36284
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Calls to `_error_checking()` would look for every work entries between 2
dates, even if we were only modifying one employee's.
Because of that the leave creation on big production database would take
a long time.
Now the method allows for filtering to the employees.
task-3142610
closesodoo/odoo#110987
X-original-commit: f54b7c34bc89140e2d31f0b602911ec9cda3ed0d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Purpose of this PR to do generic improvement for timesheet apps.
So in this PR done following improvements:
- add information about project section on time off type form view so user can better
understand time off and timesheets relation.
- display 'view timesheets' as button instead of link in sale order portal view.
- add time off link to project settings's time off section so user can easily navigate to
understand link b/w time off and project apps.
- prevent user to create new timesheet for non active employee by adding context
depending on employee's active state.
task-2983879
closesodoo/odoo#106047
Related: odoo/enterprise#34171
Related: odoo/upgrade#4056
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
This commit uses timesheet search view for timesheet report
search view so that way we don't have to repeat everything
we do with timesheet search view.
task-2983879
Part-of: odoo/odoo#106047
The current VAT check doesn't pass for valid Venezuelan VAT numbers (RIF). Venezuela has a specific method to validate their RIF, very different from the standard VIES check.
This commit adds an implementation of the VAT number validation in Venezuela. The validation is based on
(1) pattern matching
(2) checksum validation
Task id=3094593
closesodoo/odoo#110976
X-original-commit: 4fca8ed270c3406246e259b3aec7eda0b6d2d9ab
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Popeler Antoine (anpp) <anpp@odoo.com>
Open the kanban view by default when clicking on the journal name.
closesodoo/odoo#110964
Task: 3141127
X-original-commit: 05553202e0a4a59600214fcbf965cfb3c29afbc9
Related: odoo/enterprise#36271
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
*: l10n_fr_pos_cert, l10n_gcc_pos, pos_hr, pos_loyalty, pos_mercury,
pos_restaurant, pos_restaurant_adyen
In odoo/odoo#109928 the custom inheritance system of the pos was removed
and a bunch of modules were adapted. In a lot of those places, the
_super calls didn't forward the arguments to the super method, resulting
in broken methods. This commits fixes that.
closesodoo/odoo#110962
Related: odoo/enterprise#36269
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Before this commit, when the user drags and drops a task from a stage
to another one in the kanban view of tasks of a project, the kanban
records in the destination stage will be re-sequenced and this
re-sequence will re-render the kanban. For this reason, the
`onWillUpdate` hook in the control panel will be trigger many times
and each trigger will fetch the last project update.
This commit will remove the `onWillUpdate` hook to avoid re-fetching
the last project update when a change is done in the kanban view and
so, the last update of the project will be just fetch when the
component is mounted since the last update is not impacting when a
task changes stage.# Please enter the commit message for your changes.
closesodoo/odoo#110961
X-original-commit: 6117f41f52c45710d313c128bbce1d364dc40b93
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
There is only one legitimate usage of `_patch_method` (base_automation)
and none of `_revert_method`. The other uses are in tests and they are
all wrong: if the test crashes between the `_patch_method` and the
`_revert_method`, the method will not be reverted.
For the only proper usage of `_patch_method`, move the code to this
place. Correct tests using `_patch_method`/`_revert_method` by calling
the `patch` method of `BaseCase`.
Also, remove the `api.returns` from the `create` method of `BaseModel`
as it is useless and confusing. In fact, we never use it because we
have a special treatment at the RPC level for the `create` method
(see `_call_kw_model_create`).
closesodoo/odoo#110370
Signed-off-by: Raphael Collet <rco@odoo.com>
'survey.user_input' model has an inherit in hr_recruitment_survey module to
link survey answers to applicants. The field is named 'applicant_id' which
leads to issues with 'default_applicant_id' is present in context. This
happens quite often when going from a kanban view notably, as it adds this
filter in context when displaying applicants. Trying to send a recruitment
survey to this applicant fails as it tries to set an ID in a o2m.
In this commit we simply remove the default value in context to avoid issues.
As anyway this model is technical it should not depend on default values.
In master we will rename the field to avoid issues.
Followup of odoo/odoo#63946
Task-3093257 (Mail: The Composer Update)
closesodoo/odoo#110958
X-original-commit: e215ae152d0d2cad315d87ef03c58599f6d20e13
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
Create a leave allocation for a group of employees
via the "By Employee Tag" mode.
Issue:
Employees have more allocations than expected.
Cause:
The allocations are confirmed automatically when
the "base" allocation record is created
(if there is not validation required).
And the "CONFIRM" button is also clicked
which does the same operation a second time.
Solution:
Do not start the validation process if the allocation
is already validated.
opw-3096138
closesodoo/odoo#110942
X-original-commit: 7d4e0c0bb3762bb5b05871b07bdb15f0f242ab0a
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Signed-off-by: Lefebvre Thomas (thle) <thle@odoo.com>
Right now when you create an order (order A) in a POS with tables the
`date_order` is being set correctly (in UTC, so is shown in the back-end
with the user's timezone), but after you return to the Floor Screen or go to
another order (order B) and then go back to the order A and you add
another product and the order is saved (not paid) when you check that
order in the back-end now the `date_order` it says another value not the
one of the user's.
This is happening because when the JS received the back-end information
to open the order for the second time the date come in the User's
timezone and the server's timezone, and that info was saved but taking
it like UTC.
Now instead of storing inconsistent information in the DB (server side), we
are going to modify the information that is shown in the POS (client side),
so that both sides show the same date.
This will only apply in the POS where tables are being used since the
orders are only synchronized (back-end) when the option `is_table_management`
is set in the POS (`pos.config`).
closesodoo/odoo#110832
X-original-commit: 168d0e12120ced7b1093d39b10cd79c85c56aad0
Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>
This happended because when reloading the chatter, the chatter
changed position and its identity changes (i.e it's no longer
the same chatter). The old chatter was removed, therefore it's
invalid to access relation on removed records, e.g. with
`chatter.webRecord`.
The underlying problem was that chatter should stay the same,
even with reposition. The chatter was not properly passed
between aside to bottom position.
This commit fixes the issue by properly passing chatter in
form controller.
closesodoo/odoo#110912
X-original-commit: f04bb66c0714bf732202873e2de82bcbc767a43f
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Usecase to reproduce:
- Create a product with real time valuation and AVCO or FIFO
- Create an invoice for this product without stock.move
- Validate the invoice
Traceback
It happens because it tries to check if there is a difference between
the invoice line value and the value of associated stock.move. However
in this case there is no purchase line to do the link.
Since we can't associate a picking to an invoice line magicaly. We skip
this part and let the user do his own journal entries
closesodoo/odoo#110906
X-original-commit: 8ea41cba3911fb8bcc351a4c53d2aa6c5bf7bdde
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The Record component becomes more and more used, but its API and the flows
it can support are both a work in progress.
Its specs become a little clearer, we probably want two things:
- be able to display some values via Fields widget and interact with them, in
particular relational fields.
- fetch, display and interact with a proper record in the db.
- disconnect it from the use of model in Views (via the hook useModel), because Record's
feature are simpler.
This commit aims at clarifying at least 2 aspects:
- how to pass the values to the record, that is, without reading anything from the db
=> a `values` props contains server formatted data, it supports changing them via the props
- when to reload the data from the db, when not to.
=> when props did not change, don't reload anything.
We expect further improvements on this component, as the feature is still very basic at this point.
See 475f8aa for earlier improvement
closesodoo/odoo#110122
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- Install website and set in French
- in the robot wizard you see:
Exemple de règle :
Refuser : /web/login
Autoriser : *
closesodoo/odoo#110911
X-original-commit: 10e50eeeb4c3c83da2c671bd600561679fdacd44
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
On the bank reconciliation widget, we are using 2 dynamic filters "Receivable" and "Payable".
Otherwise, only one should be selected by default.
Enterprise PR: odoo/enterprise#35801closesodoo/odoo#110831
X-original-commit: 2504a623f90022dfa1c64436b7bd6e113f82e82d
Related: odoo/enterprise#36207
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Before this commit, the user had to go over each expenses to
register a payment.
He now has the possibility to do so from the expense report
tree view via the "register payment" button.
task-id: 3116195
[community](https://github.com/odoo/odoo/pull/109671)
closesodoo/odoo#109671
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
steps:
- Go to Rental app
- Open a rental Order
- Click on Action
- Send an SMS text message
- Fill phone number and message
- Sens SMS
Issue:
Traceback
Cause:
Sale order doesn't have a phone or mobile field so the sms.composer tries to write on it use "False"
Solution ensure the field name isn't false before writing
opw-3103232
closesodoo/odoo#110038
X-original-commit: 70a9995c9e02f36dc15d2723151ef0a205ebc12b
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
A recent change in owl exposes live (non-destroyed) apps on the window.
This change causes the memory used by the QUnit test suite to balloon
out of control. The reason is that when creating a mock environment, we
create a standaloneAdapter to serve as the legacy MockServer's parent,
but this standaloneAdapter creates a dummy owl application and this
application is never destroyed. This commit fixes the problem by
registering a cleanup to destroy the application at the end of the
running test.
closesodoo/odoo#110889
X-original-commit: 27ff522cd6b0c3be32be623e375052e63bb1a04f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
The setting tag was introduced in [1], it was restricted to the setting
view (the js_class : base_settings).
This commit move the setting tag to the form view, to remove the
restriction and allow the use of the setting tag in any form view.
[1]: c7c2959449
Part-of: odoo/odoo#110432
This commit introduces the documentation link widget, the aim is to
standardize the help documentation links that can be found in the views.
This widget will add an icon (o_doc_link), this icon is a link to the
documentation. Note that you can use relative or absolute path. The
relative path is relative to `https://www.odoo.com/documentation/server_version`,
so it's not necessary to hard-code the server version on the arch any more.
```xml
<widget name="documentation_link" documentation="/applications/technical/web/settings/this_is_a_test.html"/>
```
Task-id: 2980478
Part-of: odoo/odoo#110432
Extracted in its own commit to ease review of next one which is fixing
the sanitize_overide mechanism.
Note that 'Escalated' is meant to be used when talking about "Privilege
Escalation Attack". It's quite misleading when someone is reading this
"error". 'Elevated' is better (confusion brought by internal team).
Since the translation will be broken by this change anyway, the chance
is taken to make it cleaner and more helpful.
X-original-commit: 34235c48bd511d68f513e747dd3f50b9ea6f46d6
Part-of: odoo/odoo#110903
Purpose:
========
This commit removes the weird blank space at the edges of the merge contact
form (using custom css that will be removed in master), and displays the
info message and the associated action button shown when there are no more
contacts to merge inside two separate rows, instead of displaying them next
to each other (by adding `colspan="2"` on these elements).
Task-3112116
closesodoo/odoo#110887
X-original-commit: eb7e5de05a5b05054bffbcf3892cf2c432e3295a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Current behavior:
If you limit the number of product loaded in the pos to 0, and block
loading product in the background you will have a traceback when trying
to apply a down_payment.
Steps to reproduce:
- Settings > POS > Limit products to load > Set 0
- Disable the option "Load product in the background"
- Start a PoS session
- Go in the Quotation / Order screen
- Apply a down payment
- Results in traceback
opw-3113215
closesodoo/odoo#110883
X-original-commit: 77a5e134dd3c87b3ed0bd5708bf63ed76647306b
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
An `input` wasn't clicked as it should and other DOM elements then the
expected target could be found and make the tour fail.
Task-3141104
closesodoo/odoo#110882
X-original-commit: 19013c4ea5a5d4a2bc7485b4012ba0db125b99c4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Florian Charlier (flch) <flch@odoo.com>
Based on RFC3462, a Content-Type text/rfc822-headers
exists and provide a mechanism to label and return
only the RFC 822 headers of a failed message (bounce)
These are only the headers and not the full message.
The Content-Type-Encoding should be either 7-bit(US-ASCII)
or Quoted-Printable (QP) as in the section 2 of the RFC.
Spawn the error:
After getting reported by a customer, I had to reproduce
by spamming wrong outlook addresses and add logging
in a sh database on the message_process of mail_thread.py
and logged the `message` variable.
After few retry, I got one of the part that was defined
as followed:
Content-Description: Undelivered Message Headers
Content-Type: text/rfc822-headers
Content-Transfer-Encoding: quoted-printable
The `get_payload()`function used was only assuming
that there is a full email on that part and that
it could only be encoded as an email, which was not
the case in this situation (quoted-printable:
76 characters per line, character `=` used
as the end of line character).
opw-3064589
task-3131561
closesodoo/odoo#110901
X-original-commit: f86f4b671696178f8fa42b81d8753d2591578431
Signed-off-by: Julien Castiaux <juc@odoo.com>
Co-authored-by: Baptiste Vergote <bve@odoo.com>
The "All Websites" list of views is confusing for users with its
combination of default and specific views.
This commit makes the "All Websites" filter only available in debug
mode, and defaults the selected website on either the current website
(if one is selected) or the first website of the list.
The test is adapted because only the current website's pages are
displayed now.
task-3092786
closesodoo/odoo#110898
X-original-commit: 01cb743f1c0c22621bcfa92005a7d10dfa92e746
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Unfortunately, when I wrote the loc, I forgot to include
`account.group.template.csv` in `__manifest__.py`.
As such, the account groups were not loaded, and I didn't notice an
error in the chart template name.
Thanks to WAN for finding this.
closesodoo/odoo#110890
X-original-commit: 7610f1ef5f329a52ee16fe88909be30ddf395b8d
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
In [1], conditions have been made in order to allow/forbid each snippet
to toggle the grid mode. However, a case has been forgotten: when a
snippet that cannot toggle the grid mode is dropped inside a snippet
that can toggle it (so it is an inner snippet). Indeed, if we drag one
of the inner snippet columns, we can see that the grid mode is toggled,
where it should not be the case.
This issue comes from the check looking if the grid layout option is
in the right panel. Indeed, even though such a snippet does not have
it, if it is dropped inside a snippet that can toggle the grid mode,
then the option is well present in the right panel (= the outer snippet
one).
This commit fixes this issue by improving the check: now, dragging a
column can toggle the grid mode only if the container having the option
is the same as the one of the column. This commit also improves the
siblings/children filtering (to only have the relevant dropzones) in
order to take this case into account and to be more robust to
customizations.
Steps to reproduce:
- drop a Text-Image snippet
- drop a Form snippet inside one of the columns
- drag a form field
=> the grid mode is toggled.
[1]: https://github.com/odoo/odoo/commit/84d684d8bdf43d3db11defd8174dee44775085c2
opw-3100399
opw-3139938
closesodoo/odoo#110888
X-original-commit: 34b534f75dbf3e4c475ca8cc40c8fafde5dbea5d
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
https://github.com/odoo/odoo/pull/102662 Highlighted the fact that in some
cases, an rpc call can be done on a destroyed component.
There is such a case in Knowledge, which now causes a warning in some cases.
Impacted Versions
- 16.0 and higher
Steps to reproduce:
- create a new article in Knowledge
- type the space character: [ ] in the article body
- switch to another article
Current Behavior:
- warning
Expected Behavior:
- no warning
Contents of the fix:
Do not try to update the value of the html_field if the component is already
destroyed. This could happen when an urgent commitChanges was requested (i.e.
when leaving an article to open another).
Task-3101553
closesodoo/odoo#110862
X-original-commit: 1b683bd600bbf5c39c520afa041c4f6124c9dea8
Related: odoo/enterprise#36232
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The JSON object can contain characters such as `<` (i.e. in domain expressions
for the act_window object of an embedded view). This means that the JS sanitizer
DOMPurify will remove the attribute when parsing a node that contains it.
Instead of encoding/decoding that attribute each time the DOMPurify sanitizer is
called, we could encode at all time, and decode it only when we use the value it
contains, since JSON.parse has to be used at those times anyway.
This way, we don't pollute OdooEditor.js code, which is already quite complex.
Task-3101553
X-original-commit: 7686ae282c97bc255ebb66367b39447b7bc1749b
Part-of: odoo/odoo#110862
before this commit, the action name was not getting translated to user language.
after this commit, the action name will get translated to user language.
closesodoo/odoo#110856
X-original-commit: 6758cde0358359d76642b0cbea4c208eac57dd92
Signed-off-by: Tiffany Chang <tic@odoo.com>
The payment account should either be of type `asset_current` or `liability_current`, but now only `asset_current` type is allowed.
`liability_current` should also be in the payment account domain.
task-3145725
closesodoo/odoo#110846
X-original-commit: d29268c397c900774313d6069790073551458546
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Walid HANNICHE (waha)