The XML-RPC interface has a compatibility shim for binaries as
historically Odoo has returned "binary" data as base64 strings. To
avoid breakages during the Python 3 transition, the shim was
introduced to decode the output binary data (under the assumption that
it'd be ASCII-compatible).

In the case where the data is *not* ascii-compatible, however, it can
generate invalid XML documents: "C0" control codes (with the exception
of tab, LF, and CR) are not valid in XML 1.0 (which XML-RPC is an
application of), however they're perfectly valid string characters and
the standard library's marshaller does not check for them, embedding
them directly in the output document and breaking the client's
decoding.

Work around the issue by replacing such binary data with an empty
string.

While at it, move the bytes shim to the customized marshaller, this
way everything's at the same place and it's not necessary to waste
time trying to understand why the marshaller is just not calling what
it's supposed to call.

Fixes #61919

closes odoo/odoo#74699

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Currently, if a test fails there's very high chances the DOM will not
be clean, because qunit doesn't have good cleanup APIs. This means a
test failure will always be prefixed by a dump of the page DOM which
is just confusing and makes it hard to find the actual error.

This change updates the OdooAfterTestHook handler to:

* Receive the `Test` itself, instead of adding more information to the
  synthetic object it currently receives.
* Only show the leftover DOM if the test otherwise succeeded.
* Do the entire reporting via `pushFailure`, rather than having
  duplication between an explicit `console.error` and a test failure.
* Update the QUnit.log handler to
  - not show `undefined`
  - try to improve readability by removing the bracketing and quoting

closes odoo/odoo#75939

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

On my system in chrome 92 there are issues of chrome's hitboxes (and
rounding) being off leading to tests failures, something which given
the adjustment in `triggerMouseEvent` had been an issue in the past.

The first test failure was / is in the "correctly display year view"
calendar test, where the very first event dialog would fail to open
when clicking on the `2016-11-16`.

After tracing through fullcalendar, it turned out fullcalendar was
told to hit `2016-11-*09*`, suspiciously 7 days before the cell we
were looking for in a monthly calendar, hinting to an incorrect
vertical offset / hitbox.

Fix by offsetting the top coordinate in `triggerMouseEvent`, but
rather than just increment by one update the entire thing by trigger
the event right in the middle of the element being targeted, that
seems more reliable long-term, though it could be slightly confusing
for events like mouseenter/mouseover/...

The second issue was with a list test, where two cells are supposed to
be sized equally. Apparently the offset sizes are supposed to be the
rounded version of the actual size (which can be fractional), but
dumping the information of `foo` and `text` I'd get real widths (via
getBoundingClientRect) of respectively 480.46875 and 480.5, and
offsetWidths of 481 and 480 (the smaller of the two in "real size"
is rounded higher than the other one).

In Python we might use `assertAlmostEqual` for this, but we've
apparently not introduced this in JS take the real width and round up
by hand, this fixes the issue as both end up at 481.

Aside 1:

Before finding out the actual root cause I landed in
`_onYearDateClick` with missing data in the events so looked at the
API to figure what I was looking at, and turns out fullcalendar's
event object has documented properties to get the date-converted start
and end bounds of the event, so use that directly instead of doing the
same thing by hand.

Aside 2:

The attributes passed to `triggerEvent` in `triggerMouseEvent` are
pretty much nonsensical, we're getting the element's location using
`getBoundingClientRect` which is based off of the viewport, but
setting the keys

* `screen(X|Y)`, which should be the location of the hit relative to
  *the physical screen*
* `page(X|Y)`, which should be the location of the hit relative to the
  page / document (so takes in account the content scrolled off-screen)
* `layer(X|Y)`, which is the position of the hit relative to the
  nearest positioned (non-static) element, falling back to page if
  there isn't one

The one attribute which matches the semantics / reference of
`getBoundingClientRect` we didn't even set, instead it would be
automatically copied from `pageX`/`pageY` by the events mapping.

Fix that by just providing `clientX`/`clientY` and updating the
mapping functions to not overwrite it.

If the others are needed they should be computed properly based on the
document's bounding client rect and scroll information, as well as the
window's screenX/screenY (and offsetParent for layerX/layerY though
that seems unlikely to be necessary).

