Before this commit, after removing a snippet followed by a popup in the
DOM, the popup options were displayed while the popup was closed.
Indeed, selecting the next snippet after one's removal is a feature that
was introduced by [1] but did not consider that the next snippet could
be an invisible one (like a popup).
[1]: https://github.com/odoo/odoo/commit/2cdd95f140b6ec5f3b95ee19bde2f281de21f337
task-2735551
closesodoo/odoo#83512
X-original-commit: cc802d33885700543c753558dc40cc07d971f87f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, when we selected a variant of a product and then
clicked on a share button, the changed variants attributes in the shared
URL were not considered.
This commit also takes the opportunity to convert the whole file to new
Odoo modules and stopped using jQuery. The code actually had to be
refreshed following the merge of [1] so it was a good occasion to do it.
[1]: https://github.com/odoo/odoo/commit/8f7c6997e8ab381563a9fa8d06feef4e89fff4aa
task-2122733
closesodoo/odoo#83503
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
In the calendar UI, the avatars ratio has been edited differently with
the original
closesodoo/odoo#83494
X-original-commit: 81875cf0d0b2db5e2b2e0e70178d5ea04bdd509b
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Purpose
=======
This field is used for several things, like the simple holiday pay recovery.
Normally, we expect the HR officers to create a new employee, instead of
unarchiving the old one, but this could happen.
If someone leaves the company, and come back, take the new entry date as
first contract date instead of the original one.
closesodoo/odoo#83493
Taskid: 2745947
X-original-commit: a17c601fffca149a5c4d7be2924fb581ae408299
Related: odoo/enterprise#23790
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
- Remove "subtotal" amounts from headings.
- Pull GST only and G20 in under purchasing header.
- Remove tag from comparison heading, as it should have no links to audit.
- Add summary section, to make G9 and G20 transfer to 1A / 1B as per ATO
suggested formatting, and to make those figures easier to find on the
report.
closesodoo/odoo#83380
X-original-commit: 1c184391d545298b9b38d4935a6e457ba7674f43
Signed-off-by: William André (wan) <wan@odoo.com>
Before this PR, AttachmentBoxView required a Chatter to have an
AttachmentList. This model is wrong since the attachmentBoxView can direcly own
the AttachmentList.
task-2740183
closesodoo/odoo#83337
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
OWL-2 is in preparation and will be soon merged. One of the changes it
will bring is that it will be no longer possible to use the directive
t-ref on a tag component. Here we refactor the code in order to remove
two uses of such t-refs.
closesodoo/odoo#81984
Related: odoo/enterprise#23464
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
OWL-2 is in preparation and will be soon merged. One of the changes it
will bring is that it will be no longer possible to use the directive
t-on on a tag component. Here we refactor the code in order to remove
one use of it in the action service.
Part-of: odoo/odoo#81984
[1] has changed the summary structure of an order. To avoid any issues
during the deployment, we added some instructions to remove the old
summaries. Now, these instructions can be removed.
[1] 911a178c99fe56c5f644083a0bb5e992a11f34ed
closesodoo/odoo#83481
X-original-commit: 1638b3490d8fb44a6b57d6168e5e74e567f0fd50
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When creating a new working calendar, its timezone is set to the one of the user creating the record.
However, when first installing the resource app, the timezone of the default working calendar is always UTC regardless of the timezone of the users.
To fix this, this commit sets the timezone of the default working calendar to the timezone of the admin instead.
Task 2744201
closesodoo/odoo#83480
X-original-commit: 2ddddd0253db402542ab6359026888acd61c2464
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Simplify SCSS and use direction-relative margins to handle RTL layouts.
Part of the overall v16 SCSS optimization/restyle (task-2704984).
task-2731819
closesodoo/odoo#83036
Related: odoo/enterprise#23605
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit defines an arbitrary `min-width` aiming to achieve a
perfect(ish) circle when a badge contains only one character.
The badge extends as usual when more characters are rendered.
This commit addresses also an issue caused by margins defined globally,
while necessary to handle m2m field only.
Part of the overall v16 SCSS optimization/restyle (task-2704984).
task-2731819
Part-of: odoo/odoo#83036
This prevents memory issues on creating massive amount of records.
For example, on populating `account.move` table,
the process takes 10 time less memory, while execution time per batch is almost the same: ~1 minute.
closesodoo/odoo#82875
Signed-off-by: Raphael Collet <rco@odoo.com>
To apply shapes on images, we need to store them (in base64) inside the
shape SVG, but before that, we need to use 'applyModifications()' to get
the dataURL that contains the image with applied filters and size
options...(see ImageOptimize > _writeShape). But since we can't handle
GIFs on applyModifications(), we get a single frame of the animation as
a result...
The goal of this commit is to skip the updates from 'applyModification()'
(when the target is a .GIF) and only apply the shape.
This way, other "data-attributes" options should be disabled for GIFs
and only shapes option is allowed.
task-2679905
closesodoo/odoo#79330
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Like in debug mode on optional field on tree view, show technical name on export view.
closesodoo/odoo#73898
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Users with Swiss localization have a possibility to create QR_Bills from their invoices, however, PoS currently does not send information about partner_bank_id to the generated invoice, so users can not create
QR_Bill from the invoice that was created by PoS. After this commit, function _get_partner_bank_id will get partner_bank_id in case customer didn't pay for the order fully, and this information will be added to
the invoice, thus, giving user an ability to create a QR-Bill from said invoice.
In case user will try to create a QR-Bill from the invoice that has been fully paid, they will get an error saying that QR-Bill can not be generated on paid invoices. If the user tries to generate QR-Bill from
the invoice that has empty partner_bank_id, they will also get an error notifying them that they should check Recipient Bank field on the invoice.
OPW-2695969
closesodoo/odoo#83456
X-original-commit: 634f90a728cba9ff45c17e471f2b160e939bbd3d
Signed-off-by: Masereel Pierre <pim@odoo.com>
Current behavior:
When creating a gift card in a PoS the price was reset to 0 when modifying the customer
Steps to reproduce:
- Set PoS gift card mode in Generate a new barcode and set a price
- Modify the current customer
- The price of the gift card is reset to 0
opw-2666917
closesodoo/odoo#83452
X-original-commit: ffc2e11e92a5b528fa2cda855ecdf1d83a54f4bb
Signed-off-by: Masereel Pierre <pim@odoo.com>
Purpose
=======
Less secured apps are no longer supported by google, therefore, we need
to transition to the OAuth2 authentication system.
Specifications
==============
1. User will need to fill their Gmail API credentials in the main
settings page
2. Then, in the incoming / outgoing mail server form view, they will
need to tick the Gmail support checkbox
3. A link will be available to be redirected to Gmail and accept the
permission
4. The user can now copy / paste the authorization code in Odoo, set
his email as "login" and then send / receive emails with Gmail
Task-2170676
closesodoo/odoo#83424
X-original-commit: ff223afc5300b2421b8ce935bb468f503c938c5d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The action server is only available on view list. It is hard to find this.
closesodoo/odoo#83455
X-original-commit: 2fa29557d048e43bc9ed0a9fc9047de203b0c4f0
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit: static XML templates could only be defined on the
file system, and called by manifest assets or ir.asset records.
Attachments were not taken into account when evaluating static
templates.
Now, if a given path does not match a file on the system, an
additional check is run on ir.attachment records instead of failing
directly.
Task 2715333
closesodoo/odoo#83438
X-original-commit: e022c4bfafa77f1a3433c3b980631510af696ade
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Whenever we clicked on a link that contained another element
(eg. span, bold, ...), the LinkTool did not open.
Task-2667989
closesodoo/odoo#83437
X-original-commit: d69d26a2dd8830aca8c5922d3548e5ff59c688fc
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Those steps were removed with [1] to avoid a indeterminist timeout, but by
doing so that part of the feature was not tested anymore.
Sadly, it was broken by [2] without being noticed for a long period of time.
The error was discovered by fixing multiple lang issues in the website
configurator in master.
Note that by creating a new lang instead of using an existing one will avoid
the timout error that lead to the removal of those steps with [1]. Indeed, as
no .po files will be found for that lang, it won't spend time on processing
those files.
[1]: https://github.com/odoo/odoo/commit/a15c7099a36a3a5b4dca9375b233cbe3fe2a280f
[2]: https://github.com/odoo/odoo/commit/745ef9de97544d5c1a97e03be67e903feca40c2aclosesodoo/odoo#83420
X-original-commit: 0b43f52116fd9a58fb0a123db576d822fd541043
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [1] the redirection supposed to happen after a lang install from the
frontend was broken.
Indeed, the 'url_return' was moved and used before it is actually set.
[1]: https://github.com/odoo/odoo/commit/745ef9de97544d5c1a97e03be67e903feca40c2a
Cheers to @jke-be which did the same fix in another branch in parallel.
X-original-commit: 74a594bb2e68662b22477fcce24d9620b2dd0b2a
Part-of: odoo/odoo#83420
On runbot database can be create concurently by other builds, meaning
that the teardown may fail randomly if a database is create between
setup and teardown. Filtering on the dbfilter in all case may miss some
errors but will be enough in this case.
closesodoo/odoo#83414
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Steps to reproduce the bug:
- Activate packaging in inventory configurations
- set the product UOM digits to more than 2 decimals
- Create a storable product:
- Go to inventory tab > Packaging > Add a line
- Change the contained quantity to a value with more than 2 decimal places
Problem:
It will round it to 2 decimal places regardless of the set digits.
Because the formatFloat function does not receive the digits in parameter, so it uses 2 as default value
Problem:
opw-2723068
closesodoo/odoo#83411
X-original-commit: 144761f07c9de53aaeb7e1468e017eee17cbacd2
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Current behavior:
When creating a gift card in PoS you are not able to use it in the eCommerce website
Steps to reproduce:
- Activate gift card in PoS, in Generate barcode mode
- Create a gift card in the PoS
- Try to use this gift card in the eCommerce website
- You get an error "expired or not valid"
opw-2727404
closesodoo/odoo#83354
X-original-commit: 26112a57cd2ce1726af1b10f24305595d3f4d0be
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Current behavior:
When changing the type of a payment journal used in a cash payment method you couldn't close a PoS that used this payment method
Steps to reproduce:
- Point of Sale > Configuration > Payment Methods
- Select 'Cash' payment method, go to journal 'Cash', edit the type to 'Bank'
- Go to a Pos session, then try to close it.
opw-2732933
closesodoo/odoo#83343
X-original-commit: 43b64a78888d5b79d87491caf1401964228809fc
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
In order to anticipate an anomaly in the network to prevent
a save, wait for an rpc to finish.
task-2742008
closesodoo/odoo#83103
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Upon save in website or in mass_mailing, if a `cleanForSave` of a
`SnippetEditor` or a `SnippetOption` wait for the end of an
`this._rpc()` request AND the `SnippetEditor` or the `SnippetEditor`
of the `SnippetOption` has a `SnippetEditor` ancestor, the
`cleanForSave` will never resolve.
Here is the scenario:
- **SnippetEditor B** has **SnippetEditor A** as its odoo widget parent
In `SnippetMenu` `_destroyEditors`:
- **SnippetEditor A** and **all its SnippetOption** call `cleanForSave`.
- **SnippetEditor B** and **all its SnippetOption** call `cleanForSave`.
One of the promise of **SnippetEditor B** includes the result of
`rpc()` in `ajax_service.js`.
- **SnippetEditor A** and **all its SnippetOption**
`cleanForSave promises` resolve (but not **SnippetEditor B**).
- **SnippetEditor A** get's destroyed (`snippetEditor.destroy()`). As
**SnippetEditor B** is a `Widget` child of **SnippetEditor A**:
- **SnippetEditor B** get's destroyed (here is where the problem start).
... in the mean time ...
The ajax request of a promise of **SnippetEditor B** ends. The promise
of the `rpc()` will never finish because **SnippetEditor B** is
destroyed and the condition in `rpc()` is:
```js
if (!target.isDestroyed()) {
resolve(result);
}
```
Because the promise will never finish for `_destroyEditors`, the save
action will never fully complete.
Task-2742008
Part-of: odoo/odoo#83103
Before this commit, to aaccess some values of the DeliveryPackage
objects, we needed to take the value from the related picking. for
example, for the `payment country code` linked to the package, we need
to retrieve the value from the related picking or order.
To avoid passing too much data to the request objects, it is convenient
to be able to access to the order/picking related to the package
directly from the package.
Because these objects are not children of odoo.models.Model, I do not
need to follow the convention for the names, however, calling the
picking > picking_id in the DeliveryPackage suggests that the picking is
actually a odoo.models.Model child, which should be the case if it
exists.
reference-branch= https://github.com/odoo-dev/enterprise/tree/master-dhl_add_commercial_invoice-goaclosesodoo/odoo#83404
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Whenever the layout of the shop when editing the /shop page,
all the elements mutated from _onApplyShopLayoutChange
became dirty but shouldn't have as there is no intention to
save those mutations.
Task-2676809
closesodoo/odoo#83398
X-original-commit: aca32bc0ab670221ea885cf8c17e7449255f1458
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, when trying to paste an url, the editor was
properly creating a link but did not create a step in the history.
So when the user hit enter just after the paste, the last link
insertion was reverted.
Task-2720366
closesodoo/odoo#83396
X-original-commit: 0e37742d3caba1c6544e5b466503f155626375eb
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, a traceback occured when trying to remove a popup
snippet, only if content inside was clicked on before (base case but
that last part was not covered by our main test which drags and drops +
removes all snippets).
The problem is complex and annoying to solve in stable. The cause is the
combination of [1] and [2]. Indeed, with [2] we solved the snippet
activation flow to ensure the onFocus and onBlur methods are called when
needed... but that new correct implementation relies on the fact that
the number of snippet editor instances does not change for the whole
async operation of activating a snippet. That should naturally be the
case but is not because of [1]: when we remove a snippet we first
trigger a snippet activation then destroy the snippet (and its editor
instance)... but the snippet activation is not awaited at the moment.
Thus making the snippet editor instance be destroyed *during* the
snippet activation flow. Of course a better solution than this commit
must be found but this fixes the traceback with a very minimal change
for the 15.0 stable version while waiting for that miraculous solution.
[1]: https://github.com/odoo/odoo/commit/ae219ec06baf0280c76ae09b1453cc1481eece30
[2]: https://github.com/odoo/odoo/commit/0acc5e784b15d9c963660da3781763448503f33e
task-2735663
closesodoo/odoo#83378
X-original-commit: da7c1b5757a7780897c5736ddecc014a7fb50bdb
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Steps to follow
- Use an odoo instance without the planning app
- Go to the survey app > feedback form
- Click on "See results"
- Print the document with your browser
-> The output only contains the first page
Cause of the issue
A height of 100% is set to the html element
It works with the planning module because this css is present
https://github.com/odoo/enterprise/blob/ead53fcca721aaa06619b4113707cae3fe086731/planning/static/src/scss/planning_calendar_report.scss#L57-L60
Solution
Unset the html height property in the survey layout
opw-2724319
closesodoo/odoo#83370
X-original-commit: 2c2f9a13a8251791ea24e93927f9a45e8dda2c14
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
It is sometimes impossible to unbuild a product because of decimal
values.
To reproduce the issue:
(Enable debug mode)
1. In Settings, enable "Units of Measure"
2. Set the decimal accuracy of "Product Unit of Measure" to 4
3. Set the rounding precision of "Units" to 0.001
4. Create two products P1, P2
5. Create a BoM:
- Product: P1
- Quantity: 3
- Type: Manufacture
- Components: 5 x P2
6. Process a MO with 3 x P1
7. Create an unbuild order UO:
- Manufacturing Order: MO
- Quantity: 1
8. Unbuild
Error: An error message is displayed "The quantity done for the product
"P2" doesn't respect the rounding precision[...]"
At some point, for each SM associated to the UO, the modules uses the
value of `product_uom_qty` to write the done quantity of the SM. The
rounding of `product_uom_qty` is based on "Product Unit of Measure" so
the component's SM has its quantity equal to `1.6667`. Moreover, writing
the done quantity trigger the creation of the associated SML. As a
result, the SML has its done quantity equal to `1.6667` while the
rounding of the associated UoM is `0.001`. When calling `_action_done`
on such a SML, it will raise an error because the value doesn't respect
the rounding.
Side note: the error message is incorrectly written, the indents in the
file are displayed on the front-end.
OPW-2710038
closesodoo/odoo#83369
X-original-commit: c11d772f39179c5dec5eb431b6f4bc02c680643a
Signed-off-by: Adrien Widart <awt@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2731819
closesodoo/odoo#83092
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to repdroduce:
- install Purchase - Accounting
- Create a new Purchase Order
- Add a product
- Add a section or a note
- in Actions select Accrued Expense Entry
-> traceback rounding error
OPW-2728854
closesodoo/odoo#83057
X-original-commit: 582be68bb5e4d441548a987fda3ff6450faa24ca
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
This commit is a forward port of the 2 following commits:
[IMP]l10n_dk: Add support for danish tax reporting
commit: d48433589a403754e9853b5242ec42abfafbfdea
This commit creates the basis for the danish tax report.
It creates the report and link the tags to the related taxes.
[IMP]l10n_dk: tax report and taxes impl. rework
commit: 7e4017c43a72314a5ba6da40903896f2dce4e2d5
This commit aims to:
- implements formula in the tax report
- shorten tag names and add context comments to the tax report
- correct the tax implementation
- add some fiscal position for some taxes and reorder them
- delete a tax that doesn't make any sense
closesodoo/odoo#83376
Community-pr: https://github.com/odoo/odoo/pull/80823
Task: #2666277
X-original-commit: f8c1015841020244bae16715b0112f41b91ec72b
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Brice Bartoletti <bib@odoo.com>
When changing the background image with studio the image does not update.
It works in debug=assets mode.
This is due to the fact that the caching system is not aware of the presence of a possible background image
opw-2696786
closesodoo/odoo#83374
X-original-commit: 184029e3e1e8907e25dd712dd87afd65885695bb
Related: odoo/enterprise#23744
Signed-off-by: Achraf <abz@odoo.com>
This is not a big deal, but by passing a widget instance or a DOM
node as message to a QUnit.assert function, QUnit keeps a reference
to that instance or DOM element, and it can never be garbage
collected (nor its bound handlers in the case of a DOM element).
For the mail case, this was a bit more critical as we didn't check
what the author of the test actually wanted to check.
closesodoo/odoo#83384
X-original-commit: 692fd6ecee602f7ceaae093b855aff65d50ca797
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When installing 'l10n_fr_pos_cert', some fields become always editables on the bank statement form even the state is not in 'open'.
This allows the user to introduce a lot of unconsistencies regarding the bank statement balances.
closesodoo/odoo#83348
X-original-commit: cb49944f3c980fa22131713fd96cf7bcbdc757be
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
Fixes a couple of things;
1. Backorder use case when unassigning a move in reception report.
To reproduce:
- Create a Delivery w/ Demand = 8 of a stored product not in stock
- Create a Receipt w/ Demand = 10 of the product
- Assign 8 of product to delivery (don't forget to activate Reception
Report in settings
- Mark 4 of product as done > mark as done > create a backorder
- Open reception report in backorder (shows 6 instead of 4, this is a
known limitation of reception report) + unassign + close report
- Reopen report + assign 4
- Finish the backorder
Expected result: Delivery has 2 moves totaling a demand and reserved
amount of 8
Actual result: Delivery has 2 moves where 1 is fully reserved but the
other isn't and cannot be reserved (even though product in stock).
Issue was due to move split during unassign not taking into account that
the amount being unassigned could be greater than the amount still
assigned (due to backorder amount > demand qty since it doesn't know how
much was done in the original receipt). This would lead to the move
linked to the original receipt's move expecting a greater quantity from
the original move (and therefore not reserving any more quantities.)
2. Trying to unassign from an already done move. (i.e. backordered move
from above unassigned after the delivery is already done) isn't allowed,
so in case of unassigning from a done move, we don't do a split.
3. In case of failure of unassigning, fail gracefully (i.e. don't switch
button status since this is misleading).
Discovered during task: 2662730
closesodoo/odoo#83338
X-original-commit: 3c0c780032ed07da7ec14bdad8df2ff48fc5f4ef
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Tiffany Chang <tic@odoo.com>
It's not entirely clear whether `@synchronized` is even useful, but
keep it for now. `locked` is just the default instance of
`@synchronised`.
- rewrite `@synchronized` using `decorator`, don't fold everything
into a single call as there's a potential for parametric conflict
- remove the independent `locked` in `sql_db.py`
- convert `lru` to `locked`
- move `Registry` over to `locked` where applicable
closesodoo/odoo#82718
Signed-off-by: Raphael Collet <rco@odoo.com>
Before this commit, the field reversal_date was not stored, which lead to inconsistent behaviour when creating entries, as the reversal date was always recompute with the default value.
opw-2722435
closesodoo/odoo#82445
Signed-off-by: William André (wan) <wan@odoo.com>
When Jabberwock was introduced in [1], forms were not selected anymore
by clicking on the form fields.
That behavior got fixed when Jabberwock was removed in [2] but this
commit introducing a test about it was not attached to a task - and did
not get merged at the time.
Before this commit there was no test to verify if the form became
selected when clicking on one of its input field or textarea.
After this commit there is a test that makes sure that the form is
selected when the user clicks on either an input field or a textarea.
Also added the renaming of a field label followed by a blur to ensure
it triggers all UI events.
[1] https://github.com/odoo/odoo/commit/347f4413d1b1a2b1a6a9ecd6d9c20cf7f3ec5ff3
[2] https://github.com/odoo/odoo/commit/e5572c317a7775a58675ed73efc89b5c9f6c0c39
task-2729643
closesodoo/odoo#83379
X-original-commit: fe4000cd521b5e1426b9093f7671fa457ef45eb8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Set a default tag on the bank suspense account, outstanding accounts
and transfer accounts so that they are found and used by the trial
balance and COA reports.
TAsk id #2612900closesodoo/odoo#82532
Related: odoo/enterprise#23383
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Benjamin Vray