Let's have:

- on res.company a binary file field named x_file
- on res.users a related binary field to company_id.x_file, and make it readonly
- On the res.users form view, display the new field
Before this commit in create mode, upon clicking on download the file, the server crashed, because the record id was empty.
Then, the JS crashed in turn because of the unhandled 404 from the server.

Since the id of a new record will always be unset, we choose to disable the download option in this very specific case

OPW 777042

When doing a group_by in a tree view, and then ordering by an
aggregated field which contains at least one capital letter in its name,
you will get an error and won't be able to ordery by this field.

Why? read_group is called when sorting a group by, which calls
_read_group_raw which then goes to call _read_group_prepare, which will
return order by terms in this manner ['id asc', 'x_Test desc']
the problem with this is that postgres automatically converts
non-quoted/non-qualified column name to lowercase, of course this means
that if we have a field "x_Test" but no field "x_test", it will try to
look up "x_test" instead of "x_Test" and since the column doesn't exist,
it will throw a ProgrammingError.

This commit changes this behavior by wrapping the order_by terms generated in
_read_group_prepare with double quotes, which postgres interprets
correctly.

Fixes #21348

Cherry-Pick of c338e24e as previous
forward-port has been badly done...

When updating the quantity of an MO, the qty we are producing on a work
order should possibly be updated.  When the finished product is tracked
by serial number it should be 1.0 when some quantity is still to be
treated.  (and not 0 as before)

opw-785190

commit 2f3b469d fixes a problem
where open balance had to be added in the lines to create,
however in the case where no line is selected, a new one is created automatically
(for usability purpose) and the balance was not update correctly,
resulting in the creation of a double entry.

When doing a group_by in a tree view, and then ordering by an
aggregated field which contains at least one capital letter in its name,
you will get an error and won't be able to ordery by this field.

Why? read_group is called when sorting a group by, which calls
_read_group_raw which then goes to call _read_group_prepare, which will
return order by terms in this manner ['id asc', 'x_Test desc']
the problem with this is that postgres automatically converts
non-quoted/non-qualified column name to lowercase, of course this means
that if we have a field "x_Test" but no field "x_test", it will try to
look up "x_test" instead of "x_Test" and since the column doesn't exist,
it will throw a ProgrammingError.

This commit changes this behavior by wrapping the order_by terms generated in
_read_group_prepare with double quotes, which postgres interprets
correctly.

Fixes #21348

For some reason, Summernote does not trigger a change event in some
cases.  It looks like it happens in 'codeview' mode, and when the change
in question is only a backspace key event.  Maybe it listen for keypress
and backspace do not trigger keypress event.

In any cases, the situation is that it is not easy to clear an html
field: going in edit mode, then selecting the content and pressing
backspace will not work before this commit.

With this commit, we specifically compare the value in the editor with
the current value to determine if the field is dirty.

Before this commit, when a product category had a similar name than an other
e.g. ALL / Exp and ALL / Expenses

When entering the list view of its products, it displayed the product linked to the category with the similar name
e.g. When opening ALL/Exp products list, it displayed its products **plus** the products of ALL/Expenses

After this commit the list view just contains the active category's products

OPW 782905

Before this commit, the smart button on the form of product category
only displayed the number of product for the current category,
whereas the list view of products (when you clicked on the smart button)
displayed all sub-categories products.

After this commit, the behavior is harmonized: all sub-categories products
should be accounted for and displayed

OPW 782905

Before this fix, there was an issue when you changed the value of
a datetime field by editing direclty the input (without using the
datepicker popup).
If this value was equal to the offset of your timezone,
the new value wasn't saved. The problem was that no event was
triggered by the 'bootstrap-datetimepicker' lib because it
considered that the old datetime and the new datatime were the
same...

In odoo JS, we always manipulate UTC moment objects and we
manually add the timezone offset at rendering (we mainly do that
for testing purposes). When the offset is added, calling format()
on the moment object doesn't convert the datetime to the browser
timezone because it's flagged as being UTC.

The datepicker lib creates moment objects in the browser timezone.
So comparing the ones it creates with the one given by Odoo is
like comparing apples and oranges, and it gives wrong results
when the datetimes differ by the exact timezone offset. So in this
case, no 'datetime change' is triggered by the lib.

We could fix this by wrapping moment objects into some kind of
OdooDate class and stop manually adding the timezone offset, but
this would involve a refactoring that can only be done in master.

Instead, we prefered to patch the lib to ignore the comparison
between UTC and non-UTC objects, as this is the safest way we
find to fix this issue in stable version.

Before this commit, when editing the shipping id of a partner having a company_id,
an Error 500 was thrown because of recursive hierarchies.