closes odoo/odoo#75900

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Problem 1 steps to reproduce the bug:
- Install `l10n_cl`
- Create a new company
    - Choose for example Algeria in country.
    - Enter this VAT number: CL220604497
- Save
- edit
- Change the country to Chile

problem:
VAT number is not formatted according to the Chilean VAT formatting,
Because in the write function we do not trigger the VAT formatting when the country changes

Bug introduced in this commit: https://github.com/odoo/odoo/commit/11ec94df926db98265d26af1072a0c8bf1843083

Problem 2, steps to reproduce the bug:
When you install `l10n_cl`, a Chilean company is created with these demo data: https://github.com/odoo/odoo/blob/7cc252908b33b7d77d45d0630464e203b25b09dc/addons/l10n_cl/demo/demo_company.x15ml#L

- The VAT is formatted according to the standard formatting instead of the Chilean vat formatting,
Because the field `" l10n_latam_identification_type_id "` is not defined: https://github.com/odoo/odoo/blob/f3a66dd65d041ffc7367d85d5603e9627efb9f2b/addons/l10n_cl/models/res_partner.py#L33-L34

so we will have this result: CL220604497 instead of 22060449-7

- create a vendor bill with this company
- try to print it
- a traceback is triggered, because we call the `_format_dotted_vat_cl` function which divides the vat in two parts
based on the dash and then processes the result without checking that there are two elements in the result.
As in our case here. The vat has no dash in the middle, so we will only have one part
an error is triggered when the function tries to access the 2nd element

https://github.com/odoo/odoo/blob/2b500c12c2540e593f3a243bf80de28bd335b7be/addons/l10n_cl/views/report_invoice.xml#L53



opw-2630877

closes odoo/odoo#75581

Signed-off-by: Josse Colpaert <jco@openerp.com>

Github release: https://github.com/odoo/owl/releases/tag/v1.4.4



Release notes:

- fix: overlapping multi-class in t-att-class

closes odoo/odoo#75922

Signed-off-by: Samuel Degueldre <sdegueldre@users.noreply.github.com>

Currently, during the slide tour, while adding 'Section' from the
website, the modal is opened, and the tour/bubble for this step is
added at the bottom of the input which introduces a vertical scrollbar
to this simple modal which looks ugly.

This commit removes this step (and thus bubble for input), and simply
provides a placeholder for this input.

And, for the section modal next step ('Save' button), we simply improve
the wordings of the message, which now asks the user to pick
a name for the section first.

The same issue also happens while uploading new 'Content' from the
website, and so to avoid scrollbar here, this commit also adds little
bottom margin for the anchor (so that there's enough space for tour
bubble).

Task-2616529

closes odoo/odoo#74816

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

On payment creation, when changing twice the payment's journal, if the
first journal already has some lines and the second one doesn't have any
lines, the payment name will be incorrect.

To reproduce the error:
1. (If present, delete all payments)
2. Create and save a payment P01:
    - Journal: Bank
3. Create a second payment P02 (do not save it):
    - Journal: Bank
4. Change P02's payment: Cash
5. Change P02's payment: Bank
6. Save P02

Error: The name of P02 is "CSH1/2021/08/0001", which would be correct if
it was a Cash payment. This error has a consequence: suppose the user
creates a third payment (journal: Bank) and confirms it, its name will
be "CSH1/2021/08/0002" (again, name linked to the incorrect journal)

On step 4, when changing the journal to Cash, since the latter hasn't
any payment, the server returns a new name ("CSH1/2021/08/0001"). Then,
on step 5, when changing back the journal to "Bank", since the latter
already has a payment (P01) and since the current record already has a
name ("CSH1/2021/08/0001"), the server doesn't change it and the
`onchange` response doesn't contain anything. As a result, when saving
the payment from the client side, the wrong name is included in the data
("CSH1/2021/08/0001"). Regarding the consequence: later, when creating
and confirming a third payment, the server will take the name of the
previous one in the same journal and will increment it
("CSH1/2021/08/0002").

OPW-2601668

closes odoo/odoo#75504

Signed-off-by: William André (wan) <wan@odoo.com>

When a sale.order containing a slide.channel registration product is confirmed
by a person that does not have rights on slide.channel (typically a salesman),
the system will throw an error.

