Guarded catch promotes bad patterns (using promise rejections as control
flow instead of as errors), as such, we should not use it in non-legacy
code. This commit reworks the exec method of the Mutex utility class to
avoid using it.
closesodoo/odoo#93081
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Now, if you don't have ExternalID for the current record when you open the
'View Metadata' submenu from the debug menu, we add a button to create one.
Part-of: odoo/odoo#92108
This commit adds the possibility to have a custom placeholder in the
command palette depending on the namespace.
closesodoo/odoo#91947
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Until now, when we add to patch the ui size, we would have patched one of the following:
- config.device.{isMobile,size_class}
- (wowl) env.isSmall / env.services.ui.{isSmall/size}
- (legacy) env.device.isMobile
- (legacy/wowl) browser.innerWidth
The issue is that patching one does not affect the others resulting in an incoherent state.
In order to ease ui size patching, the `patchUiSize` method has been introduced. This method
take either a size or a width as parameter (eg. SIZES.SM, 1920) and affect all the properties above.
task-2582313
closesodoo/odoo#91540
Related: odoo/enterprise#27428
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This PR prepares the ground for the one introducing the new environment in the discuss app.
Indeed, switching from `env.browser` to the wowl `browser` makes a lot of noise in the main
PR. In order to reduce this noise, this change is done now.
task-2582313
closesodoo/odoo#91622
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, some dialog's footer buttons were glued to each
other which impacted their readability and usability.
This commit fixes it by properly applying the existing `gap` CSS rule
which defined the spacing between the buttons, and this independently of
the structure of the footer.
Indeed, due to historical reasons, the `.modal-footer` may contain
drastically different structures depending of the kind of modal.
A non-exhaustive list of encountered structures:
- `.modal-footer > button`
- `.modal-footer > div > footer > button`
- `.modal-footer > div > button`
Note: some existing rules already illustrate that in `modal.scss`.
task-2792884
closesodoo/odoo#91371
X-original-commit: d15bfc785d392a7dffadf9489d1d21f449d42ca4
Related: odoo/enterprise#27337
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Purpose
=======
Allow companies to centralize all their knowledge in a specific place they own.
Create wiki-like pages to structure the information and make it easily
available. Leverage those later on while working in the back-end.
Specifications
==============
An article is mainly composed of a title and a body. The later is an html field
that can contain text, images, link to other articles or records from other
models, templates, etc..
Articles will be classified in 4 categories:
- *Workspace:*
The articles are available for each internal users in read or write access.
Only internal users can create, read, modify and delete knowledge articles.
- *Private:*
The articles are only available for the owner. Only internal users
can set an article as private. A private article can be shared to external users
in read access only. If the article is shared with internal users, see Shared
section.
- *Shared:*
The articles are not available for any user except the ones that have been
added as members on it. For the current user, this section contains all the
private article the user shared with someone and all the other's private
articles shared with me.
- *Favorite:* (Additional category for UX)
Articles can be set as favorite and are user specific. Any identified user can
set an article in favorite, as long as the user has access to it. Public users
cannot add articles to favorites. Favorites can be reordered and this ordering
is user specific.
An article can have a parent and multiple children. Each parent and each
children is also an article. Root articles are the highest parent in the
hierarchy and are considered as the *Subject* (aka Topic) of their whole
hierarchy. There is no limit on how many levels there are in the hierarchy.
In the 3 first categories, the articles are listed starting for the root
article. The child articles are listed below their parents only if the user has
access to them. It can be that a user has access to an article that is not
listed in knowledge main view because that user has no access to the parent
article. More information about access below.
Categories are based on the root article. If a children is private, because only
accessible by 1 user, and its parent is accessible by everyone, the children
will be listed in Workspace section.
Technical notes
The following domains apply to assign root articles in the different categories:
- Private: permission 'none', only member = uid
- Shared: permission 'none', more than one member with read/write access
- Workspace: other
In addition, the UX category
- Favorite: is_user_favorite = True (can contain articles from any category)
Home View (backend)
===================
The main knowledge view is a tweaked form view that displays all the accessible
root articles and their accessible children in a side panel hierarchic tree.
This side panel allow quick access to each articles without having to navigate
back to a list or kanban view. This form view mainly displays the title and the
body but also integrate custom buttons to manage and search the articles.
All those buttons + the side panel are detailed below.
This "Home" view is loading displaying the first favorite article of the
user. If the user has no favorite, it falls back to the first root article of
Workspace section.
The default view mode depends on the user access:
- If user can read: readonly mode
- If user can write: edit mode
Search View
-----------
The standard list view will be used as an advanced search to find an article
that cannot be found easily via the command palette (ctrl+K). All the searching
options remains standard (search / filter / group by). Selecting an article in
that view will redirect to the home view (displaying the selected article).
Side Panel
----------
- *Reorder and hierarchy:*
From the side panel, drag and dropping an article can resequence the articles
between them and/or change the parent of the moved article.
Note on reordering:
Each parent have its own sequence for its children. So the sequence is not
common for each articles in the database, but specific for the children of a
same parent. The resequencing is done among the children of the same parent.
If some articles has no parent, there are considered as the root articles and
all root articles have their own sequence too.
- *Create:*
From the hierarchy tree, the user can directly create an article using the '+'
signs:
- as root of Workspace or Private section
- as a child of a target article.
- *Fold/Unfold:*
To speed up Home page loading: only first level is loaded + the articles that
user already unfolded in the past. The app keeps track of unfolded articles per
user (using Local Storage).
- *Icon:*
Each article has an icon associated with it. The user can click on the icon to
change it.
- *Search an article:*
This button opens the command palette to perform a search on articles.
More detail on this in the Advanced Feature section (below).
Article header and Button Menu
------------------------------
- *Breadcrumb:*
Located on the top left of the main view, the breadcrumb can be used to edit the
article title.
- *Favorite:*
Next to the title, a star button can be used to add/remove the article to/from
the favorite.
- *Create:*
Creates a new private root article.
- *Share:*
Opens the permission panel. This is where the user can configure the access on
the article or, if user has no write access, see what are the access rules on the
article. More detail on this panel in the Access Rules section (below).
- *Chatter:*
Toggle the chatter On/Off at the right of the article view.
There users can:
- Send messages and log notes
- Schedule activities
- Follow an article
The following buttons can found in the kebab menu, in which we can also find
who created or edited the article last and when.
- *Move To:*
Opens a modal to select the parent under which the current article should be
moved. The article will be placed as the last children of the selected parent.
- *Lock:*
When activated, prevents all edition of the article content (body and title)
until it is unlocked. (Purpose: avoid accidental edits)
- *Duplicate:*
Creates a copy of the current article, under the same parent, but does not copy
the children articles. The new created article will have the same access rules
as the original article.
- *Archive:*
Will archive the current article and all its children. Archived articles can be
retrieved using the Advanced Search (see below for detail) with "Archived"
filter.
- *Full Width:*
By default, the article is centered in the view, to make it easier to read.
If needed, the can activate the full width. This will make the article body take
full width available on the article view. This option impacts the rendering of
article, also in the frontend view. More detail on the Frontend View below.
Body
----
The body is composed of an html field that can be edited using the Odoo Editor
and all its capabilities. Some new commands have been added to enrich the
editor: /template - /file - /article (More details in Advanced Features section)
At the top of the article body, the article icon and cover can be added using
their respective "Add" buttons.
- *Icon:*
Can be modified by simply clicking on it.
- *Cover:*
Can be modified using the "Pen" icon at the top left of the cover,
and deleted using the "Bin" icon at the top right.
Frontend View
=============
The frontend view is basically a simpler version of the backend view where users
can only read the article and add them to their favorites (if user is
identified).
The frontend view is composed of the side panel in the left, the article title
and favorite button on the top and the main body view.
From the side panel, the user can navigate to each available article, reorganize
them favorites and filter the articles using the search bar.
From the main body view, the user can consult the content of the article and
download eventual attached files from the '/file' sections.
Access Rules
============
Basics
------
The access is defined depending on two criteria:
- The Internal Permission
- The article members and their permission
Both have 3 level of permission:
- none (No Access)
- read
- write
The internal Permission is the base permission for internal users. By default,
all internal users can write on the article, unless the permission have been
downgraded to 'Read' or 'No access'.
An internal user however can be added as a member of the article with a
specific permission that applies only for them. This member permission takes the
priority on the internal permission.
The internal users will always be redirected to the backend view when they want
to consult an article.
By default, external users (portal or public users) cannot have access to the
articles, unless they have been added as member. They can only be invited with
read acces on the articles.
External users will always be redirected to the frontend view when they want to
consult an article they have access to.
An administrator (group_system) will always have write access, even if
permissions tell the contrary. However, only the articles they have the
permission to see or write on will be listed in the side panel. They can find
the other articles in the Advanced Search view.
Only the users with write access can edit the article body and title, reorder or
change the parents and children, invite members and edit the access rules of the
article.
- *Constraint:*
An article should always have at least one user having write access on it.
- *Lock mechanism:*
Only users with write access can lock or unlock the article.
when an article is locked, the title and body of the article cannot be edited,
even by a user with write access on it.
Access Inheritance
------------------
By default, a child article inherit the access rules from its parent.
That means that access rules can be defined on the root article and those rules
will apply for each descendant article (children and their own children, etc.).
However, a child article can have specific rules that will apply only on itself
(+ its descendant):
- *Synchronized:*
That can be done by adding a member on that article, or by upgrading any of the
permission based on its parent(s). In that case, the article access rules still
depend on its parent(s). If an additional member is added on the parent,
the child article will still inherit that member. The rules that applies
specifically on the child article have the priority on the inherited rules.
- *Detached:*
When an access rule is downgraded in a child article that initially depends on
parent's access rules, the article access rules are detached from the parent's
access rules. All the access rules that applied on the parent are copied on the
child article and that article is flagged as detached. The children of that
article will, for now on, only depend on it, and not on higher parents anymore.
An detached article can be resyncronized with its parent. In that case, all the
specific access rules that do not apply on its parent will be removed. The child
article will still keep its specific upgraded access rules but will, once again,
depends on its parent.
Share Modal (and access rules application)
------------------------------------------
The share modal (or permission panel) is where the access rules of an article
can be configured.
From there, a user with write access can:
- *Invite new members:*
A modal opens and the user can:
- add existing partners or type email addresses and create new partners
- select the permission that should apply on all selected partners.
If there are external users among the selected partners, only the read access
can be used. That means that if the user select:
- Write permission: the read permission will be given to that partner.
- No Access: The partner will not be added the members.
An invitation email is sent to the invited partner.
If the partner is already registered (has an active user), them can directly
access the article with the link provided in the email. They may need to log in
first.
If a partner is not yet registered (have no user), when using the link provided
in the email, them will be asked to register first, and will be afterwards
redirected to the article.
- *Modify the Internal Permission:*
The user can select the new permission to set for all internal users.
- Special use cases:
- If the user sets internal permission != write, the user will be added as
member with write access. The purpose is to let the user continue to edit the
article.
- When downgrading internal permission on a child article (that depends on its
parent), detach it from parent in terms of access rules.
- when upgrading internal permission on a child article, just set the
permission. The article is not detached from parent, but the article will use
its own internal permission to compute the user accesses.
- *Modify a member's permission:*
The user can select the new permission to set on the target member. The user can
also remove a member.
- Special use cases:
- When downgrading or removing a member based on parent: Detach the article
from it's parent
- When upgrading a member based on parent: add a new member with the selected
permission.
Website Published (Access for public users)
-------------------------------------------
When the Website App is installed, users have the possibility to publish the
articles. When an article is published, everyone can read the article.
- *Internal users* can read a published article even if their permissions does not
allow them to read it. They can access those published articles like every other
articles, still in backend view.
- *Portal users* can read a published article even if their permissions does not
allow them to read it. They can access those published articles like every other
articles, still in frontend view.
- *Public users* can read a published article. They can access it by using the
article link from the frontend view.
Advanced Features
=================
Search and Advanced Search
--------------------------
- *Command Palette:*
Searching is done through the command palette. Just as we have '#' for channels,
'/' for menus and '@' for users, '?' has been added for articles.
The command palet is accessible by either
- Hitting CTRL+K (and then adding ? to search among articles)
- Clicking on the fa-book icon of the chatter, which already
adds the '?' so that one can start searching straight away.
- Clicking on the "Search An Article" button (in the side panel)
while reading another article, where the '?' is automatically added too)
The search result are ordered as followed:
My Favorites > Most Favorites > the rest.
The results display the article name + the subject (highest parent name).
If no results are found and user have write access, them can create a new
(private) article with the search query as title.
- *Advanced Search:*
If the user is not happy with the search results, them can do an
"Advanced Search", which sends me towards a normal Odoo list view where I can
search, filter, groupby, ...
Editor Commands
---------------
Some new editor commands have been added:
- */article:*
This command is available on every html field using the Odoo Editor.
This command allows to add a direct link to the selected knowledge article.
- */file:*
This command is only available in the Knowledge App.
This command allows to add a file (or an image) download button inside the
body. The user can choose a file to add from its own file directory or an
existing attachment already present in the database.
- */template:*
This command is only available in the Knowledge App.
This command allows the user to create a block where them can write and lay out
content destined to be reused by the readers of the article. The lasts will be
able to copy and paste it to send it as message or use it as a description on
other records.
No /command can be added inside a template.
Technical notes:
/file and /template commands can be activated in other modules by adding
knowledge_commands = True on the html field in the view where they should
be activated.
Technical considerations
========================
Access Rules Computation
------------------------
Articles access rules are based on inheritance from parent articles. Purpose is
to avoid making copies of all member rules on each article in the hierarchy.
This allows to lower database storage. The counter part is that the computation
of user accesses is made more complex. Instead of simply reading the article
internal permission and members permissions on the article, access is computed
based on each parent above the article.
To speed up batch compute, user permissions are computed directly with recursive
SQL queries. They collect all the needed information for multiple users (based
on their partner) and multiple articles.
Ordering on is_user_favourite
-----------------------------
To allow ordering on is_user_favourite computed field, the search method have
been overridden to add the favorite articles of the current user to the search
result. This is used in the advanced search view but will also be used in
the ctrl+K command.
Sequences and resequencing
--------------------------
Sequences in knowledge article does not respect the conventional sequencing
(one sequence for all the records of the model). Instead, the sequence is
specific for all children of same parents. Resequence had to be overridden to
take that into account and only resequence the children of same parent, and not
the entire table. Moving an article in the middle of a 'folder' should not
impact the other folders but only the children of that target folder.
Breadcrumb
----------
On the form view, the breadcrumb will be located in the control panel.
For the knowledge module, we needed a headless layout. In the mockup,
the breadcrumb has to be placed within the form sheet.
Unfortunately, the breadcumb is a owl component and its logic is
encapsulated in a function which makes it not editable.
To avoid having to update the core, we will render a custom breadcumb
that will be generated based on the `breadcrumb` parameter passed to the
`init` function of the form view.
Task-2674460
Part-of: odoo/odoo#82315
Co-authored-by: Damien Abeloos <abd@odoo.com>
Co-authored-by: Julien Banken <jbn@odoo.com>
Co-authored-by: David Beguin <dbe@odoo.com>
Co-authored-by: Fabio Barbero <faba@odoo.com>
Co-authored-by: Thibault Delavallee <tde@odoo.com>
Co-authored-by: Aurelien Warnong <awa@odoo.com>
Issue:
Sometime an element with an [accesskey] attribute could be triggered
through the standard mechanism (accesskeys) instead of the hotkey
service mechanism (elements with [data-hotkey] attributes).
Steps to reproduce:
- open a record on a form view with a pager
- open some dialog (without using the keyboard)
- use ALT+N => the pager behind the dialog switch to the next record
This comes from the browser default mechanism for elements with an
[accesskey] attribute.
The hotkey service should have taken over on this standard behavior but
it did not because of the dialog which became the UI active element.
NB: this occurs only on a certain set of browser/OS combination. See the
following table https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/accesskey#try_it
Before this commit:
The hotkey service would take over the accesskey standard behavior ONLY
inside the UI active element.
After this commit:
The hotkey service will always take over the accesskey standard
behavior, disregarding the UI active element.
closesodoo/odoo#91261
X-original-commit: 582963a6a18ea3a2e8d3e050af4978067bfe21e1
Signed-off-by: Bruno Boi <boi@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
That icon is not meant to have a `fa-lg` class. It is a leftover of a
wrong revert. It looks way too big.
Indeed, it didn't have the `fa-lg` class initially.
When the new homemade icons were merged, the new bug icon needed to be
enlarged for some reason, it was done with [1].
It was later reverted with [2] to keep the FA icons when we can,
bringing back the `fa-bug` icon, but replacing the new `oi-large` by
`fa-lg` while the old FA icon didn't need to be enlarged.
[1]: https://github.com/odoo/odoo/commit/4e53953756b26e103efd479148e831b111c093d3
[2]: https://github.com/odoo/odoo/commit/28f910f5bef256ebb17700dea72fed4552e16357closesodoo/odoo#91036
X-original-commit: 503401a3d575fb1c613a7c5230c67fb134f47418
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
This commit introduce a macro system, to allow code to automate user
actions. For now, this is useful for the knowledge application. But in
general, this may be used by any code that want to interact "as a user"
with the web client. For example, we may consider rewriting the tour
system using macros.
Sample macros:
```js
const testMacro = {
name: "test_macro",
onStep: (el, step) => {
console.log("macro step activated", el, step);
},
timeout: 5000,
steps: [
{
trigger: '.dropdown-toggle[title="Home Menu"]',
action: "click",
},
{
trigger: ".wrong-selector",
action: "click",
},
],
};
const testMacro2 = {
name: "test_macro2",
interval: 1000,
steps: [
{
// Open contact application
trigger: '.dropdown-toggle[title="Home Menu"]',
action: "click",
},
{
trigger: '.dropdown-item:contains("Contacts")',
action: "click",
},
{
// click on create button
trigger: () => document.querySelector('button[title="Create record"]'),
action: "click",
},
{
action: () => console.log("we are here..."),
},
{
// input name
trigger: 'div[name="name"] input',
action: "text",
value: "Aaron B.",
},
{
// save
trigger: 'button[title="Save record"]',
action: "click",
},
],
};
/**
* Infinite macro! This also illustrates that macros can be used to do non
* linear sequence of steps.
*/
const testMacro3 = {
name: "test_macro3",
steps: [
{
// Open contact application
trigger: "button.o_form_button_cancel",
action: "click",
},
{
action: () => activateMacro(testMacro3),
},
],
};
const testMacro4 = {
name: "test_macro4",
onError: (error, step, index) => {
console.log(`an error occured at step ${index}`);
console.log(step, error);
},
steps: [
{
// Open contact application
trigger: '.dropdown-toggle[title="Home Menu"]',
action: "click",
},
{
action: () => {
throw new Error("boom");
},
},
],
};
```
closesodoo/odoo#88994
Related: odoo/enterprise#27010
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Since 43463a1 it was not possible anymore to trigger hotkeys
from an editable element excepted through
the hotkey option "bypassEditableProtection".
But there are cases where the editable element may want to always
allow any hotkey: e.g. the command palette search input.
Before This Commit
Impossible to trigger hotkeys from the command palette.
After This Commit
The command palette search input now allows any hotkeys.
closesodoo/odoo#90578
X-original-commit: 72dfe16ec8453ff299c2525431db619ccfdbfdec
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Bruno Boi <boi@odoo.com>
Before this commit
An open dropdown stays opened if any other element stop a click event
closesodoo/odoo#90363
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The current datepicker implementation uses Luxon to send and receive
dates from the client and Moment to create and communicate with the
bootstrap datepicker.
Before this commit: the current database date/time format was used to
convert dates from one system to the other. However there are
inconsistencies in notation for some formats, for which the conversion
could not be made properly.
Now: a static format is used to translate dates and the actual database
format is applied only after both systems have been notified of a date
change.
Tasks 2794506, 2797949
closesodoo/odoo#90422
X-original-commit: 174bc1dfa7b2894f35c288373f5130ec2992a8e8
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previously, the useAssets hook would load the templates from the given
bundles into the qweb instance that was in the environment. In owl 2,
qweb is no longer in the environment, and templates need to be loaded in
the app.
This commit fixes that by exporting a function to load templates in the
main app from assets.js, when the main app is created, it should be
written on the function in a similar vein to renderToString, so that all
further calls to the function will load the templates in that app.
This commit also adds an actual lazy-loading test in the
test_assetsbundle module, as we don't want to pollute the manifest of
web with bundles that only exist for one specific test.
closesodoo/odoo#90122
Related: odoo/enterprise#26776
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Previously, the "debounce" util function was broken when passing
immediate=true, this was caused by the fact that the timeout was not set
to null after being executed, leading the function to always act as
though a call is already scheduled.
This commit basically rewrites the entire debounce function to fix this
problem, simplify the code, and make the API of debounce as close as
possible to underscorejs' debounce utility (with the exception that our
debounce function returns a Promise that gets resolved if and when the
call eventually goes through, and with the extra feature that the
debounced function has a cancel method to cancel the currently scheduled
call)
closesodoo/odoo#90297
X-original-commit: 24c39ba1744d83ef9712ef4d3df7db5baf35bc2e
Related: odoo/enterprise#26821
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, py_js was unabled to evaluate expressions
containing "true" or "false" (boolean values, JS syntax), which
seems reasonnable for a python interpreter. However in Odoo, we
often use that syntax in modifiers (e.g. required="true"). For
that reason, we need to add those two keywords in the evaluation
context.
Part-of: odoo/odoo#87522
*: base_automation, iap, web_tour
Previously, when trying to create a custom dialog, one would need to
extend the base Dialog class and configure it directly on the class,
using separate templates for the body and footer as necessary. This is
very unidiomatic owl code, and it is much more natural to simply extend
Component, and use Dialog at the root of the template, giving it slots
and props to configure its properties and contents.
This commit changes the dialog API to work as described and adapts code
that uses it.
closesodoo/odoo#89113
Enterprise: https://github.com/odoo/enterprise/pull/26462
Related: odoo/enterprise#26462
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit renames the `Commands` object exported by the orm
service into `x2manyCommands`, and adds the magic numbers in that
object.
closesodoo/odoo#87582
Related: odoo/enterprise#25750
Signed-off-by: Géry Debongnie <ged@odoo.com>
Prior this commit the spinner was an image.
After this commit the spinner is an animated SVG. It also improves the
layout of the block_ui component.
task-2750837
closesodoo/odoo#83811
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
This commit simplifies the SCSS of the command palette component.
task-2748052
closesodoo/odoo#83938
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
The purpose of this commit is to allow the removal of the search value
without removing the namespace.
Use case before this commit:
1. I perform a search in the homeMenu;
2. The command palette opens with "/" + my search;
3. I realise that my search is wrong and I would like to delete its
contents;
4. I press control+a to select the content of my search;
5. I press the backspace key;
6. The "/" and my search is deleted;
7. I perform a new search;
8. I realize that I forgot to add "/" at the beginning.
This commit will remove the namespace from the input which will allow
the user to delete the search without adding the namespace.
If the user wants to remove the namespace, they will have to press the
backspace key with an empty input.
If the user wishes to change the namespace, they will have to start
their search with that namespace. This will be removed from the input
and replace the old namespace.
closesodoo/odoo#86926
Task-id: 2768527
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
To reproduce the issue:
(Need a Windows machine)
1. Install Stock
2. Inventory > Products > Products
3. Try to write the diameter symbol (ALT + 155) in the search bar
Error: When pressing the key '1' on the keyboard, the page is redirected
to the Inventory Overview page
Because of hotkeys, it is not possible to use the Windows feature that
allows users to write ASCII characters with ALT+[numerical code from
keypad].
OPW-2731632
closesodoo/odoo#86981
X-original-commit: a0f419c40a8089571839c2f5a6c50d506faf9a0b
Signed-off-by: Bruno Boi <boi@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Prior this commit, the popover arrow was in raw SCSS and used only
the four basic directions (top, right, bottom, left).
After this commit, the popover uses the Bootstrap arrow and this
arrow can also use the additional directions defined in
`position_hooks.js`.
It also revamp the SCSS of the component.
task-2748120
closesodoo/odoo#83646
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Prior this commit the rainbow man was built with many separate SVGs and
a lot of raw SCSS.
This commit refactors the rainbow man in order to use less raw SCSS and
more SVG attributes instead.
It also improves the overall animation with a little rotation of the
rainbow man's head during the fade in animation.
task-2742831
closesodoo/odoo#83403
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, the animation of the rainbow, in the rainbow man
component, didn't work well in Firefox and Safari.
After this commit, this animation works well in every modern browsers.
task-2742831
Part-of: odoo/odoo#83403
Issue introduced with 030b1ba
Before this commit:
The hotkey overlays were not toggleable more than once in a row.
After this commit:
They can be.
closesodoo/odoo#86089
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With this commit, it will be possible to click on the different namespace
in the footer of the command palette to insert the namespace value
directly into the searchValue. The purpose of this feature is to make it
easier to discover how namespaces work.
closesodoo/odoo#82773
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Commit 62ebc97bd8 introduced the
possibility to customise the debounce delay associated with a command
palette search based on namespace. This introduced a concurrency bug
when changing namespace.
Problem:
Let's say we have 2 namespaces with very different debounce delays.
For example, # has 2000 and @ has 0.
1. A user enter "#"
2. He changes his mind before the end of the search. He deletes "#"
and enter "@".
3. The search associated with "@" is resolved before the search for "#".
The associated results are displayed.
4. The search associated with "#" is resolved. The associated results
are displayed.
5. The user does not get the results related to his last search which
are those of "@".
Solution:
When we change the namespace, we will cancel the current search function.
Part-of: odoo/odoo#82773
Before this commit, components used `el` and `trigger` but this works
thanks to LegacyComponent. LegacyComponent has been introduced to ease
the transition from owl 1 to owl 2.
This commit replaces the uses of `el` by `useRef` and `trigger` by
adding callback in props. Without these owl 1 features, components
no longer need to extend LegacyComponent.
This commit also adapts the tests to use `getFixture` instead of `el`.
closesodoo/odoo#85903
Related: odoo/enterprise#25032
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Simon Genin (ges) <ges@odoo.com>
Co-authored-by: luvi <luvi@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Following new policies in terms of product design-language, this commit
will partially revert 546477d reducing the number of `oi` icons.
It will also improve rendering when icons are rendered at our default
font-size (13px), avoiding blur effects when icons use thin lines.
Since fontAwesome will coexists with `oi` longer than expected, the
commit will also review size utility-classes in order to get consistent
result when used in conjunction with fa's ones (notably `fa-lg`).
Part-of: odoo/odoo#85651
Notifications have now a new look and SCSS has been cleaned up
accordingly. This commit is part of v16 overall restyle (task-2704984).
task#2719037
closesodoo/odoo#82524
Related: odoo/enterprise#23580
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
*crm, project
With owl2, the `el` of components is no longer available. It still
works in Odoo on LegacyComponent, which has been introduced to ease
the switch from owl1 to owl2, and we're now incrementally removing
it.
With this commit, the action scrolling helpers no longer rely on
component.el, meaning that views using them (through the hook
`useSetupAction`) no longer need to extend LegacyComponent.
More specifically, we move the action scrolling helpers from core/
to webclient/actions, as those helpers make no sense outside the
context of actions (and thus are unnecessary in the frontend).
Tests have been adapted as well.
closesodoo/odoo#85631
Related: odoo/enterprise#24902
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Part of the overall v16 SCSS optimization/restyle (task-2704984).
Additionally, this commit will fix the border-radius of modals that
should be rounded in community.
task-2734531
closesodoo/odoo#83128
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
All named arguments on the catch block must be used. If for some motive
the named argument on the catch block is not used, its name must begin
with '_'.
closesodoo/odoo#85569
Related: odoo/enterprise#24867
Related: odoo/design-themes#552
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit replaces Component by LegacyComponent when the component
uses removed features from owl 1 like getting its `el` or `trigger` an event.
Some tests are updated to have less LegacyComponent.
Part-of: odoo/odoo#85389
Before this commit, the numbering system used by luxon to parse and
format dates was the one set by the current locale. This means that
any date sent to and received from the server would also be expected
to use the current locale and numbering system. The consequence of
this behavior is that any domain generated by arbitrary dates would
trigger a server error.
This commit forces the numbering system to 'latn' (browser default) for
dates used by the server.
closesodoo/odoo#85487
X-original-commit: c8ef1fcb2277993f90a8e237dbd415de7d1b88bc
Related: odoo/enterprise#24822
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
The commit 62ebc97bd8 introduces a bug
that makes it impossible to use the Command "Debug tools...". When this
Command is called, a crash happens.
closesodoo/odoo#85267
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- JS and DOM registrations are now shaped similarly,
so this help to handle them with the same piece of code
- the keydown event object is now manipulated only in a single function,
so it is clearer what it is used for and when it is eventually
stopped or default prevented.
- some constants were converted from Sets to Arrays because they had
no particular reason to be Sets.
closesodoo/odoo#84969
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Samuel Degueldre