When setting an event tracks like this:
- Track 1, 10:00 to 10:30 Room A
- Track 2, 10:30 to 11:00 Room B
- Track 3, 11:00 to 11:30 Room A

In the agenda of the event, on the website, the Track 2
was displayed as in the Room A, while it should be in the Room B

opw-715480

The former URL took way too many steps to resolve
`www.odoo.com(odoo-odoo-odoo)`, more than 1 minute
according to the case, and it stucked the web client
(the entire browser actually),
and it ended matching the whole sentence as a link,
included `(odoo-odoo-odoo)`

This new regex is much simpler, resolve the above case,
and does not match `odoo-odoo-odoo` as part of the link

opw-715797

The context is created as a set, not a dict.

opw-716141

When changing partner_id on an invoice, the fiscal positions with auto_apply=True,
must be checked to apply the right one.

To have the same behavior as in 10.0

Backport of this commit: 4b11e3e3

opw:715511

In the method `xml_node_to_string` in `qweb2.js`,
which is used when extending XML templates,
such as this extend of the template `PaymentScreen-Paymentlines`

the method `(new XMLSerializer()).serializeToString(node)`
magically escapes the double quotes `"` in Internet Explorer and Edge,
while this is not the case in other browsers,
therefore converting, for instance,
`this.removeAttr("class");`
to
`this.removeAttr(&quote;class&quote;);`
whhich made the rendering of the template fails.

As this method is quite critical, we do not dare
editing it to use an alternative to `XMLSerializer.serializeToString`
in a stable release

Instead, as a workaround, we just avoid the use of the double
quotes.

opw-708296

When procurements are created, they are automatically run. Avoid this
behavior, to run all procurements at the end of the process and used the
optimized JIT behavior.

opw-710007

To reproduce:
- Get a slow connection, e.g. activate throttling in debug mode of the
  browser.
- Create an invoice with at least one tax.
- Change a price unit.
- Click on 'Save' then repeatedly on 'Validate'

The tax lines are duplicated.

The issue comes from two identical `write` calls whose purpose is to
delete the existing tax line and create a new tax line.

The two calls are issued by the click on 'Save' and the click on
'Validate', which triggers a 'Save' since it doesn't consider the form
as being saved yet.

There were several issues:
- The buttons from the statusbar were not disabled
- The buttons were enabled too soon. They should be enabled again when
  the form is reloaded, otherwise the call to 'Validate' doesn't
  consider the form saved.

This is an extension of commit
https://github.com/odoo/odoo/commit/bbbf3db581b5cf883

opw-710642

- Create a SO with both 'service' and 'consu' products
- Depending on the order of the lines, the 'Delivered qty' might not be
  editable consistently.

This is because of an incorrect `return` statement in the
`_compute_qty_delivered_updateable` method.

opw-710561

The revision
ea9ef7c3
introduced a regression:
many2one fields having one2many depending on it declared before
the declaration of the many2one itself were not unlinked
during a module uninstall.

As a result, the column in the table was not dropped,
and the table itself was not deleted either, not even truncated.

Therefore, when you tried to reinstall the module, you had data
left.

The check of the one2many dependencies must not be performed
during an uninstall. Anyway, this wasn't blocking the uninstall
of the modules,
it was just preventing the field  to be deleted, that's all.

opw-710291

Setting the taxes in the accounting move entries
is important for the taxes report.

When a price difference occures in a purchase
with a product set in a perpetual inventory valuation,
the taxes set on the price difference move line should be the same
than the move line from which this price difference
is computed. Otherwise, the taxes report
do not have the whole purchase amount

opw-710228

When you enable the IPN notifications in your Paypal account configuration,
the default IPN URL is mandatory.

You are therefore obliged to put the IPN feedback URL of Odoo
in this default URL, even if this is not used because
each transaction done by Odoo specifies the URL to which the IPN
notifications must be sent.

Because of this, if you use your Paypal account
for something else, e.g. Ebay, you receive
notifications of payments for these other transactions,
that have nothing to do with Odoo.

In such a case, Odoo returned an HTTP error status code (e.g. 500),
because Odoo couldn't find the given transactions, and
then Paypal sent emails to the Paypal owner
to tell the IPN feedback was failing. Eventually, after
several fails, Paypal automatically disabled the IPN
notifications of the given account.

With this revision, we now avoid to raise the Validation errors
in the case of the IPN feedback, and just logs it,
to avoid Paypal to sent emails to
the owner and to automatically disable the IPN notifications
if it receives transactions from other services than Odoo.

