People should be able to change manually the tax amounts on vendor bills, since they have to encode exactly what they receive and because the supplier may round differently than Odoo. On the other hand, in vendor bills, it's useless to try to compute a cash rounding impacting the taxes... as they should be now able to manually adapt it. So in vendor bills, the 'amount' field has to be the visible and editable one

Before this commit, links that had no target location opened in _self, which is the iframe within which they are embedded.
After this commit, thos links are now opened in _parent to simulate closer the beahavior with an actual e-mail

Closes #19849

After convertion python2 to python3, the arg0 was send as dict instead
of one string. We prefer to keep the same behaviour that previously.

This reverts partially commit ab2283ef.

This commit clean and clarify some code.
It also secure the call to specific page extension's template to avoid somehow
calling unexisting tempalte

It's not possible to click on the show details button if the picking is
not saved. It's a limitation of the webclient. This commit introduces a
waring telling the user to save the form view first.

warehouse basic user see all the sales app.

I did not hide the main menu only because when we customize, we can use
such menu for other purposes we just set the proper group on all first
level menus and then by default the app is hidden if a custom module add
a menu there without explicit groups then this will be shown again (which I
think is the expected behaviour).

Closes #19816

Before this commit, two variables were used to store the current
position in a list view: currentCol and currentRow. This made it
difficult to handle incremental moves (eg: tab, shift+tab) inside a
row, since we have to ignore all buttons. Previously, this was done by
converting 'currentCol' to 'currentFieldIndex', but the conversion
between the two variables was incorrect and does not appear to be
that easy to fix. As an example, it was not possible to TAB-navigate to
the last column of the components list when creating a BoM.

This commit removes all mentions of 'currentCol' and uses
'currentFieldIndex' instead, removing the need for conversions. The TAB
navigation code is simpler as a result, and should now be correct.

Since pricelist have been added in POS, the price was not correctly set
in the scale screen.

We also reduced the ferquency we call the posbox to get the scale weight,
because we requested it every 150ms, and the posbox requests only every
500 ms to the scale

Wrong condition implemented in rev[1] and it was not possible to add a
stock move in a ready picking anymore in the classic view.

[1] f359ca05

Main snippets can be dropped in `.oe_structure` elements and
`[data-oe-type=html]` elements. The second case happens when adding
a field in a page thanks to `t-field`. If used on a <p/> element,
the content cannot contain snippets (as browsers will not allow <div/>
and <section/> in a <p/>).

Note: we should not use <p/> with HTML fields at all but this might
happen with old databases... or by mistake. The problem is that the
problem is not visible during development without this fix.

This commit fix 596e88f0 , using a better bg-color in order to improve
text readability. It apply also apply a minor padding-left to avoid
having text attached to the coloured div border.
Moreover, the bg-colour can not be applied to activities thread.

The little history behind: remove the bg-color was decided by fp and
the UX dep. I’m not aware if 596e88f0 is approved or not, but the final
result was not acceptable.

This commit will restore the chatter entries UX defined for v11
and accidentally removed on 7a91d876.

In v11 unread systray chat entries have white bg and bold text. Entries
that have been read, instead, should be less emphasised with
light grey bg and normal font weight

This commit will restore the chatter App icon design defined for v11
and accidentally removed on 7a91d876.

Apps icons should NOT have a circular shape in order to keep branding
consistency.

It is not possible to work directly on the operation tab
when the detailed operation tab is available. On detailed
operations page it is now impossible to add a new move line
when the picking is done and locked.

This commit add some condition in the view and add a check
in the move line creation. If the move line has a picking but
no move then we create it (mark as done directly)

[FIX] account, base_setup, crm, event, google_calendar, hr, hr_attendance, hr_expense, hr_payroll, hr_recruitment, l10n_be_hr_payroll_fleet, mass_mailing, mrp, project, purchase, sale, stock, website: rename the actions leading to settings to "settings", for breadcrumbs

Before that, the breadcrumb used the name of the action called to access the settings view, which sometimes did no correspond with the settings tab that was actually used.

base.pot includes the description of all modules, including enterprise modules

The group is in base, this is where the group should be described.
Manage your "own stuff" is probably not very informative anyway.

This commit fine tune the appearance of the show detials icon as well as
the editability of the quantity done directly through the move line.

- if no product is selected, don't allow to fill quantity done
- if the selected product requires the show details icon, don't allow to
  fill quantity done and directly display it

Avoid error during pad creation

TypeError: cannot use a string pattern on a bytes-like object

The scheduler cron will now only call `run_scheduler`. We refactore this
method to extract `_run_scheduler_tasks` and place a call to
`_merge_quant` a the end.

We override `_run_scheduler_tasks` in stock_account to run the fifo
vacuum when the scheduler cron is executed.

The sum is already used in views for
   <field name="foo" sum="Total" />

Where "Total" is translatable and extracted in source terms export.

The progress bar kanban widget expect a field name (untranslatable).

Avoid to translate a field name by changing the attribute

Observed via google sync, for some events being moved around during
sync the stop_datetime ends up being before the start_datetime failing
the sync. Not (explicitly) reading the computed fields from the old
record properly recomputes them during copy.

Underlying issue linked to (stored) computed fields when multiple
fields are computed by the same method *and* the creation provides a
subset of these fields explicitly: depending on the order in
which *recompute* iterates the fields, it's possible that some of the
fields provided explicitly get extracted (from the cache) before
fields not-provided trigger a recomputation (and overwrite) of
computed fields.

In this case `recompute` iterates [start_datetime, start_date,
stop_date, stop_datetime], if `start_datetime` and `stop_datetime` are
provided explicitly to create, first recompute will check for
`start_datetime`, find it in the cache and extract it, then it checks
for `start_date`, does not find it in the cache, calls
`_compute_dates` which writes all four fields, then it extracts the
recomputed `start_datetime`, creating an incoherence: `start_datetime`
is the one from the old event while `stop_datetime` is the one from
the update/computation. This may lead to invisible corruption if the
event is moved forwards (e.g. creates a multi-day event) and triggers
a validation error if the event is moved backwards (stop_datetime is
now before start_datetime).

ping @rco-odoo multi-field computes may need some special handling
with respect to invalidations & sequencing & the like (e.g. check
their caching as a unit or something).

OPW-771886