The only purpose of the module `test_documentation_examples` is to test
a few of the code examples shown in the developer documentation.

As 6709e1a9794 removes the documentation sources from the repository,
the test module is removed as well.

DOC PR: https://github.com/odoo/documentation-user/pull/945



task-2352371

closes odoo/odoo#70174

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Co-authored-by: Victor Feyens <vfe@odoo.com>
Co-authored-by: Antoine Vandevenne <anv@odoo.com>

In odoo/documentation-user#945, the developer documentation is merged
with the user documentation in a single repository and build config.

This commit then removes source files for the developer documentation
from the odoo/odoo repository.

DOC PR: https://github.com/odoo/documentation-user/pull/945



task-2351938
task-2352371
task-2205684
task-2352544

Co-authored-by: Victor Feyens <vfe@odoo.com>
Co-authored-by: Antoine Vandevenne <anv@odoo.com>

We moved the function compute_all in 13.0, but didn't let it
retrocompatbile for external modules.

closes odoo/odoo#70327

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

In 13.0 and above, when looking at a quiz that was completed while not published, it would incorrectly show 2 XP awarded, when 0 XP should be awarded.
With this commit, we show instead the correct 0 XP awarded.
opw-2480343

closes odoo/odoo#70253

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

When adding a product to a repair order, the module automatically adds
all product's taxes, even if some taxes belong to other companies.

To reproduce the error
(Need 2 companies C01 and C02. Let C01 be the current company)
1. Create a product P
    - Must have a tax T_C01
2. Switch to C02
3. Edit P
    - Add a tax T_C02
4. Activate C01
5. Create a Repair Order
    - Add a customer
    - Add a line with product P

Error: Both T_C01 and T_C02 are added. However, since C02 is the current
company, T_C01 should not be added.

(Similar issue possible with `repair.fee`)

OPW-2486791
closes #68079

closes odoo/odoo#69975

Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>

What are the steps to reproduce your issue ?

    1. Go to helpdesk/configuration/stages
    2. Add rating email template to Solved
    3. Change state of a ticket to Solved
    4. Go to Technical/messages and open the sent message

What is currently happening ?

    The template is not displayed correctly

opw-2476485

closes odoo/odoo#70294

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

In eg. 13.0 when refreshing sales analysis action of a product, we would
get an error because we have a single active_ids which is not expected
by the code.

With this commit, we use .toString() on the jQuery BBQ parsed active_ids
as it was done before 32b8cec5 refactoring (january 2018).

The added test with the fix fails with an error:

  TypeError: state.active_ids.split is not a function
  at Class.loadState (/web/static/src/js/chrome/action_manager_act_window.js)

opw-2471982

closes odoo/odoo#70226

X-original-commit: a8c731092b7aa95bca46f56f6c069e1c1a8a2292
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Nicolas Lempereur <nle@odoo.com>

Before this commit, the routing map generated and used would be the one from
the website the request is performed, instead of the one from the `fw` website
ID which will be the one we redirect the user to.

This issue was introduced with the routing map by website, be8fc229 and is
restricted to a single case: a publisher using the website switcher, and it
won't happen on next page naviguation/refresh as the `fw` website id will be
the same as the current website's ID. Thus there won't be any routing map
mismatch.

Step to reproduce:
  - Create a page on website 2, set it as homepage
  - Naviguate to website 1 on '/' url
  - Naviguate to website 2 on '/' url
This will raise a werkzeug error about `EndPoint not iterable`.

----- Technical analysis ------

This is the current flow:
1. `_dispatch()` is setting `website_routing` to `get_current_website()` -> 2
2. `_dispatch()` is calling `_match()`
3. `_match()` is calling `routing_map()` with key = `website_routing`, which
   was set to 2 in step 1.
4. `routing_map()` is calling `_generate_routing_rules()` which generate the
   rules based on `website_routing`, which was set to 2 in step 1.
5. `_dispatch()` authenticate the user by calling `_authenticate()`
6. `_dispatch()` is calling `_add_dispatch_parameter()`, where URL param `fw`
   is forced in session, so `get_current_website()` now return the correct
   `website_id` -> 1

The issue: in order to handle the `fw` URL parameter (step 6.), we need to
check the rights to ensure we can allow the website switch.
To check rights, user need to be authenticated (step 5.), which is done after
generating the routing map (2. & 3. & 4.).
The routing map is generated based on the current website (step 1.)