This commit forces the addition of members by using a sudo on the
"_action_add_members" method.

We assume that when confirming a sale.order, we want to add the members and
enable their access to the course even if the person confirming the sale.order
does not have e-learning privileges.

OPW-2580128

closes odoo/odoo#75872

X-original-commit: ecac935d
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>

Without this, the warning isn't very actionable.

closes odoo/odoo#75847

X-original-commit: afe7c989
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Wolfgang Taferner <wtaferner@users.noreply.github.com>

This fixes a bug about alignment, which shifted the mega menu with the
narrow size by 50%. This bug was triggered in multiple headers:
- sidebar
- hamburger
- magazine

task-2502208

closes odoo/odoo#75597

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

During the refactor of the comparison feature, the pie_chart widget was forgotten
(commit: be5a51a3)
Before this commit, the pie_chart widget did not support timeRanges any longer

After this commit it does again.

closes odoo/odoo#75335

Related: odoo/enterprise#20551
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>

Before this commit, when loading a view containing a searchbar on a
tablet, the device's keyboard is appearing once the searchbar's field is
autofocused.

Thanks to the backport of the mobile OS detection (see PR
odoo/odoo#75455 ), we are now able to properly target mobile OS
(independent of the screen's resolution) instead of only small screens.

closes odoo/odoo#75800

X-original-commit: 5370d22d
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>

The `letterRendering` option from the html2canvas broke the receipt's characters of some localizations/languages such as the arabic one.

With this commit, we can simply override the `htmlToImgLetterRendering()` method from the `PosModel` when needed.

closes odoo/odoo#75797

X-original-commit: 60493275
Related: odoo/enterprise#20531
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

When combining two pricelists, the unit price might be incorrect

To reproduce the error:
1. In Settings, enable:
    - Pricelists (Advanced)
    - Discounts
2. Create a product P:
    - Sales Price: $100
    - Available on website
3. Edit the Public Pricelist:
    - Add a price rule:
        - Apply On product P
        - Min. Quantity: SuperProduct
        - Compute Price: Percentage
        - Percentage Price: 63%
    - Discount Policy: Included in the price
4. Create a second pricelist:
    - Add a price rule:
        - Apply on product P
        - Compute Price: Formula
        - Based on: Other Pricelist
        - Other Pricelist: Public Pricelist
        - Price Discount: 25%
    - E-commerce Promotional Code: PROMO
    - Discount Policy: Show public price & discount
5. On the website, add P to the cart
6. Edit the cart:
    - P's quantity: 500
    - Apply PROMO code

Error: The new price is $75 instead of $27.75

`_website_product_id_change` already returns the correct price value, so
the latter shouldn't be computed again (moreover,
`_fix_tax_included_price_company` should use the price with the pricelists
applied instead of the default product price)

OPW-2605804

closes odoo/odoo#75371

Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

*: website_slides

A function allowing to convert a SVG to a PNG has been added as an
utility function in website.utils and is used for the upload of document
in website_slides. This function add support for a specific case which
was not supported by the previous conversion function used for the
document upload in website_slides: SVG without width and height
attributes on Firefox.

Note: this should be simplified in master, the fix here is done the most
stable way possible.

Related to task-2602521

closes odoo/odoo#75805

X-original-commit: 7a305704
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>

Since we added a z-index: 0, on the wrapwrap, the modals are under the
main navbar and therefore partly hidden by the height of this navbar.

After this commit, the top position of a modal is the height of the
main menu navbar but only if that navbar is displayed. The height of
the modals is also reduced with the height of the navigation bar to
avoid overflowing at the bottom.

Some of what this commit did had already been merged in saas-14.2
(in this PR: #69360) but we realized that we also needed this fix in
v14.

task-2501400

closes odoo/odoo#70116

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Bug
===
The arguments model and res_id were declared on the method but never
used. This method was supposed to be callable from the model and not
from the records with those 2 parameters.

Make this possible.

Task-2599676

closes odoo/odoo#75771

X-original-commit: 07dbd96b
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

- Install delivery and active 'Addresses in Sales Orders' options
- Create a delivery allowed only in France
- Create a partner with two delivery address, one in France, an other in Belgium
- Create SO, select the delivery address in France
- Select the carrier
--> Change the delivery address in Belgium in the partner_shipping_id field,
recompute_delivery_price stay False.

This PR fix this issue, now the delivery is invalidate if you update the field
partner_shipping_id.

closes odoo/odoo#73981

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

Side effect of https://github.com/odoo/odoo/commit/69cc2911b52fd17b37fb71544574f63cf09dd17e

.

On a lead, there is a smart button allowing to see his page views on the website.
In case we have many views, we are grouping them by page. Currently, the check on
the pages is made through field page_ids which is restricted to Website Editor
access group. We should allow a regular salesman to see page views without error,
and this can be achived by using field website_track_ids.page_id instead.

closes odoo/odoo#75685

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

If for any reason the initial linked question of one possible answer was
changed and if one existing survey has already been answered using that
possibility, we currently got an Internal Server Error while we should
simply just ignore these answers when getting the statistics of that
survey.

closes odoo/odoo#75491

Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>

Issue: When reversing an invoice of timesheet and selecting a time
period, there is an user error saying there is nothing to invoice

Steps to reproduce :
 1) Create a SO with a timesheetable service
 2) Deliver some hours
 3) Invoice them
 4) Confirm the invoice, then add credit note, confirm
 5) Invoice the same hours again (the sales order indeed says 0 hours
 invoiced)
 -> There is nothing to invoice

