The div that is replaced with the existing.attachments template was not
the right target and kept nesting div into each other.
The parent div of the existing.attachments now has the
o_we_existing_attachments class (the target to be replaced by itself).
Part of #33983
Traceback appeared due to incorrect syntax in expression.AND. The function
was called with separate arguments instead of array of arguments.
Task-2017568
closesodoo/odoo#34216
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The first occurence of the set was wrongly place on the date field
instead on the recordset
Task: 2024628
closesodoo/odoo#34230
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
When instantiating a new record, the commands of an x2many field apply
on an empty recordset instead of the field's default value. This is
less bug-prone, and avoids an infinite recursion in `convert_to_cache`.
When the model has several x2many fields which are non-disjoint, the web
client sometimes invokes `onchange` with inconsistent data: a line
appearing in two x2many fields with different values for a subfield.
The method must deal with that inconsistency and return correct data to
the client.
[IMP] account: make all tax report lines accessible in every company
The former implementation, with a record rule, did not support the new multicompany implementation. Furthermore, making the tax reports accessible by every company whatever their contries is more consistent with the way other accounting reports work.
closesodoo/odoo#34154
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before this commit, share a slide was done with a small picture and so ugly
closesodoo/odoo#34133
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Since 0477bdb75a
The last use of `create_from_tmpl` was removed therefore it is better to not
change the context for no reason.
closesodoo/odoo#34107
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
You are not able to install pos_sale because of a wrong reference to a
model in the action "pos_session_action_from_crm_team".
It was referencing the module 'crm' instead of 'sales_team'.
Thi behavior has been introduced in the revision: 10f1a1a0c4closesodoo/odoo#34119
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
It seems that Google Spreadsheet only recognizes `true` and `false` as
valid boolean values.
opw-2000623
closesodoo/odoo#34100
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Create a project visible to a portal customer, create a task and attach
an attachment. As a portal user, go to the task and download the
attachment, the downloaded filename is the numeric identifier of the
document instead of the document filename.
The `?download=true` force the download of the attachment and correctly
set the filename.
opw-2008517
closesodoo/odoo#34098
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Let a database with company C1, C2,
and a website W belonging to C1, used for both companies.
Settings in C2 cannot be saved without setting a website.
At settings load W is removed from C2 because it belongs to C1.
So reset C2's website to W.
This triggers a (useless) write of company_id (C1.id) on W.
Then we have w.user_id.company_id.id != self.env.user.company_id.id, (C1 != C2).
So if contacts are not shared, then accessing w.user_id.company_id would cause
an access error because of record rules, preventing the save.
As a result, settings are unusable for company C2.
opw 2008887
closesodoo/odoo#34102
Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>
The 'predictive lead scoring' task (#1925439) changed the way stages are marked as 'won'.
This introduced a bug in the 'Won' filter of the crm 'Activites' reporting view.
This commit correctly applies the domain on the 'is_won' property of the crm.stage.
Task #2009515closesodoo/odoo#34087
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
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>
When full composer is opened it checks for partner information by calling
get_partner_info controller, if information are missing then it opens missing
partner information popup to fill missing partner information,
currently if partner information is missing and if try to open full composer it
throws traceback, this is due to commit:
https://github.com/odoo/odoo/commit/957c99abd53b42fa82903ad7ad03300797a706cf
here this._rpc is used in inner function which is wrong, it should be self._rpc
Scenario: we go to an opportunity and set the email but
we do not set a customer, and then when we open the chat composer
by sending a message, we're getting the traceback.
It will be fixed in this commit.
task-2005890
closesodoo/odoo#34084
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Task 2003965
*** New menuitems for the accounting menu:
Miscellaneous
Journal Entries (default search on misc op journal, like in v12)
Journal Items (debug mode, same as V12)
Journals (=journal items)
Sales (group by entry, filter sales journal)
Purchase (group by entry, filter purchase journal)
Bank & Cash (group by entry, filter bank,cash journal)
Miscellaneous (group by entry, filter misc journal)
Ledgers (=journal items)
General Ledger (group by account)
Partner Ledger (group by partner)
Taxes (no group by)
*** Expand group by by default
*** Adapt the name of the groups for group by moves
*** Fold the attachment viewer
*** Correct the optional tree fields on invoices
closesodoo/odoo#34083
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.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>
fja-odoo