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>
Non-external tests should not be performing requests to external
websites or services.
Add a mock to handle such requests:
- if the test is not tagged external
- and the request is not to localhost
- and the request is not to `file:` (it's possible to install a
FileAdapter in a session to resolve file URLs)
- raise a connection error (and log, both with some details of the
blocked request for debugging)
The mock is layered on the lowest possible level (`Session.send`), so
tests can either:
- reconfigure the mock to handle cases differently (the mock is
re-created on every test)
- layer their own mock at a higher level of the library
Eventually we might also built-in a routing / dispatch mechanism so
it's easier to declare external services you want to mock, somewhat
similar to what's available client-side.
Whitelist `file:` because e.g. zeep performs `file:` request, using a
bespoke adapter installed in its session.
Part-of: odoo/odoo#128497
This commit introduces the computation of the image size from a webp
binary source without relying on PIL.
This is needed by eCommerce to determine which image to fetch when using
the zoom functionality on the product page.
task-2774352
Part-of: odoo/odoo#85494
`libwebp` cannot be used to perform resize operations on webp images on
the server.
This commit uploads all resizes of webp images whenever a webp image is
uploaded:
- resized to any smaller size in 1024, 512, 256 & 128,
- each size converted to jpg as well to be usable in `wkhtmltopdf`.
When an Image field requires `_imageProcessing` to resize a webp image,
it retrieves the pre-resized image instead of running through the
Pillow toolbox.
Pre-converted images are stored as `ir.attachment`s with:
- `res_model` = ir.attachment
- `res_id` = id of transformed attachment
i.e. id of original size webp for resized images
id of webp for jpeg-converted images
- `description` = "format: image/jpeg" for jpeg conversions,
"resize: [size]" for resized images.
task-2774352
Part-of: odoo/odoo#85494
Wkhtmltopdf is unable to render WebP images.
This commit intercepts the requests for the image data during PDF
reports rendering to replace them by the converted image that was
uploaded with it.
task-2774352
Part-of: odoo/odoo#85494
The library used to generate PDFs does not support the WEBP image
format. For those images to be included in reports, they need to be
converted. For security reasons, this conversion cannot be done on the
server, therefore it was decided to keep an already converted copy of
such images.
This commit converts uploaded WEBP images to JPEG and uploads them both
so that the report generation can use the JPEG instead.
This commit also pre-generates the resized version of images - and JPEG
versions of each of them.
task-2774352
Part-of: odoo/odoo#85494
*: mail, mrp, test_website, web, web_editor
Before this commit '.webp' images could not be used in odoo.
After this commit '.webp' images can be uploaded to odoo.
- can be used in image field
- can be used in HTML field image
- can be used in mails and website
- can be transformed (shape mask, filter effect, crop, rotate, resize,
adjust quality)
task-2774352
Part-of: odoo/odoo#85494
before this commit, if user imports a non valid file,
in the import translation wizard, the users is notified
about the invalid file format by a user error and in
this message .pot is shown as a valid format.
but the only valid format's are csv and po files.
after this commit, the .pot from the user error is removed.
closesodoo/odoo#128422
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The `-i`/`--init` and `-u`/`--update` cli options behavior is only
defined when using a single database with `-d`/`--database`/`db_name`.
Using those two cli options along with multiple databases is undefined
and can have disastrous consequences[^1].
The server now crashes in this situation.
Fixes: #107188Fixes: #128273
[^1]: https://github.com/odoo/odoo/issues/107188#issuecomment-1627996425closesodoo/odoo#128306
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
action_base_document_layout_configurator should always have a dialog_size = 'large'
this ensures that the context from a calling function is not applied
closesodoo/odoo#127630
Related: odoo/enterprise#43770
Related: odoo/upgrade#4918
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Make the user be in at least one of the group employee, public or
portal to be more coherent with Odoo
closesodoo/odoo#125216
Related: odoo/enterprise#42628
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
If a user is not present in the request, he is in no group at all and
can not access any model, including the one available for public
users.
Avoid ambiguity by using sudo or add a user specifically.
Part-of: odoo/odoo#125216
Specify explicit route for each ,, line
This is part of task 3230280 where global ir.model.access will be
forbidden.
The goal is to make access to public/portal explicit. Too often,
global access was granted with only employees in mind.
Remove ,,0,0,0,0 lines
mail:
employee already had read access to mail.group
still needed to subtypes as in ir.rule domain
mail_group: employee already had read access
pos_mercury: only needed for employees
membership:
move public access for website_membership as needed in the controllers
website_customer: employee already had read access
website_event_booth: no need for category
website_event_exhibitor: retrieved in sudo
website_event_track: not needed for location
Part-of: odoo/odoo#125216
The use-case is a first call to onchange2() where:
- a one2many field has a default value with a new line
- some onchange method discards that line
The diff should not return a "delete" command for the discarded line,
since the client does not know about it. Instead, for that first call,
it should behave like if the initial value of the field was empty.
Part-of: odoo/odoo#127718
Oversight in revision
8c38baee85
In SQL,
The underscore character ( _ ) represents a single character
to match a pattern from a word or string.
Meaning
`name LIKE 'x_%'`
allows names starting by `x`, and not names starting by `x_` as expected.
Add the escape in the constraint to enforce starting by `x_`
and not just `x`
closesodoo/odoo#127883
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>
Install POS, go in the settings, add a new cash routing method.
Traceback, the field as no comodel.
The ir.property `search_multi` method wasn't compatible with the
'any'/'not any' operator.
opw-3375624
closesodoo/odoo#127750
X-original-commit: 7dd14eb0b0edb57150288361e72e407e05e67a73
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Co-authored-by: Julien00859 <juc@odoo.com>
`filtered_domain` didn't throw an exception when it is called with a
domain containing the new 'any' and 'not any' operators. Fix it.
X-original-commit: 05713a270bfad406daa9dbf739b80cf8c4d065c0
Part-of: odoo/odoo#127750
Since 5a998694a6,
`[('<many2one>', 'not any', [<domain>])]` matches rows where the
<many2one> is set and the corresponding many2one row matches the
<domain>. This is incorrect. 'not any' should be the inverse of
the 'any' operator and domains such as
`['!', ('partner_id.name', '=', 'System')]` are incorrectly converted
to "Return every record with a partner name != 'System'"
when it should be "Return every record with a partner name != 'System'
OR without partner at all".
Fix semantic and add tests to avoid any future regressions.
X-original-commit: c8c1ef45f24482e380529daf2de55b9091338a83
Part-of: odoo/odoo#127750
The `api.constrains` `_check_name` on `ir.model.fields`
ensures users do not create custom fields not starting with `x_`.
It offers a user-friendly message when users try to do that.
However, this `api.constrains` can be bypassed,
for instance when updating the field name through raw SQL.
This revision aims to no longer load custom fields
if they do not starts with `x_`.
In addition, it replaces the Python constraint
with an SQL constraint in order to have a stronger constraint.
Following bugs or unexpected flows, people
were able to add custom fields not starting with `x_`
with the `api.constrains` alone.
Adding the SQL constraint will tighten the constraint.
However, even without that SQL constraint,
for instance if users drop the SQL constraint manually,
custom field not starting by `x_` must not be loaded.
A user would be able to drop that constraint
through a SQL shell or a `cr.execute` in a server action.
This is to prevent users to override class attributes.
closesodoo/odoo#127702
Related: odoo/upgrade#4908
Before the task
when the default language for a website is not en_US, and users try to
edit_translations from the website, all terms are marked "translated"
because odoo adds
`data-oe-translation-state="to translate"` if the term is not extracted from
the en_US value and is the same as its en_US term
After this commit:
if the record's bounded website's default language is lang_base
odoo adds
`data-oe-translation-state="to translate"` if the term is not extracted from
the lang_base value and is the same as its lang_base term
closesodoo/odoo#127468
Task-id: 3344973
X-original-commit: 7c20510bda2f1312a9392df445ee38aea7b2267b
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Signed-off-by: Chong Wang (cwg) <cwg@odoo.com>
Web lacked a default route for /robots.txt meaning that if you didn't
installed website (which comes with a full fledged robots.txt) you would
get a 404 page not found.
closesodoo/odoo#127402
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Some buttons were stuck together or some had too much of a gap between
them, this commit aims to harmonize the space between buttons.
task-3378519
part of task-3326263
X-original-commit: 68d16f5b2131f44b2dfc3a5d6756aea8987b3fd5
Part-of: odoo/odoo#127613
- simplify initialization of form._values (don't fill in with False)
- use UpdateDict for form._values (more consistent with x2many values)
- better/simpler API for getting save/onchange/all values
- don't reparse subview in O2MForm (already done by toplevel Form)
- guarantee that one2many fields always have an edition view
- add assignment on many2many fields
- add __getitem__/__setitem__ to access/assign fields with dynamic name
Part-of: odoo/odoo#127400
- Improve performances, as the ir.rule restricting private partners
visibility is also applied on res.users by inheritance, on each
prefetch.
- Solve the issue of partners set as followers on records (eg: application
form) and then made private, making them impossible to contact via the
chatter.
- Solve the multiple access issues when trying to access the bank
account, or the private address for non HR people like the accountants
forcing the usage of sudo in the business code.
TaskID: 3101400
- discourage users from changing the currency's rounding precision by
making it editable only before the currency is saved;
- remove the hard-coded dict of minor units that util functions rely on.
task-3076355
closesodoo/odoo#119308
Signed-off-by: Antoine Vandevenne (anv) <anv@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>
In 15.4 (with a226bd983b94a11af9b9785b753634213141127f)
was introduced the from_filter on the system param
and mail servers that would determine which
mail server should be use to send emails out.
In 15.5 (with dbb62515bc1772a79d336e8c2fc0bd1653f1f7ca)
was implemented a fix to prevent the usage of the
archived mail servers.
An email that is going out using an archived outgoing
mail server will be blocked with a specific error msg.
However, when doing specific flows, the context
active_test would be propagate and the function,
doing the search of the mail server to use,
would take into consideration an archived mail server
(the best matching depending on the from_filter param
-- see _find_mail_server fonction).
In order to reproduce this bug, here is one of the way
to do so (on runbot, local needs to add the CLI SMTP
args):
1/ Install sale_management and crm (including contacts).
2/ Add an outgoing email server and archive it.
3/ Go through a contact to an opportunity,
4/ Convert the opportunity to a new quotation,
5/ Send it by email (should be in quotation sent state)
Email will be failed with an error msg
"Connection failed (outgoing mail server problem)".
On the technical > Emails:
The server "<OMS name>" cannot be used because it is archived.
opw-3349593
opw-3341324
closesodoo/odoo#127187
X-original-commit: 716d07b49597ca2583a8e6587f1f530cca5ee8a7
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
A TypeError is thrown when an AST node is passed to `literal_eval`
because a string is expected and the object has no len().
Check the type of the expression and make sure it's a string before
calling len() on it.
closesodoo/odoo#126874
X-original-commit: 28b5cbb33a99cdca00daa35e5ae598cc8d4b2dae
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
* = account{_payment}, base, onboarding, payment{_stripe},
sale{_management}, web, website_sale
Use the dedicated onboarding module introduced in 16.0 instead of
the res.company model to store onboarding progress.
It allows
* onboarding steps to be reused across panels
* to support steps that should be completed per-database or per-company
* to clean the res.company model from many fields and methods,
* to remove many views, controllers, actions
Module-specific notes:
* account: We also clean the remaining two steps that are not
part of an accounting panel but make the most sense to be kept here.
* account_payment: Following 8e4e8eb8, the payment provider step is
added to the invoicing onboarding panel. We apply this change here too.
Also impacts the website_sale_dashboard panel (see related ENT PR).
(The "sale tax" one is currently used for to the website sale dashboard).
* payment: Note that the step was already not part of an onboarding
panel within this module.
* website_sale: We clean
* a field not used (The website_sale dashboard onboarding panel used
the payment_provider_onboarding_state field).
* a method that was only called from website_sale_dashboard, so it is
moved there. See related ENT PR.
Includes a few tests.
Moving views/templates/styling, as well as cleaning residual onboarding-related fields and methods in base, including populate.
This also includes restoring the "onboarding_complete" overlay panel
animating it to disappear after a few seconds so that it doesn't hide
text and block buttons to re-open steps.
Task-3025136
Part-of: odoo/odoo#104223
When exiting a flushing savepoint, the method flush() is invoked before
closing the savepoint (which releases it):
def _close(self, rollback):
if not rollback:
self._cr.flush()
super()._close(rollback)
If method flush() crashes at that point, the savepoint is not closed at
all (because of the exception) and is therefore not even rolled back.
The expected behavior is that the savepoint rollbacks and the exception
bubbles up.
closesodoo/odoo#126866
X-original-commit: 5f9b4f5c998388625de27fbd8fe0f7a0524c04fd
Signed-off-by: Rémy Voet (ryv) <ryv@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
If Automation Actions's configuration is done wrong it will
cause Error at runtime which will be caught in sentry and
causes unnecessary traffic.
So, we stop catching exceptions from Automated Actions.
sentry-4200700020
closesodoo/odoo#126658
X-original-commit: 3479d998417b60807c288c047a1f469329dee59c
Signed-off-by: Achraf Ben Azzouz (abz) <abz@odoo.com>
Purpose
=======
Some SMTP configuration can be used for many domains names. E.G.,
our own SMTP configuration can be used for both "mail.odoo.com" and
"odoo.com". So we want to be able to set a list of allowed domains
name, separated by a comma, instead of a single domain.
Task-3332488
closesodoo/odoo#122234
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The previous commit introduced an optimization to reduce the number of
queries and fields fetched when we call `name_search`. But it works much
better when the dependencies of `display_name` contain field names used
in the calculation (on the same record/model).
Then, to improve the performance and the cache coherency, add `depends`
and `depends_context` depending on the custom `_compute_display_name`.
Add only the first level of dependencies (never traverse relational
field) because only these have a positive impact on the previous
optimization and the cost is very low (see `modified`).
About `depends_context`, we don't include `lang` because (when `_` is
used by example) it is unlikely to get the same display_name in the same
request with two different lang.
closesodoo/odoo#122085
Related: odoo/documentation#4639
Related: odoo/enterprise#42599
Related: odoo/upgrade#4780
Signed-off-by: Raphael Collet <rco@odoo.com>
The `name_search` makes at least 2 SQL requests, one to find the records
and one to read fields needed to compute the `display_name`. With the
default `_compute_display_name`, it only needs to fetch the `_rec_name`
field (if there is one), but the ORM perfetch field mechanism will also
fetch every prefetchable field (see `_fetch_field`).
Then, to avoid running two queries and fetching too many fields, we add
the dependency fields (with `_determine_fields_to_fetch`) to the select
clause of the `Query` returned by `_name_search`.
Part-of: odoo/odoo#122085
Rationale
=========
Since v8, the `display_name` field is present on all models. By default,
`display_name` uses `name_get` which has pretty much the same purpose
(return record name used by the web client). Gradually, many (backend)
developers (and the ORM: https://github.com/odoo/odoo/commit/6da1c3ac4c036eac289597602976538e243cb939)
started using `display_name` (more convenient than
`record.name_get()[0][1]`) but it still had the `name_get` override.
It becomes more complex than necessary and poeple start to misunderstand
the two (and sometimes override both, leading to inconstiencies between
`display_name`/`name_get`).
To simplify the ORM and the API, we decided to keep only one of them,
the `display_name` field:
- It is much more convenient from a backend point of view
(`record.name_get()[0][1]` vs `record.display_name`)
- It is cached during the same transaction (and invalidated if
its dependencies change)
- It can be overridden like any other compute field (override
`_compute_display_name` with any extra dependencies)
- `name_get` is replaced by `read(['display_name'])`
(API perceptive), which can actually be more efficient
(if `display_name`'s depends are correct, the ORM will only fetch the
fields it needs instead of every prefetchable field)
Changes
=======
- Deprecates `name_get` for the v17 and based the method on
`display_name` (the opposite of before)
- Converts all usage of `name_get`
- Overrides of `name_get` are now overrides of `_compute_display_name`
- For `res.partner`, rename the field store `display_name` into
`complete_name` because `display_name` context-dependent and it makes
no sense to have a compute store that is context-dependent.
- Previously, it was possible to return multiple names for the same
record with `name_get`, but it was tricky and most of the usage of
this `name_get` didn't take this into account. The only example of
this is the `name_get` of `product.product`
(now use `", ".join(<names>)`).
Part-of: odoo/odoo#122085
This commit fixes the malformed comment that would sometimes comment out
the rest of the html resulting in an improper display.
this is due to the new html5 notation --!> not behing understood by
our parser.
this commit replaces any --!> into -->.
this commit also remove <!--> or <!--->
opw-2812488
closesodoo/odoo#126148
X-original-commit: 4fed0c36fedf271acc3520d8219763964753dabe
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Since stock.quant are directly related to their lot/serial, we want to be able to show the lot properties on the related quants.
We also want to be able to filter quants based on the properties of their lot/serial.
closesodoo/odoo#125197
Signed-off-by: Arnold Moyaux (arm) <arm@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>
Added few basic rules and folders that are usually common to most localizations.
The template will also serve as documentation on naming conventions (not strict atm).
closesodoo/odoo#121446
Usage: ./odoo_bin scaffold -t l10n_payroll name-code (e.g. estonia-ee) [destination]
Signed-off-by: Kevin Baptiste <kba@odoo.com>
After this commit, underscore library is totally removed.
Library calls has been removed from manifests.
Library files has been deleted.
This commit closed the task below.
task-3246238
closesodoo/odoo#125889
Related: odoo/design-themes#662
Signed-off-by: Samuel Degueldre (sad) <sad@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>
uso-odoo