Why is that a bug:
 When creating the invoice in `sale_make_invoice_advance`, if there is
 a period selected, we are going to search with a domain to only count
 the quantity that have not been invoiced, this is done by checking that
 either the invoice_line_ids are not set, or that they are cancelled
 but when reversing an invoice, the state is posted, so we need a better
 domain to take that in consideration

opw-2525655

closes odoo/odoo#75431

Signed-off-by: LTU-Odoo <IT-Ideas@users.noreply.github.com>

Steps to repodruce:

  - Install 'Accounting' module
  - Set user language to French
  - Create journal entry
  - Set a date before 2000. Example : 01/01/1999
  - Insert some journal items
  - Save the journal entry

Issue:

  Error message is raised :
  ```The journal entry cannot be saved : "The Date (01/01/1999) doesn't match the Numéro (OPD/1999/01/0001).```

Cause:

  Incomplete regex: parsing only years who begin with 20 or 21.
  https://github.com/odoo/odoo/commit/26a43f23ec2b2490aec0731e25568703729581f0#diff-67b6f8b23970c1b18fc5e7f82b7585ad82e7bace885cdd78274837a4876a6a9fL24-R25



Solution:

  Add 19 to regex to allow years like '19XX'.

opw-2616575

closes odoo/odoo#74881

Signed-off-by: William André (wan) <wan@odoo.com>

The parent method _get_computed_account in the account module it already forces
the company to get the correct account, but in the stock_account module the method
is overriden when dealing with anglo-saxon accounting. In the latter, the company
is not being forced, so it leads to multi-company errors.

The fix simply enforces the correct company to prevent the error.

closes odoo/odoo#70865

X-original-commit: 56421dbc
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

This fixes the forward port of #75624 that became incorrect at #75697
because of the assertEqual -> assertEquals conflict resolution.

closes odoo/odoo#75733

Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

This revision has a similar goal than the previous revision
62c5b8d9
but this times, it's a kit/phantom bom which is nested in another
kit/phantom bom, and their computation is asked in the same time.

```
2021-08-20 11:29:54,835 1689 ERROR db_22687 odoo.upgrade.stock.tests.test_on_hand_quantity: FAIL: TestOnHandQuantityUnchanged.test_check
Traceback (most recent call last):
  File "/tmp/tmpv3ujv2vr/migrations/testing.py", line 208, in test_check
    self.check(value)
  File "/tmp/tmpv3ujv2vr/migrations/stock/tests/test_on_hand_quantity.py", line 20, in check
    self.assertEqual(before_results, self.convert_check(after_results), self.message)
AssertionError: Lists differ: [[551[14585 chars] [8988, '137'], [8989, '137'], [8990, '20'], [[1793 chars]91']] != [[551[14585 chars] [8989, '137'], [8990, '20'], [8991, '126'], [[1778 chars]91']]

First differing element 1007:
[8988, '137']
[8989, '137'
```

