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>
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>
`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>
Fine tuning of commit b9e3c153, for the same use-case.
The route may not be passed in values, in which case the bug is still present.
There are two ways to go around that.
We could add the stock.rule in values, which contains the route.
The solution we adopt here is to use the sale_line_id field on the purchase line
If it is present, it was added through _prepare_purchase_order_line,
and thus we want to keep track of the origin.
opw 1957701
closesodoo/odoo#32683
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Recommended by GitHub's repository alerts.
We normally stick as close as possible to the version we depend
on in the official DEB packages. This in turn depends on the version of
Debian stable at the time of release - for 10.0 that would be Debian 8
(jessie) and thus Jinja 2.7.3 (albeit with security backports).
However Jinja2 before 2.10.1 suffers from a few issues that could lead
to crashes of Odoo processes.
It seems it's worth an exception to our rule for pip users, similarly to
previous bump up at d2605bccdb.
closesodoo/odoo#32602
Signed-off-by: Christophe Simonis <chs@odoo.com>
This revision is similar to
605b94e64c
except that instead of an OperationalError
(e.g. a conccurent update),
this is an IntegrityError which is raised,
an sql constraint which is not met,
e.g. a unique or required constraint.
In the case of this opw,
this is the picking name unique constraint
which was not met,
the picking sequence number has somehow been re-used.
Both
`psycopg2.OperationalError`
and
`psycopg2.IntegrityError`
inherits from
`psycopg2.DatabaseError`
We therefore choose to use this Exception class,
to include all kind of psycopg2 exceptions that prevent
the transaction to be committed.
opw-1965679
closesodoo/odoo#32577
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
In mass mailing access to partners when performing a mass mailing has been
done in batch to speedup computation [1]. Emails are put into a dictionary
allowing to find back the email based on partner_id.
However the matching between the partner and its emails is done using a
shortcut using the current document ID as partner ID. It works when performing
a mass mailing on partners but fails when performing a mass mailing on models
having message_get_default_recipients not returning only emails. Currently
in saas-14 main models return only emails (crm, event, mailing contacts) but
other models may encounter issues (applicants, tickets).
This commit fixes it by correctly matching partner id and its found email.
[1] See 65ed4553a5
_compute_website_url can only be called on singletons
It should not be called with self but the record we are iterating on
closesodoo/odoo#32369
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
For existing installations, creating indices might not always be
possible, e.g. if you have a Text/Char field that has an index=True
set on it in a field override and pre-existing rows longer than
the pg supported size , the index creation will fail.
Instead of failing miserably during the schema modification, simply
log the problem instead and keep going.
closesodoo/odoo#32442
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When a asset is confirmed, it's not allowed to link it to an invoice.
Side effect, it recomputed the depreciation lines of the confirmed asset.
opw:1961468
closesodoo/odoo#32388
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Since 79af654fc61 if we had unexpected configuration of usage such as
being in HTTPS, having a POS hardware in HTTPS but an error is received
(eg. the device is closed) => the POS interface can't be opened being
blocked on an error:
Https connection to IoT Box failed
Make sure you are using IoT Box v18.10 or higher.
Navigate to {proxy_ip} to accept the certificate of your IoT Box.
With this changeset, we have a popup that does not prevent to open the
point of sale interface (and the red disconnected status in the top
left allow to retry connection as before) on first load.
opw-1934413
closes#32306
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- Create 2 companies A & B
- For a product P, create a supplier info for each company using the
same partner, with a different price and delay.
- Order the supplier so that the one for A has a higher priority than
the one for B.
- Create a reordering rule for P in company B.
- Run the scheduler as admin (e.g. thanks to the cron).
The price taken is the price for company A instead of B.
`_select_seller` is not company-aware, therefore the first matching
supplier is chosen.
opw-1959263
closesodoo/odoo#32328
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Google maps used to be free, but became a paid API.
Technically, the usage could be part of the free offer,
but to benefit from it the account needs to have billing enabled.
Since it's a paid feature security had to be ramped up,
so now APIs have to be explicitly enabled (here geolocating/geocoding).
All this makes it so that the Google account has to be properly configured
before the calls to the Maps API can work.
As a result we add an explicit UserError if the request fails,
to help the user configure the Google account
(before the error was entirely hidden as to give the user no chance at all).
Also exports transaltions, including for commit e6ca846c65
which raised a similar error message if no API key was found.
opw 1946485
opw 1947292
opw 1947337
closesodoo/odoo#32162
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Before this fix it is not possible to disable the 'available in pos'
filter on the Payment Journal list-view when opened from within the
pos-config.
related to internal task: #1932119closesodoo/odoo#32179
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Commit 180866fe1e introduced an error in the following
case:
- Go to Sales > Configuration > Settings
- Enable "Multiple Sales Prices per Product" and select option "Prices
computed from formulas (discounts, margins, roundings)"
- Go to Sales > Catalog / Pricelists
- Select "Public Pricelist" and set "Discount Policy: Show public price
& discount to the customer"
- Define the pricelist as based on the cost of the product with a
negative discount for a product P
- Go to the eCommerce, buy the product
The price used in the cart is the cost price instead of the cost +
negative discount.
This is because we force the discount to be zero in this case while
using the price of the product without the pricelist.
We usually don't want to show a negative discount, since it means the
client pays more than usual. However we still want to use the price
defined on the pricelist. We modify as follow: if the discount is
negative, we don't show it to the user (value = 0), but we use the unit
price with the discount included.
opw-1967870
closesodoo/odoo#32768
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Do a PO in a foreign currency
Invoice it in the same foreign currency
Validate the invoice
Before this commit, The account move of the invoice
contained a price difference line
which is wrong, since the price has not changed in any ways
After this commit, the move has only two lines
one in the stock input, one in the payable
Also, the case where the price does change
due to a change in currency rate is handled
OPW 1955315
closesodoo/odoo#32180
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
mreficent