opw-702403

This is a regression of
1cedcf6a
and a following of
9a9720ac

opw-709700

When changing of record, through the pager or the breadcrumb, the URL of the iframe
must change, as the model and id of the record is included in the URL

This wasn't done before this revision, and it could
lead to an INTERNAL SERVER ERROR in case of a deletion
followed by the loading of another record: the URL
of the iframe was still set to the former record,
and this URL crashed as the record no longer existed.

e.g.
- Create a new mass mailing, subject 1, add a random block in the content then save
- From this newly created mass mailing, Create a new mass mailing
  (directly with the create button)
  Subject 2, add a random black in the content and save
- Delete the second mass mailing
- Return in the mass mailing kanban view through the breadcrumb
- Open the mass mailing 1
- You had an internel server error, due to the fact the URL of the iframe
  was still the one of the second mass mailing.

opw-710239

If a pricelist PL1 set with the discount policy
`Show discount in the sale order` was based on another
pricelist PL2 with the same discount policy,
the discount applied by the second pricelist PL2
was set directly in the price, rather to be displayed
as a discount.

e.g.
PL 1: 10% on all products, show discount
PL 2: 15% on all prices of the PL1 pricelist, show discount

The discount displayed on the sales order should be
100 − (100 × (1−0,15) × (1−0,10)) = 23.5%

And the unit price of the product must remain the initial
price of the product, not the discounted price.

opw-709708

The rules "Channel: public: published only" and "Slide: public: published only"
must also be applied on portal user.

The portal user doesnt have to be allowed to create or write on slide.slide
records(introduced by 51be5bbf).

opw:708499

In case an exception (programming, out of memory or any other unexpected
failure), the cron_thread would crash and not recover until server restart.

Issue #15666 was an example of failure.

Courtesy of Nils Hamerlinck

If postgresql database is temporarly down, the cron thread may fail.

The cursor creation fails when trying to connect to the server which leads to
the cron thread to die (uncatched exception) and will not restart when postgres
is back.

Fixes #15666

Change the condition from
  [...] and debit != and credit != 0
to
  [...] and (debit != or credit != 0)

as at least one of debit or credit may have an unaffected value

Without this patch a past unpaid entry will not be included in the report.

Closes #15550

The separator in the debit/credit columns of the report must contains coma
instead of dots for decimal separator (fr).
All the other columns (cf SQL query) contains coma but not this one.

Inverse the currency sign of the credit column. Otherwise the credit is negative
and sum of the balance is wrong (sum credit != debit)

Closes #15550

message_post accepts only one id

CLA signature for igallart done at #15625

Closes #15625

When computing the discount in product_id_change, before the fix

discount was equal to (new_list_price - line.price_unit) / new_list_price * 100

But line.price_unit was already rounded so the discount computed was not the
discount set in the pricelist due to rounding error.

opw:709704

This commit closes #15254

Courtesy of @hugho-ad for reporting

Template "sitemap_index_xml":
    <loc><t t-esc="url_root"/>sitemap-<t t-esc="page"/>.xml</loc>
should be:
    <loc><t t-esc="url_root"/>sitemap-<t t-esc="website_id"/>-<t t-esc="page"/>.xml</loc>

The fix in python is not elegant but allow to fix without -u of website.

Check that fields using the same compute method have the same value for
parameter `compute_sudo`.

In mass mailing there is several possibilities of states when rendering
the widget with a possibly new value:

1. we are not in edition
  a. we are in same language than user language => the editor content
     can be updated
  b. we are in a different language => the content cannot be updated

2. we are in edition
  a. we are editing translation : the editor content cannot be updated
  b. we are not editing translation (editor language == en_US)
    i.   we are requesting editor update (by having magic value
         `on_change_model_and_list`) => the editor can be updated
    ii.  we are in same language than user language => the editor content
         can be updated
    iii. we are in a different language => the editor content cannot be
         updated

In summary:

- if language is the same than the user, we can update the value
- if value is magic `on_change_model_and_list` and we are not translating,
  we can update the editor

Before this commit, this worked as expected but for 2.a.ii. which if the
user language was not en_US would for example prevent editor updating.

closes #15583
closes #15414
opw-708032

inspired by a27e24c6d1

note: the fix is a fix for 9.0 and saas-11 only.

When uninstalling the module sale_margin, the view 'sale_report' was deleted
because this view was overwritten  in this module.

But the module sale still uses the 'sale_report' view so it raised an error
each time this view was required.

opw:709328