Such move lines can be created by POS, when closing a session. Because of commit https://github.com/odoo/odoo/commit/d3453f7d152d486cb5df01b4e40dbde57f59b49e , the cash basis entries are now created *after* reconciling everything (and not during reconciliation anymore). This causes multiple lines of the move created for the sessions to be reconciled together in case a refund was made (partial or not).
Solves ticket 2008085
closesodoo/odoo#34237
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
The count sales_to_invoice_count was wrong due to the domain
wrote in function _compute_sales_to_invoice. Using 'order_line.qty_to_invoice'
in the domain included duplicate orders in the read_group on 'sale.order'
because there is auto_join=True on the field order_line.
opw:2009808
closesodoo/odoo#34391
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Make a SO with a product that have a carriage return in its
description
- Export FEC report
The CSV contains new lines and is not correctly formatted. This is due
to c712231745.
opw-2026861
closesodoo/odoo#34386
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce:
- Go to CRM > Reporting > Sales Channels
- Click on link Open Opportunities,
Bug:
It displayed all the opportunities instead of just the open opertunities.
opw:2009808
closesodoo/odoo#34365
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce:
- Enable serial numbers
- Create two products P1 and P2 tracked by lots
- Create an inventory adjustment and specify inventory of one product only
- Select P1 and create a serial number for it
- Save the adjustment and change P1 to P2, adapt the quantity to 10 and
validate the inventory adjustment
Bug:
Go to Lots and serial numbers and the created lot was linked to P1 intead of P2
opw:2010934
closesodoo/odoo#34373
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Suppose product P has UoM U with rounding R, and the stock move has quantity Q.
Edit the quantity done to be Q + e, with e << R.
By the semantic of the UoM rounding, this should mean that no change has been
done.
However no such check was done, so a message was posted in chatter, of the form:
The done move line has been corrected.
P:
Quantity : 1000.0 -> 1000.0000000000001
opw 2006831
closesodoo/odoo#34124
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Have a product P values in FIFO, create an incoming stock move.
Suppose P has UoM U with rounding R, and the stock move has quantity Q.
Edit the quantity done to be Q + e, with e << R.
By the semantic of the UoM rounding, this should mean that no change has been
done. However no such check was done, so the move was updated.
As a result, this would mess up the valuation of P.
opw 2006831
Stock.locations should be in no-update:
Limit the impact of recompute fields during the upgrade of stock module. (especially method _compute_product_availability)
Limit the impact on migration
Method _compute_product_availability is triggered during an upgrade of module and during migrations.
This may take a lot of time of big databases
closesodoo/odoo#34074
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
In the Discuss app, using Chrome or IE11, try to send the same
attachment to different channels. The first attachment is correctly
detected but not the next ones.
The problem is due to a browser inconsistency, on firefox selecting the
same file in an `<input type=file>` triggers the `change` event. This is
not the case on Chrome/IE, selecting the same file doesn't triggers an
`onchange`.
opw-2006647
closesodoo/odoo#34076
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
On `WebRequest` `__exit__`, when an exception occured,
(in `self.registry.signal_changes` or `self.registry.reset_changes`)
cursor were left unclosed as `self._cr.close` was not called
in such cases.
Having exceptions in the above mentioned method do not happen
often, but when it does it left unclosed and unusable cursors
in the connection pool, and in the extreme case explained below,
it left the connection pool with only unclosed and unusable cursors.
The entire server was then unusable as it no longer had working cursors.
Case:
- Start a multi-thread server with db_maxconn set to 5
- Ensure you do not send any request to the server,
not even with a left open tab on `http://localhost:8069` in your browser
- Send 6 parallel HTTP requests to `/web/login`
thanks to an external thread python script
(See below, at the end of this long commit message)
According to your registry state (if you have a lot of modules installed or not),
and the native Python Garbage Collecting state,
you might end with
- either warnings telling some unclosed cursor were garbage collected,
and therefore closed (by a kind of luck thanks to the Python garbage collecting),
- either, a server completely blocked not accepting any other request
(you can try for instance `curl http://localhost:8069`
and you end up with a `500 Internal Server Error`
This observed issue looks to appear only in 11.0. Not 10.0 or 12.0.
This is because only 11.0 clear the cache during registry loading:
`https://github.com/odoo/odoo/blob/f1706c848d41c47646dabca771996e9b9f788241/odoo/modules/loading.py#L236`
This cache clearing doesn't happen in 10.0 nor 12.0
(in 12.0, thanks to e181f592f3)
When sending the 6 parallel requests,
it uses instantly all the 5 available cursors of the connection pool to handle these requests,
and when each request exits, in `__exit__`, it calls `self.registry.signal_changes()`
which tries to open a new cursor because of
- `self.cache_invalidated` which is True, for all the 6 requests, thanks to the call to `clear_caches`
explained above during the registry loading and the fact all requests have been treated in parallel,
- `with closing(self.cursor()) as cr:`, `self.cursor()` attempting to use a new cursor
(the `closing(...)` does not have any incidence on this issue, despite it could look like guilty)
The attempt to use a new cursor fails, as there is no more available (`db_maxconn` is reached),
raising a `PoolError('The Connection Pool Is Full')` exception.
In the request `__exit__` method, because of this exception raised when calling `signal_changes`,
`self._cr.close` is never reached, and the parallel request therefore left only unclosed
cursors in the connection pool,
therefore leaving the server in a state where it only has unusable cursors
and therefore can't do anything more.
This might look like really bad luck to land in such a state,
but we observed multiple actual case on Odoo.sh,
the one referenced in this commit (opw-2008340) was because of an Outlook client
which launched 18 parallel requests to fetch the email images,
and the server wasn't spawned, therefore neither was the registry.
The server registry was therefore just loaded when it received the 18 parallel requests,
and it therefore triggered this extreme use case.
The server was left unusable for several minutes, until a forced restart.
For reference, here is the script that has been used to trigger the 6 parallel requests:
```
import requests
import threading
threads = []
for i in range(6):
threads.append(threading.Thread(target=lambda: requests.get('http://localhost:8069/web/login')))
for thread in threads:
thread.start()
```
opw-2008340
closesodoo/odoo#34071
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
The field is now `quantity`. This wasn't spotted before because the
method is not used anywhere.
opw-2008491
closesodoo/odoo#34067
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Installing test_new_api without demo will fail since demo_user
does not exists. This is a problem if we want to test migration
with all modules installed. This simple fix solve the problem.
closesodoo/odoo#34065
Signed-off-by: Christophe Simonis <chs@odoo.com>
Have a multi-company setup, with shared products.
Write the default code of a product; an access error is raised on inventory.line
On inventory.line, the field product_code is defined as related to
'product_id.default_code', and stored.
So when writing on the default_code of a product, we get the inventory lines of
other companies. For obvious reasons their access is protected by the record
rule "Inventory Line multi-company", therefore the access error is raised.
To avoid that situation stored related fields should be in compute_sudo.
Note that similarly this is necessary for product_name.
There is one more subtlety: directly writing on the product.product does trigger
the access error, but writing it on the product.template does not.
opw 2007167
closesodoo/odoo#34019
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
- Create a product A of type "Service", Invoice based on "Milestones",
Service Tracking "Create a task in a new project".
- Create a new SO with A, confirm.
- Go the to task associated to the SO, go to "Timesheets" tab, add an
entry
- In the SO, edit the delivered quantity
- Create invoice, validate
Back to the SO, delivered quantity is reset to 0.
We make sure to filter out SO lines which have a delivered quantity set
manually.
Introduced by d6ad22227c.
opw-1982020
closesodoo/odoo#33991
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Display extra information on error messages:
- Access error based on ACLs: user, fields (if applies)
- Access error based on record rules: user, ids
- Missing error: model, operation, user, ids
closesodoo/odoo#33942
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: jev-odoo <jev@odoo.com>
1) Add a 1st product to compare from the ecommerce /shop page.
2) Open the compare list pop up at the bottom.
3) Add a 2nd product to compare from the /shop page.
4) Remove the 1st product from the compare list before the rpc of the
2nd product is done.
5) Javascript error `self.product_data[res] is undefined`
The function `add_new_products` and `rm_from_comparelist` are
concurrent, they both modify the internal `comparelist_product_ids`
product list. The first one perform an RPC and delay the update once the
request is done, the second does the update immediately.
The solution has been to use a mutex to exclude the two functions.
opw-1974108
closesodoo/odoo#33302
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Try to get the report_pricelist with empty data
(Studio Report editor can)
Before this commit, it crashes because we tried to access dict keys directly
in an empty dict
After this commit, it doesn't crash
OPW 2009862
closesodoo/odoo#34118
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Backport of fa39019ee1.
If crop_image is called without a default format, it would try the default,
'PNG', to save the result and crash at save when processing non-PNG images.
For example, if a jpeg image was in CMYK colors.
Here it will still crash non-gracefully when failing to save, but the default
should almost always work; if it doesn't it means we failed to detect the format
of the stream, so it is unlikely that we could save the image anyway.
opw 2009029
closesodoo/odoo#34088
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Display extra information on error messages:
- Access error based on ACLs: user, fields (if applies)
- Access error based on record rules: user, ids
- Missing error: model, operation, user, ids
closesodoo/odoo#33945
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: jev-odoo <jev@odoo.com>
Before this task, when creating the related field from the studio, it is by
default stored. When we change the field name in 'ir.model.fields' using ORM's
write method, it also renames the column in the table associated with the
field's model.
This is the expected behavior. But when someone tries to change the 'name' of a
non stored field, the column is not available in the associated model, and so
trying to rename the column results into traceback. This issue was probably
there for a while but came into light with the task 1985710. More info can
be found on the chatter of the task.
This commit fixes the issue by adding an extra check before renaming the table
column. The query will be executed only when the field is stored and thus
exists in the table.
closesodoo/odoo#33944
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The content of these fields can't be updated, there's no reason to
even show them. Just remove them from the default / auto-generated
view for client actions.
Task 1772242
closesodoo/odoo#29179
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
For each asset depreciation lines we verify that there are not linked
to a move. This verification was done for each line separately.
Moreover, during the creation of the journal entries, we were writing
on the 'line_ids'. In this case, accessing the move of a line
was invalidating the cache. This fix ensure that this operation is
done out of the loop and the cache is then not invalidated at each
step.
See opw-2000305
closesodoo/odoo#33908
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Christophe Simonis