>>> u1 = self.sudo(False).browse(1)
>>> u2 = self.sudo().browse(2)
>>> (u1 + u2).env.su
False
>>> (u2 + u1).env.su
True
Ensure all attachments are always in sudo
Before this commit, a portal user could not go in debug asset
Introduced at 3a98996eed
closesodoo/odoo#80807
X-original-commit: 9f0ce611b2acf5927a7703a7811081c4adbc3f41
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Bug
===
The arguments of the lambda function might be the same as other
variables in the QWeb. In that case the template rendering will crash.
To avoid this issue, we encapsulate the name of the argument to be sure
it's not the same as other variable in the QWeb engine (so the name of
the argument can no longer make the QWeb rendering crash)
Task-2674716
Closes#78392.
Forward-port of 96b09b127028e5c9a83c89acce86e1b6df904c6f
Change the lang of your user, translate the name of some records (e.g.
translate the "Customizable Desk" product to "Bureau personnalisable")
and create a cron that simply log the name of that record. Schedule the
cron to be automatically executed, check the created log entry (setting
> technical > logging) it is the default english name. Go back to the
cron, click "run now" contextual button, check the created log entry: it
is the translated name.
When they are automatically executed by the cron worker, crons run with a
minimal context without lang. When the user clicks on the "run now"
button his context was wrongly used while executing the code.
Closes#45388closesodoo/odoo#80532
Signed-off-by: Julien Castiaux <juc@odoo.com>
When "Saving" a settings wizard, all its settings are written, even if
not modified.
This implies updating ir.default and ir.config.parameter models.
By verifying whether there were effective changes, we can
avoid:
1) the searches to get the corresponding records from database
2) the cache clear triggered by default/parameter updates/creation
This commit thus reduces the queries triggered when saving settings,
but also the queries of future operations, since we avoid clearing
the ORM cache if not needed.
Part-of: odoo/odoo#62249
The settings wizard provides the implied_group logic to add/remove
implied_groups to an existing group (by default base.group_user).
When verifying those special fields (onchange, default_get and execute
calls), ref is called once by group, by field.
E.g. a field
group_broll = fields.Boolean(implied_group="broll")
will trigger two refs ("broll" & "base.group_user") for each
onchange/default_get/execute call on res.config.settings.
This commit uses the cached method to fetch ir.model.data,
avoiding a lot of queries (depending on the fields defined on
res.config.settings model)
Part-of: odoo/odoo#62249
Following the API for ir.model records, the same logic is provided for
ir.module.module records.
This allows to avoid a bunch of queries when modifying/opening settings.
Part-of: odoo/odoo#62249
At create, the ORM fills the missing create values with the defaults,
calling default_get.
In the case of res.config.settings model, the default_get overrides triggers
a lot of operations to manage its custom field logic (config parameters,
defaults, modules installation, ...).
This slows down the creation (and application) of settings updates for "nothing".
This commit ensures the defaults are not recomputed for fields whose value
was provided to the create call, reducing the effective time of settings flow.
Part-of: odoo/odoo#62249
Consider upgrading module 'base' on a database with millions of 'res.partner' records.
The upgrade of country and country state data makes a very costly search to reverse
the dependencies of the non-stored computed field 'contact_address', just for the sake
of invalidating its value from cache, which is most probably not present at all. The
cost of the search is so high that it may prevent from upgrading the module (timeout).
closesodoo/odoo#80251
X-original-commit: b7f9d0b7c3dfbca0f4897a650983a298da811ce1
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The `ir_import_module` module is used by users to upload custom module
data via a zip file. The zip file can contain xml data, xml views and
static files.
Before this commit, the "import module" feature of this module was
broken since the imported module's manifest was lost after the import
was performed.
Now, 'ir.asset' records are created along with the attachments pointing
to the imported static files.
closesodoo/odoo#80120
X-original-commit: ec77577796e72707fbb2077f05067428cebc3c7f
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
- Get a database with millions of files in the checklist (do not ask how
this happened)
- Set a cron timeout low enough so that `autovacuum_job` times out
The file GC will endlessly timeout without being able to delete any
file.
This is due to how the `_file_gc` method is built: we first build the
whole whitelist, then we perform the deletion. With millions of
checklist files, the loop which builds the `whitelist` takes ages. It
ultimately leads to a timeout of the scheduled action, and therefore no
file is deleted.
To avoid this, we delete the files progressively. The checklist is split
in chunks, and we check which files must be GC'd in a given checklist
chunk. This way the files are removed even in case of timeout, meaning
that there will be less files to check during the next run. Eventually
the GC won't timeout anymore.
closesodoo/odoo#79834
X-original-commit: dbae52479062ace9e2b2d376ec2d601d86482f86
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When detecting if the assets where already preprocessed, the method
only the last asset type matching was returned and deleted.
In standard, it should not have any impact as all assets are of the
same type but it may be possible to mix it with external modules.
Sign CLA
closesodoo/odoo#79786
X-original-commit: 0c2f83f4a6c4603d107007ac77c94e6a2805cd81
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Purpose
=======
Hide non-relevant fields for a portal user. E.G. we want to hide the
notification type, the menu customization... Because those fields
make no sense for a portal user.
Force the non-internal user to receive notifications by emails since
they can not open Discuss.
Task-2508521
Part-of: odoo/odoo#77766
Co-authored-by: nounoubensebia <neb@odoo.com>
Purpose
=======
In the `res.users` view, we can add / remove a group of a user with a
simple selection / boolean field.
This trick is done with an override of "fields_get" to return fields
that don't exist, and override the create / write to write on the
"groups_id" when we write on those "virtual fields". So with this trick
we can create new fields in the `res.users` view by just adding a new
group.
So when you write on the virtual fields, it will add / remove a group.
But this implementation will not trigger the on-change of "groups_id"
(because those field do not exist).
With this commit, the "onchange" of `groups_id` field will be triggered
when you write on those virtual fields (and so the computed method
which depends on `groups_id`, e.g. the `share` field).
Task-2508521
Part-of: odoo/odoo#77766
Issue:
When trying to print a Suisse QR bill, if multiple images are presents
in document and they have a url as src, some pictures will not be
displayed.
(Same issue may occur with simple QR code)
Cause:
It's a known issue with wkhtmltopdf: https://github.com/odoo/odoo/commit/2949138a7d84cd6c925ea1745d62f25ef077bb8b
Also, adding css class to body by js break wkhtmltopdf.
Solution:
Replace link by base64 image value (use a function to retrieve base64
image instead of image_url).
Remove class 'l10n_ch_qr' added by js (no need since CSS file didacted
to this report).
Move `_get_qr_code_base64` and `_get_qr_code_url` logic/flow
(since generic) to account module.
Move specific logic like `_get_qr_vals` and
`_get_qr_code_generation_params` to specific module (ex: l10n_ch).
extra: Alter some css for better rendering + update unitest.
opw-2620082
closesodoo/odoo#77643
X-original-commit: 699b6eeac993e3a8d97ae7949170f7e18ca05831
Signed-off-by: Olivier Colson <oco@odoo.com>
`assert_log_admin_access` uses the `name` field of `ir.module.module` for logging.
`assert_log_admin_access` was added to `install_demo` method of `ir.demo` in d345fb649e3e3c1bf141dca49b45503b8b3a7164 but `ir.demo` does not have `name` field, hence causing AttributeError.
The proposed solution here is to use `display_name` instead
closesodoo/odoo#79398
X-original-commit: 9d6f54e7f7219cbbda41129e35682f6a76aae1d4
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Raman Obaid Ahmed (raob) <raob@odoo.com>
Only admin users should be able to load demo data, if needed.
This is only possible from the settings dashboard, and thus,
the method could be decorated.
See: c002e2eb37
* = auth_signup, calendar, im_livechat, snailmail_account, survey, test_mail,
web_editor, website_crm_iap_reveal, website_livechat
The aim of this PR is to improve/fix various flaws and limitation of the current
API, to make it easier to use and more efficient.
Notification are now defined with 3 distinct parts:
- the channel determines which client(s) should receive it
- the type determines how it should be handled
- the payload determines any extra information helpful for handling it
Channel
=======
Business code
-------------
- Record channel is introduced for ease of subscribing to and sending
notifications to specific partners, channels, documents, ...
- String channel is still supported (but it is converted internally to the tuple
channel).
- Tuple channel is still supported without any change (but should be avoided
whenever possible due to its complex syntax).
The channel is no longer sent to the client. When the channel was used for
business purpose, the information it contained has been moved into either the
new type, or the payload itself.
Technical note
--------------
All channels are now internally converted to the tuple (db, ...) channel, which
is necessary for the platform code (saas/sh).
Internally, the bus.bus table is not changed, type and payload are grouped
together into what was (and still is) called message.
Type
====
Type is introduced to uniformize the way notifications are sent and handled.
All existing notifications already had some kind of manually-built type in them.
This is now officially supported at the bus API.
In client code this will allow (to be done in future commits) to register one
handler per specific type, instead of having to iterate and to filter all
received notifications on every handler.
Payload
=======
Payload (ex message) did not change, it can still be anything depending on
business needs.
Few adaptations:
- When the type was included on the payload, the type has been moved to the new
type parameter.
- When the channel was used in business code, its data has been copied into the
payload.
task-1891151
closesodoo/odoo#79201
X-original-commit: 543af27c7d6836ffac9e80ff8490b6ddbd849221
Related: odoo/enterprise#21998
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Following-up to previous commit, this one makes the
`get_translations_for_webclient()` more defensive with regards to the
absence of a `lang` key in the context, rather than relying on callers
to protect it. The rest of the logic was already fine with this.
This allows simplification of the `session_info` logic and removal of
the conditional for `translation_hash`.
Further cleanups in `session_info()`:
- removed a duplicate calls to `session.get_context()`
- removed duplicated resolutions of `request.session.uid`
closesodoo/odoo#79182
X-original-commit: 3eca1a2e58b8c644c0701d33d0c9d0330bdc234f
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
In https://github.com/odoo/odoo/pull/78652 a fix was made in the layout
designer guaranteeing that the company_details field followed the correct
address format set by the company. However, this fix didn't take into account
all company data, making some `format_address`es raise a `KeyError`. This PR
fixes that by using the company_date defined in `_display_address`.
Fixes https://github.com/odoo/odoo/issues/78942closesodoo/odoo#79097
X-original-commit: 3cdc770c4966cef88362f8119a96de5501d21b18
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
Issue:
Our functionality for merging PDFs from multiple vendor bills relies on PyPDF2. It is well-known that PyPDF2 is sometimes unable to manipulate even perfectly normal PDFs. To provide a helpful error message to the user when this happens (i.e. give them the names of the vendor bills corresponding to the offending pdfs), the `_get_unreadeable_pdfs()` function is called right before we try to merge the PDFs in `_merge_pdfs`. This function is meant to identify the offending PDFs and provide them to the user.
However, _get_unreadable_pdfs did not notice the problem with 3 of my customer's pdfs, because the error was only triggered once the PdfFileWriter.write function was called in _merge_pdfs. This function, however, is not called in _get_unreadable_pdfs, therefore, it did not notice that anything was wrong.
Fix:
- Change _get_unreadable_pdfs so that it also makes a call to PdfFileWriter.write
- As soon as PdfFileWriter.write fails once, it will continue failing when we append more PDF streams to the PdfFileWriter. I therefore suggest initialising a different PdfFileWriter at each iteration of the for loop in order for an offending PDF to not cause a false positive on subsequent PDFs.
closesodoo/odoo#78966
X-original-commit: 0b4efd37376223806e7ff7273f520b2d17337bc8
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Some records have NULL create_date. In that case we get a traceback like
below.
```
Traceback (most recent call last):
...
File "/home/odoo/src/odoo/15.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4249, in _compute_field_value
getattr(self, field.compute)()
File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/res_partner.py", line 259, in _compute_avatar_128
super()._compute_avatar_128()
File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/avatar_mixin.py", line 62, in _compute_avatar_128
self._compute_avatar('avatar_128', 'image_128')
File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/res_partner.py", line 263, in _compute_avatar
super(Partner, partners_with_internal_user)._compute_avatar(avatar_field, image_field)
File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/avatar_mixin.py", line 39, in _compute_avatar
avatar = record._avatar_generate_svg()
File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/avatar_mixin.py", line 66, in _avatar_generate_svg
bgcolor = get_hsl_from_seed(self[self._avatar_name_field] + str(self.create_date.timestamp()))
AttributeError: 'bool' object has no attribute 'timestamp'
```
Observed during upgrade request 40906
closesodoo/odoo#78945
X-original-commit: 559d53fd2a0d437fae595dd4700f2607c8de81a8
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
After some analyze on a lot of customer databases, seems like most of the time
their are performance probleme, and big store, it is due to a lot of big file
uploaded without reason. E.g. barcode, photo, ... a small one will be enough.
Now, we decided (in stable) to auto resize these pictures to 1920x1920px
by default and compress it with a quality of 80 when the source is bigger.
You can bypass this behaviour in your specific use case,
using a context key: 'image_no_postprocess' set to True.
You can disable the resize (and quality implicitely)
using an icp: 'base.image_autoresize_max_px' set to '0'.
You can change the default resize (1920x1920) format using an icp:
'base.image_autoresize_max_px' set to '<width>x<height>' (e.g. '1024x768')
You can change the default quality (80) using an icp:
'base.image_autoresize_quality' with a value between 0 and 100 where 0 skip it.
You can change the type of file that will be post process using icp:
'base.image_autoresize_extensions' (subtype of the mimetype comma separated).
Api of image has not be changed in this commit, only refactored to allow to
work with image directly without the need to encode/Decode in base64 the raw.
We decide to keep 1920x1920 by default instead of 1080p to avoid to resize
portrait picture in 1080px and stay consistent with field image_1920 that
return a 1920px image for width or height whatever the orientation.
+ fix some lint diff for ci style in master
closesodoo/odoo#78556
X-original-commit: d9ce0507960f247e1187baf7bd8399f90be237aa
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
There exists an optimization when creating fields to avoid calling
`setup_models()` for fields when creating a custom model, since the
latter already calls `setup_models()`.
We add the same optimization for field selections, so that creating a
custom field with selections only calls `setup_models()` once. Note
that both optimizations are combined when creating custom models with
selection fields: `setup_models()` will be called once for all.
closesodoo/odoo#78514
Related: odoo/enterprise#21746
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before this commit, trying to create a field related to another field in
the same batch raises an error, because the computation of the field
'related_field_id' cannot find the target field in the registry.
The new approach consists in getting the target field from the database
instead. It works when creating fields in batch, because all records
are inserted into the database before the field is computated.
This costs extra queries, but it allows to batch field creation and
avoids multiple calls to setup_models() when creating a model with
partner field in Studio. (see odoo/enterprise#21746)
The creation of a simple custom related field (related="x.y") costs 3
additional queries to determine the target field:
- 2 queries to get a given field on a given model
- 1 query to get the first field's comodel
Part-of: odoo/odoo#78514
Registry updates can be quite expensive (on the order of a second).
When creating new fields, this update is performed *for each field*,
leading to sub-par performances when bulk-creating fields.
Also remove `_existing_field_data` which has been unused since
9afce4805f, and the `clear_caches`
set up for that purpose.
Part-of: odoo/odoo#78514
This commit fixes the case where you have some text after a comment.
Until know, we miss it. Now we render the tail part.
```
<t>
<!-- HIDE Text 1 -->
Text 1
<p>SHOW Text 2</p>
</t>
```
After the fix, Text 1 is correctly rendered
This commit fixes#76628closesodoo/odoo#78782
X-original-commit: 566360b07b4ff6c7290f264d9064400df2b06ca5
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
This is a followup on b6c688caa2, which
has introduced a new bug.
Consider two groups A and B in a given category, where B implies A and
also A.id > B.id. For the sake of simplicity, assume that A.id=2 and
B.id=1. Following the commit above, the name of the group selection
field will be 'sel_groups_1_2'.
Consider a user in group B. Because B implies A, this means that the
user now belongs to both A and B. A call to read() on that user returns
field 'sel_groups_1_2' with value 2, which on the form view appears as
the user belonging to A only.
The error is in read(), which assumes that the group ids in the field
name correspond to the implication order of the groups, which is no
longer the case since b6c688caa2.
closesodoo/odoo#78662
X-original-commit: e73c406671a51e9c1c4872a9e85eebe5656ea38e
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Steps to follow
- Set the thousands_sep of the current lang to an empty string or null
- Create a report
-> The thousand separator from the system locale will be used instead to format numbers
Solution
Use an empty string if there is no thousands separator
opw-2507441
closesodoo/odoo#78384
X-original-commit: 767adf94c3162c1d93d93aa638200f73123f4ab6
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Hubert Van De Walle <hubvd@users.noreply.github.com>
Before this commit: the "Asset changed" log message would display
an incorrect version and name. This commit fixes that.
closesodoo/odoo#78175
X-original-commit: d4350ddace643fefa5951655e53f701b13b45333
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In some cases we migh want to change to a value that isn't the default
one when uninstalling.
For instance: when we uninstall the module `event_sale`, a product has
the field `detailed_type` set to `event`, which is a subtype of `service`.
So we want to update the value to `service` when uninstalling instead of
the default value, which would be `consu` and wouldn't make any sense.
Part-of: odoo/odoo#77876
In the payment_adyen module, files of adyen are added as part of the
assets_frontend bundle. That bundle is lazy loaded on the website... but
those external files were not, as not added within the bundle itself.
This commit fixes that, properly lazy loading "remaining" files
out of a lazy loaded assets bundle.
closesodoo/odoo#77877
X-original-commit: 8dd71bdc42c8d4ab3373a2a0601c93d1687aabca
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
PURPOSE
Help people setuping their mail server with clear labels and form view.
SPECIFICATIONS
Rename Description to Name, as Description indicates a secondary text
field. Add a placeholder to indicate it is used as a functional name
and not a technical field.
Relabel the field for filtering to FROM Filtering. Current From Filter
could lead to think it filters incoming emails which is not the case.
Move button for testing in header as on all form views.
Use radio buttons for authentication and encryption to display available
settings directly to user. This is more user friendly than selection boxes.
Split connection information in two groups: authentication and security.
Each group comes with its options below main radio-based field.
Task-2628092
closesodoo/odoo#76301
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The context key 'validation_views' is used by ir.ui.view to determine
what parts of a view arch must be validated. Its associated value is
either True or a recordset, and having those types leads to unexpected
warnings when creating environments.
Before creating a new environment, the class Environment looks for an
existing environment with the given parameters: cr, uid, context, su.
The comparison of a context where 'validation_views' is a recordset with
another context where 'validation_views' is True, generates the warning
"unsupported operand type(s)"...
We avoid this situation by using ids instead of a recordset for the
value of the validation context key.
closesodoo/odoo#77747
X-original-commit: 210cd625a052a4d3c230a93bcba644c9a31e67ab
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Though it can't really be typechecked it makes clearer what the
expectations are.
closesodoo/odoo#77577
X-original-commit: b28d2f5b9f7ca0656afe8020c1fa4b3c4eb5594b
Related: odoo/enterprise#21336
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
Suppose the TZ is UTC+12 and a user creates a new rate in the morning:
the date will be the day before
The default date should consider the user's timezone.
OPW-2590972
closesodoo/odoo#76914
X-original-commit: 94eb684d83c3afb717f1a548ef02b4449e0db959
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Because the field is stored it doesn't make much sense to have a
context dependency and that can cause significant issues. However
`name_get` looks pretty innocent and it's not necessarily insane to
have a context dependency *there* (or even in the average
`display_name` as they're normally non-stored computed fields).
`_compute_display_name` previously blanked (blacklisted) just a few
context values, but doing the opposite is probably the better idea.
See also: odoo/odoo#68946
OPW-2453956
Task 2500978
closesodoo/odoo#76469
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
PR #75856 introduced a default implementation of group_expand for
Selection fields that set the value of group_expand to True.
However the PR lacked the necessary bits that allow the same behavior
for fields created on the fly instead of through code.
This commit allows the propagation of the group_expand attribute for
fields of type Selection, this commit also exposes the checkbox in the
UI to enable/disable the setting.
closesodoo/odoo#76775
X-original-commit: 1cacc3e53cf722a31bedff7a76f8e5cc6ed45ce0
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When adding an image to the library from an URL, if the URL contains
parameters (e.g. ?width=200&height=200), the link will not be accepted.
In this commit, we remove these parameters from the URL before checking
the image, so that the URL is considered valid.
We also remove these parameters before computing the mimetype of the
image, since it is computed based on the end part of the URL.
task-2618494
Part-of: odoo/odoo#75205
Martin Trigaux