When the PostgreSQLHandler is used to store some logs in the ir_logging
table of a database, the log record pathname is truncated to keep only
the relevant part of the path. In some circumstances, the path is
wrongly truncated, leading to totally invalid paths.
e.g.: When using an addon-path like `/data/build/enteprise` the removed
part correspond to the length of `/data/build/odoo/`. The resulting path
is `prise/....`.
With this commit, the full path is kept.
This commit is mainly a fix for the runbot logs and should not have an
impact on existing databases.
closesodoo/odoo#50246
X-original-commit: f3c96aa21ad0d8756fadc1608107438ba8cd6c05
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
DeprecationWarning was configured as `once` which might be why I
missed some previously: `once` means the *filter* will only signal
once, meaning only one DeprecationWarning gets shown per run. Even if
there are 5 *completely different* warnings getting generated by the
codebase.
`default` should be more suitable, I think I'd originally
misunderstood it as "whatever the default is for this warning" but
what it *actually* means is "print once for each (module, lineno)".
An alternative could be `module` which would show the warning once per
module but wouldn't trigger from different warnings in the same module.
Before this commit, trying to use Odoo as a library without initializing
the logging features would result in a crash because `Logger.runbot()`
is monkey-patched inside the function `init_logger()`, which is de facto
necessary for using Odoo as a lib.
With this commit, we do the monkey-patch at the module-level so whenever
the `netsvc` package is imported the patch is applied, which should be
well before the loading of the registry starts.
closesodoo/odoo#48396
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
* from collections import <ABC> is deprecated, unclear why the
deprecation warning didn't appear before (possibly only appears in
3.7/3.8?) either way `collections.abc` should be 3.3+ so switch
everything to it.
* add some more ignores on third-party packages deprecation
warnings (meh)
* while at it, mitigate generation of non-breaking space on some
versions of Babel (in the french locale used by our tests anyway)
closesodoo/odoo#47581
Related: odoo/enterprise#9214
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Performances from a general point of view can be difficult to track.
This commit proposes to improve logs in two ways:
The current logs only use the sql_counter, wich will only be updated
when a cursor is closed. In a test-enable install, this counter
is actually the queries of the tests wince the install cursor is
open untill the end. The first fix is to use bot sql_counter and
sql_log_count to have total queries untill now on closed cursor,
but also the current number of queries of the current cursor.
This means that the new log format will be
{nb} modules loaded in {time}, {loading_querie} (+{test_cr_queries}) queries
instead of
{nb} modules loaded in {time}, {tests_cr__queries}queries
Nothe that in the current version, {nb} is actually the total number of
loaded modules until now.
This commit also add an equivalent end log by module and change the
loglevel of module start on install (mainly usefull if an error occurs
before anything else is logged hidding the module causing this error.)
A cleaner runbot logger is also added, in order to be abble to call
_logger.runbot( instead of _logger.log(25. This will clarify the purpose
of such a log level.
closesodoo/odoo#47283
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Allows better formatted and commented log_handler items in
configuration files: configparser allows multiline values and
interspersed comments (stripping out comment lines), but while it
removes indent it leaves the linebreaks, so e.g.
foo =
bar,
# qux
quux
when parsed and split on "," results in `['\nbar', '\nquux']` which is
obviously an issue for logging (as it assumes the leading `\n` is part
of the logger name proper).
Since log_handler items can be fairly long and are not necessarily
self-descriptive as to *why* they were selected for re-configuration,
allowing one per line & comments is helpful.
Configuring the non-root logger based on --log-level had the
side-effect (unclear whether it was intended or not as none of the
relevant commits really documented the idea) that log-level could
override log handlers being set on the root logger e.g. if
`log_handler = :INFO` is set in the config file, `--log-level=warn` on
the CLI will override it.
This could be replicated by swapping `pseudo_config` and `logconfig`,
*however* it would also make the sub-loggers override
differently (currently on an exact logger match log-handler overrides
log-level).
The ideal fix would likely be to sequence log-level from the
configuration file, log-handler from the configuration file, log-level
from the CLI and log-handler from the CLI. However that doesn't really
work with the current structure.
closesodoo/odoo#41180
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
* root the base.partner.merge wizard's logger in odoo.addons so the
"odoo" logger configuration properly applies to it
* update the default logging configuration to set the root logger
rather than independently set the odoo and werkzeug loggers
closesodoo/odoo#40872
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
DROP CONSTRAINT (even with IF EXISTS is specified) acquires an ACCESS
EXCLUSIVE lock on the table, preventing e.g. inserts in an other
transaction, so ir_logging would systematically deadlock if configured
to the same database and a warning would be triggered during install
or update (if that ran ir.logging's init).
1. hand-roll the "IF EXISTS" bit, to avoid taking an ACCESS EXCLUSIVE
lock on the table if the problematic constraint does not exist and
thus doesn't need to be dropped (which by now should be the vast
majority of cases).
Replacing DROP CONSTRAINT with DISABLE TRIGGER does not fix the
issue as *that* acquires SHARE ROW EXCLUSIVE. While that's less
constraitning than ACCESS EXCLUSIVE, it still conflicts with an
insert's ROW_EXCLUSIVE.
2. add a timeout to the logging INSERT anyway, the deadlock is still
an issue if we're updating a database which does have the
problematic constraint, and we want to preclude the possible
eventual introduction of new deadlocks in the future.
closesodoo/odoo#34243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This reverts commit c42a130a98
and commit fb7ac56d65.
The runbot is using cross db logging and those commit were breaking the
mechanism. As a result, the master builds logs were empty.
If we update the runbot to use logging_type instead, the other versions
builds will be impacted hence this revert.
closesodoo/odoo#28512
When there is a performance issue, it's sometimes difficult to discover
which request increased the query count or its duration.
With this commit, the query count, the query time and "python and io" time are displayed
in the logs at the end of each werkzeug request line.
Co-authored-by: Christophe Monniez <moc@odoo.com>
4e5119c6e5 didn't account for
`tools.config['workers']` being `None` on windows, resulting in the
entire thing crashing when trying to execute `None > 1` in Python 3.
Fixes#26447
- RML Reports
- Webkit Reports (most part already removed by 13b9982c62)
- LocalService in netsvc.py
- rename attributes like rml_% to report_%
- rename ir.actions.report.xml to ir.actions.report
- allow rendering directly on an ir.actions.report by calling render method
- remove 'controller' report_type
- remove unused res.font stuff
- remove print_report method in models.py (not used)
- restore removed call to pdftotext process in test_reports
Christophe Monniez