odoo/odoo#87522 introduced the concept to automatically
inline tree, kanban and form views under one2many/many2many fields
within form views.
The goal being for the web client to make less `get_views` calls.
However, currently, automatically inlined form views
under one2many/many2many fields leads
to more triggered onchanges than before,
triggering more field computations than before,
potentially leading to performance issues
as more fields are computed than before.
Besides, they are not visible in the tree/kanban view
and their computation can therefore be considered useless.
At worst, it can even causes bugs, by triggering computation
in places they were not used / do not handle correctly,
as explained in
https://github.com/odoo/odoo/pull/87522#issuecomment-1132554918odoo/odoo#91878
This revision reverts the behavior to automatically inline
form views, while keeping the inlining of kanban/tree views.
However, by reverting this, we re-introduce a limitation
of the web client behavior regarding onchanges,
explained in odoo/odoo#91935.
This is therefore not perfect,
but at least the previous behavior is back.
In the future, work will be done to re-introduce the automatically
inlined form view, while solving both issues:
- Do not trigger more onchanges than necessary,
- Solve the limitation of the web client shown in odoo/odoo#91935closesodoo/odoo#91968
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
It is very common when using kanban view to need a way to declare what
action is executed when clicking on a record. The default action
(switching to form view) is sometimes not what we would like. For
example, clicking on a project kanban record should open the
corresponding tasks, instead of the project form view.
Until this commit, it was not possible to do this simply for a whole
kanban record, however it was possible to add a button with a name and
type attribute to specify the resulting action. This commit introduces
the same idea, but on the complete kanban record, instead of just a sub
element.
To specify the action that should be executed when clicking on a record,
one can now use the 2 attributes 'action' and 'type' (which corresponds
to the 'name' and 'type' attribute for the kanban record. 'name' was
also considered, but it was too weird). For example:
<kanban default_order="name" action="action_brand_model" type="object">
...
</kanban>
Part-of: odoo/odoo#92071
Define "Bootstrap v5 ready" utility-classes to handle font-size.
These classes definitions can be safely removed after migrating to v5.
task-2838625
Part-of: odoo/odoo#90476
Define "Bootstrap v5 ready" utility-classes to handle border-width.
These classes definitions can be safely removed after migrating to v5.
task-2842691
Part-of: odoo/odoo#91298
Since (at least) Chrome 94+, some element's sizing computation returns a
slightly different value (in the order of a fraction of a pixel). Sadly,
due to rounding, this difference has an impact on exact sizing assertion
(specifically in the list view column sizing tests).
As the difference is *really* small, introducing a margin of error (i.e.
<= 1px) looks reasonnable ; as implemented in this commit.
closesodoo/odoo#92203
Forward-port-of: odoo/odoo#92066
X-original-commit: 5f0353814fc314b75a34a38e700bd7f0797dd18d
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Before this commit, patchDate used the machine offset and not the offset
fixed in luxon.
For example:
Date to Patch = 01-01-2000 10:30:00
Machine offset = -120 (UTC-2)
Luxon offset = 360 (UTC+6)
Before:
Patched Date = 01-01-2000 10:30:00 UTC-2
After:
Patched Date = 01-01-2000 02:30:00 UTC-2
closesodoo/odoo#91591
Signed-off-by: Bruno Boi <boi@odoo.com>
Before this commit, the dialog 'View Metadata' open the date in utc since the
refactoring of Owl. It is not coherent with all others dates shown in form.
Now we show the date in the timezone of the current user.
Part-of: odoo/odoo#92108
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
To reproduce
============
- choose boxed layout as document layout in settings
- enable packages in inventory
- set Incoming Shipments of warehouse on 3 steps
- enable detailed operations of *PACK* operation
- create a pack transfer
- in detailed operations tab, set destination pack
- validate the transfer and print the delivery slip
on PDF the line of destination pack is white text on clear gray (unreadable)
Purpose
=======
on that line two style classes are applied and both of them are changing the background color,
`.o_line_section` :
https://github.com/odoo/odoo/blob/9ce6136be700ae426b8910efd2357d16e2f49d7d/addons/web/static/src/scss/layout_boxed.scss#L61-L64
`.page > table:not(.o_main_table) tr td:last-child` :
https://github.com/odoo/odoo/blob/9ce6136be700ae426b8910efd2357d16e2f49d7d/addons/web/static/src/scss/layout_boxed.scss#L73-L75
We are taking the background color from one and the text color from the other one that don't match.
Specification
=============
to solve the issue we set the text color on `.page > table:not(.o_main_table) tr td:last-child` so that when this style class is
applied it has it's own text color, that matches the background, and doesn't take it from an other class.
opw-2841460
closesodoo/odoo#92096
X-original-commit: 4ee580d32f88fa9a13775355c75503678369c421
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
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>
It is now possible to get access to the action context keys when the
search filters are evaluated. This means that a search arch filter like
<filter name="my_filter" domain="[('my_field', '=', context.get("my_value))]"/>
can be safely evaluated if "my_value" is in the action context (or in
the user context or is builtin as before).
closesodoo/odoo#91959
Signed-off-by: Géry Debongnie <ged@odoo.com>
Since Chromium 97, folded `<details>` content has non-zero computed
width and height which returns false-positive QUnit
`assert.isNotVisible()` calls.
In a nutshell, this was introduced in https://bugs.chromium.org/p/chromium/issues/detail?id=1185950
when Chromium implemented the ability for "Find in page" to search in folded
`<details>`. To do so, the `content-visibility` rule was used instead of
`display: none` which, even if functionally similar, has an impact on the
values returned by `getBoundingClientRect()` (i.e. used in
`assert.isNotVisible()`.
A regression report was filled in https://bugs.chromium.org/p/chromium/issues/detail?id=1276028
to highlight this change of behavior. What emerged from this report's
discussion is that Chromium has no intent to revert this change and
instead put the emphasis on avoiding to use `getBoundingClientRect()`
and similar methods for visibility check (even pushing a proposal for a
`Element.isVisible()` API; cf. https://github.com/w3c/csswg-drafts/issues/6850).
This commit works around this issue by forcing the content to `display:
none`, like in the previous Chromium versions.
closesodoo/odoo#91833
X-original-commit: b718e7eb5ceb827f59ac395577408b7bc54aa3f9
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Pierre Paridans (app) <app@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>
Steps to reproduce:
- Have two companies set up
- In settings, check for company 2 the Files Centralization
- For a Product, upload a document
Issue:
The document will not appear in Documents.
It will only appear if the option is checked for company 1
Cause:
The company_id is not fetched correctly throughout the process.
There is a similar solution for the specific `documents` upload route:
https://github.com/odoo/enterprise/blob/bdf712d66c3e5cee70a6b424b69a618fe655a39f/documents/controllers/main.py#L147-L149
Solution:
Get the id directly from the cookies
opw-2774365
closesodoo/odoo#91751
X-original-commit: 46db92d5211c215d07448676e619154390b7147f
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
If applied, this commit will fix the following bug by fixing
the url used to ping the server
Steps to reproduce:
1- open apps with debug mode
2- click on updates
3- the server is read as if it is offline
Bug:
in ecfe85db84 all links are changed
static/src/(img|fonts) => static/(img|fonts) however in this specific
case the server is remote
(https://apps.odoo.com) and it still needs /src/
Fix:
add /src to the url
OPW-2791531
closesodoo/odoo#91112
X-original-commit: bf629cf3063119a5c819f74329a51a0e1a7c172f
Signed-off-by: Géry Debongnie <ged@odoo.com>
The boolean_toggle should only be disabled when there is a readonly
modifier, not when the view is in readonly mode.
Cause of the issue
The input was disabled but the `_onClick` was registered on the
widget root node.
Solution
- Listen for clicks on the input element
- Override the render method to set the disabled prop according to the
readonly modifier.
opw-2739468
closesodoo/odoo#91601
X-original-commit: 29a2402153dc95414dad8c833487e7dd18c8a222
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
Instead of having 4 buttons to select a view in calendar, we start using a
dropdown button with the framework data-hotkey approach.
task-2704432
closesodoo/odoo#81705
Related: odoo/enterprise#23131
Signed-off-by: Arnaud Joset <arj@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>
Since 15.2, when creating an invoice containing both a recipient address and an invoice address, the addresses would both appear on the left, one after the other.
This made reading difficult and the invoice unclear.
Furthermore, the company address wasn't present by default on the invoice : it was only there if a layout had previously been selected.
This PR:
- reverts the behaviour of the company address, i.e. it appears even if no layout is (yet) selected ;
- aligns the delivery and the recipient address on each side of the page when necessary, while not changing the outcome if a single address is given.
Also displays a "title" above the addresses when necessary to make things clearer.
task-2809240
related : https://github.com/odoo/enterprise/pull/27240closesodoo/odoo#91487
X-original-commit: 1e745256fabbec4d6979180d8f792c99be463509
Related: odoo/enterprise#27383
Signed-off-by: Florian Gilbert <flg@odoo.com>
This commit shows the sum of field 'recurring_revenue_monthly' on
leads' kanban progressbar next to the sum of 'expected_revenue',
if the recurring revenu is enabled for logged in user.
taskID-2414576
closesodoo/odoo#66237
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As result of [1], control panel's search menu-items were highlighted
correctly on ':hover', but not using a keyboard.
This commit assigns the default <Dropdown> 'focus' class on both
circumstances.
[1] https://github.com/odoo/odoo/pull/87448
task#2852217
closesodoo/odoo#91206
Related: odoo/enterprise#27355
Signed-off-by: Pierre Paridans (app) <app@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>
Prior to this commit:
- If the color attribute is set on a field on which the user might
not have access to the model / record, a traceback is returned. However,
in the case of a M2O, the name_get would be returned, so its is
a pity that the color raise an access error.
After this commit:
- A search_read is made instead of a read, which returns nothing if
the user does not have access to the model / record and does not raise
a traceback.
closesodoo/odoo#91147
X-original-commit: 3e8744418d629a62e9eacd16dfa4721921e02453
Related: odoo/enterprise#27318
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
purpose of the task is to improve the usability of the base,
base_geolocalize, project and web
task-2764760
closesodoo/odoo#85295
Related: odoo/enterprise#24706
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Now that pyEnv is available, using it in the mock_server lighten the syntax.
task-2582313
closesodoo/odoo#90783
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit adds some commands that can be used in the html editor.
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.
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>
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>
Before this commit, when we go to the project kanban view:
the color displayed on the left of the card isn't totally responsive
when zooming in. there is a gap between content and border of kanban card.
This commit fixes the issue by aading the outline to remove white
space between border and content.
task-2720976
closesodoo/odoo#90897
X-original-commit: 89bc3255ef1496a033389e9c6d3c6eeef46115a3
Related: odoo/enterprise#27116
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Currently, when we go to the planning > config > resource
(editable list view without any record) and create a ersaource
the color picker widget is resized vertically instead of horizontally.
In this commit we have fixed the issue, when there is no record in
the planning_resources list view, the color_picker widget gets 72px width by
default, so we have added a condition that if there is a color_picker widget
in a field, we will calculate the width based on the total fields in the view.
task-2720976
X-original-commit: d047080c18ea4c9314df5f2aefdfb6b7deeef45a
Part-of: odoo/odoo#90897
Before this commit, when we go to the project.task > kanban examples wizard:
small display issue if we zoom in the wizard until we see the scroll bar,
then the left border of the menu disappears.
The commit solve the issue by adding a property height : fit-content that
will adjust content according to the height.
task-2720976
X-original-commit: cabf5bef9c1f0470c171e9f375bb29fc749ad8fa
Part-of: odoo/odoo#90897
When the wizard (new dialog) is opened on the burger menu item, the burger menu does
not close. The burger menu appears on the wizard. It is fixed.
Reproduction Steps
-Installed project application
-Reporting -> Burndown Chart
task-2739646
closesodoo/odoo#90721
X-original-commit: 69821a67ca04d9aa5bb040d93e491c7f75b67232
Related: odoo/enterprise#27027
Signed-off-by: Laurent Stukkens (ltu) <ltu@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>
`res.users` has virtual fields which are emulation of the real fields.
It requires extra check to ignore such fields. BEFORE there was the following
error:
```
undefined is not an object (evaluating 'fieldInfo.depends.length')
```
STEPS: Go to a User record and use the Dev settings to 'Set Defaults'
---
opw-2731081
closesodoo/odoo#90677
X-original-commit: 6320f38332345ca61d472cae87d1e512b95b84c3
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>
Steps to follow:
- Switch the current lang to mongolian
- Go to a list view
- Add a custom filter on a date type field
-> locale() locale mn-MN is not loaded from moment locales!
Cause of the issue
- moment.js tries to use the mongalian locale but it is not present
Solution
Add the mongolian locale (from moment 2.29.2)
opw-2829233
closesodoo/odoo#90704
X-original-commit: 179a4b2f31d8e2e0e2be308917725a05c5b78058
Signed-off-by: Hubert Van De Walle <huvw@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>
the patchDate function had these issues:
./addons/web/static/tests/helpers/utils.js
29:5 error Read-only global 'Date' should not be modified no-global-assign
58:21 error 'date' is already defined no-redeclare
Part-of: odoo/odoo#90578
This commit uses params.displayName instead of params.action.name for calendar views titles.
This allows us, among other things, to use the project name as a title
for the project's tasks calendar view, which is more consistent with other views.
Task-2741733
Part-of: odoo/odoo#86008
Prior to this commit branded UI components were styled exclusively in
raw SCSS using the '$o-brand-odoo' variable.
This leaded to unnecessary code repetitions since, to achieve the same
visual result, each module defined its own classes.
Visual inconsistencies were frequent too since each module defined its
own variations for interactive states (eg :hover).
This commit injects '$o-brand-odoo' into bootstrap's default
'$theme-color' map, allowing the framework to automatically generate
odoo utility/contextual classes.
These classes can be used to handle text, backgrounds, borders and
buttons wherever needed.
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2800721
closesodoo/odoo#87448
Related: odoo/enterprise#25700
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
This commit improves consistency between jQueryUI dropdowns and the
overall UI. It also address inconsistencies between versions allowing
to remove 'dropdown_extra.scss' [1].
Part of the overall v16 SCSS optimization/restyle, task-2704984.
[1] enterprise adaptations: https://github.com/odoo/enterprise/pull/25700
task-2800721
Part-of: odoo/odoo#87448
Review 'o_searchview' menu entries design, improving consistency within
the overall UI.
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2800721
Part-of: odoo/odoo#87448
The recordId parameter was not necessary in the _updateComodelRelationalFields method
of the legacy mock_server
closesodoo/odoo#90497
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Denis Ledoux