`_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>
Add a test for exporting the source terms of modules.
This will allow automated scripts to fetch latest terms
Backport save_test_file with a parameter on date_format to have
predictable filenames
closesodoo/odoo#159373
X-original-commit: e7246ea48828746471a2e3a485bee30687eeee80
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Steps to reproduce:
- Remove all permissions to write/create/delete a view for the user "demo"
- Open a view form with "demo" user
Actual result:
- View code is displayed in plain text and with formatting
Expected result:
- View code is displayed with formatting only
- You can't edit the view or the translations
opw-3776073
closesodoo/odoo#159592
X-original-commit: a1f4e3de224d91e49d5adb2a6385d76c3282d206
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
Upon calling `invalidate_recordset` the current recordset present is
flushed. That recordset can be active=True which override active=False
set `_process_job()`. Flushing the recordset *before* calling
`_process_job` makes sure that there is no dangling data to be flushed.
closesodoo/odoo#159262
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
The underlying `odoo.tools.email_send` was removed in
82de620424 (merged in 14.5) but this
callsite was missed, this method has been broken ever since.
I really want to remove this method directly, but technically it's an
expensive no-op if called on a recordset of partners without emails
set (or an empty recordset), so instead make it trigger a warning &
remove in master.
closesodoo/odoo#159177
X-original-commit: 457a4be9d6bb1e15b996a5a14468f9b0d88e0b0f
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
If you're on Linux, make sure `inotify` is uninstalled:
pip uninstall inotify
Install `watchdog` to its latest release, 4.0.0, and start odoo in
dev-reload mode. This mode restart the application everytime a file is
modified in one of the addons.
pip install watchdog==4.0.0 -U
odoo-bin ... --dev=reload # replace ... with your arguments
Modify a file, save it. The server doesn't reload while it should.
Before gorakhargosh/watchdog@41fca1eb, only the `FileSystemMovedEvent`
class had a `dest_path` attribute (actually a property). In our code, we
used a `getattr` approach to fallback on `src_path` (which is set on all
three event classes) in case `dest_path` was not set.
Since that commit, the attribute has been moved to the base abstract
class `FileSystemEvent` which all three `FileCreatedEvent`,
`FileModifiedEvent`, and `FileMovedEvent` inherit. Hence the attribute
is always set (sometime to an empty string) and the getattr must be
adapted.
The new code supports both watchdog==3.0.0 and watchdog==4.0.0.
closesodoo/odoo#159102
X-original-commit: 9dd441858fa26d1fb6f13c7cd59076e8898aceb3
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
When we use the `|` (or) version of this rule the ORM generates two
sub-queries when checking the company. This causes sub-optimal and in
some cases really bad planning for the queries and thus PG takes hours
to complete them.
Example (formatted):
```sql
SELECT "mrp_routing_workcenter".id
FROM "mrp_routing_workcenter"
LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
AND ( ("mrp_routing_workcenter"."bom_id" in (
SELECT "mrp_bom".id
FROM "mrp_bom"
WHERE ("mrp_bom"."company_id" in (1))
)
)
OR ("mrp_routing_workcenter"."bom_id" in (
SELECT "mrp_bom".id
FROM "mrp_bom"
WHERE "mrp_bom"."company_id" IS NULL
)
)
)
ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
"mrp_routing_workcenter__bom_id"."id",
"mrp_routing_workcenter"."sequence",
"mrp_routing_workcenter"."id"
```
If we use the single term version the generated query has only one
sub-query:
```sql
SELECT "mrp_routing_workcenter".id
FROM "mrp_routing_workcenter"
LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
AND ( ("mrp_routing_workcenter"."bom_id" in (
SELECT "mrp_bom".id
FROM "mrp_bom"
WHERE (("mrp_bom"."company_id" in (1))
OR ("mrp_bom"."company_id" IS NULL))
)
)
)
ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
"mrp_routing_workcenter__bom_id"."id",
"mrp_routing_workcenter"."sequence",
"mrp_routing_workcenter"."id"
```
In this version PG is able to produce a better query plan resulting in
better execution times.
Also, the `company_id` field is required on some models, so the "= False" comparison is useless.
closesodoo/odoo#159123
X-original-commit: 1b5c41f36801fb886ec591f29dba42787d698526
Related: odoo/enterprise#59378
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Co-authored-by: Christophe Simonis <chs@odoo.com>
Before this commit, when creating a many2one field from an xml, with an
impossible combination "`required=True` - `on_delete='set null'`", the
column was not created in the database without any notice to the user.
This commit adds a constraint checking that any attempt to create a field
with this configuration would raise a ValidationError. This constraint
replaces the previous onchange method.
closesodoo/odoo#158778
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
That is how states are (might be?) exported, so it should be possible
to find them the same way.
closesodoo/odoo#158984
Task-id: 3644762
X-original-commit: 26df8e2858d8bcaa11dfae68be328388b1983745
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Purpose
=======
Tremendous amount of support tickets (ex: 3800405) are opened because the user_admin
has been removed and is referenced everywhere, leading to tracebacks or
the impossibility to install a new application as res.group configurations
all relies on this, like:
<record id="group_helpdesk_manager" model="res.groups">
<field name="name">Administrator</field>
<field name="category_id" ref="base.module_category_services_helpdesk"/>
<field name="implied_ids" eval="[(4, ref('group_helpdesk_user'))]"/>
<field name="users" eval="[(4, ref('base.user_root')), (4, ref('base.user_admin'))]"/>
</record>
We could adapt all the occurences (severeal hundreds) to ensure robustness
but this won't prevent developer from introducing new use cases + the user
can be archived instead if we want to remove him from the pricing.
closesodoo/odoo#158885
Taskid: 3802440
X-original-commit: b55994b4c5e737aae593eb0419f96347ad90bebb
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
The attribute cache is mainly used from the Environment class. The
ormcache attribute using the same name leads to confusion.
Related task:
task-3818968
closesodoo/odoo#155264
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
_read_group doesn't raise an error when we have an aggregate
specification like `order_id.create_date:min`, instead it silently
ignores the `.create_date` part.
We only add a warning in the stable version to avoid breaking any
change.
closesodoo/odoo#158777
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
- BooleanFavouriteField wasn't translated as the component was using
an untranslated variable instead of relying on the translation of
the template.
Some other translation fixing:
- ID Azienda is very generic, the correct name is Numero REA:
See: https://www.registroimprese.it/codice-fiscale-p.iva-rea
- No one calls a mobile phone "Dispositivo mobile", we already
translate it as the more common "Cellulare" even in the same file
task-3263708
closesodoo/odoo#157949
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Create a cron with an `interval_number` of 0 and change its nextcall so
that it is called soon. When the cron gets executed, the cron worker
enters an infinite loop during the computation of the next nextcall.
The cron now gets disabled with an error message. On the form view,
users now get a warning when `interval_number` is invalid.
closesodoo/odoo#158519
X-original-commit: aaf498ff2acf39f73fe408eab74e82a8d58f6f1b
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
This fixes an issue where access rules are checked on a new record: the
rule domains are evaluated with method filtered_domain(), and one rule
uses the operator 'child_of', which is implemented with a call to
search(). When used with a new record, filtered_domain() returns an
empty recordset instead of the record itself.
By design, the ORM doesn't check security on new records. A base
automation of type 'onchange' will run some server action on a new
record. The server action may still check access rights on the model,
but should not check access rules.
closesodoo/odoo#158309
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
When an addon has an invalid version but is not installable,
there is no need to error out. This situation typically happens
when unmigrated modules are present in the addons path.
closesodoo/odoo#157657
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>
Before this commit, ir.actions.report can be randomed orderer.
closesodoo/odoo#157616
X-original-commit: 1a2b83d8a4fc956e07d6009eb7fc308eb16eedd2
Signed-off-by: Raphael Collet <rco@odoo.com>
Ensure an avatar is generated based on the employee/user name
if no image is provided at the record creation (for internal users only).
closesodoo/odoo#147446
Taskid: 3637523
Related: odoo/enterprise#58646
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Yannick Tivisse <yti@odoo.com>
BaseModel's sorted() has two problems:
- It breaks the prefetch of self for no reason
- When it is called without an argument, it filters out new records
because the search() used in sorted() doesn't return new records.
Keep the same prefetch as self to fix the first problem.
We partially fix/support the second issue, we just avoid filtering out
new records (but we don't actually sort them)
closesodoo/odoo#157145
X-original-commit: 0551c3b7e8e1469dabdb19d6420c544a1654fec5
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
It is possible for a cron to be executed twice at a same moment if the
cron is currently being executed by a cron worker and that a user click
on the "run manually" button from its form view.
closesodoo/odoo#157203
X-original-commit: a45f171eabdb571465d6245bf2a6bccecab53fa0
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
The INFO "Starting job x" and "Job x done" logs are only logged for the
automatic executing of the cron by the cron worker. When running the
cron manually via its form view, no INFO was logged.
The technical support is reporting problems where a cron server action
is running twice at a same moment leading to problems such as
mass-mailing sending emails twice. There is a mutual exclusion mechanism
for cron workers but no exclusion mechanism seems in place for http
worker vs cron worker. Logging the "run manually" actions will help us
figuring out the problems.
X-original-commit: fcc2eabc671557e610688eac93bae333b0a2c119
Part-of: odoo/odoo#157203
`Environment.__new__` expects a Cursor.
Ensure developers pass a Cursor and not another kind of unexpected object.
Passing another object with the same attributes would work during
the creation of the new environment, but then would fail later,
when using the created environment with the wrong `cr` attribute,
with a less comprehensive error.
Task-3796479
closesodoo/odoo#80644
Signed-off-by: Raphael Collet <rco@odoo.com>
-Step to reproduce: add a post_load method in the init of any module,
specify in the manifest like : 'post_load': 'post_load'. in v16 or above
Run
test_manifests of the test_lint module and we will get warning
closesodoo/odoo#156593
X-original-commit: f87473e82af8372346320ca747c1b41d3d5cf3c5
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Screencast are not always enable and a recent change broke the ffmpeg
call. This call was already broken in some ffmpeg versions.
This test will help to ensure this feature continues to work, and will
also test it in different ffmpeg versions during distro builds.
closesodoo/odoo#156738
X-original-commit: a3d6ef64e218683f7455f60d20860b62780be3b9
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This tasks aims to improve the out-of-the-box configuration of the NZ
localization by updating some tax groups, taxes, accounts and default
COA settings.
Task ids 3647518 & 3647460
closesodoo/odoo#154541
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Description of the issue/feature this commit addresses:
There is no localization for Zambia.
Desired behavior after this commit is merged:
This commit adds the base package of the Zambian localization including:
- Default Settings
- Chart of Accounts
- Taxes
- Fiscal Positions
- Reports (BS, P&L, Tax Report)
task-3391861
closesodoo/odoo#150134
Related: odoo/enterprise#54707
Signed-off-by: Josse Colpaert <jco@odoo.com>
Create an attachment with an URL to a static file that does not exists,
e.g. '/web/static/idontexist.png'. Inside your browser try to access
that file, open <localhost:8069/web/static/idontexist.png>. The browser
fails with a "Too Many Redirections" error.
When a path is not found, nor in the static files, nor in the
controllers, `_serve_fallback` kicks in and attempt to find a resource
outside of the router that matches the URL. In case it finds an
attachment with a matching URL, it'll deliver it.
In this specific case, it finds our attachment and return a redirection
to it's URL, which is the same URL as the request hence it loops back.
Don't deliver URL attachments via `_serve_fallback`, only deliver stored
files.
closesodoo/odoo#156323
X-original-commit: d2bea592db6a66d531b83437d42b273606f629f1
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Reduce the log size in case of failure of a screencast frames
Avoid a race condition while removing tree.
closesodoo/odoo#156341
X-original-commit: 97dc741929eb9497f9b44c110607254f0a873698
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Fix race-condition when a directory is created by two processes (python's os.py
handles it for all directories, but not for the last one). Happens sometimes
when generating assets for the first time (CSS, JS); one of the two times might
crash.
sentry-4417110945
closesodoo/odoo#156232
Signed-off-by: Fabien Pinckaers (fp) <fp@odoo.com>
Denis Ledoux