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>
Steps to reproduce the bug:
- Create a consumable or storable final product A with invoicing policy
in "delivered quantity"
- Create two storable products B and C
- Create a BOM kit for A with 1 B and 1 C
- Create a SO with 5 qty of A and confirm it
- Deliver 3 B and 2 C and either on "No backorder" or "With backorder"
Bug:
The delivered_qty on the SO line is of course not automatically updated
(as in this case, a right value is not computable) but the delivered_qty
was not updatable manually and then it was possible to invoice the SO.
Co-authored-by: nim-odoo <nim@odoo.com>
DO NOT FORWARD-PORT
opw:1966170
closesodoo/odoo#32583
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
When a user register a payment for multiple invoices,
the communication field is populated using all invoices.
However the payment should use the communication individually for each invoice.
This is a behaviour closer to what is done in 74b6f84cc8 for v12.
opw 1954887
closesodoo/odoo#32143
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Commit 1be873d removed the modification of the reference field
from the _onchange_origin.
The reasoning was that since this is an onchange on invoice_line_ids, it was
applied too often, which annoyed users in the case they overwrote that field.
However when using the "Autocomplete" field (purchase_id),
then the user expects values to by modified.
Before, it worked by setting the origin field, which trickled down
to the reference.
Since that commit removed this, we re-add it explicitly in that case.
opw 1962364
closesodoo/odoo#32656
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
The field `order_mail_template`'s purpose is to provide a shortcut to
help the configuration. When `website_quote` is installed, it points to
a template which is actually never used anywhere.
opw-1961866
closesodoo/odoo#32543
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
To comply with Mexican laws, this l10n_mx_edi should always be installed when
both l10n_mx and the accounting modules are installed.
It should ease the onboarding process a bit too.
opw-1960982
closes#32566
Signed-off-by: Christophe Simonis <chs@odoo.com>
Before this fix there was no check if there was already a decimal point
in the value when using the onscreen keypad.
Fixes#32034
Steps to reproduce:
* Open up POS interface
* Add an item
* Press the decimal point button multiple times (2 or more)
* Note that pressing additional number keys do not display
* Backspace must be pressed for the number of digits entered,
plus the multiple decimal points, to clear
all the hidden characters in the value buffer
* Same behavior occurs with the Discount and Price
values
Current behavior:
Multiple decimal point characters can be
"entered" and are inserted into value buffer
(Qty, Disc, or Price), but do not display on
screen.
Additional digits entered after multiple decimal
point presses are inserted into buffer, but do
not display on screen.
Additional digits entered after the last valid
digit on the screen are also inserted into the
buffer.
Backspace must be used to remove the invisible
characters from the value buffer.
Expected behavior:
The value buffer for Qty, Disc, or Price should
more closely match what is displayed on the
screen.
Characters which are invalid and aren't
displayed on the screen, should not be inserted
into the value buffer, including the decimal
point button.
closesodoo/odoo#32089
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
In fullcalendar, we have in f5b7ad80f fake moments date with UTC time
that are the local time, thus when we move an event to another day, we
need to set it as:
- the selected year-month-day
- the original utc hours (real local hours) -> local hours
- the original utc minutes (real local minutes) -> local minutes
- the original utc seconds (real local seconds) -> local seconds
When it is sent to server, timezone offset will be removed so we will
transfer to server the expected datetime in UTC.
With this changeset we send server the correct time when a fullcalendar
event is "all_day" but the original event was not (eg. drag and dropping
event on the month view).
Added test without change failed with:
- 4. event moved to 27th nov 16h00 +40 hours timezone
(expected "2016-11-29 08:00:00", result: "2016-11-27 16:00:00")
- 5. expected: "event|6|11/27/2016|16:00:00"
result: "event|1|12/09/2016|08:00:00"
- 6. expected: "event|1|12/09/2016|08:00:00"
result: "event|3|12/10/2016|23:55:05"
opw-1955281
closes#32136
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
When displaying product template list in kanban mode, all the variants
of the product template are loaded but aren't used at all. This causes a
perf issue when loaded product templates have a lot of variants.
This commit removes the field `product_variant_ids` from view
`product_template_kanban_view` to avoid that perf issue.
opw 1951369
closesodoo/odoo#32048
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
closesodoo/odoo#32185
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Do not raise if data have been deleted. Since the fields are not
required, do not fallback.
opw-1959184
closesodoo/odoo#32163
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Set the 'Public Pricelist' with 'Discount Policy: Discount included
in the price'.
- Go to the shop and search the product 'iPad Retina Display'
- Add product to cart by using the quick add to cart button
The 'Add to Cart' modal show public price & discount to the customer.
Closes#31378
opw-1944362
closesodoo/odoo#32114
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
On a form view:
- we open a modal form view
- in this modal we open a modal form view
- we close that second modal
=> the modal is closed and the first one is still opened, but on mobile
we can't scroll to above or below the modal.
This is because bootstrap remove .modal-open class on body when we close
the second modal, but this class is necessary to scroll (this is not
much an issue on desktop since scroll is often not necessary).
We already had a fix that was weakened in 02a063fd73.
With this changeset, we keep .modal-open as long as a modal is opened.
Without the change, added test failed with:
10. Modal is said opened (expected: true, result: false)
opw-1948423
closes#32106
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before that, the tag set on this tag for its base amount was wrong; it caused it to be reported in the wrong section in l10n_fr_reports.
closesodoo/odoo#32103
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The editor has a tooltip editor wizard "Change media description and
tooltip", but when selecting an image there is also a tooltip:
"Double-click to edit"
added by the editor.
The combination of the two break the functionality, eg:
- if a tooltip is set with editor, then selecting the tooltip: we see
the set tooltip and not "Double-click to edit"
- if a tooltip is set with editor, then selecting the image back, then
opening the tooltip editor => the set tooltip is lost
With this changeset, we just do not show "Double-click to edit" tooltip
if there is a tooltip set on the element.
opw-1946801
closes#32482
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Have the module 'City Addresses' installed.
Open a contact, with the city field and the zip code field filled.
Before this commit, there is a display error, the city and the zip code
are bonded. This occurs because the 'City Addresses' module override all
views with the city field. In this override the city field don't had a
CSS class.
Now, the city and the zip code are display correctly.
opw-1958175
closesodoo/odoo#32455
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Before this commit, some constrains rose UserError
Which is not compliant with the api.constrains
After this commit, the constrains raise ValidationError
OPW 1949572
closesodoo/odoo#32444
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The payment token was created using the partner of the invoice,
not the one really paying the bill.
opw 1938787
closesodoo/odoo#32176
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Creating field indexes might not always be possible. For instance,
adding an index on an existing Char/Text field will fail if the column
contains values longer than 8192 bytes (PostgreSQL limit for BTrees).
Instead of failing miserably during the schema modification, simply log
the problem and continue.
closesodoo/odoo#32416
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
- Set up a stockable product for which the product category is FIFO / Perpetual
- Create a PO for this product with a unit price of 100$
- Confirm the purchase order
- Receive the item in stock
- Create a SO for this product
- Confirm the SO
- Deliver the item
- Unlock the delivery order and change the done quantity to 0
- Unlock the delivery order and change again the done quantity to a positive value
A `ZeroDivisionError` is raised.
Since `move.product_qty` is still zero, we fallback to `quantity`.
opw-1963984
closesodoo/odoo#32421
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Reintroduces 5324284f5 that was reverted because in the case of an URL
like /payment_stripe/static/src/js/stripe.js directly inside a QWeb
template, we would possibly get:
/fr_FR/payment_stripe/static/src/js/stripe.js
Which is not accepted by werkzeug SharedDataMiddleware we use to serve
static data in /{module_name}/static/ directories.
Added test without changeset failed with:
- test_process_att_no_request_lang: <AssertionError>
line: self._test_att('/en_US/', {'href': '/'})
wrong result: {'href': '/en_US/'}
- test_process_att_with_request_lang: <AssertionError>
line: self._test_att('/', {'href': '/fr_FR/'})
wrong result: {'href': '/'}
- test_process_att_matching_cdn_and_lang: <AssertionError>
line: self._test_att('/en_US/a', {'href': 'http://test.cdn/a'})
wrong result: {'href': 'http://test.cdn/en_US/a'}
- test_process_att_no_route: <AssertionError>
line: self._test_att('/my-page', {'href': '/fr_FR/my-page'})
wrong result: {'href': '/my-page'}
- test_process_att_url_crap: <IndexError: list index out of range>
line: request.httprequest.app._log_call[-1],
opw-1922051
closes#32095
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- Sell 4 units of a product in stock
- On the picking, create a scrap for 1 unit
- Validate
- In the immediate transfer wizard, validate
The scrap is reset to zero.
This is because the wizard overwrite the done quantity with the reserved
quantity (0.0).
If the move is already done, there is no reason to overwrite the
quantity.
opw-1958514
closesodoo/odoo#32410
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The jQuery selector is slightly too permissive, and therefore incorrect
elements may be matched. See opw for example.
Co-authored-by: Nicolas Martinelli <nim@odoo.com>
opw-1947698
closesodoo/odoo#32149
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Because of rev. d3453f7d15
when none of the pos order lines were reconciled,
the closing of the point of sale sessions failed
because of the tax cash basis entry generation.
There is no need to create the tax cash basis entries as nothing has been reconciled.
A known case is when the the bank journal credit account is set to a receivable account,
which has as effect to fully reconcile the payment line with its counterpart,
leaving no payment lines to reconcile with the order debit lines.
This is obviously not a correct accounting configuration,
but the point of sale validation did no fail because of this previously.
Fixes#32330closesodoo/odoo#32399
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
Often an invoice with the same amount is send to the same customer every week/month. If the customer pays just the amount, without any matching invoice information, common practice is to take the oldest invoice first.
Odoo currently suggests the invoice with the highest due date.
After the fix Odoo will suggest the invoice with the lowest due date.
closesodoo/odoo#32334
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This reverts commit 5324284f56
This reverts commit ad826f56ba.
If for example we had in a template:
<script type="text/javascript" src="/payment_stripe/static/src/js/stripe.js"></script>
it has been reproduced to be gotten as:
<script type="text/javascript" src="/de_DE/payment_stripe/static/src/js/stripe.js"></script>
which is unexpected and could cause an error.
closes#32090
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Nans Lefebvre