Step 6 depends of steps 5 which depends of steps 2/3/4 which depend of step 1,
but step 1 should depend of step 6, which is an impossible cycle.

closes odoo/odoo#69416

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

Issue

	- Install 'Survey' app
	- Enable "es_VE" language and activate on main website
	- Create a survey:
	- Add a question of type 'Date' then save
	- Click on "TEST" button
	- Start survey and add a date with the datepicker
	- Submit survey

	Error message / traceback.

Cause

	The date format is wrong because since locale params
	only after page survey widget is loaded.

Solution

	Use 'session.load_translations()' to load translation.

opw-2452237

closes odoo/odoo#69507

Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>

This "depends context" was missing fields and the compute of the stock qty's were not correct in several cases.
We add the same as the fields "force_company".

closes odoo/odoo#68046

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

When selling a tracked product that comes from a specific place in the
warehouse, the module will ignore this information and set the parent
warehouse as source location.

To reproduce the error:
(Use demo data)
1. In Settings, enable "Multi-Warehouses"
2. Create a product P:
    - Product Type: Storable Product
    - Available in Pos: True
    - Tracking: By Unique Serial Number
3. Update its quantity:
    - Location: WH/Stock/Shelf 1
    - Serial Number: USN01
    - Qty: 1
4. Start a POS session
5. Sell P
    - Enter the same serial number
6. Go back to quantity update page for product P

Error: The quantity for "WH/Stock/Shelf 1, USN01" is still 1, it should
be 0. Moreover, a new line appeared: "WH/Stock, USN01, -1" which is
incorrect. The POS module considered that the product sold came from
WH/Stock instead of WH/Stock/Shelf 1.

OPW-2473002

closes odoo/odoo#70165

X-original-commit: dd62f84e
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

Make translation work for "Visitor" that was appearing in livechat
session to the visitor.

opw-2504461

closes odoo/odoo#70139

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

While a listen backlog of 1 isn't needed, removing the entire listen
call was too much, because accept needs it to be there.

closes odoo/odoo#70120

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

Make translation works for "Website Visitor" that was appearing when a
logged-out user open a livechat session.

note: list comprehension has to be removed since translation only search
language in direct calling method closure.

opw-2504461

closes odoo/odoo#69439

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

Give a coherent group as otherwise we could have access errors. Simple
case: an Admin Rights user goes into a mail message form which is only
available in debug mode which sets `group.no_one` into such user. This
model is only readeable by `base.group_sytem` so an AccessError will
raise.

closes odoo/odoo#70102

X-original-commit: 8930e082
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

Before the tests were using data from the demo data. Now the data used for the test are declared before the test starts.

closes odoo/odoo#61631

Related: odoo/enterprise#14705
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

This fix displays the price with tax included on the product screen and not only on the order.

When changing the product price precision, this can lead to incorrect
stock valuations.

To reproduce the error:
(Enable debug mode)
1. Go to Settings > Technical > Database Strucutre > Decimal Accuracy
2. Edit Product Price:
    - Digits: 4
3. Create a Product Category PC:
    - Costing Method: FIFO
4. Create a Product P:
    - Product Type: Storable Product
    - Product Category: PC
5. Create a RfQ with product P:
    - Quantity: 1000
    - Unit Price: 0.035
6. Confirm Order, Receive Products, Validate
7. Click on Valuation

Error: The total value is equal to $40 instead of $35. The calculation
was done after rounding the unit price: $0.035 becomes $0.04, then
1000*0.04=$40.

When confirming the RfQ, a stock move is created. To do so, the method
`_get_stock_move_price_unit` is called. When validating the delivery, it
recomputes the unit price thanks to method `_get_price_unit`. In both
situation, and if the line has taxes, the method `compute_all` is called
like this:
```python
price_unit = line.taxes_id.with_context(round=False).compute_all(price_unit,
	currency=line.order_id.currency_id, quantity=1.0)['total_void']
```
But here is the problem. In this method, total amount is computed with
this line:
```python
base = currency.round(price_unit * quantity)
```
However, `quantity` is equal to 1 and the multiplication is rounded
using the currency precision. As a result, `base` is equal to $0.04.
Then, all computations will use this value and will be incorrect.

This fix applies the real quantity so `base` will have the correct
value:
```
base = currency.round(price_unit * quantity)
     = currency.round(0.035 * 1000)
     = 35
```

OPW-2472192

