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
* add t-out to set of text-generation attributes
* fix comment location
* don't handroll `iterancestors()`
* only check the `@string` on the toplevel button, doesn't really make
sense that a button would contain a button in the first place (in
fact it's not allowed per the HTML spec, a button can only contain
*non-interactive phrasing content* cf 4.10.6)
Part-of: odoo/odoo#76581
Clientside, the only key got from an `ir.actions.act_window_close` type
action is 'infos'. But this key isn't a part of the whitelisted
readable fields server side, which means you will get a warning if you
use it.
closesodoo/odoo#76109
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
By activating the profiler debugger, the two qweb options is added. The
qweb templates that need to be rendered are compiled into a new function
to add instructions for saving data.
`Add qweb directive context`
It's a sub-option of "Record sql" or "Record traces", add some context on
thread at current call stack level. This context stored by collector
beside stack and is used by Speedscope to add a level to the stack with
this qweb directive information.
```
directive=t-call='website.layout', xpath=/t/t
t_call_content
directive=t-foreach='5' t-as="'a', xpath=/t/t/div/div
directive=t-esc='website.search([])', xpath=/t/t/div/div/t
execute
```
`Record qweb`
Add profiling data used by ProfilingQwebView widget. In the `ir.profile`
form view, the widget display the duration and number of sql of every qweb
directives with the xml of templates. Every xml is recorded to be
consulted even if the user change the xml templates.
```xml
<t t-call="website.layout">
<div>
<div t-foreach="5" t-as="a">
<t t-esc="website.search([])"/> <!-- will display 5 separate requests -->
</div>
</div>
</t>
```
closesodoo/odoo#74712
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Here is the idea: when creating a view V that inherits another view, and
V only adds elements in the parent view, only the elements added by V
must be validated. The other elements are not modified, and thus do not
need to be validated again. However partial validation cannot be done
when modifying an existing view, or when the view replaces elements in
the parent view. In such cases, the method _check_xml() validates the
whole combined architecture.
The time spent in method _check_xml() to install a database from scratch
with module sale_management went from 2.730s to 2.243s (-18%), and the
number of queries made in the method went from 2283 to 1614 (-29%).
closesodoo/odoo#75796
Related: odoo/enterprise#20633
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Also speed up view validation by not calling fields_get when possible.
This avoids a call that is usually not necessary for validating a view.
Most of the time, fields can be found on the model itself. Only
overridden fields_get() with fake fields are actually useful, like the
one of model 'res.users'.
The time spent in method _check_xml() to install a database from scratch with
module sale_management went from 3.510s to 2.730s (-22%), and the number
of queries made in the method went from 2995 to 2283 (-24%).
Part-of: odoo/odoo#75796
Besides simple code improvements, remove node_info['attr_model'], and
check domain on specific elements. Also refactor _validate_attrs. The
changes have no impact on performance.
Part-of: odoo/odoo#75796
This makes it easier to optimize the algorithms for both cases:
postprocessing without validation, and validation without
postprocessing. Also factor out some common bits like the editability
of nodes.
The net result is a speedup in performance. The time spent in method
_check_xml() to install a database from scratch with module
sale_management went from 4.955s to 3.578s (-28%), and the number of
queries made in the method went from 3779 to 2995 (-21%).
Part-of: odoo/odoo#75796
This generalizes an existing optimization and saves a few time to
validate a view. The time spent in method _check_xml() to install a
database from scratch with module sale_management went from 5.145s to
5.044s (-2%).
Part-of: odoo/odoo#75796
+ Added the 'Trusted Devices' feature
+ Added 'Remember this Device' checkbox on /web/login/totp
+ Added trusted device's OS / browser on Profile > Account Security
Added '2FA Trusted Devices' feature to allow users to remember their
device to bypass the 2FA for the next connections. The trusted devices
are displayed in a 'Trusted Devices' One2Many under the 'Developer API
Keys'. It is possible to revoke all the trusted devices at once with a
special button. It is also possible to revoke one at a time on the
desired one.
Task-id 2523092
closesodoo/odoo#75535
Related: odoo/upgrade#2800
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Martin Trigaux <mat@odoo.com>
Right after some module operation (install, uninstall), the framework
looks for some ir.actions.todo to execute. Currently those actions
cannot be found, because the cursor seems to see the database in the
state it was just before the operation. Simply add the commit() which
was removed by revision 1595c0ee27.
closesodoo/odoo#75980
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
When using profiling on a fresh test database, it can be tedious to
access settings to enable the feature. This commit adds a wizard to help
enabling profiling without accessing the settings when trying to
activate profiling on a administrator session.
closesodoo/odoo#75967
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
When generating some sale order/invoices pdf automatically (via cron for example), the format of the
invoice is not correct (missing style, background image, etc). The html used to generate these pdf's
misses the asset lines (link to css and js files).
The asset lines are not generated because the manifest cache (http.addons_manifest) is empty if we
render a pdf from a cron.
This commit will generate http.addons_manifest if it's not yet done before.
opw-2581621
opw-2597990
opw-2542242
closesodoo/odoo#75092
X-original-commit: 3ae4db7fc8dbc404984e34ac532426d6bf2c6a0f
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Signed-off-by: ThomasBeckers <ThomasBeckers@users.noreply.github.com>
Martin Trigaux