When bin_size=True is in the context, a computed non-attachment binary
is incorrectly saved to the database. The row is actually updated with
the size of the binary instead of the value itself.
This commit fixes the problem by avoiding setting the cache with the
bin_size value as dirty.
Moreover, the binary size is computed with `pg_size_pretty` for
non-attachment binary fields. Also, method compute_value() calls
b64decode() on the value that was previously encoded in base64 by
_compute_datas(). But _compute_datas() is specific to attachments, and
is not used in this case. Thus b64decode() doesn't make sense.
These 3 bugs are now covered by testing web_save(), where cache
consistency is required. It was first reported for this method.
Closes#156673closesodoo/odoo#160708
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Renaud Thiry <reth@odoo.com>
Non-attachment binary fields need to be flushed before reading their
size, since the latter relies on the database's binary size function.
Part-of: odoo/odoo#160708
After writing or creating on a related Image field, its cache contains
the full-size image instead of the resized one (according to its
attributes max_width and max_height). Fix the cache with the resized
image at the end of the inverse method.
Part-of: odoo/odoo#160708
When invoking create() or write() with a binary field, the cache of the
field was incorrect if bin_size=True was in context. Force context with
bin_size=False when putting a binary value in cache. It is particularly
important to have coherent values in the cache for `web_save`.
Also, because an environment with bin_size=False won't return the same
context cache key as one with bin_size=None, it leads to have a cache
inconstistency when we write with bin_size=False. Change Environment
method cache_key() to return the same cache key when bin_size is absent,
bin_size=None or bin_size=False.
Tests on binary fields have been updated to not rely on flush and
invalidate. We also created specific tests for write() on binary
fields.
Part-of: odoo/odoo#160708
Changing the environment in method create() to force bin_size=False
looks harmless, but it actually breaks many tests, in particular in
module account. The reason is that company_dependent fields are read at
the wrong place in the cache. And this is because `env._cache_key` can
be polluted with old data.
Make sure that `_cache_key` is cleared when resetting all the lazy
properties on the environment. Only the change in res_user.py makes it
work, but let's not tempt the devil.
Side note: I hate caches.
Part-of: odoo/odoo#160708
Steps to reproduce:
[account_edi_ubl_cii]
- create an invoice and set a line with on the control character https://unicode-explorer.com/b/0000
- confirm it
- try to print it
Issue:
Ugly Stack Trace
Cause:
XML does not accept such characters
```
The characters to be escaped are the control characters #x0 to #x1F and #x7F (most of which cannot appear in XML)
[...] XML processors must accept any character in the range specified for Char:
`Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]`
source:https://www.w3.org/TR/xml/
```
opw-3773808
closesodoo/odoo#163433
X-original-commit: d06a22991cd604e46d6392f6394b2b0e6a4ae673
Signed-off-by: William André (wan) <wan@odoo.com>
The test_sudo_commands fails when testing portal user without demo data.
With this commit, a portal user is created in a setupClass.
closesodoo/odoo#163319
Build-error: 55927
X-original-commit: 83c2201543d4d37b2d8e760200c5b111e1d74fa1
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Some options have been renammed a long time ago but there was no
mechanism to warn the user should those option be still present in its
configuration file.
Odoo versions up to Odoo 14 (excluded) used `osv_memory_time_limit` and
`geoip_database` in their configuration, those two options have been
renamed to `transient_age_limit` and `geoip_city_db` in 14.0 ab4000f and
saas-16.1 c59750d824 but no deprecation warning / automatic failover
were provided.
closesodoo/odoo#163193
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
`l10n_es_edi_sii` requires `Client.bind` as well as `_binding_options`
in the service returned by this `bind` call.
```py
serv = client.bind('siiService', service_name)
if company.l10n_es_edi_test_env and connection_vals.get('test_url'):
serv._binding_options['address'] = connection_vals['test_url']
```
Can be tested with a external l1On unit test,
tested only in nightly builds,
not by regular runbot builds / mergebot.
`--test-tags=external_l10n:TestEdiWebServices`
opw-3888257
opw-3888559
opw-3888155
opw-3890269
opw-3889683
closesodoo/odoo#163123
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Original issue:
1) Create a company "main", with 2 branches: "A" and "B"
2) Create a sub-branch for "A": "A1"
3) Archive company A
4) In the company selector, make "main" the active company. It will auto-select branch B as well.
5) Open the tax report, and try clicking the "Closing Entry" button
==> The button is disabled ; it shouldn't be.
This happens because Odoo considers the full hierachy of branches to submit together is not selected. The problem originates in the way _get_branches_with_same_vat searches for sub-branches, doing
self.env['res.company'].sudo().search([('id', 'child_of', current.root_id.ids)])
In our example, this search will return main, B and A1. We then compare that with the company selector, which only contains main and B.
This configuration of companies does not make sense functionally speaking, as a branch whose parent is inactive will not be usable anyway. Therefore, we now archive all the sub-branches when archiving a company.
opw-3877368
task-3878070
closesodoo/odoo#163078
X-original-commit: b5f297616e937535f2d0ba3f05fd905858741d53
Signed-off-by: William André (wan) <wan@odoo.com>
Until now, it is impossible to do <g:title>xxx</title> because qweb
will autoclose the <g:link> because it checks if link is a void element
instead to check g:link.
Now we check the el_tag instead of unqualified_tag.
closesodoo/odoo#159476
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
The various keys and certificates used by the TestIrMailServerSMTPD test
suite were generated on-the-fly via a shell script present next to the
test. It is just easier to save the keys and certs in git rather than
re-generating them everytime.
Changed the private keys from RSA to ed25519 for the smaller files size,
changed the validity date to a thousand year.
task-3703209
opw-3640374
Part-of: odoo/odoo#151483
A previous commit broke the smtp authentication using a TLS certificate
and we only figured it out after that a client created a support ticket
several weeks later. It turns out that there are no tests that validate
the various ways outgoing mail servers can be configured.
In this work, we add a test suite where a local smtp server is started
and controlled during the test execution. This makes it possible to test
all the possible outgoing mail server configurations, including TLS.
This work revealed several problems that have been sorted in other PRs,
a problem that is left to solve is to verify those certificates as shown
by the `test_man_in_the_middle` test. This will be sorted in a future
work.
We chose [aiosmtpd] which is a pure-python lightweight SMTP server that
aims at providing a programming API that is well-suited to be used
inside unittests.
task-3703209
opw-3640374
[aiosmtpd]: https://aiosmtpd.readthedocs.io
Part-of: odoo/odoo#151483
Uploading a WEBP or SVG file disguised with a proper file extension (JPG, PNG)
will cause a traceback because img.image is
not populated when there is an empty source, SVG, or WEBP file uploaded
as this code should not be reached with these file types.
The reason this occurs is because we check for the file extension when
deciding to post process an image, but when we get to initializing the
ImageProcess object, we then check the actual file structure to verify
the type of file.
This is a workaround for the time being, but should not be a final
solution in future versions.
Adding a null check on img.image in the _postprocess_contents method
in order to avoid attempting to access the size of this image when it is
null.
Raises a user error in order to trigger the catch and exit the code
while logging the error and 'Post processing ignored:'.
Includes test for this new workflow with no errors.
opw-3672250
closesodoo/odoo#162976
X-original-commit: e9750b16a61c3598f7a2b14a1552fcb4ecf1a293
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>
Signed-off-by: Ryan Cen (ryce) <ryce@odoo.com>
The module `l10n_nl_reports_sbr` requires
- `zeep.wsdl.utils.get_or_create_header`
- `zeep.ns.*`
- `zeep.wsse.*`
In addition, it requires the `session` to be already
set during the creation of the client.
The module `l10n_pe_edi` requires `requests.Response` as possible
output for service
```py
result = client.service.sendBill
if result.status_code != 500:
...
```
Can be tested with
`--test-tags external_l10n:TestEdiSunat`
opw-3887309
opw-3884785
opw-3885630
opw-3870707
opw-3888951
opw-3885636
opw-3885392
opw-3885383
opw-3889366
opw-3888841
This test can sometimes fail randomly
FAIL: TestProfiling.test_sync_recorder
Traceback (most recent call last):
File "/data/build/odoo/odoo/addons/base/tests/test_profiler.py", line 440, in test_sync_recorder
self.assertEqual(stacks_methods, [
AssertionError: Lists differ: [['a'[114 chars]], ['__exit__', '_remove'], ['__exit__'], ['__exit__', 'stop']] != [['a'[114 chars]], ['__exit__', 'stop']]
First differing element 11:
['__exit__', '_remove']
['__exit__', 'stop']
First list contains 2 additional elements.
First extra element 12:
['__exit__']
[['a'],
['a', 'b'],
['a'],
['a', 'c'],
['a', 'c', 'd'],
['a', 'c'],
['a', 'c', 'd'],
['a', 'c'],
['a'],
[],
['__exit__'],
- ['__exit__', '_remove'],
- ['__exit__'],
['__exit__', 'stop']]
Since we don't care about the last lines, just remove them from the
assertion.
closesodoo/odoo#163016
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
While searching for a similar attachment, as the fallback url pattern is
the same as the url pattern, the condition is never satisfied.
With this commit, the ignore_params parameter is used to find a similar
attachment.
closesodoo/odoo#162654
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Since 17.0, the tag `apps` of ir.action.client was removed with the
legacy code of javascript. This commit removes the only usage in
`res.config.installer` (not used in standard) to avoid a traceback at
install.
Fixes#160293closesodoo/odoo#162228
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>
The API of zeep changes according to the version of zeep.
We want to limit the number of used methods and attributes
of the zeep client by our developers.
Hence, we provide our own zeep Client limited to the
attribute and method we really need.
In addition, a timeout for GET/POST requests
should be applied by default when creating a new Client,
which is not the case by default.
We override that behavior to always provide a default timeout,
and an easier API for developers wanting to change
the default timeout.
Before it was needed to import `Transport` from `zeep`,
instanciate that `Transport`, with a timeout and optionally
a session, and then pass that transport instance to the creation
of the Client.
We provide a way to directly pass these timeout parameters
through the Client constructor.
In addition, we serialize the returned values of Zeep service operation
calls, to make sure we return simple types in methods of models
e.g. bools, integers, string, ...
Monkey-patching C types is not straightforward.
It relies on changing the attributes or methods in memory
at the right address with the exact right size.
This requires the greatest caution.
A simple mistake can mess up the memory used by the Python interpreter,
and for instance lead to `SegmentationFault` exceptions
or unforeseen behaviors.
However, being able to patch C type is a very powerful tool.
With great power comes great responsibility.
`patch_c_type` is implemented with the greateast caution.
The Python C-API documentation has been thoroughly followed
and understood.
In addition, this patch has been battle tested in real
conditions.
In the end, this allows to patch unwanted behaviors
from types implemented in C.
Co-authored-by: Denis Ledoux <dle@odoo.com>
Co-authored-by: Christophe Simonis <chs@odoo.com>
Co-authored-by: Mathieu Walravens <wama@odoo.com>
Prior to this commit, some attributes such as "data-tooltip" were not
exported in /static/src/ templates, while "label" was only exported in
them.
This commit adjusts the code to use the same list of translated
attributes everywhere, fixing the problem and making it less likely to
happen again.
Task-3872895
closesodoo/odoo#162250
X-original-commit: 6c272a432cea29fa98d9f2a3e4f454214099f3e6
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Start a SMTPS server with client certificate authentication. In Odoo
configure an outgoing mail server with encryption="ssl/tls" and
authentication="certicifate". Load a valid client certificate and key to
use with the SMTPS server then test the connection.
The connection fails because the client certificate wasn't sent during
the TLS handshake.
If you're having trouble running a SMTPS server, I made a script here:
https://gist.github.com/Julien00859/5090d1cff6c02197e5854aabb67bf5ac
It uses aiosmtpd, a light pure python smtp server, install it with pip.
You'll need to copy your snakeoil ssl key + cert inside your /tmp
directory and to expose them to your current user:
# public cert
cp /etc/ssl/certs/ssl-cert-snakeoil.pem /tmp
# private key
sudo cp /etc/ssl/private/ssl-cert-snakeoil.key /tmp
sudo chmod 400 /tmp/ssl-cert-snakeoil.key
sudo chown $USER /tmp/ssl-cert-snakeoil.key
task-3703209
closesodoo/odoo#162297
X-original-commit: b3d7c1fc9c017a4354dc4a6f8abfbf590bc26a51
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Previously, when the odoo server was running on some Windows
installations, it was possible for javascript files loaded directly from
the static folder of an addon to fail to run because the Content-Type
header was set to text/plain instead of text/javascript. This is because
the mimetypes module from the standard library honors the mimetypes from
the OS, in the case of Windows it reads a key in the registry, which can
be misconfigured to text/plain for .js files.
This commit forces the mimetype of .js files to text/javascript to solve
this issue.
closesodoo/odoo#162313
X-original-commit: 64cbe389e698398eee93ebde9c61b2ee79756380
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>
In the currencies list view, the current rate and inverse rate were swapped.
Their strings were also changed to match the string in the form view.
Currency rates were inversed in the currencies list view.
task-3856386
closesodoo/odoo#160882
Signed-off-by: William André (wan) <wan@odoo.com>
When we load a module and the SQL constraints exist both in the table
and in `ir_model_constraint` we need to ensure the xmlid is loaded.
Otherwise the record in `ir_model_constraint` is removed.
Since 4c9968397b we skip returning
existing non-updated constraint records in `_reflect_constraint`. This
leads to them being removed by the ORM. At the end of the load the ORM
sees the record in `ir_model_data` but not in the xmlid pool, thus it
removes it.
closesodoo/odoo#162105
X-original-commit: b5670c7f0d35d13affee2ae93158556346b7dd23
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Steps to reproduce:
Create and print an SO for a customer based in Luxembourg
Expected behavior:
According to Bpost and to the Post of Luxembourg, the zip code should be
displayed before the city name in the address format in Luxembourg.
Current behavior:
The zip code is displayed after the city name.
opw-3791142
closesodoo/odoo#161738
X-original-commit: 83b38fab6cc69d0ed2c6abae34f2b4e76ef8a601
Signed-off-by: Lancelot Semal (lase) <lase@odoo.com>
When updating the categories, if by any chance there is a loop in the
category hierarchy, the current code was falling into an infinite loop.
With this commit, the graph loop is broken by clearing a parent_id, and
if the resulting module category path is wrong, a clean new one will be
recreated anyway.
This allows unblocking uncomfortable situations where people cannot
update the modules list any more. In 15.0, [a check][1] has been
introduced to prevent the existence of recursive categories, but as it
is a python check it doesn't prevent corrupted data to remain corrupted.
OPW-3704007
Related to odoo/upgrade#5574
[1]: odoo/odoo@6932714200closesodoo/odoo#161583
X-original-commit: f2765d2cab5671a010404c36842bf1b4c4d6350b
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Issue
-----
The cache is not updated properly when the configuration of a currency changes.
This leads to reading stale values in other places. For instance, changing currency
symbol position isn't reflected in invoice tree views unless after a server restart.
Steps
-----
- Open Accounting -> Configuration -> Currencies.
- Pick the active currency, say USD.
- Change 'Currency Symbol Position' to a different value.
- Go to Accounting -> Customers -> Invoices. The displayed amounts don't reflect
the change.
Cause
-----
Cache refresh was misplaced after a premature return, so the cache wasn't refreshed
when 'digits', 'position' or 'symbol' fields of `res.currency` are written, although
that was the intent.
opw-3849155
closesodoo/odoo#161036
Signed-off-by: Moataz Hussein (mohu) <mohu@odoo.com>
-Step to reproduce: create a custom module and try to extend method in
website_slides controller like this:
@http.route(sitemap=sitemap_slide_view)
def slide_view(self, slide, **kwargs):
return super(WebsiteSlidesSeo, self).slide_view(slide, **kwargs)
From there, 'rule.endpoint.original_routing' will take the value from
the extend method not the original one therefore user will one again go
to the the forbidden error page which is'n friendly. We shouldn't access
original_routing because that's the "function's specific @http.route"
closesodoo/odoo#160864
-solution: we only need rule.endpoint.routing because it is the one holding the "merged @http.route accross inherited controllers".
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
The test test_tz_legacy will fail if the taget does not exist on the
operating system. This is breaking in some versions of the tz-data
package. Don't make this test fail if the target is missing.
closesodoo/odoo#161341
X-original-commit: 276eb0192fdddb736453857c18bf9f0cccecb4a3
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
`_UNSAFE_ATTRIBUTES` was changed from a `list` to a `set` in odoo/odoo#151989.
odoo/odoo@cde2781591
Reset it to a `list` as before, by retro-compatibility concerns,
in case developers used features not working on `set`.
For instance:
- `_UNSAFE_ATTRIBUTES.append`
- `_UNSAFE_ATTRIBUTES.extend`
- `_UNSAFE_ATTRIBUTES + ['foo']`
The opportunity is taken to add `_co_code_adaptive`,
which is a new attribute added from Python 3.11,
hence available from Ubuntu Noble.
Firstly added as `_co_quickened` in
https://github.com/python/cpython/commit/001eb520b5757294dc455c900d94b7b153de6cdd
Then renamed to `_co_code_adaptive` in
https://github.com/python/cpython/commit/2bde6827ea4f136297b2d882480b981ff26262b6
The opportunity is also taken to move `mro` out of the `Python 2 functions` section,
as `mro` is available in Python 3, hence making the comment confusing.
Part-of: odoo/odoo#151989
The logger show "Job done" before the flush. But if during the flush an
error appear (sql constraint, validation error during computed field,
...), the log contain "Job done", but is not True.
The time to compute the cron is not good because it doesn't contain the
flush time.
closesodoo/odoo#161204
X-original-commit: 0cde9c7238ece225ebd50c50f4a78d16ac6b5226
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Outlook and similar Windows based systems use windows-874 for encoding
Thai characters which is not natively known by Python.
Simply aliasing the Windows encoding as cp874 adds support for this
encoding.
opw-3684161
closesodoo/odoo#161117
X-original-commit: 65d4c2507e762dc273a02a2e2215c49a5976568d
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>
The conditionnal `isinstance(exc, NotFound)` is shadowed by the
conditionnal `isinstance(exc, HTTPException)` two lines above. Nobody
ever complained that the warning for NotFound error was gone. Since
werkzeug 1.0.0, the status code in the response log is colored, 404 is
colored yellow which should catch the eye. The explicit warning line
isn't really necessary.
closesodoo/odoo#159895
X-original-commit: 851b91f19b87446662421cb8d801a9472725bc72
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
In ubuntu noble, some timezone where removed leading to errors when
trying to assign/access them.
This was partially fixed in the code by removing all references to old
timezones but one issue remains: if a database contains timezones that
are not defined in the os, the resolution will fail and break at runtime
This patches proposes to alter timezone to fallback on the new canonical
timezone if the timezone was removed.
This list was generated by checking all symlink in /usr/share/zoneinfo
in ubuntu 22.04 that disapeared in ubuntu 24.04
This solutions will work when moving a database from one server to
another, even without migration.
The all_timezone is not modified on purpose to avoid breaking existing
logic. This list may be used to define if a timezone is known by
postgress, define selection fiels, .... we don"t want to increase the
list in those case.
Some other logic using all_timezone may need to be updated but This
will be done in master.
Part-of: odoo/odoo#160842
Some of the non canononical timezones are not present in Ubuntu Noble,
it would be a better practice to only use canonical timezones in data
and tests.
Note that this is not a real fix for all cases since the database that
ran on Ubuntu Jammy and are moved to an ubuntu Noble server will have
the issue with timezones already in database.
One of the possible fix would be to manage that during upgrades, but
this isn't a verry flexible solution since upgrade are meant to manage
chyange of version, not change of server. If an old 17.0 versions needs
to be moved to a Noble server, this won't work.
Another solution would be to install package like tzdata-legacy that may
keep the old timezones but it is not the only think since TAI-10 are
also in this package. This solution is not ideal because non canonical
timezone will still be shown in the dropdown. We would need to filter
them.
A last solution would be to add the support for those old timezones by
monkeypatching the lib. This way, only new timezones would be shown but
non canonical one won't crash when used. This is not ideal either
because we may need to keep this for a while. But in combination with
the upgrade solution, it may work proprely.
Part-of: odoo/odoo#160842
In latest versions of werkzeug, the `werkzeug.urls` module has been
reduced to remove feature present in urllib.parse. This commit vendored
the old version to avoid breaking compatibility with older versions of
odoo on ubuntu Noble, without adapting the whole codebase. This
should/may be removed in stable by adaptaing eveything to urlib.
This version of the lib was minimalized to avoid redondunce with feature
still present in werkzeug.urls. Some unused features in odoo are still
vendored for ease but are not exposed on the werkzeug.urls for now.
Part-of: odoo/odoo#160842
When python expression is evaluated in odoo form an action or qweb, we
are checking the opcodes generated by the evaluation of this code. We do
such a verification, because the code from actions and templates can be
written by someone having not access to the server and we don't want to
let them perform actions out of the scope of their database.
In python 3.11, some opcodes from previous versions of Python have been
renamed, grouped or sepcified. There are also new ones that have been
introduce.
In this PR, we are whitelisting the new ones that are needed by odoo to
properly work in this version of Python.
Part-of: odoo/odoo#160842
When creating a new company from a move, if the tax ID is repeated, a warning is displayed.
The warning includes the company name, address and VAT, if those have been added. In this case,
address is shown in an extra line, which looks broken.
This commit removes additional partner information by updating the context,
displaying only the partner name.
It also slightly rewords the warning, from "are you sure to create a new one?" to
"are you sure you want to create a new one?".
To replicate the issue:
1. Create an invoice
2. Click on the empty field next to Customer, type a new name and click "Create and edit..."
3. Add a Tax ID that is already in use (e.g. US12345673)
4. Warning of duplicate Tax ID shows, displaying company name, address and VAT
task-3829641
closesodoo/odoo#160373
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
This commit removes an unwanted `bg-primary` class applied to the change
password modal, making it weird and unconsistent regarding others modals
across Odoo.
=========
Steps to reproduce
=========
> Open a database
> Click on your avatar in the top right corner
> Click on `Preferences`
> Go to `Account Security`
> Click on `Change password`
>> The modal has a `bg-primary` class, making it look purple.
task-3836699
closesodoo/odoo#160462
X-original-commit: 2813540aba7556b915185e482cbb6d9500db7af1
Signed-off-by: Chrysanthe Gomrée (chgo) <chgo@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
In `ir.model.data` model, there is no SQL constraint which is
ensuring that the `name` field can not contain `.` (dot)
So when loading the translations to database if the xmlid's `name`
contains dot then `xmlid.split('.')` will split it more than 2 parts.
Which will cause issue during saving it to database as it is expecting
2 parts `[<module>, <name>]`. I ensured the splitting to 2 parts
with `maxsplit=1`
closesodoo/odoo#160228
X-original-commit: a1ae06f499b183db69b7e763a2803a079f540a77
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