closes odoo/odoo#69297

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

This can happen if the terminal had a power reset, or a network cable
was unplugged temporarily on the terminal or IoT box. It will try to
reconnect, but the box wasn't aware the first connection was gone and
would ignore the second connection. So the terminal was waiting for
a response on the second connection and the IoT box was waiting for
data on the first connection resulting in a deadlock.

This solution closes the first connection and replaces it with the
second.

opw-2432864

closes odoo/odoo#65456

Related: odoo/enterprise#16099
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

Now we try to open a socket every 3 secondes
It generate some issue for connection of Ingenico
Terminal.

Now we open a socket in the initialization of the socket
interface and listen all devices that send request to
Iot.

opw-2432864

Steps to reproduce the bug:

- Let's consider a project P set with analytic account AA and company C
- Allow timesheet on P
- Let's consider a task T belonging to P
- Set AA with comapny = False
- Try to encode a timesheet on T

Bug:

A UserError was raised because the field company_id on account.analytic.line is required

opw:2486034

closes odoo/odoo#69841

Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

The changed test uses the drag&drop helper, and an operation does
not work as expected with the given params on chrome 90. The runbot
currently uses chrome 80, so it is not an issue, but if your chrome
is up-to-date, and you try to run the test suite, this test would
fail.

closes odoo/odoo#69999

X-original-commit: 43994da9980e4133274984f720bb58f3546ea0f9
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

When the user submits a form, a lead will be created but the language
won't be the one selected by the user.

To reproduce the error:
(Enable debug mode)
1. Settings > Translations > Languages
2. Activate another language L_other
3. On website, add a form:
    - Action: Create an Opportunity
4. Add an existing field: "Language"
5. Submit the form
    - Language must be L_other
6. Consult the new lead

Error: The language is not the selected one.

OPW-2486276

closes odoo/odoo#69941

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

Before this update if you would update the module the default livechat details would be reset.
By wrapping it in a no-update they're not updated with a module update.

closes odoo/odoo#69961

Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

This commit allows the `form_builder_send` widget to be reused.
Moreover, the creation of `post_form` allows other modules to specify
how post the form to the server

(Linked to OPW-2473001)

closes odoo/odoo#69401

Related: odoo/enterprise#17757
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

uuid should be unique even after copying

closes odoo/odoo#65319

Related: odoo/enterprise#16052
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

These changes have been made to be able to add some behaviors in some specific points of the flow when overridden.

Steps to reproduce the bug :
- Create a French company
- Go to accounting settings > in “Fiscal Localization” install French accounting
- Install “l10n_ch_qriban”
- Go to contacts > Configuration > Bank accounts
- Create a new bank account > add a French company newly created in the “Account Holder” field

Problem:
The specific fields to a Swiss company appear.

Solution :
Check if the country of the company encoded in the “Account Holder” field is Switzerland.

opw-2504699

closes odoo/odoo#69813

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

The media modal's document tab has cells with icons and filenames. If
the filename was too long, it would overflow its cell, which caused an
ugly design glitch. This ensures an ellipsis on the filename when it is
too long.

closes odoo/odoo#69893

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

Suppose Google Calendar synced with Odoo. When the user updates a
recurrent event on Google, syncing with Odoo may cancel the change.

To reproduce the error:
(Need google_calendar)
1. [On Google Calendar] Create a recurrent event
2. Sync with Google Calendar
3. [On Google Calendar] Move one of the recurrent events
    - Its date must be different
4. Sync with Google Calendar

Error: The updated event didn't move. On Google Calendar, the event has
moved to its initial date.

At some point, when updating a recurrent event that has moved, the
method `detach_recurring_event` is called. This method is in charge of
getting all data before creating the moved event. However, to get all
data, it first calls the `read` method and then adds some other
information:
https://github.com/odoo/odoo/blob/acaca80f0ce544d1c9a738a5aac992a8ac9c75b2/addons/calendar/models/calendar.py#L1409-L1420


