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>
Since 1594f82 a user can no longer checkin/checkout if not
in kiosk mode (warning "Wrong Pin").
The mentionned commit revealed a previous mistake: the pin was
never checked if `None` was provided because superuser does not have
group `hr_attendance.group_hr_attendance_use_pin`.
Pin checking should work as follows:
- For the logged in user: he should be able to checkin/checkout
without his pin through the "My attendances" action and with his pin
in kiosk mode
- For other employees: they should only be able to checkin/checkout with
their pin through kiosk mode.
The opportunity is taken to make method `attendance_action_change` private.
closesodoo/odoo#34058
Signed-off-by: Romain Libert (rli) <rli@odoo.com>
Since the use of the polib module in commit 632fa04, the Byte Order
Mark at the beginning of a po file is causing a traceback.
As stated on https://en.wikipedia.org/wiki/Byte_order_mark, the UTF-8
BOM (0xEF, 0xBB, 0xBF) may interfere with software that does not expect
non-ascii bytes at the start of a file, as it seems to be the case with
polib.
As the l10n_* modules are black-listed on the runbot, the traceback only
appeared in the lightly l10nall test.
closesodoo/odoo#34003
Signed-off-by: Christophe Monniez (moc) <moc@odoo.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>
If the option 'Reload from attachment' is checked for a report, it will be generated from the existing attachments.
However, for snailmail, we have to force the re-rendering to apply specific css rules to match the layout of a A4 letter.
Task-ID: 2008896
closesodoo/odoo#34053
Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>
To reproduce:
- Go on the website page of a product with optional products.
- Disable the Select Quantity customize show.
- Click add to cart.
This will open the optional product modal, where the quantity will be displayed.
However changing that quantity will have no effect, especially the price will
not update accordingly.
The real issue is that the quantity should not be displayed there if Select
Quantity is disabled, but this has never worked before, so this is outside the
scope of this fix.
Anyway, since the quantity is present there, we would at least expect it to
correctly recompute the price, which worked fine when the modal was introduced,
but has been broken since 51e51055bf
opw-2005317
closesodoo/odoo#33992
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Set an analytic account on an employee contract
- Set credit and debit accounts on the salary rules
- Create a payslip, confirm
The journal items created do not use the analytic account set on the
contract.
If no analytic account is set on the salary rule, we fall back on the
contract account.
opw-2006090
closesodoo/odoo#34095
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>
It seems to be a better solution to keep starting tests without being in debug
mode to avoid having new fields and menus appearing.
This commit simply drop the debug mode in test mode and retrieve the test
assets by checking if test mode is enabled directly.
closesodoo/odoo#34012
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The purpose of this modification is to add the route buy on the
component of the desk combination. So it's more easy to setup a
production order that trigger multiple purchase order.
closesodoo/odoo#34021
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This merge replaces the stage based probability on leads by a new Predictive Lead scoring mechanism based on Naive Bayes Probability computation theorem.
Probability are now computed automatically based on past experience (already lost and won leads)
and based on multiple criteria (field values on leads). The user is still able to set a probability on a lead manually, or come back to a automated probability, both via the lead form.
A cron runs every day to rebuild the frequency table and to recompute all the active pending leads.
See sub commits for more details.
Special thanks to @awa-odoo who did his job. Quite well indeed!
Special thanks to @tbe-odoo who helped me for testing and performance optimisation.
Task ID : 1925439
NOTE : This task must be followed by task ID 2008365 : Remove old lead scoring system
closesodoo/odoo#33589
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Christophe Simonis