* Some accounts have wrong tax tag mapping
* Some fiscal positions don't work properly (mapping of taxes, right tax
keys, right accounts)
* Missing fiscal position "domestic partners" in order to allow
automatic selection of the right fiscal position if it is a doemstic
partner and to make it more clear for customers, otherwise they might
wonder why fiscal position field is empty for domestic partners.
* Issue with fiscal position "Geschäftspartner EU (ohne USt.-ID)" to
detect the right account, tax, tax tags if we sell to a customer / buy
from a supplier located in the EU without valid VAT-ID (for example
private people)
* Issue with fiscal position "Geschäftspartner Ausland" to detect the
right account, tax, tax tags if we sell to a customer / buy from a
supplier not located in the EU.
Closes#31389closesodoo/odoo#32673
Signed-off-by: Nicolas Martinelli (nim) <nim@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>
When creating a delivery product from the delivery carrier form.
The delivery product should not be sealable or purchasable.
opw-1958029
closesodoo/odoo#32289
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
In this way the description of the delivery method can be used on a SO
line. If the description wasn't set, the name of the delivery method
will be used.
opw-1958029
On the ticket 1961412, the custommer has more than 12 millions
of stock moves. Before this commit, the search request does
not take too much time to execute but fetching the fields on the
recordset takes a lot of time due to the 'in' in the where clause
of the associated SQL request.
This optimization permit to avoid this 'where clause' and decrease
the time to gather all the different fields. The time has been reduce
to less than one minutes where it takes approximately 20 minutes before.
closesodoo/odoo#32520
Signed-off-by: Simon Lejeune (sle) <sle@openerp.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 11.0 that would be Debian 9
(stretch) and thus Jinja 2.8 (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#32601
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>
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 commit, Odoo notifies the user of all the recurring past
events, existing before the installation of the module Calendar (old
events imported when synchronizing with Google, for instance). This
occurs only the first time a synchronization with Google is made. This
occurs because Odoo notify all the events that occurs since the last
time it notified, and the first time you install the module the date of
the last notification is empty.
Now, when the module Calendar is installed, the date of the last
notification is set by default to the current date (the date of the
installation of the module)
opw-1942443
closesodoo/odoo#32535
Signed-off-by: Nicolas Martinelli (nim) <nim@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>
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>
Christophe Simonis