This commit is a performance fix to improve the speed of opening the pos kiosk or QR code.
`_get_attributes` method of pos_self_order's product.product extension will call `self.env["pos.session"]._get_attributes_by_ptal_id()` every time it is called. For *N* products, `_get_attributes` is called *N* times. This can lead to slow performance for high enough *N*, because `_get_attributes_by_ptal_id` method is slow, because it makes many `read` calls to product.attribute.value
This commit lifts the call to `_get_attributes_by_ptal_id` higher in the call stack, so that it is only called once as opposed to *N* times. It passes its result into `_get_attributes` via context, which will re-call `_get_attributes_by_ptal_id` if it wasn't in context for backwards compatibility reasons.
attributes must be deep copied within `_get_attributes`, because `_add_price_info_to_attributes` mutates the values within, which would invalidate future calls. The deep copy gives a fresh instance for each call, and only copies the applicable attributes so it shouldn't be large.
In this particular customer's DB they have 1376 product.product records and their pos config's pricelist (id 36) has 1572 rules in it.
Overall, based on the benchmarks below, this commit makes loading the pos about 4-5 times faster.
Benchmarks:
__Before commit__
_Customer DB_
product.product count == 1376
SQL query count ~= 5034
Time to load pos ~= 44 sec
_Customer DB with more products_
product.product count == 3792
SQL query count ~= 9359
Time to load pos ~= 96 sec
__After commit__
_Customer DB_
product.product count == 1376
SQL query count ~= 2360
Time to load pos ~= 8 sec
_Customer DB with more products_
product.product count == 3792
SQL query count ~= 3906
Time to load pos ~= 22 sec
closesodoo/odoo#162962
X-original-commit: f09db068ff3c5a4e8444885c0cdd28e4221cf024
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Zachary Hanham (zaha) <zaha@odoo.com>
The module `l10n_nl_reports_sbr` requires
- `zeep.wsdl.utils.get_or_create_header`
- `zeep.ns.*`
- `zeep.wsse.*`
In addition, it requires the `session` to be already
set during the creation of the client.
The module `l10n_pe_edi` requires `requests.Response` as possible
output for service
```py
result = client.service.sendBill
if result.status_code != 500:
...
```
Can be tested with
`--test-tags external_l10n:TestEdiSunat`
opw-3887309
opw-3884785
opw-3885630
opw-3870707
opw-3888951
opw-3885636
opw-3885392
opw-3885383
opw-3889366
opw-3888841
This test can sometimes fail randomly
FAIL: TestProfiling.test_sync_recorder
Traceback (most recent call last):
File "/data/build/odoo/odoo/addons/base/tests/test_profiler.py", line 440, in test_sync_recorder
self.assertEqual(stacks_methods, [
AssertionError: Lists differ: [['a'[114 chars]], ['__exit__', '_remove'], ['__exit__'], ['__exit__', 'stop']] != [['a'[114 chars]], ['__exit__', 'stop']]
First differing element 11:
['__exit__', '_remove']
['__exit__', 'stop']
First list contains 2 additional elements.
First extra element 12:
['__exit__']
[['a'],
['a', 'b'],
['a'],
['a', 'c'],
['a', 'c', 'd'],
['a', 'c'],
['a', 'c', 'd'],
['a', 'c'],
['a'],
[],
['__exit__'],
- ['__exit__', '_remove'],
- ['__exit__'],
['__exit__', 'stop']]
Since we don't care about the last lines, just remove them from the
assertion.
closesodoo/odoo#163016
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Those were broken by the theme update for 17.0, in particular at [1].
Indeed the underline colors were defined using `text-XXX` classes to use
the theme colors, relying on the fact that the default color of HR
elements used the `currentColor`. Now they use the `currentColor` but
very faded... making those underline colors uglier and for one of them,
basically invisible.
As a stable fix, this updates the XML to make the border use the
`currentColor` as before in new mega menus... although they do not work
as well in 17.0 as they did in 16.0. This will be reviewed in master to
use better colors and a more reliable and beautiful way.
[1]: https://github.com/odoo/odoo/commit/fad514ebdc25b9de03fd387a0c07dbbc274c364eclosesodoo/odoo#163011
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
All these countries use the chart of accounts that is defined in l10n_syscohada.
This commit then add the tax report for each localization, and taxes to be able to fill it.
task-2841655
closesodoo/odoo#136155
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Issue:
Have a grouped list view with several pages, go to the next page,
open a group and click on a record to open it in form view. Click
on the breadcrumb to go back to the list: the offset is lost, and
we're back in page 1.
After this commit, the offset is correctly kept.
opw~3851390
closesodoo/odoo#162969
X-original-commit: 8dbf154fdbbff7790c99b3f91d3c1896d436a346
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Issue:
======
Colorpicker doesn't appear in mass mailing
Steps to reproduce the issue:
=============================
- Create a new mass mailing with a some template other than plain text
- Try to change the color of some text
- The position of the colorpicker is wrong.
Origin of the issue:
====================
When wysiwyg was converted to owl in [1], an effort was made to
speed up the loading of the iframe in mass_mailing. One of the
changes that were done in that regard was to remove assets from
the iframe to make it load faster. This required to create the
sidebar (SnippetsMenu) outside of the iframe since the iframe did
not have the required files anymore, and insert it back in the
iframe afterwards, since it was designed to work inside the iframe.
This change actually had an impact on the positioning of the
colorpicker, and basically anything that relied on popper.js for
positioning, because since popper.js was outside of the iframe then
the checks it did based on `instanceof HTMLElement` were returning
false for every node inside the iframe. At the time of [1] this
went unnoticed because the chatter was not yet in the side of the
screen for mass_mailing, so the wrong positioning of the colorpicker
was actually only slightly off the right position, thus being hard
to catch while not specifically looking for that particular issue.
As soon as the chatter was made to be on the side even in the case
of mass_mailing, the wrong colorpicker position became visible but
the issue went unnoticed at the time as well, probably because the
two changes were completely unrelated. This went live in saas-16.4
and is the case in 17.0 as well. However, the issue does not exist
anymore in saas-17.1 due to the refactor of mass_mailing to have
the sidebar (SnippetsMenu) working from outside of the iframe
instead of inside.
Solution:
=========
Fixing this issue properly would require huge changes to how the
SnippetsMenu is constructed and would most likely require going
back to the slow iframe with all the assets inside. That would not
be a desirable outcome, especially in a stable version. With that
in mind, and considering the issue doesn't exist in saas-17.1, we
decided it was a prime example where a local change in the popper.js
library was actually the best fix. The library is very unlikely to
be updated in a stable version and the change won't reach saas-17.1.
[1]: https://github.com/odoo/odoo/commit/76d4f98
co-authored with dmo-odoo
task-3614965
closesodoo/odoo#162964
X-original-commit: 88c16966b6b2d29d464ac3b43cc4998d3f4fe0e2
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Prior to this commit, there were scenarios where sync orders did not
contain an order, leading to a failure when reading its state. This
commit introduces a check to ensure the order exists in sync before its
state is read, thereby preventing this error.
opw-3856451
closesodoo/odoo#162943
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Since commit 7d2baaa0c7 ("Unity read"), we are able to
pass a full specification to subfields in a view and retrive records directly according to that
specification. This could include "order".
In the case of a list view that has a `widget="handle"`, this order is automatically set to "[handle_field] ASC".
Before the unity read feature, it did not cause problems for one2manys because the ids of records were retrieved in python
using the "natural order" of the model (the `model._order` slot), which usually had the right parameters.
(see `sale.order.line` for example). When fetching the ids of the one2many, those were already sorted in natural order.
In unity read, the natural order is overriden by the specification and became only "[handle_field] ASC". This was insufficient
as more often than not, sequences on model are set up with a default. So eventually, all records couls have the same sequence.
The sorting in SQL becomes undeterminate.
After this commit, we had the sorting key "id ASC" to avoid any unwanted results.
opw-3790378
see discord https://discord.com/channels/678381219515465750/687338039717920792/1231977078564585555 for a detailed discussion.
closesodoo/odoo#162933
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Step to reproduce:
- Go to /jobs (install website_hr_recruitment)
- Go on a job offer
- Click on the "Apply" button
- Edit the form
Purpose:
Since the implementation of commit [1], our system employs alerts
resembling `this field 'partner_name' is mandatory for the action
'actionName'`. However, this alteration has led to a bug where in
certain forms exhibit an undefined action name value, particularly
evident when users attempt to modify specific forms containing required
fields. The bug manifests when an alert is triggered, and the action
name becomes undefined due to the condition `this.modelCantChange`
evaluating to `true` within the `willStart` function. Consequently,
invoking `_super` results in the return of `willStart` without assigning
a value to `currentActionName`.
After this commit:
Now, before returning the function, it sets a value for
`currentActionName` and then proceeds with the necessary steps. This
prevents the issue where an action was `undefined`.
[1]: https://github.com/odoo/odoo/commit/b154fe1
task-3680483
closesodoo/odoo#162468
X-original-commit: 3626e36a9c4995286be48206b0d927f1de51e295
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Current behavior:
When trying to print a receipt offline, the image will not be loaded
and you get a traceback.
Now the receipt is printed, and an error is logged in the console if
the images couldn't be loaded
Steps to reproduce:
- Add a logo to the company
- Launch PoS
- In the browser devtools network tab turn the connection down
- Do an order, and try to print the receipt
- You get a traceback and the receipt is not printed
opw-3811663
closesodoo/odoo#162451
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
When the module "sale_product_configurator" is not installed, an AttributeError is raised
Steps to reproduce:
Install the "point_of_sale" app, the "pos_self_order_sale" module and remove the "sale_product_configurator" module
Go to settings -> point of sale -> Self ordering: QR Menu -> preview web interface
Cause:
The field "optional_product_ids" is provided by the module "sale_product_configurator" which is not a dependency of this module
opw-3850421
closesodoo/odoo#161921
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Currently when we have an Analytic Filter applied on an accounting
report, we lose that filter when we click on any amount to audit the
journal items.
This fix makes sure that when auditing, we only view the journal items
filtered by the Analytic Filter.
In order to do that, we extend the search function in the analytic mixin
to allow searching on analytic account ids.
task-3718751
closesodoo/odoo#161873
X-original-commit: 2e3be9726514f74ea8c0c2314c9cdfeb6ed57915
Related: odoo/enterprise#60742
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
forward ported the commit https://github.com/odoo/odoo/commit/cbefaa6bff5bab6c787d8b9ef4668ba7d9870d55
In odoo#126249 the german balance sheet report was updated and
during the 15.2 FW port, some issues needed fixing. The
issues and their fixes are:
- Deleted tags: As the script didn't run, some tags (like F and
all D tags) would be deleted and not renamed. As the tag might
already be used as a FK in another table, we remove it from
ir_model_data so it's not deleted by the ORM. Also, this means
that the tags xml adds the B1 as a new tag which means renaming
C1 to B1 will not work in the script due to the unique name
constraint, this is handled by checking if B1 exists and if
it does we do not run the script.
Enterprise PR: odoo/enterprise/pull/45899
closesodoo/odoo#162436
X-original-commit: c019d6f3f5cfe3884ba10fd1aa9357dabe592db8
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Steps to reproduce the bug:
- In Website edit mode.
- Drag & drop a "inner content" search snippet into the footer.
- Save the page.
- Enter the letter "h" in the input.
- Bug: The dropdown doesn't adapt properly and increases the height of
the page.
This commit fixes this issue by detecting if the searchbar menu
overflows at the bottom of the page when it's open. If it does, we
reduce its height, and if it still overflows despite the reduced height,
then we move it above the search bar instead of below.
task-3751401
closesodoo/odoo#160426
X-original-commit: d6fb56556c08a1c3aac5951991d40d403e235b90
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
Reduce the survey questions page in every display mode
and the print page display to be the half screen size.
This is done to match the previous results page improvements.
Also reducing the font size of the "Thank you" message and the
print page questions and sections titles to best match the new
half screen display.
Removing the badly placed livechat from the survey main layout as
it is overlapping the survey navigation.
The current "no_livechat" variable in the survey main layout and the
user input session layout is not taken into account.
This is due to the fact that, in the "website_livechat" module, the check
for the "no_livechat" variable is performed inside the "head" tag,
so way before the "div[@id='wrapwrap']" element.
Changing the xpath so that the "no_livechat" variable is correctly defined
before the check.
related odoo/odoo#152263
Task-3789479
closesodoo/odoo#156665
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit, several qunit load state tests sometimes
failed. They all follow the same pattern:
- trigger an "hashchange" event to simulate an update of the url
- wait twice for nextTick
- check the DOM reflects the url change
However, waiting for 2 ticks isn't enough. Indeed, when the url
hash is set, our mock location object dispatches a "real" hashchange
event on window, but it does it after a setTimeout [1]. Then, the
webclient is notified (via the router service) of the url change,
and reacts by loading the appropriate action. This then requires
2 ticks, because we first clear the DOM with the BlankComponent,
and then we mount the requested action/view.
This commit makes those tests more robust by waiting for a
setTimeout before the 2 nextTicks.
[1] https://github.com/odoo/odoo/blob/1882d8f89f760bd1ff8a2bf0ae798939402647a3/addons/web/static/tests/setup.js#L52
Runbot issue~37030
closesodoo/odoo#162939
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Steps to reproduce the issue:
- Create a storable product “P1”:
- Route: dropship
- Vendor: Azure interior and deco addict
- Create a sales order with one unit of P1
- Confirm the sales order
- A purchase order is generated with a dropship-picking
(linked to the SO)
- Create an alternative PO and confirm it
Problem:
The alternative PO is linked to the SO, but the dropship-picking is not
linked. This is because the procurement is not propagated when creating
the alternative PO.
opw-3828132
closesodoo/odoo#162815
X-original-commit: 727eae85cf532e2b7057a5645550e67875c37d62
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Issue: Error when the 'date_from' field is left blank.
Cause: When deleting the 'date_from' field, the onchange
'_onchange_date_from' is triggered. It will call the
'_process_accrual_plans' function and report an error as shown below:
first_level_start_date = allocation.date_from +
get_timedelta(first_level.start_count, first_level.start_type)
TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'
Solution:
- Check the 'date_from' condition before calling next function
- Handle it only in the onchange because the 'date_from' field is
required
closesodoo/odoo#162730
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Fix the demo user input lines which were considering "Pinaceae"
as a correct answer to the question "Dogwood is from which family
of trees ?" even though the suggested answer was declared as incorrect
for the question.
Dogwood is indeed from the "Cornaceae" family of trees, not the "Pinaceae".
Fixing the issue by updating the user input lines to be incorrect.
related: odoo/odoo#72298
Task-3856668
closesodoo/odoo#162886
X-original-commit: ee9ce57f4bb63d1c311d9474c26626081f333ba4
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Amélie Dieudonné (amdi) <amdi@odoo.com>
using sudo().is_kits to account for user not having access
to the bom module and boms in different companies
closesodoo/odoo#162830
X-original-commit: badd0a6dce90cc103ebc2c193e47da3f753f80a6
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
Current Behavior:
Tasks with or without dependent tasks and a state not in closed states have their state changed to `01_in_progress` when duplicated.
previous PR that changed this logic: #139249
Purpose of this PR:
To retain the state of the original task when duplicated.
Steps to Reproduce in Runbot:
1) Enable Task Dependencies in Settings
2) Create a Project with Task A
3) Set state of Task A to 'Approved'
4) Duplicate Task A > Task A will now have a state of 'In Progress'
opw-3836251
closesodoo/odoo#162794
X-original-commit: a50d0317732232dad6c4b8b65c985643d0ff94b5
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
While searching for a similar attachment, as the fallback url pattern is
the same as the url pattern, the condition is never satisfied.
With this commit, the ignore_params parameter is used to find a similar
attachment.
closesodoo/odoo#162654
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
A few x2many list embedded in form views have the "editable" attr
set to "1". Normally, the valid values for this attribute are "top"
and "bottom". Regular list views are validated, but not lists
inside form views.
When set to "1", some features of the model aren't enabled. For
instance, when the current page is full and the user adds a record,
the limit isn't temporarilly increased for the added record to be
displayed on the current page, like it would be in editable="bottom"
lists, so the user doesn't see the record he just added.
The issue can be observed in the stock move form view for instance.
This commit is only good for stable versions: we add a fallback
on "bottom" s.t. if the editable attribute is set, it's always
either "top" or "bottom".
In master, we'll probably rethink the API.
opw~3860903
closesodoo/odoo#162832
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
This commit fixes an issue occurring in the `web_editor` when multiple
users edit some content.
Prior to this commit, the user avatar was not using any aspect-ratio
rule, resulting in a stretch avatar if the uploaded image wasn't square.
This commit fixes this issue by adding the `o_object_fit_cover` class to
the image, ensuring a correct ratio no matter the format of the uploaded
image.
task-3877841
closesodoo/odoo#162810
X-original-commit: 7240fa3ff495a8aba7bd53b720e99cd767948342
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Chrysanthe Gomrée (chgo) <chgo@odoo.com>
Access rights on ir.attachment depend on the record it is linked to.
steps to reproduce:
- log as admin
- create a calendar event and invite marc demo
- log as marc demo
- check discuss notifications and try to download "invite.ics"
before this commit:
- file can not be downloaded from the webclient (access error appear in logs)
after this commit:
- file can be downloaded from the webclient
opw-3754798
closesodoo/odoo#162694
X-original-commit: 6a698ef3ee99af45251156279c9a5af6185f5dd1
Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
The `use_create_components_lots` option of manufacturing picking type was never read
as the context to get the active production order was not always
specified.
Also, this field was not taken into account to display or not the
'generate serial' and import 'lot buttons'
closesodoo/odoo#162581
Related: odoo/enterprise#61137
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
The FEC report contains initial balances. These representing balances on accounts from the previous period.
When calculating the initial balances, there is no requirement to include balances from the previous period for an account if they are at zero.
When there are settled transactions for many thousands of partners from the previous period, this results in many thousands of initial balance lines in the FEC report that all have a balance of zero.
This PR remove initial line with zero balance.
closesodoo/odoo#160729
X-original-commit: 1d1beaf4aa02875f1843b99564562f9ed4446ae8
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
A lot of users don't understand why they can't reserve in MTO chain after
moving a product with an immediate transfer. It's due to the double check of
_action_assign that look where the move orig stored the product and
if the quants exist in this exact location. In our case the product was
moved so the match doesn't work.
We introduce an new parameter to check if modifying the behavior on
those cases could work. When _free_reservation is call on a
`stock.move.line`, we expect to never find it at this place
anymore (except if we bring it back). Then we drop the MTO link
for this step and use the MTS reservation.
WARNING, this parameter could remove too many mto links. e.g.
There is multiple stock.move.line linked to different locations
they will lose the link for product remaining in the same place.
closesodoo/odoo#155118
X-original-commit: af41b538d89a3c59c78f65c9174c7fbf4aa43922
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
PR odoo/odoo#157918 has a bug on commit 8bd8d4a3eaf.
We cannot do `int(x) in Command` as it's TypeError.
closesodoo/odoo#162786
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
This PR fixes two translation issues when launching a chat bot with a
different language than the user's:
1. Wrong translation for `question_selection` answers
2. Wrong translation for the `question_email` answers
1. The answers to a `question_selection` could be mistranslated
because the lang is missing from the context when `post_welcome_steps`
is called`. As a result, the `discuss.channel/new_message`
notification would have the wrong answers format.
Steps to reproduce the issue:
- Go to the test chat bot test page
- Switch the website language to the one that is not used by the user.
- Check the return result of `post_welcome_steps`: answers are in the
correct language.
- Check the corresponding `discuss.channel/new_message` notification
received through the websocket: the language is the one of the user.
2. The chat bot language is not specified when calling the
`validate_email` route so the lang is the one of the user by default.
Steps to reproduce the issue:
- Go to the chat bot test page
- Activate another language than the one of the user
- Select "I have a pricing question" with no operator available
- Enter an invalid email
- The answer is in the user's language while it should not
opw-3862125
closesodoo/odoo#162655
Signed-off-by: Matthieu Stockbauer (tsm) <tsm@odoo.com>
Current behavior:
When an order is invoided after the session has been closed, a reversed
payment is created. This payment is not reconciled correctly with the
invoice. This is creating an aged receivable for the partner.
Steps to reproduce:
- Change the bank payment method to "Identify customer"
- Create an order in the PoS and pay with bank and specify a partner
- Close the session
- Open the session again, and create an invoice for the order
- Go to the accounting module and look for the aged receivable report
you should see some entries under the partner you selected.
- You can also go to the partner form and see that he has some due
invoices.
opw-3678298
correct partner
closesodoo/odoo#162653
X-original-commit: 31aff389c4c9d01be2f960a0ae134ff658e802c9
Related: odoo/enterprise#61158
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
When in demo mode, we always want to be able to change the CoA
* to remove friction when demoing: no need to be overly safe
* to ensure that `test_all_l10n` always works even if we load a CoA
in `<res.company>.create`
closesodoo/odoo#162299
X-original-commit: cceb4e823f7a697076615a13c2b47bc6dbdbaedb
Related: odoo/enterprise#60993
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
The chatter in documents was not flex, which made it take a lot
of space without any wrapping. As a result, usually chatter took
all the screen and content was massively overflowing, resulting
in poor UX.
This was caused by a specific stylerule in documents with chatter
that made sense in a earlier version of chatter CSS, but this
is no longer needed.
Also we actually want to reuse most style of chatter in form view.
This commit adds `o-mail-ChatterContainer` classname on same
HTML node as `o-mail-Form-Chatter` and adapts style, so that
Document can set this classname to reuse style.
opw-3681435
closesodoo/odoo#161940
Related: odoo/enterprise#60772
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
This commit add a new tax call VAT exemption for VN accounting
-Exempt goods and services
There are stipulated categories of VAT exemptions, including certain
agricultural products; goods/services provided by individuals having
annual revenue of 100 million Vietnamese dong (VND) or below; imported
or leased drilling rigs, airplanes and ships of a type that cannot be
produced in Vietnam; transfer of land use rights (LUR) (detailed
guidance is provided to specific cases); various financial services;
various securities activities including fund management; capital
assignments; foreign currency trading; debt factoring; certain types of
insurance; medical services and elderly/disabled people care service;
postal and telecommunications provided by the Government; education,
printing/publishing, public transportation, export of unprocessed
natural resources, etc.
read more at
https://taxsummaries.pwc.com/vietnam/corporate/other-taxeshttps://www.sumup.com/en-gb/invoices/dictionary/vat-exemption/
Part-of: odoo/odoo#161457
Before this commit, the log message did not clearly indicate
who attempted to request a payment.
After this commit, the message specifies whether the payment request
was initiated by the customer or by the system.
task-3864521
closesodoo/odoo#161252
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
__Current behavior before commit:__
Sometimes the following tracebacks are popping up when an RTC connection
is being established between two users trying to edit the same document.
```log
InvalidStateError: Failed to execute 'setLocalDescription' on
'RTCPeerConnection': Called in wrong signalingState: stable
```
```log
InvalidStateError: Failed to execute 'setRemoteDescription' on
'RTCPeerConnection': Called in wrong signalingState: stable
```
__Description of the fix:__
These errors are not blocking and don't impact the successful ensuing
RTC connection. Thus, we can just catch the error and log it in the
console instead of showing it to the user.
__Steps to reproduce the issue (in 17):__
- Go to a knowledge article
- Open a new tab and open the same article
- On this new tab, quit the article and come back multiple times
Eventually a traceback will appear on one of the tab.
Note that this error seems to occur very randomly. It is similar to the
one dealt by [this commit][1] and it is probably due to a similar cause
i.e. a browser bug when the RTC connection is under stress.
It is however possible to trigger it in a more consistent way by calling
[_createClient][2] repeatedly.
opw-3778272
[1]: https://github.com/odoo/odoo/pull/158861/commits/0eca324
[2]: https://github.com/odoo/odoo/blob/a1afcc8/addons/web_editor/static/src/js/wysiwyg/PeerToPeer.js#L374closesodoo/odoo#162709
X-original-commit: 034d45b6cde6d818755128778fdcf99dd9ff1254
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Julien Launois (jula) <jula@odoo.com>
In case a quant for a product tracked by lot/sn exists but without any
lot/sn set and have some quantity, `_action_done()` should update it
instead of a quant with the correct lot but without any quantity
closesodoo/odoo#162683
X-original-commit: 534220ee90da3e213ea99ec5da7ce6cc9eff4203
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit an error appeared if a block had been set at the top
of the /blog page and the user wished to re-enable the
'Top banner - Name / Latest Post' option. This commit resolves the issue
by giving higher priority to the activated view.
Steps to reproduce the fixed bug:
- Go on /blog page
- Disable the customize option "Top banner - Name / Latest Post"
- Enter in edit mode
- Add a snippet to the top (in the oe_structure)
- Save the page
- Enable the customize option "Top banner - Name / Latest Post"
=> An error happens.
task-2774944
closesodoo/odoo#162620
X-original-commit: 5880aac0c79330e5ef62c475102d53765895cec4
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Steps to reproduce the bug:
- Create a storable product “P1”
- UoM: gram
- Create an internal picking with 0.01g of P1
- Validate the picking
- Create a return and try to validate it
Problem:
A UserError is triggered: “Please specify at least one non-zero quantity.”
When creating a return, we check if the quantity is not zero using the
“float_is_zero” function, but we mistakenly use rounding as
precision_digits.
opw-3862142"
closesodoo/odoo#162389
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
With this commit, on several form view (gantt, calendar and form view)
the status bar does not overlap and the text is no longer truncated.
closesodoo/odoo#161359
Task: 3849814
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Steps to reproduce:
- install `hr_homeworking`
- open calendar and click on "Set Location"
- it will give trace back (same thing can be check by installing `appointment` too)
Cause:
if condition in `onDateClick` method is missing one edge case where
`info.jsEvent` can be undefined.
Fix:
handled missing edge case in `onDateClick` method.
task-3790418
closesodoo/odoo#156861
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Most e-mail clients apply some padding around their e-mails, like
mass_mailing does in its editor. So for the plain text email template,
we mostly don't want to transfer that padding, but for Apple Mail we do
want some padding lest the e-mail be crammed in a corner. The editor's
padding was lost in conversion because the padding was applied to a
table with `border-collapse: collapse` so it was not applied (see
[mdn]).
Since we can't change that property (or layouts will be broken), our
remaining option is to wrap the layout table's contents in a `div` and
apply the padding to it instead. Since we only want this for Apple Mail,
we apply it in a nested media query, which Apple Mail is currently the
only client to support. This is the only known way to target Apple Mail
specifically but since e-mail clients tend to be remarkably slow at
adopting new technologies, this should be safe for a while.
[mdn]: https://developer.mozilla.org/en-US/docs/Web/CSS/border-collapse
task-3062027
closesodoo/odoo#162629
X-original-commit: bc84a40ff49cc82f1c6dd43ffddbffea6e211af0
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Previously, if a product had `price < list_price` and `price < compare_list_price`, but
`website_sale.group_product_price_comparison` unset, no strikethrough price was shown.
However, in that case, we should show `list_price` as the strikethrough price.
Previously, in the search dropdown, `compare_list_price` was only shown as the strikethrough
price if `price < list_price` (which is unrelated). This change make it consistent with the
product page.
opw-3845926
closesodoo/odoo#162611
X-original-commit: b4620c123b753caf2b77472a8d6c42d767471c53
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Louis Tinel (loti) <loti@odoo.com>
Steps to reproduce:
-------------------
1. Install the resource module without demo data (or install any module which depends on it, again without demo data).
2. Login with the administrator user for the first time.
3. The default resource calendar (e.g. "Standard 40 hours/week") timezone will be set to 'UTC' by default
while it should be set to the timezone of the administrator.
Fix:
-------------------
When there is no demo data, no resource_calendar_id is linked to the admin.
In this case, we need to retrieve the record of the default working calendar and
set its timezone to the one of the admin user on the first login.
This is a follow-up of this fix: https://github.com/odoo/odoo/pull/84258
task-3793313
closesodoo/odoo#162531
X-original-commit: b280a9b2c77a1a74a0154154cb4c1cf36e5111af
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Issue:
Discounts are not displayed in DDT
Steps to reproduce:
- create a quotation with a sale line having a discount
- smart button delivery > set qty > validate
- Print
opw-3745866
closesodoo/odoo#162287
X-original-commit: 957443d8a0f416997de9c99354c9d3ae2fb3dfbf
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Yolann Sabaux (yosa) <yosa@odoo.com>
Zachary Hanham