One of the main issue with ormcache is that the invalidation clears
everything, meaning that some value, slow to compute but with a long
lifetime, can be removed from the cache because an easy to invalidate
value is cleared, like after writting or creating a product has an
example.
Most example in the code will try to invalidate the cache of the models
doing something like `env['ir.qweb'].clear_caches()` but it is
finally equivalent to `env.registry.clear_cache()`, and cross worker.
The idea is to have multiple cache, maybe with specific sizes for a
specific purpose.
Having one per model is maybe a bad idea because it will be difficult
to size the LRU correcly, and it is too dynamic. Checking invalidation
may be expensive.
The proposed solution is closed allow a limited number of named caches,
using onse sequence per cache. This is actually close to the
cache_longterm.
We want to discourage using a specific cache for one use case in
the buisness code. Adding a cache shouldn't be something easy, doable
in stable.
Note that we could also change the invalisation mecanism using an
insert only table. We an check the sequence of this table, but also
fetch all invalidation messages.
Another possible improvement, especially if we have more than x cache is
to have a global sequence, checking signaling would mean to check the
main sequence, and only the other ones if the main one changed.
Note that this poc is inspired from the long term cache but not all
use case where applie yet.
Part-of: odoo/odoo#119813
When investigating an issue on a customer database, the diff view modal
can be pretty useful. However it is not very good looking and therefore
poorly readable.
This PR improves the CSS styling of that modal so that it resemble more
the diff view of GitHub. This is done by:
- Increasing the width of the modal
- Aligning the text to the top of the table cell, that way there is no
text floating in the middle of two lines
- Lightly coloring the whole line when there is a change on it while the
actual change is on a darker background
- Putting in red all types of change on the left and in green on the
right (instead of mixing green, red and orange together)
This commit is improving the tool that was made at [`96d3fa4`](https://github.com/odoo/odoo/commit/96d3fa4e01bf8afc35dbf0b7301ce75c6bf3a5c7)
closesodoo/odoo#127765
X-original-commit: bf412f6920b10376a979c9f95c4508dedfec5d5f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Revision odoo/odoo@cabb9e7e57 introduced a
regression: This is no longer possible to import a data module
using `<field file="..."/>` in their data file.
This revision targets to restore the feature as expected.
The unit tests added covers the feature, so that regression
no longer happens in the future.
It introduces a new concept of temporary directory `file_open`
can read from.
e.g.
```py
with odoo.tools.file_open_temporary_directory(self.env) as module_dir:
with zipfile.ZipFile('foo.zip', "r") as z:
z.extract('foo/__manifest__.py', module_dir)
with odoo.tools.file_open('foo/__manifest__.py', env=self.env) as f:
manifest = f.read()
```
Note that `file_open` will be allowed to read from that temporary
directory only if `env` is passed to `file_open`,
and if the `env` is part of the same transaction/request than the `env`
passed to `file_open_temporary_directory`.
This is to avoid having users, whether from other databases,
or even the same database,
trying to access these directories not belonging to them.
e.g. If an admin uploads sensitive data in this temporary directory,
no one than him must be allowed to read from these files, not even
another user from his database.
closesodoo/odoo#126326
X-original-commit: ea5cfe2e9493e4ef5a9b81851af452c8c51e407e
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
A visitor could visit a web page having a lang in its context that is
not installed in the databased he is connected to. The problem is that
visitors are not logged-in thus it is not possible to determine their
lang via their `res.users` preferences. The lang used instead is the
lang set in the `Accept-Language` header of the incoming request, that
header is set by various browsers in accordance to the user system
preferences or browser settings.
The browser lang (`Request.best`) is only parsed according to the
`babel` database, it is a lang syntactically speaking but not necessary
a lang that is installed in the database.
At the moment the browser lang is set in the context (inside of
`Request._get_dbname_and_session`), it is not possible to verify it is
installed in the database as no connection to any database as been
established yet. Instead the lang is validated inside of
`ir.http._pre_dispatch` which is the method responsible to prepare/fix
various stuff on the request/session/context.
In regard to 93b684d3c7, we prefer to fallback on English, hence the
modification in `get_lang`.
closesodoo/odoo#116683
Reference-to: 93b684d3c7 ([FIX] base: lang should fallback on english instead of arab)
X-original-commit: 743e97667e44cdaab6db334d807cf3d409cea621
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Before this commit:
Thread details gave information regarding the database
the UID and the URL.
After this commit:
It also informs on the "performance times":
- `qc` = query count
- `qt` = query time
- `pt` = python time. It should in theory be "remaining time", but it won't be use as its acronym `rt` is too ambiguous/confusing
closesodoo/odoo#106610
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Purpose
=======
Add a new field "Properties" to be able to light customization of workflows
based on a parent model. Those properties acts in some ways like Odoo fields
without requiring specific columns e.g. add new properties on tasks of a
specific project.
Usage
=====
Define properties on a parent model (e.g. project) with
```
attributes_definition = fields.PropertiesDefinition('Message Properties')
```
It defines properties available on children: types, default, value, model for
relational properties,...
Use it on children records (e.g. task) with
```
attributes = fields.Properties(
string='Properties',
definition='parent_id.attributes_definition',
)
```
Technical
=========
Parent | Properties definition
------------------------------
The properties definition is stored on the parent, on a JSON field.
This definition contains the type of the properties, the default value,
the model of the many2one,...
```
[
{
'name': 'name',
'string': 'Name',
'type': 'char',
'default': 'Default Name',
}, {
'name': 'partner_id',
'string': 'Partner',
'type': 'many2one',
'comodel': 'res.partner',
},
]
```
Child | Properties values
-------------------------
The value is stored on the child, using a Properties field.
```
{
'name': 'Mitchel',
'partner_id': 1337,
}
```
When we read this field, we will automatically read the definition on
the parent, and merge both JSON into one, so the web client has the
value of each property, and their definition.
```
[
{
'name': 'name',
'string': 'Name',
'type': 'char',
'default': 'Default Name',
'value': 'Mitchel',
}, {
'name': 'partner_id',
'string': 'Partner',
'type': 'many2one',
'comodel': 'res.partner',
'value': 1337,
},
]
```
Integrity
---------
If we remove a property on the parent, we won't update the child value.
Instead, when we read the child properties, we will filter them based
on the parent. So the removed properties will be removed the next time
we write on the field.
In the same logic, the many2one existence is checked when we read the
field. There's no foreign key between the integer stored in the JSON
in the SQL row corresponding to the record in database.
Write
-----
We can write on the Properties field with a list of field definition
+ value.
Some types are not JSONifiable (like the date, datetime), they are
stored as string in database and parsed when we read the value.
In order to update the parent definition by writing on the child,
you need to add the dict key `definition_changed` or
`definition_deleted`. This is because we need to be able to know
if the definition has been changed without doing extra SQL queries.
Access rights
-------------
A user can add a many2one / many2many property to a model only if he
has the access rights to it.
Many2one / Many2many
--------------------
The model choice of a many2one / many2many properties was subject to
changes.
First implementation stored models in both parent and children to easily
spot changes and avoid complex queries when fetching records, trying to
synchronize them, ...
As this leads to storing a lot of duplicated content we choose to instead
reset the value on the child if the model has been change. We generate a
new name for the property. So it behaves like if we removed the property
and created a new one.
To be able to restore the old value (e.g. if by mistake we changed the
model, and go back to the old model), we store the initial states.
Task-2852259
Part-of: odoo/odoo#95184
This patch discard the fields to delete from data structures like field
triggers, field inverses, and fields to compute.
This is quite useful when uninstalling modules. This commit fixes the
uninstallation of modules base_setup, bus, mail, web_tour.
closesodoo/odoo#98668
X-original-commit: 49398a769b2ec4965bf148f10b5e13d0a6c1acff
Signed-off-by: Raphael Collet <rco@odoo.com>
STEPS in v14:
1. Set user's timezone to Asia/Qatar
2. Inventory > Config > Setting > Enable Lots & Serial Numbers, Expiration Dates, Display Lots & Serial Numbers on Delivery Slips, Display Expiration Dates on Delivery Slips
3. Create a product (storable, tracking by lots, expiration date)
4. Manually update the on-hand quantity for the product
5. Create a lot for the product created in Step 3 > Set the expiration date to 3/30/2025 00:00:00
6. Create an SO with the product > Confirm it to Delivery
7. Validate the Delivery > Print the Delivery Slip
Before this commit the expiration date is rendered as 03/29/2025 instead of 03/30/2025
opw-2901367
closesodoo/odoo#98371
Signed-off-by: Julien Castiaux <juc@odoo.com>
It's really not a general purpose utility, it's just a way of forcing
a lazy collection's evaluation.
Alternatively, add a helper for this to / alongside `lazy`? Note that
the lazy object(s) may not be the top-level.
closesodoo/odoo#98023
Related: odoo/upgrade#3776
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
They're not used much and they don't seem much of an advantage
compared to just calling `subprocess` with the discovery utility
functions.
While at it, fix `dump_db` to not unnecessarily have an open stdin to
`pg_dump`.
Part-of: odoo/odoo#98023
Leftovers of previous fixes of this issue.
closesodoo/odoo#95162
X-original-commit: dffc184862018670008ff4da839fc520a72bddca
Signed-off-by: Christophe Simonis <chs@odoo.com>
We introduce a new decorator/context-manager to catch some exceptions
and re-raise them as another error. This utility main's purpose is to
hide a route that a user has no access to behind a fake HTTP 404 Page
not Found error.
The utility is at `odoo.tools.misc.replace_exceptions(*exceptions, by)`.
Its usage is as follow:
@route('/some/route', auth='public')
@replace_exceptions(AccessError, AccessDenied, by=NotFound())
def some_route(self):
if not request.session.uid:
raise AccessError("Must be connected to see this route")
...
Or as a context-manager if you don't want to except an entire function:
@route('/some/route', auth='public')
def some_route(self):
with replace_exceptions(AccessError, AccessDenied, by=NotFound()):
if not request.session.uid:
raise AccessError("Must be connected to see this route")
...
Task: 2800772
Close: #90433
Part-of: odoo/odoo#88134
In some languages and layout the currency symbol might be wrapped in a separate
line, which is not acceptable from accounting point of view. Fix it by replacing
space with a special symbol.
STEPS for v15:
* install MX localization;
* create a Spanish speaking customer
* generate a pdf:
1) Create quotation with products
2) Add IVA 16%tax
3) print a report
BEFORE: the currency symbol is incorrectly displayed on a separate line
AFTER: currency symbol is always with the amount
---
https://github.com/odoo/odoo/pull/89722
opw-2829138
closesodoo/odoo#90961
X-original-commit: 684687226b87022bc9f9ba7667b295e545100645
Related: odoo/enterprise#27138
Signed-off-by: William André (wan) <wan@odoo.com>
A traceback is caused when migrating/upgrading certain databases. It seems to be caused by special characters in the `street` field.
When there are `newline` characters the regex match function returns None.
This fix improves the REGEX with DOTALL mode (view newline characters with `.` expression) and also checks if the Regular Expression match function succeeds OR provides a fallback otherwise.
Add tests to base_address_extended - tests for `street_split` are enhanced to include problem case
closesodoo/odoo#89727
X-original-commit: 6f72b8f8c2a0080a67c62b40aa4f6d8f3427b16c
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
This commit is the 4th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
Complete refactor of the "registry" of controllers. The `ControllerType`
metaclass have been replaced by an abstract class with a py3.7
`__init_subclass__`. The `Endpoint` class is gone too, replaced by a
clever usage of `functools.partial`. This refactor is "pure", it doesn't
add any new feature, it only merely adds a few warnings.
The four `@route`, `Controller`, `_generate_routing_rule`, `routing_map`
work as follow:
1. A reference to each immediate child class of `Controller` (not grand-
children) is registered in a global list indexed by module (thus a
dictionnary) everytime the server starts. Remember that every first-
child (not grand-children) of `Controller` is the primary controller,
the one that can later be extended by other controllers (the grand-
children) in other modules. Remember that it is possible to get each
class's children via the `__subclasses__` dunder method.
2. Every controller method that is decorated with `@route` is granted an
attribute: `original_routing`, a dictionnary containing the `@route`
arguments. When a controller method has the `original_routing`
attribute, this method is called an `endpoint`.
3. `_generate_routing_rules` receives the list of installed module
names, this list is topologicaly sorted according to the modules
dependencies. That is `base` comes before `web` in this list. The
objectif of this function is to pair each route to an endpoint whoose
class's MRO respect the above-mentioned order. Whe achieve this by
carefully crafting classes at runtime, classes inheritating from the
correct "source code" controllers in accordance to the topology. This
method is also responsible of merging each method's `original_routing`
into one `routing` dictionnary, the very `rule.endpoint.routing` dict
that is used through the rest of the http framework.
4. Each route-endpoint pair is saved into a `routing_map`, an object
that bind each route to its endpoint. This object exposes a `match`
method used to find back the endpoint given its route (=http path).
In addition to this refactor, we added some new helpers in our tools,
among them `submap` that implement a kind of `dict() - set() -> dict()`
operator. Filtering a dict on a set of keys is a common operation but
the python standard library lacks a dedicated operator.
PR: odoo#78857
Task: 2571224
Rely on country.address_view_id instead of hacking the view on the fly. The
address layout (street VS street_name street_number street_number2) depends now
on the country of the user, not on the installed localisation. (it's now
configurable per country)
Unified street format to "Chaussee de Namur 40 - Appt 12"; the
configurable ones where actually wrong by country.
Allow street split without base_address_extended; all EDIs can now be
used with or without base_address_extended.
Merged base_address_city into base_address_extension, to avoid creating bridge
modules for no reason. Uses city_id instead of city if the country of the user
defines it AND if enforce_cities is set on this country.
Improved post_init script for large databases.
Split of street removed on res.company. (not required by any l10n)
[IMP] l10n_cn_city,l10n_nl,l10n_cl,l10n_co,l10n_pe: base_address_extended improvements
l10n_cn_city defined cities but did not provide a means to edit the city_id, so enforce_cities
l10n_nl only requires street names and numbers and thus does not need to depend on base_address_extended
l10n_cl should not depend on base_address_extended as none of the features are used
l10n_pe improve the view
l10n_co remove base_address_city dependency - move to l10n_co_edi
closesodoo/odoo#81710
Related: odoo/enterprise#23108
Related: odoo/upgrade#3129
Signed-off-by: Laurent Smet <las@odoo.com>
Since auto-retry, real errors will lead to doubled errors on runbot.
This can be noisy and hard to understand.
This commit will help with this by using a lower log level on the first
execution. Log 25 are kepts.
closesodoo/odoo#80378
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before when we do `reserved(records)`, it iterates in a reverse
order of `records`. Unfortunately, the `__reserved__` method don't
exist explicitly in BaseModel then Python fallback on
its own implementation using `__getitem__` and `__len__` (coming from Sequence): https://github.com/python/cpython/blob/3.10/Lib/_collections_abc.py#L1047-L1049
Because it uses __getitem__, it breaks the prefetch of the recordset.
Example:
-------------
```
partners = self.env['res.partner'].browse(1, 2, 3, 4, 5)
for partner in reversed(partners):
partner.name
```
will generate 5 SQL requests to fetch data (one by record)
Then create our own `__reversed__` and handle the prefetch correctly
(like `__iter__`). Now in the example it will correctly generate only
1 SQL request because of the prefetch.
task-2687953
closesodoo/odoo#79622
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: rco-odoo <rco@odoo.com>
* add configuration for `flake8[flake8-rst-docstring]`
* enable docstring-related checks
* fix invalid docstrings in odoo's core & `base`
* fix a few more bits (mostly missing or incorrect `:param:` info
fields) are out of scope for the lint but my editor catches
closesodoo/odoo#74604
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
As per the logging documentation, it is fine to send arguments that are
not string. Logging takes care of stringifying and injecting the
arguments in the message template.
closesodoo/odoo#78172
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This pr proposes an auto retry mechanism for tests. This shouldn't
impact normal testing: tests are not supposed to fail, but the growing
number of tests and pull requests can lead to some bottleneck when a
staging fails because of a random error. This mechanism should help to
reduce splits/the need to retry a failed pr.
This branch have been tested with the nightly multi build, creating 40
identical build without test-tags to disable know random errors.
This multi build is used to detect test failing randomly, this is an
excellent candidate to detect the effect of the retry.
On average, with the current base of this pull request, there is between
10 en 15 failures over 40 build.
With the auto retry mechanism, only 1 build failed over 40 builds since
the same error was triggered twice.
This is simply because with the retry mechanism, an error that has a
probability of p to fail randomly will still have a probability of p² to
fail with the retry mechanism. A error that occurs 10% of the time
should only appear 1% of the time with one retry. In most of the case,
the retry is sucessfull: https://runbot.odoo.com/runbot/build/10053257
The current solution to allow to enable this mechanism only in some
cases (staging) is to check an environment variable
"ODOO_TEST_FAILURE_RETRIES" that defines a number of retry.
This will allow to retry more than once if an error still occurs to ofen
with the autoretry.
The mechanism will run multiple time the same test on the same
test_case, meaning that some modification on self may impact the second
execution. The following code is an example of how this could be
problematic, but also a good example to test the auto-retry mechanism.
```python
class TestRetry(HttpCase):
def test_fail(self):
self.t = getattr(self, 't', 0) + 1
if True or self.t == 1:
import logging
_logger = logging.getLogger('test_a')
with self.assertLogs(level="ERROR"):
_logger.error("This shouldn't be log at all")
with mute_logger('test_a'):
_logger.error("This shouldn't be logged (mute)")
_logger.error("This should be log")
```
As we can see here the error logs are also managed, and emit at a lower level the first time, butany log higher than 25 will make the test "failed" and the autoretry mechanism will be triggered. The second time, everything is logged normally. We also need to replace Traceback by _Traceback to avoid being catched by runbot Traceback detection regexes.
The inspiration here commes from the assertLogs, that replace all handlers. The mute_logger had to be adapted to use the same strategy, so that quite_logger won't detect logs catched by mute_logger or assertLogs.
closesodoo/odoo#76336
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Use `frozendict` for dicts that often remain empty on models, like
_inherits and _depends, and also make `frozendict` more compact in
memory.
On a registry with 296 modules, this saves 635 kilobytes of memory,
which is about 6% of the registry's memory footprint.
closesodoo/odoo#70402
Related: odoo/enterprise#18142
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Also speed up the basic setup of fields that are always duplicated
top-level (on the model's registry class). This saves time and memory,
as we also discard field.args and field._base_fields on toplevel fields
(those values are no longer useful after setup).
Add a big fat warning when the qweb compiler finds a `t-raw`.
`t-esc` should now be used everywhere, the use-case for `t-raw` should
be handled by converting the corresponding values to `Markup`
objects. Even though it's convenient, this constructor *should never
be made available in the qweb rendering context* (maybe that should be
checked for explicitely?).
Replace `werkzeug.escape` by `markupsafe.escape` in
`odoo.tools.html_escape`, this means the output of `html_escape` is
markup-safe.
Updated qweb to work correctly with escaping and `Markup`, amongst
other things QWeb bodies should be markup-safe internally (so that a
`t-set` value can be fed into a `t-esc`). See at the bottom for the
attributes handling as it's a bit complicated.
`to_text` needed updating: `markupsafe.Markup` is a subclass of `str`,
but `str` is not a passthrough for strings. So `Markup` instances
going through would be converted to normal `str`, losing their safety
flag. Since qweb internally uses `to_text` on pretty much
everything (in order to handle None / False), this would then cause
almost every `Markup` to get mistakenly double-escaped.
Also mark a bunch of APIs as markup-safe by default
* html_sanitize output.
* HTML fields content, sanitization is applied on intake (so stripped
by the trip through the database) and if the field is unsanitised
the injection is very much intentional, probably. Note: this
includes automatically decoding bytes as a number of default values
& computes yield bytes, which Markup will happily accept... by
repr-ing them which is useless. This is hard to notice without `-b`.
* Script-safe json, it's rather the point (though it uses a
non-standard escaping scheme).
* Note that `nl2br`, kinda: it should work correctly whether or not
the input is markup-safe, this means we should not need to escape
values fed to `nl2br`, but it doesn't hurt either.
Update some qweb field serialisations to mark their output as
markup-safe when necessary (e.g. monetary, barcode,
contact). Otherwise either using proper escaping internally or doing
nothing should do the trick.
Also update qweb to return markup-safe bytes: we want qweb to return
markup-safe contents as a common use-case is to render something with
one template, and inject its content in an other one (with Python code
inbetween, as `t-call` works a bit differently and does not go through
the external rendering interface).
However qweb returns `bytes` while `Markup` extends `str`. After a
quick experiment with changing qweb rendering to return `str` (rather
unmitigated failure I fear), it looks like the safest tack is to add a
somewhat similar bytes-based type, which decodes to a `Markup` but
keeps to bytes semantics.
For debugging and convenience reasons, MarkupSafeBytes does *not*
stringify and raises an error instead (`__repr__` works fine). This is
to avoid implicit stringifications which do the wrong thing (namely
create a string `"b'foo'"`).
Also add some configuration around BytesWarning (which still has to be
enabled at the interpreter level via `-b`, there's no way to enable it
programmatically smh), and monkeypatch `showwarning` to show warning
tracebacks, as it's common for warnings to be triggered in the bowels
of the application, and hard to relate to business logic without the
complete traceback.
`t-out`
=======
`t-esc` is a bit confusing for the new behaviour of "maybe escape
maybe not", so add a `t-out` alias with the same behaviour.
Unlike `t-raw`, `t-esc` is only soft-deprecated for now: there are
thousands of instances, so editing all the templates is not
great. Eventually we'll add a `ci/style` to prevent addition of new
ones, and eventually we might do a bulk-replace and hard-deprecate.
Attributes handling
===================
There are a few issues with respect to attributes. The first issue is
that markup-safe content is not necessarily attributes-safe
e.g. markup-safe content can contain unescaped `<` or double-quotes
while attributes can not. So we must forcefully escape the input, even
if it's supposedly markup-safe already.
This causes a problem for script-safe JSON: it's markup-safe but
really does its own thing. So instead of escaping it up-front and
wrapping it in Markup, make script-safe JSON its own type which
applies JSON-escaping *during the `__html__` call.
This way if a script-safe JSON object goes through `markupsafe.escape`
we'll apply script-safe escaping, otherwise it'll be treated as a
regular strings and eventually escaped the normal way.
A second issue was the processing of format-valued
attributes (`t-attf`): literal segments should always be markup-safe,
while non-literal may or may not be. This turns out to be an issue if
the non-literal segment *is* markup-safe: in that case when the
literal and non-literal segments get concatenated the literal segments
will get escaped, then attributes serialization will escape
them *again* leading to doubly-escaped content in attributes.
The most visible instance of this was the `snippet_options` template,
specifically:
<t t-set="so_content_addition_selector" t-translation="off">blockquote, ...</t>
<div id="so_content_addition"
t-att-data-selector="so_content_addition_selector"
t-attf-data-drop-near="p, h1, h2, h3, .row > div > img, #{so_content_addition_selector}"
data-drop-in=".content, nav"/>
Here `so_content_addition_selector` is a qweb body therefore
markup-safe, When concatenated with the literal part of
`t-atff-data-drop-near` it would cause the HTML-escaping of that
yielding a new Markup object. Normal attributes processing would then
strip the markup flag (using `str()`) and escape it again, leading to
doubly-escaped literals.
The original hack around was to unescape() `Markup` content before
stringifying it and escaping it again, in the attribute serialization
method (`_append_attributes`).
That's pretty disgusting, after some more consideration & testing it
looks like a much better and safer fix is to ensure the
expression (non-literal) segments of format strings always result in
`str`, never `Markup`, which is easy enough: just all `str()` on the
output of strexpr. We could also have concatenated all the bits using
`''.join` instead of repeated concatenation (`+`).
Also add a check on the type of the format string for safety, I think
it should always be a proper str and the bytes thing is only when
running in py2 (where lxml uses bytestrings as a space optimization
for ascii-only values) but it should not hurt too much to perform a
single typecheck assertion on the value... instead of performing one
per literal segment.
Note: we may need to implement unescape anyway, because it's still
possible to get double-escaping with the current scheme: given an
explicitly escape-ed `foo` and `t-att-foo="foo"`, `foo` will be
re-escaped.
fixup! [CHG] core, web: deprecate t-raw
CRM install query count can vary from one execution to another, leading
to difficulties when analysing performances evolution.
The main reason for this is that some compute methods were called in
different order. Even if compute order shouldn't have any effect on the
final result, making it well defined will help finding other causes of
non-determinism.
The initial observation was that sorting Environment.fields_to_compute
leads to a fixed number of query when installing crm.
The main cause of non-determinisim is the usage of `set` impacting
Field.compute_value and BaseModel._modified_triggers.
Transforming all these `set` to `OrderedSet` solves the problem.
The query count is now deterministic when installing a database from
scratch, but not when updating a database with -i crm.
OrderedSet is also slightly optimised by using a dict instead of an
closesodoo/odoo#68692
Ordereddict: dict order is deterministic since python3.6
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
add mail_tz to calendar_attendee model in order to make it easier to change the
timezone displayed in the mail template so that we can use it to make the
appointment time shown on the email reminder sent to the attendees consistent
with the time shown on the website page.
Change the invitation mail template and use the mail_tz field to display time
field instead of using the partner's timezone in order to make the time shown
in the invitation consistent with the time shown on the website page.
Remove the get_interval method in the calendar_event model and use standard
formatting tools instead, as this is more conveniant than having a custom
method for formatting dates, For this reason the format_time function located
in tools/misc.py has been modified to be capable of handling timezones in
order to be able to display time in the correct timezone, furthermore, this
function has been added to the rendering context provided in the
mail_render_mixin file to be used in email templates.
see: https://github.com/odoo/enterprise/pull/16204
Task-2451154
closesodoo/odoo#65729
Related: odoo/enterprise#16204
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
- Remove legacy arguments (`subdir`, `pathinfo`) of `file_open()`,
they were not used anymore and made the code more complicated
- Drop the long-deprecated support for files inside zip archives,
considering that zipped modules were discontinued a long time ago:
278ed718e9
- Remove the redundant `_file_open()` method, that should never have been
called directly anyway
- Add the possibility to filter allowed file extensions, in order to
avoid opening up access to arbitrary addons files, such as .py files,
depending on the context of use
- Split up the verification of the file path, to make it accessible
without actually opening the file, as a separate `file_path()` function.
closesodoo/odoo#68043
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Issue
- add a new language with locale code KUR (for Kurdish)
- print any report with a datetime on it (RFQ for example)
Cause
Babel (version < 2.7.0) does not handle locale "KUR".
Solution
If wrong locale or not managed by Babel, try to fallback
on server default locale.
If still wrong locale or not managed, then fallback on "en_US" as locale.
opw-2416482
closesodoo/odoo#64304
X-original-commit: e6ccdb397792db62c3b08d96435b3c1667c1aa9d
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
The callbacks system is not re-entrant: because we were only clearing
the callbacks after having executed them all, if one of the
post-commit callbacks commits then all the callbacks will get
re-executed (including the one which commits). Which at best can lead
to odd effects & data corruption and at worst crashing the software
because we're overflowing the stack (or maybe the other way around,
hard-crashing might be a better idea than unexpectedly calling the
same functions multiple times).
By popping the callbacks before executing them, we ensure that each
one will only get called once (unless it's explicitely re-pushed on
the stack).
closesodoo/odoo#57516
X-original-commit: 4257be4d771605ecd972bd5b04cb9c0f1163b455
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Python 3.8 changed the equality rules for bound methods to be based on
the *identity* of the receiver (`__self__`) rather than its *equality*.
This means that in 3.7, methods from different instances will compare
(and hash) equal, thereby landing in the same map "slot", but that isn't
the case in 3.8.
While it's usually not relevant, it's an issue for `GroupCalls` which is
indexed by a function: in 3.7, that being a method from recordsets
comparing equal will deduplicate them, but not anymore in 3.8, leading
to duplicated callbacks (exactly the thing GroupCalls aims to avoid).
Also, the API of `GroupCalls` turned out to be unusual and weird. The
bug above is fixed by using a plain list for callbacks, thereby avoiding
comparisons between registered functions. The API is now:
callbacks.add(func) # add func to callbacks
callbacks.run() # run all callbacks in addition order
callbacks.clear() # remove all callbacks
In order to handle aggregated data, the `callbacks` object provides a
dictionary `callbacks.data` that any callback function can freely use.
For the sake of consistency, the `callbacks.data` dict is automatically
cleared upon execution of callbacks.
Discovered by @william-andre
Related to odoo#56583
References:
* https://bugs.python.org/issue1617161
* python/cpython#7848
* https://docs.python.org/3/whatsnew/changelog.html#python-3-8-0-alpha-1
(no direct link because individual entries are not linkable, look for
bpo-1617161)
X-original-commit: d4b2e9224839aed8fc160ebe5a89e0f7d4c6a5bb
Since recordsets are self-recursive, they should be treated like
strings (where iterating a string yields a string, infinitely) in case
somebody happens to return a non-downgraded recordset from a method.
closesodoo/odoo#54572
X-original-commit: 6d88845f339d164fc2667c3417dcc331b317e4db
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Issue
The misc feature remove_accents(input_str) return a
string 'False' if the param is a boolean.
Solution
Return input_str if equal '' or False.
opw-2278959
closesodoo/odoo#53572
X-original-commit: 3fc7ce3b5599355933734e5e3f59d14a7a9b199c
Related: odoo/enterprise#11391
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Purpose
=======
Provide a follow-up/overview of the Mailing 24 hours after its been sent.
Specifications
==============
Send an email to the responsible of the mailing 24 hours the last email
of the mass mailing.
During the link trackers creation, extract the button label if exists
(so we can display them in the statistics email).
Technical remarks
=================
The statistics email is sent to the responsible of each mailing in the
CRON of mass mailing.
Task-2227411
closesodoo/odoo#49836
Related: odoo/upgrade#1094
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to improve tracking of opened traces. Notably
a token is added to ensure we do not mess with traces and have unique
tracking URLs.
MIGRATION REMARK
Emails sent before the migration will not be marked as opened anymore after
migration. We recommend to avoid sending statistically important mass mailings
about one week before migrating database. Indeed statistics show that most of
open emails happen within the first week after being sent.
Task 2223146
closesodoo/odoo#49139
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Without this commit, if `lang_code` or `env.context.get('lang')` was set, we
would still access `env.user.company_id.partner_id.lang` to fill the loop array
even if we break and don't need that value.
Switching from loop to if conditions prevents that.
task-2211013
Co-authored-by: Romain Derie <rde@odoo.com>
Co-authored-by: Jeremy Kersten <jke@odoo.com>
Also non-browser jsonrpc (as it goes through a similar process): for
internal performance reasons, name_search and read_group have been
converted to a *lazy* name_get, so the "display name" is not
unnecessarily computed.
However this is an issue for the RPC endpoints (/xmlrpc and /jsonrpc)
as they have no support for `lazy` and thus tend to blow up and / or
do the wrong thing when trying to output a lazy:
* xmlrpc has no way to handle lazy at all and straight blows up
* jsonrpc falls back to `json_default` so they try to stringify the
lazy, which might have worked except
*Problematically* both endpoints delegate the actual work to
`dispatch_rpc` which handles dispatching between various services and
ultimately creates a *new* cursor before calling model
methods (`object` service and `execute`/`execute_kw`).
This means by the time the result is serialized to be output, the
lazy's cursor has long been closed, and thus any access to an
unevaluated `lazy` errors out when trying to fetch the underlying
item.
This also means we can't just add a hook to serialize the lazy
in the xmlrpc marshaller, though we do have to do that. We *also* (for
both xmlrpc and jsonrpc) have to force evluation of lazy values before
our cursor is closed, meaning it has to be done right after the method
is invoked, iterating the entire response.
Related to task 2170343
closesodoo/odoo#49286
X-original-commit: e2b5a359c1d5eccbe725c1c3169b4130d7bca49b
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.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>
This commit adds the possibility to compare a view arch to another one.
The result will be shown in a diff viewer (github like).
This is following what was done at #32009
task-2190072
closesodoo/odoo#44646
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Some library versions are outdated since the release of Debian Buster.
With this commit the required libraries versions will match as close as
possible the versions available in the current Debian stable release
(Buster).
Also, the requirements were tested against a Windows Python 3.7 to
ensure that a "pip install -r" can be used without the need of a CPP
compiler.
As Babel format_time now returns 'HNE' (Heure Normale de l'EST) for Fr
locale instead of the zone offset, the test is adapted.
Finally the babel.dates is explicitely imported, otherwise the proper
import of this submodule is relying on a side effect.
closesodoo/odoo#43106
X-original-commit: 32e455bf72980e6330871aa9cd99c26c6e1225d7
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
- Install timesheets and studio.
- In timesheets add a time of -0.5 (minus half an hour).
- Enter studio
- Switch to the Reports tab, and click Timesheet Entries.
Before this commit:
The time is displayed as 00:30.
After this commit:
The time is displayed as -00:30.
closesodoo/odoo#38542
Opw: 2036188
X-original-commit: b12374a266d4b5f2783d84e3a65b1c273e343a81
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
en_US may not be activated as it is possible to create a database in
another language using the database manager.
When trying to install a chart of account, the tax return entry tried
to format a date at the installation of the module, with no lang in
the context. The fallback was made on en_US but an error is raised if
that language is not activated.
As it is a very common scenario to retrieve a language from the
context, add a generic tool method to do it.
Replace and closesodoo/odoo#37629closesodoo/odoo#37568
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit adds support for the parameter 'add_direction' on the '_format_time_ago' method
from tools.
This will allow formatting to '25 minutes' instead of '25 minutes ago'.
Preparation commit for the social 'feedback' task.
Task#2075858
Xavier-Do