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>
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>
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>
- 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>
If the database name contains one of the tested strings, it can render
the assertion of the test invalid or inconclusive. Ensure we strip it
away during the tests.
opw: 1957055
closesodoo/odoo#31987
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this patch, the ir.logging's write_uid field was a many2one which
could cause a module install/update to hang when the module is changing
the res.users model schema and when this module causes to orm to warn
through the logger. (eg: declaring two res.users fields with the same
string attribute)
In such situation the transaction cursor that is processing the
res_users table alteration will be granted an exclusive postgresql lock
hence causing the ir_logging insertion to block because of the write_uid
foreign key to res_users.
This issue has never been raised by runbot as it is using a remote
database with --log-db
Note: the write_uid conversion from m2o to int was left over in commit e6a5d82closesodoo/odoo#32015
Signed-off-by: Christophe Simonis <chs@odoo.com>
Avoid potential tracebacks from the FSWatcher's thread being killed.
Drawback: Server shut down can have an extra small delay
(only applies when the --dev=reload option is given)
closesodoo/odoo#31855
Signed-off-by: Christophe Simonis <chs@odoo.com>
Add the alternative of inotify instead of watchdog to watch the addons
paths the server was started with.
Reason: watchdog spawns 2 threads per path to watch. When there are a
lot of addons paths, this can become too costly. With inotify we watch
all the repositories in a single thread.
https://github.com/dsoprea/PyInotify
installation:
pip install inotify
We set the default rate to be 1.0 instead of 0.0, since a rate of 0.0
doesn't make sense.
Partial backport of 298491597c
opw-1949866
closesodoo/odoo#31866
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit iteration in a t-foreach containing null or
undefined values crashed because they have no attributes.
closesodoo/odoo#31828
Signed-off-by: Fabien Meghazi <amigrave@users.noreply.github.com>
- When creating a user from the "Grant Portal Access" wizard, the code
checks for duplicate users.
It does so by checking if there is a user with the same login as the
one we want to create.
The check is case sensitive which could lead to issues.
For example a mistyped email (with a uppercase somewhere) could fail
the duplicate user check.
Since emails are not case sensitive, we want the check to be case
insensitive too.
OPW-1932918
closesodoo/odoo#31818
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
This is related to issue #31549, fixing it in 10 since it's already a
minor issue here (importing 500 partners which all have the same parent,
on my system the import time goes from 2:30 to 2:00).
This is mostly a problem for such fields as `property_product_pricelist`
(added do the commercial fields list by `product`): since we're first
getting it then writing a field it depends on (updating the address,
which contains the country), the field gets invalidated for all records
on each record being imported, so if we're importing a bunch of partners
which all have the same parent (e.g. company employees)
`property_product_pricelist` is going to be re-computed for every
partner imported so far as well as the one parent we're interested in,
for every new partner we're creating.
The problem is much more prevalent with 12.0's batched creates as we're
first creating all the new partners then doing the updates, and thus for
each new partner we're computing `property_product_pricelist` for all
new partners and the one parent we're interested in, roughly doubling
the import time of a series of partners which all have the same parent.
closesodoo/odoo#31804
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Jorge Pinna Puissant