```
SELECT b.id, b.type,  p.id as kit_product_id, b.product_tmpl_id as kit_product_tmpl_id, pt.name as
kit_product_name FROM mrp_bom b JOIN product_template pt ON pt.id = b.product_tmpl_id JOIN product_product p ON p.pr
oduct_tmpl_id = pt.id WHERE p.id = 8988;
-[ RECORD 1 ]-------+-----------------
id                  | 2208
type                | phantom
kit_product_id      | 8988
kit_product_tmpl_id | 9049
kit_product_name    | KIT Poulie AR G4
```

```
SELECT b.id, p.id as kit_product_id, b.product_tmpl_id as kit_product_tmpl_id, pt.name as kit_product_name, l.product_id as component_product_id, component_t.name as component_name FROM mrp_bom_line l JOIN mrp_bom b ON l.bom_id = b.id JOIN product_product p ON p.product_tmpl_id = b.product_tmpl_id JOIN product_template pt ON pt.id = b.product_tmpl_id JOIN product_product component ON component.id = l.product_id JOIN product_template component_t ON component_t.id = component.product_tmpl_id WHERE l.product_id = 8988;
-[ RECORD 1 ]--------+---------------------
id                   | 2213
kit_product_id       | 8761
kit_product_tmpl_id  | 8879
kit_product_name     | VEL BP KIT direction
component_product_id | 8988
component_name       | KIT Poulie AR G4
```

upg-22687

closes odoo/odoo#75723

X-original-commit: c2df3d43
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

Steps to reproduce the problem:
- Connect as admin
- Create a new employee, e.g: “Employee1” for company “My Company (San Francisco)”
- Create a new time off request for this employee, and select a time off type linked to the company "San Francisco"
- create a user and do not give him access to the company “San Francisco”, e.g: “user1”
- Log in as “user1”
- Go to time off > Managers > Allocations > remove default filter

Problem:
user1 is able to see the time off allocation of “Employee1”, even though he does not have access to My Company San Francisco.

Solution:
Add multi-company rules  for the “hr.leave_allocation” model to display only the time off allocations to which the current user has access

A rule has already been added for "hr.leave" model:
https://github.com/odoo/odoo/blob/0f3281e3b1dc943b81d79d2a8f82fca7b95b8186/addons/hr_holidays/security/hr_holidays_security.xml#L65-L70



opw-2535709

closes odoo/odoo#75211

closes odoo/odoo#75689

X-original-commit: a6f95184
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>

Issue: When receiving a mail on a alias for a job position, the
application is created correctly in the right stage but the e-mail
template for that stage is not sent to the applicant

Steps to reproduce :
 1) Set an alias and a external mail server
 2) Configure incoming mail server
 3) Create a job position with a mail alias and a email template
 4) Receive a mail for that job position
 5) The application is created but no mail is sent to the applicant

Why is that a bug:
 When we create an application manually the mail is sent to the
 applicant but when creating it via e-mail reception, it's not sent
 even though it should. This is due to stage_id missing from the flow
 when receiving an e-mail

opw-2533310

closes odoo/odoo#75520

Signed-off-by: Nathan Marotte <nmarotte@users.noreply.github.com>

After 0411dda6
the associated test fail in certain time frame due to the datetime check

closes odoo/odoo#75697

X-original-commit: 55fac5d3
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

Strap yourself in, we're in for a ride:

The module sale_stock_margin overrides
`SaleOrderLine._compute_purchase_price` and adds some extra dependencies,
the key dependency here is 'move_ids'.

The field `move_ids` is defined in sale_stock's override of
sale.order.line, however sale_stock is **not** a dependency of
sale_stock_margin, but since they implicitly share the same dependencies
and are both `auto_install=True` it is impossible to install
sale_stock_margin without having sale_stock be automatically installed.

However, since sale_stock_margin does not **explicitly** depend on
sale_stock, if one were to uninstall sale_stock without uninstalling
sale_stock_margin first, the registry would crash because
sale_stock_margin's override of `_compute_purchase_price` would depend
on a field that no longer exists (`move_ids`).

This commit fixes this in an odd way, because of the following reasons:

- We cannot change a dependency in a stable branch.
- An uninstall_hook cannot inject an uninstall dependency because the
  hook step is too late into the process (we'd need a
  pre_uninstall_hook)