And here is the problem. The method `read` provides additional
information, such as `start_datetime` and `stop_datetime`. However,
theses fields are computed based on the *calendar_id* of the event. Such
an identifier is like `<ID>-<Date>` where *Date* is the initial date of
the event. Therefore, `start`, `stop`, `start_datetime`, ... will be
incorrect.
Back to `detach_recurring_event`, `data` will be updated with some other
values and with `values`. Hopefully, since the latter contains the new
start and stop dates, `start` and `stop` will be overwrote with correct
values (i.e., dates of the moved event). However, `start_datetime` and
`stop_datetime` are still present and incorrect.
Therefore, because of the presence of these two variables, the method
`_inverse_dates` is triggered on creation of the new event. This one
recomputes `start` and `stop` based on `start_datetime` and
`stop_datetime`, but theses fields are incorrect (they are equal to
intial start and stop dates). This is the reason why (1) the updated
event didn't move and thus (2) on Google Calendar, the event has moved
back to its initial date.
This fix suggests to remove several fields from `read` method, because
some undesirable behaviors may happen. Moreover, since these fields are
computable, it's easy to get their (correct) value.

OPW-2474721

closes odoo/odoo#69150

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

This revision solves two things:
 - On installation of `l10n_latam_base`,
   `l10n_latam_base` is set as default as `l10n_latam_identification_type_id`
   for all partners in the database.
   The ORM method `write` was used to do so.
   With a database having a large number of partners,
   such as multiple hundred of thousands,
   this leaded to performance issues when `l10n_latam_base`
   got installed.
   I checked compute methods that could depends on this field,
   and the only one I found is `_compute_l10n_ar_vat`,
   which is not yet `installed/loaded` when this posthook takes place,
   as it's in the module `l10n_ar` which depends on `l10n_latam_base`
   and therefore is loaded after. So, it was already not executed/computed
   when using the ORM `write` method before this revision.
   Therefore, the use of plain SQL can be used to speed up the performance.
 - Also, the ORM `write` triggered unexpected compute fields
   which could raise exceptions, because of the `commercial_partner_id`
   synchronization.
   For instance:
```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line 1198, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 89, in new
    odoo.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 455, in load_modules
    loaded_modules, update_module, models_to_check)
  File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 348, in load_marked_modules
    perform_checks=perform_checks, models_to_check=models_to_check
  File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 239, in load_module_graph
    getattr(py_module, post_init)(cr, registry)
  File "/home/odoo/src/odoo/14.0/addons/l10n_latam_base/__init__.py", line 8, in _set_default_identification_type
    env['res.partner'].search([]).write({'l10n_latam_identification_type_id': env.ref('l10n_latam_base.it_vat').id})
  File "/home/odoo/src/odoo/14.0/addons/base_vat/models/res_partner.py", line 538, in write
    return super(ResPartner, self).write(values)
  File "/home/odoo/src/odoo/14.0/addons/snailmail/models/res_partner.py", line 26, in write
    return super(ResPartner, self).write(vals)
  File "/home/odoo/src/odoo/14.0/addons/partner_autocomplete/models/res_partner.py", line 199, in write
    res = super(ResPartner, self).write(values)
  File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 550, in write
    partner._fields_sync(vals)
  File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 469, in _fields_sync
    self._children_sync(values)
  File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 478, in _children_sync
    self._commercial_sync_to_children()
  File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 452, in _commercial_sync_to_children
    sync_children._compute_commercial_partner()
  File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 297, in _compute_commercial_partner
    partner.commercial_partner_id = partner.parent_id.commercial_partner_id
  File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1127, in __set__
    records.write({self.name: write_value})
  File "/home/odoo/src/odoo/14.0/addons/base_vat/models/res_partner.py", line 538, in write
    return super(ResPartner, self).write(values)
  File "/home/odoo/src/odoo/14.0/addons/snailmail/models/res_partner.py", line 26, in write
    return super(ResPartner, self).write(vals)
  File "/home/odoo/src/odoo/14.0/addons/partner_autocomplete/models/res_partner.py", line 199, in write
    res = super(ResPartner, self).write(values)
  File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 546, in write
    result = result and super(Partner, self).write(vals)
  File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_activity.py", line 766, in write
    return super(MailActivityMixin, self).write(vals)
  File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_thread.py", line 322, in write
    result = super(MailThread, self).write(values)
  File "/home/odoo/src/odoo/14.0/addons/website/models/mixins.py", line 182, in write
    return super(WebsitePublishedMixin, self).write(values)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 3640, in write
    self.modified(relational_names, before=True)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5786, in modified
    tocompute = list(tocompute)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5862, in _modified_triggers
    yield from records._modified_triggers(val)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5858, in _modified_triggers
    records |= model.search([(key.name, 'in', real_records.ids)], order='id')
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 1708, in search
    res = self._search(args, offset=offset, limit=limit, order=order, count=count)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4492, in _search
    self._flush_search(args, order=order)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4470, in _flush_search
    self.env[model_name].flush(field_names)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5442, in flush
    self.recompute(fnames, records=records)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5908, in recompute
    process(field)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 5879, in process
    field.recompute(recs)
  File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1145, in recompute
    self.compute_value(record)
  File "/home/odoo/src/odoo/14.0/odoo/fields.py", line 1175, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/14.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
    return super()._compute_field_value(field)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 4068, in _compute_field_value
    self.filtered('id')._validate_fields(fnames)
  File "/home/odoo/src/odoo/14.0/odoo/models.py", line 1260, in _validate_fields
    check(self)
  File "/home/odoo/src/odoo/14.0/addons/sale_project/models/project.py", line 70, in _check_sale_line_type
    product_id=task.sale_line_id.product_id.display_name,
odoo.exceptions.ValidationError: You cannot link the order item SO/2019/11374 - [COMOD2H] Servicio de Correctivo dos Horas to this task because it is a re-invoiced expense.
```
upg-11324

