This patch prevents bugs fixed at 5d463d2 to block the database.
It was preventing the autovacuum to properly clean old records.
Failing to unlink (may have various different reasons) should not block the
autovacuum to try on other models
Closes#23455
From time to time, it happens that a developper forget to remove debuggers.
This commit adds a test to find such imports (pdb and pudb). The test
will fail if that kind of import is found. The Odoo runbot should run
this test and prevent developper from those small mistakes.
If a record is deleted *and* has property fields, the deletion of the
property fields will trigger the various recomputes before the record
itself has actually been deleted, and thus stuff which depend(ed) on
that record will be recomputed under the assumption that the record
still exists, which probably will not work.
Under the assumption that the same issue would occur when deleting
more than one batch of records (unlinking the data, values or
attachment would also trigger a recompute before the proper end of the
function and could lead to incoherence, e.g. some of the records being
deleted being visible to recomputes), lift the entire effective body
of the unlink into a norecompute context, to ensure that only the very
final recompute (from the top-level unlink) is actually triggered.
opw-807036
Before this commit, if the first exported field of an M2M is `id` (the
xid) the entire M2M is folded into a single cell with comma-separated
xids and any following field is ignored. If `id` is any but the first
field, the export behaves normally (with the m2m exported as a "table"
inside the parent record).
This behaviour makes sense for import-compatible exports where the id
is the only thing which can be exported anyway, but it is troublesome
outside of that mode as the behaviour of m2m under export becomes
incoherent/unpredictable (ish) as it depends on the position of the
m2m's `id` in the exports list.
Change it so we only perform folding in import-compatible mode (which
is the default for backwards compatibility with e.g. API calling
export_data directly & the like).
opw-813361
Fixes#22600
The emails sending is skipped during the tests.
The mecanism to determine if the server was running tests
was to check if the attribute `testing` was set for the thread.
Unfortunately, this `testing` attribute is removed/set to false after the loading/installation
of the modules is done, and phantomJS tests are ran post-installation,
and therefore the emails that were potentialy sent following an action
performed in a PhantomJS tour were not skipped.
This occurred for instance in the tour `project.tour`,
when the responsible of a task was changed,
the sending of the assignation notification email was not skipped.
In the case the machine on which the tests are ran does
not have an smtp server (or mailcatcher) running on the port 25,
this resulted in a test fail.
When having an automated action which
triggered upon changing a field to write on another
(no python code, but operatiing with ir.server.object.lines)
Before this commit, the onchange was not performed.
This was because there was no active id
(in fact the code did not take object(<NewId>) into consideration)
After this commit, the onchange is performed.
OPW 801424
Before this commit, one could choose the App Switcher as his Home action.
and arriving on /web would trigger an infinite loop at startup
After this commit it is not possible to choose the App Switcher as Home action anymore
OPW 800323
On MS Windows, the mimetypes module relies on the Windows Registry to
guess mimetypes. As a consequence, when generating assets bundle for
javascript files, the mime type of js files may be wrong. In that
particular case, the Odoo user is facing an empty web page.
This commit enforce 'application/javascript' for js assets when they are
saved as ir_attachment in the database.
This commit is a backport of 77ca51f
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 c338e24ee7 as previous
forward-port has been badly done...
Commit 763d714 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.
Martin Trigaux