Fix mexico accounts nature of the following SAT accounts:
- 119.01
- 119.02
- 119.03
- 199.04
- 180.01
- 503
- 505.01
- 505.02
- 607.01
- 610.01
- 612.01
Currently some debit accounts are being labeled as creditors and vice
versa. For example the account 119.01 IVA pendiente de pago should be
labeled as a debit account but is set as a credit account.
closesodoo/odoo#33287
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Activate cash basis
- Set a tax
Tax Due: Based on Payment
Include in Analytic Cost: true
- Create an invoice, add the tax and an analytic account on the invoice
line
- Validate and pay
The analytic account is correctly set on the tax line, but it is not set
on any of the cash basis entries.
Partial backport of 079a13a349.
opw-1971751
closesodoo/odoo#33236
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Set a product barcode to a 8 letters value, e.g. 'AAAAAAAA'
- Print 'Product Barcode (PDF)' (or any other report containing the
barcode)
The barcode doesn't print.
All templates assume that:
- a 13 characters barcode is EAN13
- a 8 characters barcode is EAN8
But this assumption is too restrictive: one could want to generate
barcodes with such length without following the EAN13 or EAN8 structure.
We fall back on Code128 when the barcode generation fails.
Backport of 06cfdbaab8
opw-1981988
closesodoo/odoo#33240
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
There was a syntax improvment in the commit merged but it was not
intended to be unfinished.
fixes#33228
opw-1981839
closes#33239
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When paying an eCommerce order with an acquirer which doesn't
redirect (payment_flow: s2s) the "Pay Now" button is correctly
disabled after clicking it. This prevents a user from clicking it
multiple times and being charged multiple times.
When paying with an existing payment token however the button was not
disabled and the user gets no feedback his request is being
processed. Charging an existing payment token takes a while (~5
seconds with Authorize) and so it's possible users will hit the button
multiple times.
This disables the button when reusing an existing payment
token. Additionally it now uses the correct font awesome icon (fa-lock
instead of fa-plus-circle).
opw-1981064
closesodoo/odoo#33196
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Python2 uses byte strings by default and python3 text string, so adapt
the code communicating with blackbox to still only use bytestring.
Also raspbian image has been updated in posbox 17 to Raspbian 9
(stretch) so ifconfig command returns has different format output (
`ether {MAC address}` instead of `HWAddr {MAC address}`) so the way we
get the MAC address is changed.
opw-1981839
closes#33150
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
ONLINE:
make an order, chose a customer, click on "invoice"
Make the payment, validate
Just **before** the request to download the pdf of the invoice
go OFFLINE
(to achieve this, just put a debugger before the do_action() fires, and kill the server)
Before this commit, the button validate on the payment screen stayed inactive forever
This was because the deferred representing the invoicing flow was still pending
After this commit, we handle the case to invite the waiter to print the invoice
from the backend
OPW 1972301
closesodoo/odoo#33188
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
There was 2 issues regarding delivery price when the delivery was set to fixed
price and free over a certain amount.
1. On /shop/payment step, such deliveries would have the fixed price shown on
the badge, even if the sale order amount exceed the free over threshold.
2. When clicking on a delivery carrier, it is supposed to compute all the SO
costs (delivery, taxes..) and display them.
The delivery price selector would try to get the 'badge.hidden' element
which never exists for fixed prices. Thus, it would not update the delivery
badge price.
Now:
1. If the free over threshold is met, we display 0$ instead of the fixed price
by calling `rate_shipment`.
Note that `rate_shipment` can't fail in case of a fixed rate (see method).
The only failing case is if the customer country does not match the delivery
allowed country, but such a flow is not possible as delivery shown during
cart payment are already filtered by allowed countries.
2. The delivery value returned after clicking on the carrier is correctly
updated on the badge.
Fixes#31502closesodoo/odoo#32938
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Putting *args and **kwargs confuses the function `odoo.api.split_context`.
This causes that a call to `search` via XMLRPC gets the wrong argument: takes
the first argument of ``args`` as the context.
Example which ignores the `count=True`::
```
api.call_kw(self.env['product.product'], 'search', (
[], False, False, None, True, {'lang': 'en_US'}
), {})
```
would ignore the `count=True` and use the wrong argument for context.
Issue introduced in commit 15ea753a.
Since:
`def search(self, model=None, *args, **kwargs)`
is equivalent to:
`def search(self, args, offset=0, limit=None, order=None, count=False):`
because the call to the super will anyway call the parent method, we can
change the method arguments.
note: this is only for [10.0,saas-14] where 15ea753a is.
closes#33147
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Nicolas Lempereur <nle-odoo@users.noreply.github.com>
This commit is a followup to #25854
If a custom relational field is in a view and the field it references is
in another module and this module is uninstalled, the registry will
crash.
This is not because the ORM doesn't properly cascade-delete the field,
it tries to, but since the field is in a not-to-be-deleted view, the
unlinking of the field is interrupted and an error is raised to prevent
the breakage of the view.
However, module install/upgrade/uninstall cannot be stopped by such
errors and once the registry is reloaded, it crashes because it cannot
find the referenced field.
The solution, while not ideal, is to force the deletion of the field if
we're in uninstall mode... This means that the view in question will be
broken until the field is manually removed from the view, but a broken
view can be dealt with more easily than a broken registry.
opw-1974362
closesodoo/odoo#33130
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Following the fix in 4c35983d0, it appears that the excludes and
packages options are conflicting. py2exe seems smart enough to include
jinja2 package without the explicit include via the 'package' options.
closesodoo/odoo#32991
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Prefetching it triggers its translation, which quickly becomes most of
the overhead of /jobs despite the field not being displayed on that
page: an empty /jobs takes ~150ms, a /jobs with 99 jobs takes ~2000ms,
>70% of which are spent in html_translate and ultimately
translate.py:process (14600 calls, 60% of runtime, 40% own).
Removing prefetching lowers the runtime to ~700ms.
closesodoo/odoo#32985
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Make a PO then an invoice with a product that will create an asset
cancel the invoice
Open the Assets Analysis report
Before this commit, the asset lines corresponding to the invoice
are shown
After this commit, they are not shown (only non archived assets are by default)
OPW 1974344
closesodoo/odoo#32955
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Since 78ba90d5, when building the windows package, py2exe fails to
compiles jinja2 asyncsupport module. Even tough jinja detects the
environement, py2exe tries to compile the async part. The problem comes
from the fact that async keyword was introduced in python 3 and we use
py2exe with python 2.7.
With this commit the async part of jinja is execluded from py2exe.
closesodoo/odoo#32913
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Because of c56b746221
server action "state" (what it should execute) defaults to
Update a record
This commit corrects the check printing action accordingly
OPW 1972938
closes#32928
Have a SO with a quotation template and some optional products set
Display it on the portal
On an optional product, click on the cart icon
to add it to the SO
Modify the quantity of the optional product
Before this commit, the feature was barely working:
- the total price of the optional product did not change
- negative quantities were allowed
- there was no reaction when directly putting a number in the input
- when decrementing the quantity, it crashed
- untaxed and tax amounts were not dynamic
After this commit:
- the total price of the optional product changes as a function of the quantity input
- negative quantities are not allowed
- it is not possible to manually input the quantity with a keyboard
only +/- buttons are used to change the quantity
- decrementing the quantity works
- untaxed and tax amounts are dynamic
OPW 1947769
closesodoo/odoo#32715
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
It's quite common that the `$().text()` method returns lots of random whitespaces at the beginning and end of the string. They're pretty unpredictable (extension views can add or remove them) and invisible to the end user.
This code chunk should allow to select an `<option>` based on its raw text content, but most of them will just fail without this patch. And most chances are that current ones just work equally with this patch.
This will make frontend tours more pleasant to write.
closesodoo/odoo#32791
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The depends value on picking weight and package_ids of picking are only
set on the move_line_ids, which lead to compute the value of the picking
weight only when move lines are created or deleted and not when a
package is set on a line, quantity done changed and/or unit of measure
changed.
To fix this issue, we've changed the depends, of thos computed fields.
closesodoo/odoo#33114
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
- Set the company currency in USD, activate multi-curency
- Create an invoice in EUR
- Create a payment in EUR for less than the invoice
- Open the payment matching => all amounts are in USD
- Create a write-off, reconcile
The write-off amount is incorrectly converted.
The write-off amount is sent in USD, but considered in EUR in the
server since the currency considered is the one of the line. However,
the currency in the widget is computed based on the account currency:
https://github.com/odoo/odoo/blob/b6f55dac5633d8ccb16568e0c85a5c32072e8846/addons/account/models/account_move.py#L654
Note that this is the opposite of commit 1806ea1859,
introduced in v9. Since the widget was refactored in v11, many changes
have been introduced, and we assume that this change is now justified.
opw-1907332
closesodoo/odoo#32723
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Commit d7a3f39d refactored hr views.
This broke the inheritance of the view in that module.
opw 1971570
closesodoo/odoo#32972
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
The use case is similar to 084dbf9b8f, but
applied to pickings.
When the picking contains many stock move, the manual edition of the
quantitites is quite slow due to the `onchange` call. In the example of
the OPW with 300 stock moves, the modification of the done quantity
triggers an `onchange` which lasts about 1 second.
The reason is the same than in the mentioned commit: the `onchange` is
triggered on all lines in the case of an inline tree view, and there is
not much we can do to optimize the business logic.
Therefore, the solution is the same: add a stat button to access the
stock moves directly in a tree view instead, to avoid this `onchange`.
opw-1965248
closesodoo/odoo#33004
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Create 2 invoices for a customer:
Inv 1: 100
Inv 2: 200
- Register a partial payment of 80 on Inv 1
- Select both invoices and pay the remaining amount (220)
- Print the 'Payment Receipt'
The 'Amount Paid' for Inv 1 is 100, while it should be 20.
This is because the report doesn't take into account which part of the
payment was used in the corresponding invoice.
Closes#32755
opw-1970401
closesodoo/odoo#33012
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Since commit 56645335b7
the subtype `gamification.mt_badge_granted` is not used anymore. Therefore
this method will never return anything.
However, it is very costly on performance, and it is run on every page of the
forum! The problematic performance point is that `needaction` is a computed
field, which implies all existing `mail.message` having the target subtype have
to be fetched to compute this field, which obviously does not scale well at all.
closesodoo/odoo#32861
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When displaying a video, with the browser window at a certain size, or
resizing it (or opening developer tools) we could the following error:
"ResizeObserver loop limit exceeded"
This can be reproduced in chromium just with this JS code:
window.onerror = function(e){ console.log(e); };
document.body.innerHTML = '<div><video controls src="v.webm"/>';
The issue only happen if:
- the video server does not support HTTP range requests
- the controls are displayed on the video
- browser size is in problematic size/resized to problematic size
And the error is raised in window.onerror but not displayed in the
developer console.
With this change, we ignore these errors until fixed in chromium.
chromium bug tracker: https://crbug.com/809574
backport of 12.0 535da9e (in pr #30239) since video loader was in 11.0
opw-1928512
closes#32983
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- Set a product P to average valuation, real time
- Create a PO for 1 unit @ 100, validate the picking
- Create a PO for 1 unit @ 0 (e.g. you receive a free product)
You cannot validate the picking because of the message 'The cost of P is
currently equal to 0...'
This error message is historical, to prevent users from an incorrect
configuration.
Since we still want to prevent misconfiguration, but support the
mentioned use case, we introduce an `ir._config_parameter` for people
who 'know what they are doing'.
opw-1962249
closesodoo/odoo#32550
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
closesodoo/odoo#32951
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
On the portal, in "/my/projects/x" it is possible to send messages in the
"Message and communication history" section. Those messages are attached
to the project model but it is not possible to access those messages
from the backend. The chatter on the project model is just a dummy
chatter with no message/thread capacities.
As messages are not accessible from the backend, the frontend section is
pretty useless. The section is no more present on v12 either.
opw-1970586
closesodoo/odoo#32952
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Create a new product, but don't save it just yet
give it a name,
Add some packagings
Save
Before this commit:
- the form to create the packaging had a mandatory product_id field
which is useless in a x2m context (fixed in v11.5 with a6557a2306)
- the packages disappeared after save
This was because at template creation, all "real" fields that are on
its variants must be manually set after the creation, including packaging_ids
OPW 1970589
closesodoo/odoo#32925
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The use case is a bit complicated so brace yourself:
OFFLINE
- Make an order, invoiceble with a partner
- Pay it, validate it
- An error popup is shown
=> Before this commit, the payment screen was still on
=> After this commit, the receipt screen is shown proposing to
print the invoice
ONLINE
- Make another order, non invoiceable.
- Pay it, validate it
- Both orders are now pushed to the server
=> Before this commit, it was still possible to click on "Back"
and add some products. The result of this will be that the order in DB (server)
would not have the newly added product, whereas the ticket would state that there was a new product
=> After this commit, we basically block the edition of a paid and validated order, even if the invoice
printing failed
OPW 1971028
closesodoo/odoo#32885
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
- Create 2 companies A & B
- Set the superuser in company A
- Create a POS and a user in company B
- Create a product P. The 'Inventory Valuation' must be different in
both companies:
Company A: Periodic (manual)
Company B: Perpetual (automated)
- Connect with the user in company B
- Sell the product P, select a customer and print the invoice
The COGS journal entry is not posted.
This is because `action_invoice_open` is called as `sudo()`, but
ultimately `product.valuation` is called in:
https://github.com/odoo/odoo/blob/0cce154794c8de945805d9b9acc4c33e5258191a/addons/stock_account/models/product.py#L325
`product.valuation` is computed based on the property field
`property_valuation`, which is therefore company-dependant.
Closes#32803
opw-1961861
closesodoo/odoo#32903
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The calendar should send to server:
- for an all day event (all_day field on view): the date in UTC (ie. if
we are on 22 august 2018 on UTC+2, not send 21 august 2018 22:00)
- for a datetime event not all day: the UTC datetime corresponding to
UTC (for 03:25 with UTC+5 timezone, we send 22:25 the day before)
- for a date event: the date in UTC (ie. same as all day)
The current code was alright for datetime, but there was a missing case
if the start_date was a Date field (eg. project task calendar view uses
a date_deadline Date field) and not a Datetime field.
This changeset apply the same behavior as an all_day event to a calendar
with a start date that is a Date field.
Note: the issue happen since 11.0's 03d74f4 (26th march 2019) that
solved a similar case but for datetime (a datetime event at 8:00 with
timezone UTC+9 would be moved the previous day when drag and dropped on
the month view).
opw-1969876
opw-1971106
opw-1971019
closes#32796
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Create a SO with two lines (sol_1, sol_2) selling a given service.
On the corresponding Project/Task, set the partner so that the sale_line_id
can be chosen to one of the lines.
Add an AAL with x hours, save.
This updates the delivered quantity (x) on sol_1.
Edit, change the sale_line_id to the second one:
it updates the delivered quantity on sol_2 (to x) but not on sol_1.
Has a result, the delivered quantity has been doubled.
The issue is that the quantities are only recomputed on the SOL that we write;
instead they should be recomputed on the old one and the new one.
We base ourselves on 371a92fb which solved a similar bug to add the recompute on
both lines.
opw 1959509
11.0-opw1959509-sltmsht-len
closesodoo/odoo#32820
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Fine tuning of ac31252d54
Do not pre-filter on canceled entries since they are used a few lines
below.
opw-1964459
closesodoo/odoo#32835
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
`reserved_availability` is a computed field of a move depending on its
move lines. We access this field at each iteration of the loop over the
moves to assign and then we create a new move line for it. This triggers
an invalidation of this field, The next iteration will again access this
field and prefetch it for all the next records.
We read the field out of the loop and don't access it again to prevent
these prefetch/invalidation issues.
Confirmation of a PO of ~800 lines goes from 5 minutes to 1 minute.
opw-1953398
closesodoo/odoo#32774
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
closesodoo/odoo#32805
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
goliveirab