On top of that, since no employees should be able to modify its company's address,
we hide the dit button in that case
BUT we display addresses type=other (the one that a child of a company has anyway)
meaning that the billing address appears also as a shipping one.

OPW 782524

Mixing positive and negative values in a pie chart is not possible.
However, in this case, a crash occurs instead of displaying an error
message.

opw-786137

Archive the associated analytic account when a project is archived. Once
a porject is archived, it is assumed that we don't want to use the
analytic account anymore.

Moreover, it might be tempting for a user to delete these "useless"
analytic accounts, and therefore it would delete the archived projects
and tasks without notification.

Closes #21224
opw-784685

Let's have:
- on res.company a binary file field named x_file
- on res.users a related binary field to company_id.x_file, and make it readonly
On the res.users form view, display the new field

Before this commit in create mode, upon clicking on download the file, the server crashed, because the record id was empty.
Then, the JS crashed in turn because of the unhandled 404 from the server.

Since the id of a new record will always be unset, we choose to disable the download event in this very specific case

OPW 777042

/!\ This commit *must* be "forced" forward-ported /!\

Recent commit(s) broke existing databases making website videos
disappear / not be saved / ...

Original code was broken then fixed by a succession of commits which
solved some errors to create new ones. Hopefully, this one is the right
stable one. Existing databases should be restored while allowing new
videos to be added correctly no matter the version. In master, a solution
must be found to smoothly migrate old videos to a new better system.

See:
https://github.com/odoo/odoo/commit/8749410b1033ddec1207ce1db42d1889a0d2ea33
https://github.com/odoo/odoo/commit/45e0cd564afdae71e9525193250744e88076da71
https://github.com/odoo/odoo/commit/6d2bf44fee76a8b73ebad206cd7a283c88b6c4ef (opw-783233)

opw-786165

Closes #21387

default_get expects ids, not recordset (e.g. called by webclient)

Closes #21358

Purpose
=======

Currently the wage reduced by a superior amount of 20 holidays is not taken into account in the brut2net computation.

Specifiation
============

Take also the wage deduction into account

Log In and Sign Up was not translatable

Closes #21333

Before this commit, it was not possible to save a page
containing a snippet with a SVG tag.

To support SVG elements, we need to use 'Element.getAttribute'
and 'Element.setAttribute' as mentionned in the documentation:
https://developer.mozilla.org/en-US/docs/Web/API/Element/className

For more information, see GH-14485

- Create 2 FPos (1 & 2)
- Create 3 customers:
  Customer A has no FPos
  Customer B has FPos 1
  Customer C has FPos 2
- Set-up the POS so that FPos 1 is the default FPos (FPos 2 is not
  accepted in the POS)

Issue 1
- Select Customer A

The FPos is set to blank, while one would expect to keep the default
FPos.

Issue 2
- Select Customer B
- Deselect Customer B

The FPos is set to blank, while one would expect to keep the default
FPos (as it was before selecting B).

Issue 3
- Select Customer C

The FPos is set to blank, while one would expect to keep the default
FPos since his FPos is not accepted.

opw-782855

Due to a previous commit (@d2e1a1de), if a date was selected in
search filter, the time was converted to UTC to the server.
For negative offset, the search was then executed for the day before.

Now, we avoid to convert the searched date to UTC.
We only need to convert datetime fields.

Commit 763d714f introduced cron job locking for databases which had
modules with states set to 'to x', however if an
installation/uninstallation/upgrade fails, the state will stay at 'to
x', and it may stay in that state for an indefinite amount of time,
meaning that cron jobs could stay locked forever.

This commit fixes this in part by adding a cleanup function to loading.py that
will be executed whenever load_modules fails, the function will change
every 'to x' module to their original state, effectively unlocking the
execution of cron jobs.

This however only works to prevent "zombie" transient states for
brand new databases, however for existing databases which already
contain some modules in a zombie state it won't do anything unless
a module is installed/uninstalled/upgraded, which may never happen.

This is where the second part comes in (ir_cron.py), when failing to
execute crons, we check if the failure was due to bad module state
and if an arbitrary amount of time (5 hours as of this commit) has passed
since the last time it was supposed to be executed, if it is the case, it means
that the cron execution failed around 5 * 60 times (1 failure per minute for 5h)
in which case we assume that the crons are stuck because the db
has zombie states and we force a call to reset_module_states.

Was added at 78014ff3

Closes #21372

…ke lock date into account

If we have a payment in october and a statement in november and the lock date is 1st november, we can't reconcile both because we try to write statement_id on payment but there is the lockdate constraint. This is not correct and we should be able to reconcile both even after lock date as it is the case for other moves.