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>
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>
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>
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>
Before this commit, it was impossible to eval the domain if context_today was
used in domain.
closesodoo/odoo#34031
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
When the channel has a linked forum, the "Review" link on the forum should redirect the user
to the "Review" tab on the course page.
Task #2003222closesodoo/odoo#33786
Signed-off-by: Jérome Maes (jem) <jem@openerp.com>
This commit improves the footer image of the slides home page by adding
the top 3 users avatars (ordered by karm desc) in the image.
We only fetch users that have an image set as avatar.
Task #2003222
Co-authored-by: @stefanorigano <sri@odoo.com>
- On the HR module, the field `parent_id` is added on `res.users`.
The issue here, is that `res.users` inherits the fields from
`res.partner` where `parent_id` is already defined.
This causes issues when trying to read the parent `res.partner`.
Issue found by @rrahir
closesodoo/odoo#34059
Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>
From now, the color option 2 ('Mixed color & B/W') is not available anymore. So set the option to 1 ('Color').
Task-ID: 2008913
closesodoo/odoo#34052
Signed-off-by: Pierre Rousseau (pro) <pro@odoo.com>
This tour is useless in backend.
This patch will be required in saas~12.2 as `web_editor.base` (used in
the tour) is only available in frontend.
closesodoo/odoo#34041
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
- Create a mailing campaign
- Create a mailing 1, set the subject to "Test 1"
- Create a mailing 2, set the subject to "Test 2"
The subject of mailing 1 is set to "Test 2".
When checking the code, this behavior seems the one expected. The
`_rec_name` of a mass mailing is the `subject_id`:
https://github.com/odoo/odoo/blob/7ef4ba03c4f8dce42f5a56b64d2374373d13aa8d/addons/mass_mailing/models/mass_mailing.py#L437
Moreover, there is an onchange to set the subject in line with the
subject of the campaign:
https://github.com/odoo/odoo/blob/7ef4ba03c4f8dce42f5a56b64d2374373d13aa8d/addons/mass_mailing/models/mass_mailing.py#L608
However this behavior is not present up to v11, and only appears in v12.
Surprisingly, this is due to an unrelated improvement which adds the
field in the view (in debug mode): 5b0bcaef3e.
Up to v11, the onchange exists, but since the fields are not in the
view, it has no effect. However, in v12 the fields are in the view so
the onchange has an effect.
Since this was the behavior up to v11, and that the behavior is fixed
in f50fbc6d16, we keep it consistent in v12 as
well.
opw-2007764
closesodoo/odoo#34028
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Have a translation linked to a record unreadable because of a record rule
(e.g. a product that is not shared between companies).
Display the translations list view; if one such translation is in the view,
it will raise an access error.
When computing the source value, _compute_source will fail to read the record,
and raise an access error.
This will make it impossible to access untranslated terms.
Instead we guard this error.
Since it is displayed in the view, we display an informative message.
Note that since we make this error go away, we also fix the check method.
Only the superuser bypasses the record rules; so if we made the check on write
with _is_admin, it means than a user in group_erp_manager cannot read a record
but can edit its translations.
opw 2000817
closesodoo/odoo#33989
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Christophe Simonis