When the user tries to modify the view with an invalid xpath expression,
an XPathSyntaxError traceback will appear.
Steps to produce:
1. Install the Accounting module.
2. Settings > Technical > UI > Views > Open any view
3. Invalidate expr syntax and try to save, thus an error will be generated.
Error: XPathSyntaxError: Invalid expression
This commit handles XPathSyntaxError by raising ValidationError
instead of a traceback.
sentry-4377014622
closesodoo/odoo#139435
X-original-commit: 2af583d0b803b3334b871002e447d3211eb09bc2
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>
Currently, When the user is adding a double hyphen or space or anything within a
comment in a view's architecture and tries to save the view, then an error
occurs.
To reproduce the issue:
1. Go to Settings > Technical > Views > open a view.
2. In View Architecture comment out a line.
3. Add a double hyphen or space or anything within the comment.
4. Then save manually, the error will occur.
To solve this issue the error has been handled using a try-except block in
'parse_html' method.
sentry-4306359331
closesodoo/odoo#132267
X-original-commit: ba6f90fac142ae53995f4fce4b75799e61b95b6c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Saurabh Choraria (sauc) <sauc@odoo.com>
An error occurs when the user attempts to delete the 'database.secret' record,
either by following these steps:
- Enable developer mode.
- Go to Settings > Technical > System Parameters.
- Select the 'database.secret' record and attempt to delete it.
Or when the user tries to update the key for the 'database.secret' record using
the following steps:
- Open the 'database.secret' record.
- Update the value of the key field.
- Save the record.
- The server will stop running and not be accessible.
Error: ValueError: CSRF protection requires a configured database secret
sentry - 4291267997
closesodoo/odoo#131460
X-original-commit: fe694e5b8285ceed99b321c22af534eee25cf282
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
The label was already Status on the field but not in the search view.
"State" is always used for the meaning location.
Sharing the same term meant it was not possible to have two different
translations.
closesodoo/odoo#130444
X-original-commit: 70fcdf30fc842410aafa9e61d2a1903589a15311
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When the user deletes the 'Portal User Template' and when any new portal user
will do signup, then traceback will be generated.
If User deletes the 'Portal User Template', then no new portal user will be
created. Also, new portal user will see the traceback as it is generated in
UI.
Steps To Produce for Portal User Template:-
1) Install the 'auth_signup' module
2) Go to Settings > Users
3) Filter only 'Inactive Users'
4) Delete the 'Portal User Template'
5) Open the Incognito tab and click on 'Don't have an account?'
6) Fill required values and click on the 'Sign Up' button
Traceback will be generated on the portal user side as well as in the
backend (Terminal)
Steps To Produce for Default User Template:-
1) Go to Settings > Users
2) Filter only 'Inactive Users'
3) Delete the 'Default User Template'
4) Try to install 'website' or 'hr_timesheet' module
Traceback will be generated
Applying these changes will resolve this issue.
sentry-4184429514,4274176666,4147914005
closesodoo/odoo#127516
X-original-commit: c3e5bed9307498b435857f7736c20cefde3ed6a7
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Signed-off-by: Urvi Soni (uso) <uso@odoo.com>
JSONDecoderError occurs when users enters invalid JSON format data in
'Default Value' field inside 'User-defined Defaults' and wherever this field is
being accessed to get default value this traceback will be generated.
Steps to reproduce:
1) Install 'Contacts' module.
2) Open 'Settings' > 'Technical' > 'User-defined Defaults'.
3) Click on record 'Language' > 'EDIT' button > in 'Default Value' field enter
any improper JSON format data (e.g 'Maa' : FI ) .
4) Now, open 'Contacts' module > click on 'CREATE' button and traceback would be
generated.
By applying this, it will check for proper JSON format.
Sentry-4169062951
closesodoo/odoo#126932
X-original-commit: 71b32d9ea892c8a79c8eac51b9f394c92c44f45d
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
This error occurs when user import records having value in 'properties' column
which is of datatype, 'properties' and while trying to get attribute from
getattr to get value of converter it is getting default value None. That's why
this error is produced, 'NoneType' object is not callable.
Steps to reproduce:
1) Install 'CRM' module.
2) Open 'CRM' module and in it click on 'List' view.
3) Open any record and add value for field 'Add a property'.
4) Export that records.
5) Now click on 'Favourites' > 'Import records'.
6) Now click on 'UPLOAD FILE' button > upload that exported file.
7) Now click on 'TEST' button, error will be generated.
By applying this, user will be able to import record of datatype
'properties'.
Sentry-4128524668
closesodoo/odoo#126609
X-original-commit: b80d4294a000e748677a3a0c1849140bf46ddbe8
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Before this commit:
`id` cannot be set as the dependency for a field's compute method.
So, when a user configures `id` as a dependency for a studio field's compute,
there is no error shown to the user and
the field is saved with `id` as a dependency.
After this commit:
It will throw a `UserError` to the user.
sentry-3979435039
closesodoo/odoo#124660
X-original-commit: 9eab433e09aafafd3015f731b9ec449965d97748
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
before this commit, if tries to delete a user group
which is linked with a field in settings, ie, via
implied_groups in res.config.settings or used in the
field group, there is no restriction and user group
will get deleted.
and then if user tries to access any settings page
the traceback will be shown to user.
after this commit, on deleting any user group
which is linked with a field in res.config.settings,
a validation message will be shown to the user that
the group cannot be deleted as it is linked with
a settings field.
closesodoo/odoo#123905
X-original-commit: ef3dfd02012e16c88789137f5eb0ec49b22f4df8
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
when the user did a mistake in any view from UI, like missing the closing tag or
did any syntactical mistake in any view (standard or custom view) during that
time XMLSyntaxError is generated. Instead of traceback we can show
ValidationError to User.
Steps To Produce:- (This is only for example)
1) install 'industry_fsm' and make debug mode on
2) Go to 'Project', Open any Project
3) Go to debug mode > Edit View: Kanban
4) remove the 'closing tag' of the 'attribute tag' and try to save.
The error will be generated.
Applying these changes will resolve this issue.
sentry - 4157344102
closesodoo/odoo#121855
X-original-commit: ff6bfbdfd6eaf994e4ceca2cf8770301602c5650
Signed-off-by: Raphael Collet <rco@odoo.com>
The co-model field in `IrField` view is accepting Related Model name
even if it is invalid. And replaces the invalid model name with `_unknown`.
This causes KeyError `display_name` when trying to create or read a record.
To fix that we are adding Validations for the Related Model field when it gets
updated from UI side.
sentry-3933471439
closesodoo/odoo#118052
X-original-commit: e4f7798fd5a5cccd5d385f535fbc21264cb6948b
Signed-off-by: Rémy Voet <ryv@odoo.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit aims at preventing the deactivation of a company currency.
Was the issue on 2852452 support ticket (v14). But it seems appropriate to merge it in 13.0 as it is probably a good idea that a company currency always stays active.
How to reproduce bug:
In 13.0:
Install accounting with demo data > activate multi currency in settings > deactivate usd > create new invoice > select eur currency > cannot set usd currency back on invoice
Reconcile JS traceback in 14.0:
Install accounting with demo data > activate multi currency in settings > deactivate usd > go to accounting dashboard > click on reconcile 7 items on Bank journal > click on any “customer/vendor matching” line.
closesodoo/odoo#115444
Task: 2852452
X-original-commit: 09cb57446d99a48651cbfeeb5405029bc2d77226
Related: odoo/enterprise#38255
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
This commit adds a check to prevent saving a translation in a language that was not installed.
Upon adding a translation, the field "language" in the request was not checker,
allowing to add translation for language (or any strings as key) for a given field
This is not ideal and we want to prevent that, it can bloat the database for no reason.
opw-3208305
closesodoo/odoo#114793
X-original-commit: 89cd5ce88a0c666e811410e264e3cb474f9851c0
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Steps:
- Create new rate in random currency (for example USD)
- Try to put 0 in USD per Unit
- Try to put 0 in Unit per USD
Two errors are raised: ZeroDivisionError and Expected singleton
sentry-3916858495
sentry-3767286632
closesodoo/odoo#112348
X-original-commit: 3a320f5ec2c772a33dc905ed5b717adb9f134800
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Achraf <abz@odoo.com>
To that end, we will now do the VIES and regular VAT
check separately.
The VAT check stays as a constrains, while the VIES
check will now be done in an onchange and simply
display a warning if it fails.
We will also now allow VAT with a single character to
ignore the checks. This will allow users to better
distinguish partners for which they didn't enter VAT
against partners which are not subject to VAT by setting
the later's VAT to '/' or any other characters.
Task id #3138441
X-original-commit: eff3b140cc88dd48b77948a577f195f2e1910fd8
Part-of: odoo/odoo#111324
Extracted in its own commit to ease review of next one which is fixing
the sanitize_overide mechanism.
Note that 'Escalated' is meant to be used when talking about "Privilege
Escalation Attack". It's quite misleading when someone is reading this
"error". 'Elevated' is better (confusion brought by internal team).
Since the translation will be broken by this change anyway, the chance
is taken to make it cleaner and more helpful.
X-original-commit: 34235c48bd511d68f513e747dd3f50b9ea6f46d6
Part-of: odoo/odoo#110903
currently the module is named as LT, where as it has to be Lithuania according to odoo localization module standards
closesodoo/odoo#109240
X-original-commit: 84291b92655a260bd75669466c8f66d421fa3e7b
Related: odoo/enterprise#35488
Signed-off-by: Laurent Smet <las@odoo.com>
Home action is first action to do on opening Odoo. Usually, it's an action to
open specific menu. The `action_id` field doesn't have domain and user may
select any action. This commit prevents user selecting action with "reload" tag,
because it would lead to infinite page reloading.
STEPS:
* Set `Open POS Menu` as a Home Action
* reload the page
opw-2900439
closesodoo/odoo#108729
X-original-commit: 5f689f73ca1b5c366cc94af4b84933f9e98a4314
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
currently in the kanban view of the apps, the install button is renamed to activate from https://github.com/odoo/odoo/commit/c70984f4031612d64872fcc12e89c35f03e7d2b2 , but still in the form and action(in tree), button is still labelled as Install, so unifying the label of button to Activate in tree, form and action.
closesodoo/odoo#107907
X-original-commit: 26935d67e62649c10ed907e4a730b8f5ab1f127f
Signed-off-by: Julien Castiaux <juc@odoo.com>
New class `fields.Json` is introduced in v16. The feature lacks some converting
methods for export/import. This commit fills the gap.
Example: field `line_ids/analytic_distribution` in `account.move` (Invoices)
opw-3056669
closesodoo/odoo#105973
X-original-commit: abbe2e002c0125ecb83a1ab3ee80acf3f43e3cb6
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
The initial bug report was the ability to disable all companies
at once and messing up the whole database when you do so.
However, forcing administrators to choose a new company for active users
before archiving a company seems relevant, and solve the
above reported issue in the same time.
closesodoo/odoo#104112
X-original-commit: 786ed3c7a688a662767abfb6e74e7f6dbc938f2e
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Translated fields no longer use the model ir.translation. Instead they store
all their values as JSON, and store them into JSONB columns in the model's
table. The field's column value is either NULL or a JSON dict mapping language
codes to text (the field's value in the corresponding language), and must
contain an entry for key 'en_US' (as it is used as a fallback for all other
languages). Empty text is allowed in translation values, but not NULL.
Here are examples for a field with translate=True:
NULL
{"en_US": "Foo"}
{"en_US": "Foo", "fr_FR": "Bar", "nl_NL": "Baz"}
{"en_US": "Foo", "fr_FR": "", "nl_NL": "Baz"}
Like before, writing False to the field makes it NULL, i.e., False in all
languages. However, writing "" to the field makes its value empty in the
current language, but does not discard the values in the other languages.
Here are examples for a field with translate=xml_translate:
NULL
{"en_US": "<div>Foo<p>Bar</p></div>", "fr_FR": "<div>Fou<p>Barre</p></div>"}
Change for callable(translate) fields: one can now write any value in any
language on such a field. The new value will be adapted in all languages, based
on the mapping of terms between languages in the old values. Basically the
structure of the value must remain the same in all languages, like before.
Reading a translated field is now both simpler and faster than the former
implementation. We fetch the value of the field in the current language by
coalescing its value with the 'en_US' value of the field:
SELECT id, COALESCE(name->>'fr_FR', name->>'en_US') AS name ...
The raw cache of the field contains either None or a dict which is conceptually
a subset of the JSON value in database (except for missing languages). For the
sake of simplicity, most cache operations deal with the dict and return the text
value in the current language.
Trigram indexes have been adapted to the new storing strategy, and should enable
to search in any language. Before this change, only the source value of the
field ('en_US') could be indexed.
Computed stored translated fields are not supported by the framework, because of
the complexity of the computation itself: the field would need to be computed in
all active languages. We chose to not provide any hook to compute a field in
all languages at once, and the framework always invokes a compute method once to
recompute it.
Code translations are no longer stored into the database. They become static,
and are extracted from the PO files when needed. The worker simply uses a cache
with extracted code translations for performance. This is reasonable, since
fr_FR code translations for all modules takes around 2MB of memory, and the
cache can be shared among all registries in the worker. Changing code
translations requires to update the corresponding PO file and reloading the
worker(s).
Performance summary:
(+) reading 'model' translated fields is faster
(+) reading 'model_terms' translated fields is much faster (no need to inject
translations into the source value)
(+) searching translated fields with operator 'ilike' is much faster when the
field is indexed with 'trigram'
(+) updating translated fields requires less ORM flushing
(-) importing translations from PO files is 2x slower
Some extra fixes:
- make field 'name' of ir.actions.actions translated; because of the PG
inheritance, this is necessary to make the column definition consistent in
all models that inherit from ir.actions.actions.
- add some backend API for the web/website client for editing translations
- move methods get_field_string() to model ir.model.fields
- move _load_module_terms to model ir.module.module
- adapt tests in test_impex, test_new_api
- because env.lang is injected into SQL queries, its returned value is
now guaranteed to correspond to a valid active language or None
- remove wizard to insert missing translations (no longer makes sense)
task-id: 2081307
Co-authored-by: Fabien Pinckaers <fp@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
Ensure that the value of binary_field_real_user is a record before using
it.
closesodoo/odoo#92441
X-original-commit: 4ccf918c1596ac0ee104774d98d014708f03e901
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The l10n_sa_invoices changes do not need to be in a separate module as
they are always required for l10n_sa.
This merges the two modules into l10n_sa
closesodoo/odoo#85215
Task: task-2723443
Related: odoo/upgrade#3303
Signed-off-by: Julien Alardot (jual) <jual@odoo.com>
Signed-off-by: Florian Gilbert <flg@odoo.com>
Automated action with a many2many field and reference evaluation can be created but don't work
Steps to reproduce:
1. Install Automated Action Rules module and Contacts app
2. Create an automated action for model 'Contact' with trigger 'On Creation' and action 'Update the Record'
3. Add a line to the automated action 'Data to Write' for the field 'Tags (res.partner)' with evaluation type 'Reference'
4. Go to Contacts, create and save a new one
5. An error is raised when trying to execute the automated action
Solution:
Raise an error when a many2many field is of evaluation type 'Reference'
OPW-2673939
(This PR is a duplicate of https://github.com/odoo/odoo/pull/82035 which for some reason couldn't do the forward ports)
closesodoo/odoo#82168
X-original-commit: 8d45823f2dda24c03b427ecbe7003a64b63d01b7
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
PyPDF2 can't read some PDFs due to bugs, lack of fault-tolerance and not
supporting some encryption schemes. When invoices are uploaded directly
through the Invoices / Accounting app, that will fail for those files
because it will try to read part of them. When invoices are uploaded
through the Documents app, they're not read, which means the customer
can end up in a situation where read and merge operations (like when
printing a selection of original vendor bills) will fail.
The structural solution for this is to replace PyPDF2 with a more capable
library, like pikepdf: https://github.com/odoo/odoo/pull/64356 .
This change is too impactful for stable, and there are compatibility
concerns as well.
A possible workaround is merging the PDFs we can and bundling the rest
together in a zip file. This is possible on the level of just
_merge_pdfs, but the PDF extension and mimetype are pretty hard-coded
and the changes required to switch them to ZIP based on what happens in
_merge_pdfs seem too impactful.
Instead, this fix detects as early as possible if the PDFs can't be
read and reports it to the user. The excluded PDFs can still be
downloaded individually. In this way the user has a workaround
and does not need to resort to trial and error to figure out which PDFs
are causing the problem.
Related tickets: 2359929, 2389679
closesodoo/odoo#69082
X-original-commit: e935cf55975e4bbffcfe29dcfe51b3a91dd0aeab
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Louis (wil)