- A post_install_hook could create a dependency between
  sale_stock_margin and sale_stock, however this would only apply to
  **new** installs of sale_stock_margin and the bug would persist for
  existing users

Thus the only solution left is to extend ir.module.module and override
the downstream_dependencies to inject sale_stock_margin as a sale_stock
dependant if sale_stock is one of the modules for which we're
calculating the downstream dependencies.

closes odoo/odoo#75690

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

Steps to reproduce the problem:
- Connect as admin
- Create a new employee, e.g: “Employee1” for company “My Company (San Francisco)”
- Create a new time off request for this employee, and select a time off type linked to the company "San Francisco"
- create a user and do not give him access to the company “San Francisco”, e.g: “user1”
- Log in as “user1”
- Go to time off > Managers > Allocations > remove default filter

Problem:
user1 is able to see the time off allocation of “Employee1”, even though he does not have access to My Company San Francisco.

Solution:
Add multi-company rules  for the “hr.leave_allocation” model to display only the time off allocations to which the current user has access

A rule has already been added for "hr.leave" model:
https://github.com/odoo/odoo/blob/0f3281e3b1dc943b81d79d2a8f82fca7b95b8186/addons/hr_holidays/security/hr_holidays_security.xml#L65-L70



opw-2535709

closes odoo/odoo#75211

X-original-commit: a6f95184
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>

When cloning a website_form field, we rerender the cloned field to
reassign its elements ids and for attributes with a unique ID instead of
the old ones.

Rerendering the list also removes an issue with Selection fields that
were not visible after a clone and a save, as it was usually done after
a _rerenderXML, not executed after a clone.

Also, _renderField docstring was wrong, and its return values
terminology have been replaced with correct one.

task-2485093

closes odoo/odoo#69019

Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>

Some footer and header templates, introduced in [1] were using snippet
classes without the snippet data attribute. Therefore, they were not
using the snippets versioning system.

For example, the template_footer_descriptive was using an outdated
version of the s_title snippet, when a V001 css version had already been
introduced by [2].

[1]: 34ed29cb
[2]: f34d7f4f

task-2212216

closes odoo/odoo#75594

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Before this commit if the Apply/Discard buttons of the background image
positioning overlay were drawn outside of the visible area the user was
unable to access them - and thus had to reload the editor page.

After this commit the viewport is always scrolled to the background
image positioning overlay, making it always usable.
Because the block is always scrolled into the view, the buttons can
always be positioned near the top border of the overlay.

task-2627710

closes odoo/odoo#75467

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

This commit fixes a behavior when we send a batch of mailings
with no recipients.
When there is no recipients passed down, each mailing should
use it's own recipients and not the recipients of the first mailing.

closes odoo/odoo#75642

X-original-commit: 88d74fde
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

- Create a product with a kit BOM and weight
- kit components should have list price and weight as well
- Create SO with kit product
- Add shipping (fedex int. or bpost will do)
- Delivery product

A custom's form is generated but the value of the product it is not
correct as it take the valuation of the kit in the sale order
for every component of the kit, resulting in higher customs taxes for
the final customer

opw-2628309

closes odoo/odoo#75575

Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>

Before this PR when you accessed a certification through one company and passed it, the certification pdf was under the name of another company.

opw-2577532

closes odoo/odoo#75592

Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>

Linked issue #75112. Patching commit https://github.com/odoo/odoo/commit/54b09df46fe0acf551e10070cbf6e669d340438d



closes odoo/odoo#75626

Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

When there is a connection failure (eg. server restart) while we are
polling adyen for payment status during the payment process, we would
show a connection error and when clicking on retry, we would do a new
payment even if the first one was successful causing a double payment.

After dcb1e2b4, the retry after failure should just continue the
polling as if there was no connection failure, so for example:

- order 1: pay with adyen => connection failure during payment
- order 1: retry => payment successful

But in this particular case:

- order 1: pay with adyen => connection failure during payment
- order 1: close adyen payment line and pay with another payment method
- order 2: pay with adyen => we will receive the response from order 1

With this changeset, we only continue the polling for adyen status if we
are retrying to pay the same order.

opw-2587625

closes odoo/odoo#75246

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>