closes odoo/odoo#69869

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

A computed field on event may crash if current user is a portal user as it
tries to access registrations to know if current user is already participating
to the event.

We also fix ACL on the registrations as most code already use it as sudo and
do not access it directly. Only the event users or admins should access it
directly.

Task ID-2322411
PR odoo/odoo#

closes odoo/odoo#69928

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

Purpose
=======

When creating an attendee from frontend some fields may be added in
parameters, notably through inheritance (questions, ...). We want the
defaults values to have the priority on those parameters (e.g. barcode code).

Task ID-2322411
PR odoo/odoo#

Steps to reproduce the bug:

- Try to export mail.message records

Bug:

A traceback was raised

Wrong forward-port of 69b27ac3

opw:2514584

closes odoo/odoo#69839

Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

Description of the issue/feature this PR addresses:
_compute_quantities calls _compute_quantities_dict which calls _get_domain_locations, this last function depends also on 'location' and 'warehouse' from context, so also this variables should be put in the depends_context decorator

Current behavior before PR:
product.qty_available and product.with_context(location=x).qty_available return the same value also if the product in stored in more than one location
Desired behavior after PR is merged:
product.with_context(location=x).qty_available should return the quantity available only in location x

This has been already fixed in 14.0.
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

closes odoo/odoo#69874

Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>

Before this commit, we would compare a lang `code` (used in context) and a lang
`url_code`. For languages where those 2 are differents, the `if` condition
would always be falsy, making the canonical URL impossible to be reached.

Technically, this condition is used to get the translated name of records to
later construct the canonical URL.

Since the canonical URL will be incorrect and unreachable, the whole system to
tell search engine/crawler about translation won't work since no
`alternate/hreflang`[1] will be set in the DOM.

[1] see https://developers.google.com/search/docs/advanced/crawling/localized-versions



--------

Technical explanation:
- italian language `code` = `it_IT`, `url_code` = `it`
- belgian french language `code` = `fr_BE`, `url_code` = `fr_BE`
Install those languages on website as secondary languages.
Translate blog `Travel` to `Voyager` in french and `Viaggi` in italian.
Visiting `/fr_BE/blog/travel-1/post/post-1` will redirect to
`/fr_BE/blog/voyager-1/post/post-1` as it should, and the canonical URL will be
set to that same URL.
Visiting `/it/blog/travel-1/post/post-1` will redirect to
`/it/blog/voyager-1/post/post-1` as it should, but the canonical URL will be
set to `/it/blog/travel-1/post/post-1`.

opw-2486918

closes odoo/odoo#69503

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

closes odoo/odoo#69681

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

When retreiving the list of badge owners in `_get_owners_info()`,
we should apply `res.users` ir rules to be sure to respect multi-company
rules.

upg-7081

closes odoo/odoo#69357

Signed-off-by: Christophe Simonis <chs@odoo.com>

- Create an invoice with an empty fiscal position
- Create a line with a product having 100.0 as sale price and 21.0% price-included tax
=> price_unit equals 99.99

This is because 100 / 1.21 ~= 82.64 but 82.64 * 1.21 ~= 99.99 != 100.0.
The bug only appears when managing a fiscal position because the code is trying to adapt the product price_unit to the newly computed taxes.

closes odoo/odoo#69522

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