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>
When a submodule overrides an old UNIQUE constraint with a new one,
records in that module may respect the new one and not the old one.
As the old module is updated, it would fail giving an ERROR message,
and therefore blocking the Odoo.sh deployment pipeline.
i.e. website_sale (old): res_users_login_key -> ['login', 'website_id']
base (new): res_users_login_key -> ['login']
With this patch, the error level is changed from ERROR to WARNING,
leaving Odoo.sh free to continue the build deployment, as the error
was not a blocking one.
closesodoo/odoo#79199
X-original-commit: 8ed3641f81502d3a7e9c9bb93771c6f5601a31a9
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@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>
Currently, the domain expression on a many2one field with
negative operator + string values leads to a extra SQL request on the
target model of the many2one which is not optimal and lead to
performance degradation.
Example:
--------
With a simple model A with a one2many (`b_id`) targeting model B (with
a field `b_name` and `_rec_name = b_name`):
The `A.search([('b_id', 'not like', 'OneName')])` will
generate two SQL requests:
- A _name_search on model B and returning ids who match
`('b_name', 'not like', 'OneName')`.
- A other on the model A with the application of the result
of the first one `('b_id', 'in', <returning ids> + [False])`.
Solution:
---------
Avoid the extra SQL request (the first one) and use subquery instead.
We do it by translate the `('b_id', 'in', <returning ids> + [False])`
expression into `['|', ('b_id', 'in', _subquery), ('b_id', '=', False)]`
task-2671476
Part-of: odoo/odoo#78948
* = hr_timesheet, sale_project, test_main_flows
Smaller changes:
- Projects created on the fly (through `name_create`) will now come with a
default `new` stage in order for them to not be empty.
- Removed task auto assign upon creation besides in FSM's 'My tasks' menu.
- Allow the reordering of projects without needing to group by
anything.
- Make `project.task`.`description` and `project.tags`.`name`
translatable.
- Disable the creation of records in the view when clicking on `Tasks
in recurrence` stat button.
- Track the planned date of the task in the chatter
- Disable the creation of records in the view when clicking on
'invoices' stat button and add the kanban view to that action.
- Make milestones completely available to regular project users.
- Remove the 'Documents' button in the project's kanban settings menu.
- Add kanban, pivot and graph views to the 'Hours Recorded' stat button
on projects
- Add the calendar view on the 'Hours Forecast' stat button on projects
- The 'Sales Orders' stat button on the `project.project`'s form view
will now display the amount of sales order linked to the whole
project. So the one linked to the project itself if it exists + all
the tasks. It will also open them, form view if 1 else list view.
- Fix a typo in the settings 'projets' => 'projects'
- The analytic account of the project will now be assigned to the
sales order when a task is created through the 'Create a task in an
existing project' option.
Changed the portal task view to include a sidebar similar to sales
orders, with a simple menu leading to different parts of the screen.
Changed the `project.task` 'rating' stat button:
- The icon will now represent the latest review.
- The action will directly lead to the record's form view if there is
only 1 rating.
- Make some fields readonly in the form view.
- Display the % of satisfaction instead of the number of ratings.
Reorder all stat buttons on the `project.task` form view in this order:
- Products, Worksheet, Sales Order(s), Invoices, Ratings, Hours
Forecast, Parent Task, Tasks in recurrence, Tickets, Quotations and
lastly Customer Preview
Make the status of the project editable directly through the kanban
view. A new widget has been added to handle that properly. When editing
the status through that means, a `project.update` will be created with
the current date and the appropriate status. In addition to that a new
status has been added (only on `project.task`, not `project.status`)
namely `to_define` in order to differentiate new and running projects.
Projects now start with the `to_define` status.
The `project.project`'s rating stat button has been changed in the
following ways:
- The icon will now change in function of the satisfaction percentage,
smile above 66%, meh between 33% and 66% and frown below 33%.
- The color will also change depending on the rate, smile is green, meh
is orange and frown is red.
- The ratings will now be in function of the last 30 days instead of
all time and the action will also filter on those 30 days.
- Change the action name from 'Rating' to 'Ratings'.
`project.project` ticket stat button:
- Will now open the form view when there is only one record.
- Added the activity view.
- Disable the creation of new records.
- Rename the action to 'Tickets'.
Closes: odoo/odoo#75269
See: odoo/enterprise#20334
Task ID: 2611006
Signed-off-by: Laurent Stukkens (ltu) <ltu@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>
- The batch version of get_metadata won't work correctly for the xmlid
returns due to the limit=1 (cause by
718b0f8b63 ). Fix the
previous issue by reversing the order and without limit.
- The read should be read with the correct user.
closesodoo/odoo#79091
X-original-commit: 29a53f19a7729f486cbc6ff69893b8d150c3512d
Signed-off-by: Rémy Voet <ryv@odoo.com>
A related field copies the attributes from its target field, except for
the attributes defined on the related field itself. The implementation
of this feature was not working properly for attributes with a truthy
default value.
closesodoo/odoo#79025
X-original-commit: dec4a7ec478fa02f19dee8c8426c88d17dc3c7f3
Signed-off-by: Raphael Collet (rco) <rco@openerp.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 modules are only adding data/tests/routes/static content.
In this case, it is useless to check the database schema or setup models
in registry.
closesodoo/odoo#78898
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
With a lot of module installed setup_models can be quite slow.
One of the reason for that are the call to resolve_mro.
This operation is fast, but called for a lot of models/fields this
become an important part of get_depends and setup_base.
- This is call once for each models in setup_base
- This is call more than once for each computed_field in get_depends.
The use of a cache shows significative performance improvements.
During the install of a database with all modules, the install times
is reduced by ~3 minutes over ~14
Part-of: odoo/odoo#78898
Co-authored-by: Raphael Collet <rco@odoo.com>
Seems like depending the pillow version, the output image size could differ
from one or two bytes. Now we check the expected size with a tolerance of
+/- 1 byte.
closesodoo/odoo#78965
X-original-commit: 42d3427975592a914b5a61aee304d499750e8afe
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.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>
The current system uses an imperative request/response model to a
communication which is full-duplex and thus (hopefully) more suited to
a reactive approach.
This updates the Chrome runner to:
* use a separate thread for reading from Chrome, which limits stalling
/ buffering
* uses futures for request/response cycles
* uses a callbacks system for events (unrequested messages from
chrome)
The test end (success / failure) is also signaled via a future.
This requires a bit more cleanup as the browser is reused for all
tests of a *class*, so e.g. the results future must be reset between
tests.
Also for convenience add debug logging of WS requests / responses,
it's convenient for looking at a test / tour's traffic.
Part-of: odoo/odoo#77735
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
The real overhead of creating a related field is actually two queries:
- one query in update_db_related, the purpose of this test
- one more query for _compute_related_field_id in flush()
With the previous version of this test, one prefetching done in the
first create was not present in the second create since it was in cache.
The fix clears the caches to make the creation of both fields in the
same situation, such that query counts are compared in a fair way.
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
When using a profiler manually inside the code, and longpolling uses
this part of the code, an error will appear on runbot since gevent
server cannot be profiled properly.
This fix mitigate the issue by disabling the profiler automatically in
this case.
Part-of: odoo/odoo#78514
When installing a database with all modules in enterprise,
install take around 20 minutes and almost half of that is spent in the
`setup_model` method.
There is actually two calls to `setup_models` for each module.
One of them was introduced in b5c50fa824
and only looks useful when upgrading a module with migration scripts.
This first fix proposes to skip `setup_models` if the module state is
`to install`.
closesodoo/odoo#78808
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
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>
With the release of Debian Bullseye the time has come for the balancing
act by trying to update the requirements.
The constraints are the following:
* Stick as close as possible to python3-* Debian packages versions
of the current Debian stable.
* Same but for the Ubuntu LTS version.
* When one of the above package is patched by Debian or Ubuntu
maintainers, set the upstream version that includes the patch if any.
Also, as support for python < 3.7 is dropped, some cleanup can be done.
The `reportlab / pillow` combo is a special case:
* Pillow has to be updated to 8.1.2 as this version includes the
security patches that were added to Ubuntu package 7.0.0 (Focal).
* Reportlab crashes with 8.1.2 with version prior to 3.5.54 [0].
The problem does not occur on Ubuntu Focal as both versions from
the Ubuntu packaging are compatible.
So the reportlab 3.5.59 is chosen as it's the Debian Bullseye version
and to avoid multiple lines for a few minor versions.
[0] https://hg.reportlab.com/hg-public/reportlab/rev/0cf382dab63b
X-original-commit: 794677fb6a3391379200eb2144a6ed372e89c17a
Part-of: odoo/odoo#78781
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>
The processing of the LINK command in a one2many should fail when the
line being linked does not exist. However, there is one case where it
should not fail: when that line existed and was linked before applying
the commands. That use-case may seem strange, but it actually exists:
deleting a line in a sales order automatically deletes the corresponding
reward lines.
closesodoo/odoo#78318
X-original-commit: 4bfe1b5cab10d3171d386d76799a7d7729f49154
Signed-off-by: Raphael Collet (rco) <rco@openerp.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>
As per the logging documentation, it is fine to send arguments that are
not string. Logging takes care of stringifying and injecting the
arguments in the message template.
closesodoo/odoo#78172
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
base: The two elements were not distinguishable by an xpath.
partner_autocomplete: Use new ids in xpath
The class `o_text_overflow` set on the fields was also
preventing the dropdown menu from appearing. This class is
now moved to the `input` tag instead of the while `div`.
closesodoo/odoo#78141
Task: 2638570
X-original-commit: fd7bfbccd45f874d5a826e695858bc75c8467700
Signed-off-by: Florian Daloze (fda) <fda@odoo.com>
A cursor created by a Connection object is not expected to be used with
environments; use registry.cursor() instead.
closesodoo/odoo#78143
X-original-commit: 6aeb73f10953f3547b7cf830718c02a3933df9e0
Signed-off-by: Raphael Collet (rco) <rco@openerp.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>
Martin Trigaux