We added trigram index for char fields since https://github.com/odoo/odoo/pull/83015.
But if `unaccent` is installed in the database (and isn't force to
`False` on field), these new trigram indexes are pointless and cost a
lot for nothing (almost nothing, it still can be used for equality
operator but in this case a btree will be far more efficient).
The simple way to fix it is to add `unaccent(<column>)` in the index
trigram definition, but unfortunately `unaccent` is not immutable and
may therefore not be indexed. In order to make `unaccent` indexable, we
must declare it as immutable (see
https://stackoverflow.com/questions/11005036/does-postgresql-support-accent-insensitive-collations/11007216#11007216
for more information and how to do that).
With this patch, trigram indexes are created with `unaccent(<column>)`
if the function `unaccent` is available in the database, and for the
fields that are not declared with `unaccent=False`. Moreover, we issue
a warning when `unaccent` is available but is not immutable, in which
case most trigram indexes will be useless.
odoo/upgrade#3736
task-2551518
closesodoo/odoo#95943
Signed-off-by: Rémy Voet <ryv@odoo.com>
Have a many2one in an editable list view. Type something in the input and click
on "Create and edit".
Confirm the record creation in the modal.
Before this commit, the input of the field disappears.
After this commit, the input stays.
closesodoo/odoo#99480
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this PR, some mail tests relying on DOM elements being present
but that are added after the messaging initialization could fail
unpredictability. This commit fixes this issue by waiting the next
render following the initialization of messaging.
closesodoo/odoo#99461
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The master plan finally comes to an end.
Thanks to:
- odoo/odoo#87522 refactoring `load_views`,
- odoo/odoo#94337 refactoring `common.Form` to prevent changing
invisible fields in unit tests using `Form` instances,
- odoo/odoo#95729 refactoring the behavior of `groups=` in views,
- odoo/odoo#98551 removing the need of the `groups_id` many2many field
on back-end views.
The result returned by `get_view`/`get_views` can now finally be easily
and efficiently cached, in order to cache back-end views.
The goal of this revision is to cache the model views and fields
already post-processed for the web client
(with the modifiers, etc., already computed)
without group restriction.
Then, from this cached version, post-process group related features,
such as removing nodes restricted with a `groups=` attribute,
set the create/write button according to the user access rights to models, ...
Not including the groups in the cache key allows:
- to have less cached versions,
(otherwise it would be one cached version per different group combination)
- to not have to fetch the user groups to compute the key
(with the current cache key,
there is nothing to fetch from the database to compute the key)
Besides, post-processing the groups features
after taking the view from the cache of the view doesn't take a tremendous time:
- parsing arch from/to string with etree is fast,
- removing the `groups=` nodes using etree is fast,
- adding the `create="False"`, `write="False"`, `delete="False"` on the view
root node according to the access right of the user on the model is fast.
This allows way faster calls to `get_views` by the web client,
as the server no longer need, for each call, to fetch the views in database,
combine the inherited views, post-process the modifiers attributes, etc.
Timing tests are available on the pull request of this revision.
Part-of: odoo/odoo#99417
The cache key of _get_bindings was not super efficient.
The result of _get_bindings is cached,
but its performance was altered by the cache
key which requires to fetch the user groups for each call to
_get_bindings.
Besides, as there is a lot of possible group
combination, this resulted in a lot of possible cache keys,
and therefore a lot of cached values.
This revision aims to make _get_bindings more efficient
by:
- do not use the groups in the cache keys (less cached values)
- filter out actions not available to the user groups after
retrieving them from the cache
- use has_group to do the above, which is itself cached as well,
and therefore do not need to fetch the user groups
at each call to get_bindings.
In addition, move get_bindings from `get_view`
to `get_views`. If there was 3 views asked by `get_views`
(let's say kanban, list, form)
`get_bindings` was being called 3 times, through `get_view`
with each time the same arguments and therefore the same result :-).
Moving it to `get_views` allows to call it only once for all view types
requested, and for the web client it doesn't change much,
as it always request the toolbar/get_bindings through `get_views` only.
In addition, add the lang to the cache of _get_bindings.
it was actually a bug not to put it: if you had 2 users
with the same group set, using 2 different languages,
the user accessing first the get_bindings would cache
the action names within his language, and then the second
user would see the action name within the language of the first user
:-).
Before
```py
In [1]: %time for i in range(1000): self.env['ir.actions.actions'].get_bindings('res.partner'); self.env.invalidate_all();
CPU times: user 790 ms, sys: 104 ms, total: 893 ms
Wall time: 1.7 s
```
After
```py
In [1]: %time for i in range(1000): self.env['ir.actions.actions'].get_bindings('res.partner'); self.env.invalidate_all();
CPU times: user 23.5 ms, sys: 9.12 ms, total: 32.7 ms
Wall time: 36.9 ms
```
Part-of: odoo/odoo#99417
This commit implements the blur feature to the user-video (=not screen
sharing) during video calls using google's MediaPipe library*.
* https://google.github.io/mediapipe/
task-2818116
closesodoo/odoo#94982
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Time comparison can always be slightly random (this is why this test
is a nightly one). The 20% margin left by the 12 ratio is not enough
in all cases. This test was sometime breaking with a
12.944994188420822 not less than or equal to 12
This is one of the max value found by quickly checking the builds.
A ratio of 14 should be hopefully enough.
closesodoo/odoo#99156
X-original-commit: cc86b80342d38913f7af79474c41f8764c8b2dd2
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Before the websockets were introduced, longpolling coroutines were
sleeping until postgres notify. Each coroutine was then wake up and
notifications were fetched.
Since the websocket introduction, the main loop, responsible for listening
to postgres sends the notifications itself. This means, the postgres loop
is blocked during message fetch/dispatching and notifications are dispatched
in a sequential fashion resulting in a slow message dispatching.
In order to solve this issue, websocket coroutines are now responsible to
fetch/dispatch notifications, letting the main loop free to relay notifications
as they come and allowing notifications to be sent simultaneously.
When instructed to dispatch available notifications, the websocket coroutines
will try to acquire a cursor. Each coroutine will try up to `MAX_TRY_ON_POOL_ERROR`
times, sleeping between each try. If no cursor can be acquired, the connection is
closed with the TRY_LATER` close code.
closesodoo/odoo#98880
Signed-off-by: Antony Lesuisse <al@odoo.com>
The present kanban view of acquirers is not the most appealing
one. It is full of useless information (e.g. "online payment") and the
combination of provider logos makes it look "old".
After this commit, the kanban view will hopefully have a "cool" and
concise look simular to the "Apps"'s kanban view.
Task - 284171
closesodoo/odoo#98345
Related: odoo/enterprise#30585
Related: odoo/upgrade#3803
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
This commit improves cards and toggles designs and part of the overall
v16 SCSS optimization/restyle, task-2704984.
The default values of the cards wasn't consistant with the rest of odoo
(ie. default background color value was grey instead of the BS default
which is white) and to avoid these inconsistencies, the card classes
were not used (even though we do have card-like visual elements).
Before this commit, if we wanted to use them, we had to add utility
classes all over the place (ie. the 'bg-white' class) which is not
optimal.
This commit also simplifies toggle's visual rendering by removing
unnecessary graphical elements that were not readable in regular & small
font-size,
In some case the toggle design was even irrelevant with the content and
required unnecessary overrides in css to hide it (ie. it's ok in
Recruitment but not in Payroll).
task-2924487
closesodoo/odoo#98770
Related: odoo/enterprise#29829
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Purpose of this PR to improve generic usage of project app.
So, in this PR done following changes:
- In project.project form view :
- Added name label above name field
- Changed placeholder name of field to 'e.g. Office Party'
- in project_project_view_form_simplified:
- displayed name as Title
- renamed 'create' into 'create project'
- in project.task form view > extra info notebook :
- added the 'personal stage' field (Only visible in debug mode)
- in project.project form view:
- based timesheet encoding unit set the 'cost' field name to Daily cost
if uom in Days or In Hourly cost if uom in Hours
- configuration > projects: if possible, clicking on a project kanban card
will be open its form view
task-2821488
closesodoo/odoo#90588
Related: odoo/enterprise#26977
Related: odoo/upgrade#3492
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
This commit enables eCommerce customers to pay with the express payment
methods Apple Pay and Google Pay from the cart page.
For the moment, only Stripe supports this additional feature but it
was designed to make it easy to implement with a new provider.
task-2754209
closesodoo/odoo#88374
Related: odoo/enterprise#29915
Related: odoo/documentation#2392
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
At present there are two methods of sending/receiving electronic
invoices in odoo.
The first, contained within l10n_it_edi, sends and receives the xml via
a verified email known as 'PEC mail', with use of a fetchmail server. It
is no longer the prefered method.
The second, contained within l10n_it_edi_sdicoop, sends and receives the
xml via a proxy hosted by odoo. The proxy server in turncommunicates
with the 'sdicoop' system. This has become the prefered method.
The 'PEC mail' method of sending/receiving invoices will no longer be
supported. The contents of l10n_it_edi_sdicoop will be merged into
l10n_it_edi and the fields, views, methods, and dependencies
exclussively associated with the old 'PEC mail' are deleted.
There are many instances in which a function was provided in l10n_it_edi
that worked through the fetchmail edi system, and was then overriden in
l10n_it_edi_sdicoop. In this case the content of the overriden method
is replaced with the content of the method that has overriden it.
The manifest has been updated to reflect the slight change in the file
structure (the addition of cron.xml and res_config_settings_views.xml to
the data and views folders respectively). The fetchmail dependency has
also been removed from the manifest.
The tests have been updated to match the restructuring of the module.
The i18n files have been altered to include the relevant translations
from the l10n_it_edi_sdicoop module, and the translation terms that are
made redundant are deleted.
closesodoo/odoo#82581
Related: odoo/upgrade#3828
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>
With this commit, we use the new (owl) FormViewDialog instead of
the legacy one in the "View Metadata" debug item.
closesodoo/odoo#99532
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Since commit fbfc0dc63c that reworked the scss of the KanbanView,
the favorite icon in dashboards was no longer aligned with the
text (for instance, in the Project dashboard). This commit fixes
the issue.
closesodoo/odoo#99503
Related: odoo/enterprise#31033
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Brieuc-brd <brd@odoo.com>
In form views, we want the fields displayed in the "oe_title" div
to take full width. It worked before because we have a rule in
webclient that applies on all almost all kinds of inputs (text,
number,phone...). However, since we wrap fields in a div, those
rules no longer have the wanted effect in our particular usecase.
This commit is a heuristic, but it should solve most of the cases.
It applies on all char fields displayed as title.
Part-of: odoo/odoo#99503
Before this commit, the values in the CoA searchpanel weren't
visible, making it unusable. This was due to the use of bootstrap
classes in /web, which have padding rules that took the priority
over the account customization to make it as thin as possible.
Part-of: odoo/odoo#99503
This class is added automatically on large screens, to better
style the form view to benefit form the available space. However,
the width of dialogs is limited, so it makes no sense to apply
this classname in this case. If we do, those form views may display
an horizontal scrollbar. For instance: in project with worksheets
enabled, create and edit a worksheet many2one.
Part-of: odoo/odoo#99503
Before this commit, if the user multi-edited a field in a list
view, and the widget on that field was legacy, this widget was
displayed in edition in the confirmation dialog. This was because
the "mode" argument wasn't correctly computed in the legacy
compatibility layer. This fix comes with no test as this layer
will be removed in the next week or two.
Part-of: odoo/odoo#99503
website: get_base_url was not working with unprivileged users
Before this commit, when a unprivileged user tried to generate a report
(in sale for example), he could not access to the field website_id on ir.ui.view
An access error would be raised. This commit allows to read the base_url for all users.
Misc: UI for sale order templates
Before this commit, the sale order template information was not clear enough.
Note: these changes were merged into a single commit to ease the manual FW port of
changes in 15.3 for sale_subscription
taskid: 2942621
Since the fields were rewritten in owl, they all have a width of 100% by
default, which is what we want when displaying a field on their own.
In some places, fields are used as part of a longer block of content (eg
unit of measure behind a number). In those cases, we want to display the
field inline, which requires the addition of the oe_inline class in the
arch.
There was also a missing piece of css for the monetary field, as the
previous rule no longer applied because of the slight changes to the DOM
structure.
closesodoo/odoo#99529
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Part of the overall v16 SCSS optimization/restyle, task-2704984
It also introduces BS5 utility-classes for font sizes.
Requires:
- https://github.com/odoo/odoo/pull/87448
task-2812594
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
closesodoo/odoo#88073
Related: odoo/enterprise#31048
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Part of the overall v16 SCSS optimization/restyle, task-2704984
- Converts dropdown into "nav ul li" structure.
- Removing of '.o_burger_menu_user'
- Removing of '.o_burger_menu_app'
- Removing of '.o_menu_sections'
- Removing of '.o_burger_menu_section'
- Some 't-key' not necessary anymore (thx to OWL2)
task-2812594
Part-of: odoo/odoo#88073
Co-authored-by: Adrien Dieudonné <adr@odoo.com>
Not entirely sure about TestAllocationRights. For TestEsEdiCommon
issue is quite obviously that it's inherited by tests which are
external, so when the `post_install_l10n` tag gets applied those tests
get run during "normal" l10n and they break.
closesodoo/odoo#98814
Related: odoo/enterprise#30825
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The linter would require flagging "Common" classes with
`post_install_l10n`, which is incorrect but innocuous before tag
inheritance, however it's incorrect and broken with tag inheritance.
Fix to only apply the lint to actual test containers.
Although eventually the analysis should probably run on the actual
classes, so that the "common" classes can be tagged and the children
don't need to be (since they inherit tagging from their parents).
Part-of: odoo/odoo#98814
The unconditional setting made a lot of sense before the new test
tags (95b4f2ab4b) when the test module
was a test tag: filtering the module out of the existing tags would be
difficult.
However since then the tags should only contain "actual" tags,
therefore inheriting tags (and tagging mixins or Common cases) should
not be an issue anymore.
Part-of: odoo/odoo#98814
*: website_blog, website_event, website_forum, website_hr_recruitment,
website_sale, website_slides
As indicated by previous commits, new custom list views are created to
fill the "Content" area of the main website menu with key app models:
blog posts, events, forum posts, jobs, products and courses (+ some in
the enterprise version, see related commit).
Those list views will act as the page manager one: a click on an item
redirect to the website iframe, the create button acts as creating a
record via the "+ New" systray button while being on the iframe, the
delete button will in the future allow to know the page that mentions
the related object before deleting it, etc etc.
task-2889981
closesodoo/odoo#98937
Related: odoo/enterprise#30782
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_blog, website_forum
A "page manager" list view will be created for key models in other
apps. This commit moves blog and forum views to a dedicated file to
save some history for the future introduction of that "page manager"
list view.
task-2889981
Part-of: odoo/odoo#98937
*: website_event, website_sale
The "Site" menu will now be organized in 3 sub-areas, the last two being
named "Content" and "This page". The first area contains a link to the
website iframe and the menu editor. The "Content" area will contain
menus to list all contents of the website (page, products, events, ...).
This commit only moves the "page" one, the others will be created by
other commits of this PR. The "This page" area contains elements
specific to the page (html editor, page properties, ...).
task-2889981
Part-of: odoo/odoo#98937
After [1], the frontend website page manager was replaced by a custom
'website.page' list view and, with following commits on this PR, this
view will be used with other website content models records (blog,
event, forum, ...) too.
The goal of this commit is to adapt the pages list code to the new Owl
view system.
Other changes (related to the view's behavior) were added in this
commit:
- "Page list action buttons" are removed, we keep only the action that
triggers the form view of 'page.view_id' in debug mode. Page properties
and SEO dialog can be accessed via the website iframe after clicking on
the page entry in the list. The clone button should be later restored as
part of the main website backend menu, still when viewing the iframe.
Meanwhile, it is accessible in page properties. The 'delete' button is
still accessible via page properties too but the standard "delete"
button when selecting records in the list view will later be improved to
act the same way.
- The "website switcher" on top of the list view (to filter records
which impact one website, generic + specific records) is added as part
of the search view. Limitation: it will only be shown for pages at the
moment.
- A standard "Create" button is added and displays the form view dialog
to create a new content record as with "+ New". Known bug: it only
allows to create on the first website at the moment.
- The click on page/content record should redirect to the corresponding
url/website_url in iframe. This is now achieved via the new possibility
of defining an action on the <tree> tag in the view definition. Known
bugs/inconsistency: depending on the model, this opens in edit mode, in
a new tab, ... behavior to unify in a future update.
- The 'PagePropertiesDialogManager' is removed since the code is in Owl
and we don't need page properties dialog on the list view anymore.
Follows the merge of the "website in backend" task at [1].
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2889981
Part-of: odoo/odoo#98937
A "page manager" list view will be created for key models in other
apps. This commit prepares a convention that all other apps will follow:
a dedicated file for the views related to this feature, named
"website_pages_views.xml".
task-2889981
Part-of: odoo/odoo#98937
This commit adds the possibility to use a grid to move and resize
columns inside some building blocks.
More precisely, for the majority of the building blocks having columns,
it is now possible to toggle between the current layout (= normal mode)
and the grid layout (= grid mode). The grid mode can be triggered in
two ways:
- by using the "Grid" button in the options (when available),
- by dragging a column using the move handle.
The toggle places the different columns in the grid as close as
possible as how they were placed in normal mode.
The normal mode is toggled back by clicking on the "Cols" button (when
available).
Since the move handle is now used to trigger the grid mode, the columns
in normal mode are now moved using the arrows.
NB: to avoid any confusion with the word 'column' in the explanation
below, the BS column will be called 'grid item' and the grid column
will be 'column'.
When in grid mode, the building block is a grid with 12 columns and a
number of rows which depends on the height of the grid items.
This mode offers the following functionalities:
- Moving a grid item:
When a grid item is dragged, it can be placed anywhere in the grid. If
it is dragged towards the bottom, new rows are added in the grid to
increase its height and to place the grid item lower. These added rows
are removed when it is dragged towards the top.
A grid item can also be placed over an other item (-> they can overlap)
and their order can be changed using the two new buttons to place an
item in front of/behind all the others.
A grid item can be moved from a grid to another, and also from a grid
to a building block in normal mode.
- Resizing a grid item:
A grid item can be resized vertically, horizontally and diagonally with
the help of the grid. When resized towards the bottom, new rows are
added in the grid and they are removed if it is towards the top (like
with the drag and drop).
- Adding elements:
The "Add Elements" option allows the user to add as many images, text
blocks or buttons as wanted in the grid.
Inner contents can still be dragged and dropped inside a grid item.
- Changing the padding of the grid items:
The padding option allows to change the vertical/horizontal padding of
all the grid items at the same time.
- Mobile view:
When in mobile view, the grid items are not in a grid anymore (the
display is back to flex) but they keep their grid properties. They
cannot be resized, nor dragged and dropped but they can be moved using
the arrows. By moving this way, it does not impact the desktop view.
task-2825241
closesodoo/odoo#93144
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Now trigger an UI update for all the options when clicking on the mobile
preview button. This is at least important for the next commit in this
PR to update the visibility of the different overlay elements as some
will be shown in desktop and some other on mobile.
task-2825241
Part-of: odoo/odoo#93144
Co-authored-by: qsm-odoo <qsm@odoo.com>
When adding an option, using data-select-style with a CSS variable in
data-css-property does not work. This commit adds the support for the
use of these variables.
task-2825241
Part-of: odoo/odoo#93144
*: base, mrp_account, product, mail, website_blog, website_event,
website_forum
This commit improves the button that allows to go to the backend view of
an object when you are on its corresponding page on the website. The
button is more visible and the user can see which object he is going to
edit. Note that this commit also:
- Changes the access key to translate a website page to ALT + T.
- Adds a new access key to edit an object in backend with ALT + E.
- Removes the possibility to duplicate a blog post (but this feature
will be reintroduced later for all models, generically) **.
**: Note that the duplication of blog posts actually had a mistake:
The controller to create a new blog post has been added with [1] where
it has been decided to not be a follower of the blog posts at their
creation. A new controller has been added by [2] to be able to duplicate
a blog post, to be consistent with [1], here also the user does not
become a follower of the new blog post (the copy). So far, so good.
Finally, [3] has changed the blog post creation controller so that the
user who creates the blog post is a follower of the new blog post.
Unfortunately the same change was not made for the duplicate controller,
which is a mistake. There is no reason to be a follower of the newly
created blog posts when you go through the add blog post controller but
not when you go through the duplication controller. The behaviors should
be consistent and there is no reason for there to be a difference.
[1]: https://github.com/odoo/odoo/commit/4c3b516a7b988d758a67ff19242e8ed0837d756c
[2]: https://github.com/odoo/odoo/commit/fe40538aff2b65f7719840c8e2d6e51e858f560f
[3]: https://github.com/odoo/odoo/commit/4bf9dc4078a5ca413539a6fd16400fd5aad46907
task-2889929
closesodoo/odoo#97353
Related: odoo/enterprise#30075
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
This PR adds some trigger to make sure that all python request
is correctly finished. This is needed because an unfinished python request
makes a traceback appears on runbot.
opw-28835921
closesodoo/odoo#99475
X-original-commit: 7a98b59b36e9e2cf1816b73ebc3be5de58e054c2
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
*: website_slides
After [1], the website "new content" dialogs were replaced by formView
dialogs of targeted content (blog, slides, product,...).
The goal of this commit is to restore the "course layout image preview"
on the "New Course" dialog for the "channel_type" field (as on the old
frontend dialog).
Remarks:
- The field was added on 'website' module so it can be used on other
website related modules if needed.
- Some CSS related to the old form was removed in this commit too.
Follows the merge of the "website in backend" task at [1].
[1]: 31cc10b91d
task-2687506
closesodoo/odoo#96346
Related: odoo/enterprise#29922
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Rémy Voet (ryv)