This commit adds the name of the currently viewed slide
to the breadcrumbs at the top of the page

Task ID: 1999672
PR: #33635

closes odoo/odoo#34137

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

- Set a payment provider with:
'Save Cards': 'Always'
'Payment Flow': 'Redirection to the acquirer website'
- Process an order on the eCommerce

The payment token is not saved.

The `save_token` value is based on the checkbox which is only added in
'ask' mode:

https://github.com/odoo/odoo/blob/4b8f72eb2315e675ca6d5a0d0961272fc024c475/addons/payment/static/src/js/payment_form.js#L162



We hide and pre-check the checkbox in this case.

opw-2008441
opw-2008275

closes odoo/odoo#34106

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

It seems that Google Spreadsheet only recognizes `true` and `false` as
valid boolean values.

opw-2000623

closes odoo/odoo#34100

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Oversight of previous forward-port.

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

closes odoo/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

closes odoo/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

closes odoo/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

closes odoo/odoo#34076

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Slightly increase margins between questions in a test.

closes odoo/odoo#34055

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.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 e181f592)

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

closes odoo/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

closes odoo/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

closes odoo/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 51e51055

opw-2005317

closes odoo/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

closes odoo/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.

closes odoo/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

closes odoo/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.

closes odoo/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 #2003222

closes odoo/odoo#33786

Signed-off-by: Jérome Maes (jem) <jem@openerp.com>

This commit improves the karma rank layout displayed on the courses home page
and on the user profile.

Task #2003222

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

closes odoo/odoo#34059

Signed-off-by: Toufik Benjaa (tbe) <tbe@odoo.com>

Oversight of previous forward-port.

From now, the color option 2 ('Mixed color & B/W') is not available anymore. So set the option to 1 ('Color').

Task-ID: 2008913

closes odoo/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.

closes odoo/odoo#34041

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

This allow error to have a predictable message. Forbid some tests to
fail randomly.

Oversight of previous forward-port.

- 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): 5b0bcaef.

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 f50fbc6d, we keep it consistent in v12 as
well.

opw-2007764

closes odoo/odoo#34028

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>