It was technically possible to register a link that would loop on itself
by abusing the query and fragment parts of the URL. It was possible to
register a link targetting `#` and get the following HTTP exchange which
enter an infinite loop.
GET /r/bAd HTTP/1.0
HTTP/1.0 301 Redirect
Location: #
GET /r/bAd# HTTP/1.0
Prevent such links from being registered and highlight flaws inside the
`validate_url` method with unittests.
Part-of: odoo/odoo#150678
Steps to reproduce:
- Install Contacts app
- Go to General Settings and add another language
- Add a new contact to a parent.
- Don't add a specific contact name
- Assign a contact type (delivery address, invoice address, other address)
- Go to the list or kanban view of the contancts and change the language
- The type of the contact listed next to the parent name is not translated from English.
Investigation:
- When the contact name is not set, the `display_name` displayed in both kanban and list views is set by concatinating the parent name with the contact type.
- The line https://github.com/odoo/odoo/blob/03b7e17faef4075dbbb805bca4e7f40f7fbcc988/odoo/addons/base/models/res_partner.py#L345 in the function `_compute_display_name`, `with_context({})` in particular basically enforce to compute the name in english language regardless of the active language. That actually makes sense as the `display_name` field has `store=True` https://github.com/odoo/odoo/blob/03b7e17faef4075dbbb805bca4e7f40f7fbcc988/odoo/addons/base/models/res_partner.py#L199
Solution:
- add a computed field that is not stored that gets recomputed on changing the language.
opw-3569171
closesodoo/odoo#147650
X-original-commit: 60b3ae846de59b1f6e71df68e99e29758ba734fe
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Ali Hassan Youssef (alhy) <alhy@odoo.com>
One of our customers is receiving emails with headers and attachments
encoded using the "iso-8859-8-i" charset instead of "iso-8859-8" which
is natively supported by Python. Both encoding are using the same
character set[^1] and only differ in the way the text is rendered on
screen[^2][^3] which is not revelant for Python.
Add an alias for iso-8859-8-i so that the emails that this customer
receive stop failing in Odoo. Note that there is a PR opened on
CPython for exactly that, see [bpo-18624].
opw-3653210
[bpo-18624]: https://bugs.python.org/issue18624
[^1]: https://encoding.spec.whatwg.org/#legacy-single-byte-encodings
[^2]: <data:text/html;charset=iso-8859-8,hello%20%E0%E1%E2%E3>
[^3]: <data:text/html;charset=iso-8859-8-i,hello%20%E0%E1%E2%E3>
closesodoo/odoo#150467
X-original-commit: 5a025467a605ca4fa963b79bae254c823518d54c
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Currently, when a worker (process/thread) has finished processing a request, it
will keep handles on resources held by the werkzeug `Request` object. This
includes open filhandles to temporary files, e.g. those of uploaded files. On
platforms supporting `O_TMPFILE`, these files are not visible in the
filesystem, but keep using up space in `TMPDIR` until werkzeug finally closes
the file handles when the next Request is being handled.
In some contexts, e.g. the upgrade platform, it can happen that there are
multiple workers that only handle rare requests that upload big files (multiple
GiB), kept open after the upload has finished:
```shell
lsof -nP | grep -E 'odoo\/tmp.*(deleted)' | grep -vE 'GeoIP'
python3 213853 odoo 13u REG 252,3 1064251 926275 /home/odoo/tmp/#926275 (deleted)
python3 213853 213865 python3 odoo 13u REG 252,3 1064251 926275 /home/odoo/tmp/#926275 (deleted)
```
This can pose problems, because often the filesystem on `TMPDIR` is not very
large and idle workers holding on to large files can increase the chance for
ENOSPC.
This patch changes the behavior such that the resources held by the werkzeug
`Request` object are being closed[^1] after the response has been sent out.
This also has the advantage that this work is done at potentially idle time
instead of within handling the next request.
[^1]: https://werkzeug.palletsprojects.com/en/2.0.x/wrappers/#werkzeug.wrappers.Request.closeclosesodoo/odoo#150029
X-original-commit: a920ddca57e7bf9353611396f1c0b1060c8cb044
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
This revision adds a flag
`_allow_sudo_commands` to which models can opt-in
to protect themselves against malicious
manipulation of one2many or many2many fields
through an environment using `sudo` or a more priviledged user.
Flagging a model `_allow_sudo_commands = False`
disable `sudo` and `with_user(...)`
when manipulating a one2many or many2many
field targeting this model.
task-3695103
Tests the method formatLang() to be able to do safe(r) refactoring in future versions.
closesodoo/odoo#149775
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
The user can define automated actions for sending data to a remote
server using a webhook.
To prevent this feature from sending unwanted data from a test database,
this commit neutralizes the field `webhook_url` to an invalid URL.
When the action is run, a warning is logged.
closesodoo/odoo#149592
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
This reverts commit 6c59eea421.
smtplib is expecting the Context of ssl found in the stdlib and the
Context object of the pyOpenSSL lib isn't a drop in replacement. The
various `TLS_METHOD` constants are not the same and the Context object
of pyOpenSSL lack a `wrap_socket`-like method.
opw-3640374
closesodoo/odoo#149566
X-original-commit: 028277129897c7d49942a148a0ac295386cd2d89
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The unit tests introduced in 4820be3c only work if pdfminer is installed.
As it's an optional dependency, it may not be installed in some environments.
This commit skips the tests if pdfminer is not installed.
See also: 6fa4dbf2closesodoo/odoo#147720
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
do not compare types, for exact checks use `is` / `is not`,
for instance checks use `isinstance()`Flake8(E721)
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Steps:
- Update a module category to reference itself as parent
OR
- Update multiple module categories to create a circular dependency (A -> B -> A)
Actual result:
- Upgrade a module is impossible
- Un/Install a module is impossible
- Infinite loop: https://github.com/odoo/odoo/blob/15.0/odoo/addons/base/models/ir_module.py#L900
Expected result:
- Circular dependencies not possible
- Module can be upgrade and un/install
opw-3490162
closesodoo/odoo#149284
X-original-commit: 6932714200d158a21bf10b90b2f71fa5cae0b13f
Signed-off-by: Raphael Collet <rco@odoo.com>
Before this commit user was able to archive the language used by superuser
Odoobot by activating different language. Because of which whenever odoobot was
in action then the user faced error.
Steps to produce:
- Install `contacts`.
- Settings > Translations > Languages > Choose a language eg: English (UK).
- Activate that language and switch to it.
- In `contacts` change the language of each contact in the contacts to the
newly selected language.
- Settings > Translations > Languages > Choose English (US) and archive it.
- Settings > User & Companies > User, Apply the filter of Inactive Users.
After this commit user would not be able to archive the language used by
superuser or the language in which there db was installed.
Task-2896526
closesodoo/odoo#149215
X-original-commit: 681fc0a04c7ca625c7120ff2f7b537b75398b23d
Related: odoo/enterprise#54209
Signed-off-by: Raphael Collet <rco@odoo.com>
Purpose
=======
When a database is miss-configured, we have no other choices to
potentially spoof the FROM. We decided that a better heuristic would
be to use the notification email instead of the user email.
Task-3645895
closesodoo/odoo#149189
X-original-commit: eae9214ade8487ac326fc83abe67af53d861e00a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
-------------------
- install the "hr" module;
- remove access rights for "Employees";
- change language on the user profile.
Issue:
------
There's an Access Error because we can't read the `private_street` field
on the employee that corresponds to the user.
Cause:
------
The new version of onchange fetches the record values on the server side,
unlike the old version which used the values in the view.
In the old version, as we were using view values, this didn't cause any problems,
as the values came from a read that which took into account `SELF_READABLE_FIELDS`.
Note:
We do not have access to the value of the `private_street` field because it is a
related field with the attribute `related_sudo=False` and we do not have
access rights for the `hr.employee` model.
Solution:
---------
Use the cache and place the values of the fields in `SELF_READABLE_FIELDS` in it
before performing the onchange logic.
opw-3664929
closesodoo/odoo#148997
Signed-off-by: Raphael Collet <rco@odoo.com>
When the server-side form view reads its record, the call to web_read()
leaves data in cache, which may prevent some access error to be
triggered in the first call to onchange(). In order to avoid that,
simply clean up the environment like after the other method calls.
Part-of: odoo/odoo#148997
Commit 8889a896f introduced the state in the address format for spain
between parentheses, however if the state is unset this leads to weird
values like
```
Isabella López Navarro
()
Spain
```
which is bad.
This commit instead formats spanish addresses by adding the state below
the Zip+City line and above the Country, as suggested here:
https://en.wikipedia.org/wiki/Address#Spain
This avoids empty parentheses.
Task-3679058
closesodoo/odoo#149012
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
In e0297bd, we fixed the inverse field values of the new record during
the onchange. But we actually filter out inactive records by doing
record[self.name] in _update(). And since the XtoMany field cache
values should always contain inactive records, we need to add
with_context(active_test=False) on records.
Also remove the useless 'if value', value is always truly because it
is always a record.
Note that this solves a performance issue in our production, because
in order to filter out inactive records, we need to fetch the active
field next to every prefechable field.
closesodoo/odoo#148675
Signed-off-by: Raphael Collet <rco@odoo.com>
When a model_terms translated field is overridden to a model translated field.
Its terms in the po files should be ignored otherwise calling field.translate
which is boolean will cause error.
opw-3644158
closesodoo/odoo#148518
X-original-commit: 50b314ff3c5d5003ad570d29a05bacd832d70362
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Chong Wang (cwg) <cwg@odoo.com>
Steps to reproduce:
- Go to "Settings / Users & Companies / Groups"
- Create a group (e.g. Group X)
- Go to "Settings / Technical / Actions / Server Actions"
- Create a server action:
* Model: [any] (e.g. Contact)
* Action To Do: Execute Python Code
* Python Code: [any]
* Security: Group X
- Create contextual action
- Connect with a non-admin user (i.e. Marc Demo)
- Open Contacts app
=> An Access Error is raised:
"You are not allowed to create 'Model Data' (ir.model.data) records.
This operation is allowed for the following groups:
- Administration/Access Rights
Contact your administrator to request access if necessary."
Cause:
When the group is created, its external identifier is not created directly.
When opening Contacts app, the list of authorized actions is evaluated.
During the process, "_ensure_xml_id" is called on the groups configured on
the actions to create the missing external identifiers.
However, the current user (i.e. Marc Demo) has not the rights to create an
external identifier.
opw-3328506
closesodoo/odoo#148503
X-original-commit: 34af4c8e6b4273688881b37bfba33d457054676c
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>
Following odoo/odoo@2a8dd6011, if a db has `web.max_file_upload_size`
ICP set to any value, the request would have been wrongly limited to 1 byte
closesodoo/odoo#148617
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>
`res.users.company_ids` returns only active companies, while
`res.users.company_id` may be inactive. This leads to a situation where
`self.env.company` is inactive but still associated to `self.env.user`.
Since in multiple cases the default value for relational fields pointing
to `res.users` is `self.env.user`, we may get an error in this check:
`self.env.company` is not in `self.env.user.company_ids`.
See https://github.com/odoo/odoo/blob/5506ca7/odoo/addons/base/models/res_users.py#L281-L282closesodoo/odoo#147127
Signed-off-by: Raphael Collet <rco@odoo.com>
In #126914 a limit on the request size has been enforced, that limit is
by default 128MiB and can be configured via an ir.config_parameter. When
restoring a backup larger than 128MiB via the database manager, the
default limit was used and the request was cancelled with a Request
Entity Too Large (code 413) HTTP error.
It is now possible to define a default max content length per route,
that per-route limit takes over the `web.max_file_upload_size` ICP.
Moved the code from `get_http_params` to `pre_dispatch` to better align
with the httpocalypse new http stack.
Fixes: #144144
opw-3643475
closesodoo/odoo#147506
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Enable TOTP on your account and create yourself an API key. Connect in
xmlrpc using that API key. Traceback `request` is not bound.
Fixes: odoo/documentation#6919
See also: #147475closesodoo/odoo#146270
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
There are various cases where we observe crons which systematically
face a CPU / memory limit. In a setup where a single worker cron is
launched, a failing cron will prevent subsequent crons to run.
This happens because the limits are evaluated at the worker level: the
worker is killed, then starts over with the same job list order.
If the vacuum cron cannot be run anymore, it leads to tables not
garbage collected anymore (e.g. `bus_bus`), causing performance issues.
To avoid this, we give a higher priority to the vacuum cron.
closesodoo/odoo#144210
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Related fields created when using composition based inheritance are
created without the 'definition' attribute which leads to errors if
you try to read it.
steps to reproduce:
in an odoo 17 shell (it's easier to reproduce in 17 because there is
an example of a problematic field)
self.env["product.product"].search_read([], ["product_properties"])
before this commit:
an error is raised:
TypeError: tuple indices must be integers or slices, not NoneType
after this commit:
the field product_properties is read from product.template
opw-3618178
closesodoo/odoo#147729
X-original-commit: bd012785fe3081aa14a556a94702373cfce4f5db
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
PDF written with scribus (and some other software) have a problem when filling fields: the output
does not work as expected. The replaced value is there, but hidden behind a blue overlay, shown
only when clicking on it.
We now show the field value and ensure filled fields are read only.
Additionally, some readers only allow a single value per field name. Even if the values were
different on the documents, only one would be shown. We now rename the fields to ensure they are
different when they have different values.
task-3626047
closesodoo/odoo#145163
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
A anchor menu in the mobile offcanvas related to an element in the
current page doesn't work in offcanvas:
- The offcanvas doesn't close
- The page doesn't scroll to the clicked location
This is because the menu anchor navigation is hooked to use our own
scrolling behavior instead of the browser one.
Doing so, we preventDefault, which prevent the offcanvas menu to close
itself when clicking on a anchor menu.
This commit simply manually closes the offcanvas and once the closing
animation is complete, starts our own smooth scrolling.
It also targets the desktop offcanvas menu (when hamburger layout is
selected) so it got a smoother UX: it closes then scrolls, instead of
scrolling but not closing.
Another possibility would have been to just close manually the offcanvas
without a preventDefault and without a call to our custom scrolling
method.
Doing so, the browser would naturally scroll to the element while we
close the offcanvas but it would be less elegant as you wouldn't see the
scrolling animation.
Note that the offcanvas was introduced with commit [1].
[1]: https://github.com/odoo/odoo/commit/bc13176de8d66bbdc1c536017b1f046c5fd31a86
opw-3604963
closesodoo/odoo#146907
X-original-commit: db881e66785a866319bd4980a9ae7b6393e55457
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Keeping things in the same order between both files will help when
modifying this file later.
After this commit, the `globals` in both files are 100% sync'd.
Part-of: odoo/odoo#146907
A later commit will add `Offcanvas` as new bootstrap global in the
eslintrc files.
Since the globals are randomly sorted, the chance is taken to regroup
those.
Part-of: odoo/odoo#146907
The default is 25000 rounds, which is too low nowadays.
An off-the-shelf laptop takes ~400ms for a single hash at 600k rounds.
closesodoo/odoo#147202
X-original-commit: e200e96bfbb9cc29771b3727231e2f9a9ae01825
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
When we add a new record N to an one2many tree view from an existing
record X form, during the onchange() on the one2many comodel, the cache
of the N.one2many contains only the new record X (the siblings aren't in
it). Because of this, the result of compute methods may be incorrect
and the form won't be updated accordingly. See
https://github.com/odoo/enterprise/pull/52957 for a concrete example.
Technically, this is due to _update_cache() forcing the inverse field
value to the single value of the new record
("not cache.contains(inv_rec, invf)" is True), instead of also
considering the original values (which is properly done by
Field._update()).
closesodoo/odoo#146778
Related: odoo/enterprise#53298
Signed-off-by: Raphael Collet <rco@odoo.com>
Phone and mobile numbers are not well displayed
on contact widget..
This is because of the display flex that split
the column in two if there is too much information.
We remove the display flex + flex column as
all the children of the element are div, which is
a block element, therefore they are already arranged
one on top of the other.
Steps:
- Having a contact X with full address informations
(address, name, phone)
- With purchase module, you see the bug by
printing a RFQ for the contact X
opw-3626486
closesodoo/odoo#146455
Related: odoo/enterprise#53201
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
This issue occurs when a customer passes an invalid context in the view, at that
time this error will be generated.
Steps To Produce:-
- Go to `Settings >Technical >User Interface >Views`
- Open any view
- pass invalid context like
`context="{'search_default_demo': active_id}, 'search_default_x_stage_id':[3]}"`
-error will be generated
error-SyntaxError
unmatched '}' (<unknown>, line 1)
after this commit, we can display Validation Errors to users instead of a
traceback when they make mistakes in any UI view.
sentry-4684090820
closesodoo/odoo#145193
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Steps to reproduce issue:
1. Open Contacts
2. Select a contact
3. Choose:
- Add an address
- Only if contact is individual: Select drop-down menu next to Address fields in form
4. Private Address doesn't show in the options
Explanation:
Private Address was intentionally deleted from `res.partner.type` in *v16.4* (cf. b1f7e56f79).
Suggested change:
Remove Private Address paragraph in `res.partner.type.help`, it should not exist anymore.
opw-3602922
closesodoo/odoo#146298
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
The Content-Security-Policy[^1] http header was only set on the response
generated by controllers but it was missing from the `/<module>/static/`
route.
It is not strictly necessary to set that header on the responses comming
from that routes as it is not possible to add new static files or edit
existing ones via the interface (not even as admin). Only the developers
and system administrator can access those files.
It is also worth mentionning that using the Odoo internal web server to
deliver static files is suboptimal. Outside of a dev environment, those
files will typically be delivered via a web server[^2] and sysadmins
should configure their web server to set the CSP header on static images.
[^1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
[^2]: https://www.odoo.com/documentation/master/administration/install/deploy.html#serving-static-files-and-attachmentsclosesodoo/odoo#146591
X-original-commit: 55e09d504df9bd134afb6e0b38f03457b5c71e8e
Related: odoo/documentation#6953
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
After the previous fix introducing a deepcopy, the pregenerate of the
assets became slower because of the many call to get_manifest (in loop,
recursively)
Since the manifest is immutable here and won't go outside of the call,
we can use the lower level version.
closesodoo/odoo#146602
X-original-commit: acb671f4d1b9c53c9e7d91414e847f26e8026ca3
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This is because the `env.registry` may not be the latest registry in the
Registries pool, which happens when new modules are installed by a request and
fail. In the `setup_model` the `_m2m` is set to the old registry, but models
will try to read the `_m2m` from the latest registry and raise 'Registry' object
has no attribute '_m2m' error
This commit fix the issue by resetting the env when necessary
closesodoo/odoo#146544
X-original-commit: a433f3175a5105d9028dd9937d5461ae2d5d11fe
Signed-off-by: Raphael Collet <rco@odoo.com>
Julien Castiaux