There is an access error when using the product configurator in a mutli-
company environment
Steps to reproduce:
1. Install Sales
2. Go to Settings > General Settings > Companies and create a new
company
3. Go to Settings > Sales > Product Catalog and enable Product
Configurator
4. Switch to the new company
5. Go to Sales > Products > Products and create a new product
6. Set the product's company to the new company
7. Add the 'Color' variant on the product with at least two values
8. Go to Sales > Orders > Quotations and create a new quotation
9. Add the new product to the quotation, the product configurator shows
up
10. Increasing the number of product in the configurator will put the
total to 0 and the http request `/sale/get_combination_info` raises an
access error
Solution:
Pass the company in the context of the rpc call
Problem:
If we are in a secondary company, we try to acces the product of this
company from the default company in `price_compute`, which raises the
error
opw-2826227
closesodoo/odoo#91266
X-original-commit: 5477e1bce1a3791b39d0f6de9d382416fb4b6ebf
Signed-off-by: Guillaume Merlin (megu) <megu@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>
Before this commit, it was not possible to change the internal permission in the permission panel.
This commit fixes that.
Task-2674460
closesodoo/odoo#91283
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>
If applied, this commit will fix the following bug by adding some
restrictions on the creation of analytic default
and the uses of tags in account.move
Steps to reproduce:
1- install account.accountant, account_analytic_default
2- Accounting --> Configuration --> Analytic Tags, analytic accounting
3- Create an Analytic Tag, with no Analytic Distribution.
4- Accounting --> Configuration --> Analytic Default Rules.
Create an Analytic Default Rule, using the Analytic Tag above
and select a Partner
5- Create a Vendor Bill on that partner. The Analytic Tag is added to
the invoice, as expected
6- However when selecting Accounting --> Reporting --> Analytic Report,
the report is empty and does not contain the Analytic Tag. Adding the
Analytic Tag to the filter has no effect.
Bug/Issue:
An analytic tag is meant to be an additional dimension of analysis.
Dimension which is only worth/valid when an analytic account is
specified.
An analytic default rule should never be applied without
- either an analytic account
- or analytic tag used for distribution
Fixes:
1- changing the error condition on creating analytic default
2- changing the error message accordingly to better explain the issue
3- raise an error when the user creates an account.move with analytic
tags without (analytic tags + analytic account) or (analytic tags with
analytic distrubtion)
Please refer to the ticket for the whole discussion on this
OPW-2766749
closesodoo/odoo#91271
X-original-commit: 99c50b9d48448bff54fc5a7c76bbec300bd25d25
Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
With commit that replaced most of the text fields to HTML fields (see
commit[1]), the `description_to_html_lines` method was removed from
`calendar.event` model and linked templates. But another commit[2]
merged afterwards introduced a mail template that used this method,
due to which the rendering used to crashed.
This commit adapts the template and thus fixes the crash while
rendering the template.
commit[1] - https://github.com/odoo/odoo/commit/cb4f597410bcb08208ee277144d755bef8b6d688
commit[2] - https://github.com/odoo/odoo/commit/40fd44f618cb54d8c75b8c090cc36655316aa825
task-2821957
closesodoo/odoo#91280
X-original-commit: 71b9e36f5c5e36f13f26bf74038ddb736d5e25de
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The current implementation is rather non-standard and largely an
ad-hoc pre-RFC implementation, with a number of incompatibilities with
the standard & actual real-world identity providers (IDP).
Tested with the following IDP:
- google oauth v1
- google oauth v3
- auth0
- okta
Add support to bearer Authorization
===================================
Sending the access token via "Authorization: Bearer $TOK" is strongly
recommended by the RFC, and required for all IDP to support. The query
parameter method is a legacy compatibility method and should be
avoided.
Query parameter access tokens are supported by Google (both v1 and
v3), and auth0, but not okta. All three support bearer tokens. However
making this the default is complicated by compatibility issues with
current behavior.
Use standard `sub`ject for identity
===================================
The specification defines `sub` as the userinfo key providing the user
identifier at the IDP.
- auth0, okta, and google v3 use `sub`
- google v1 uses `id`
- google v1's `tokeninfo` (possibly v3 as well, not tested) uses
`user_id`
- odoo replicates the google v1 tokeninfo behavior, using `user_id`
All the code is now standardised on `sub`, with `_auth_oauth_validate`
performing unification under that key.
Support non-json error bodies and WWW-Authenticate
==================================================
Per-spec, there is no requirement for error (userinfo) responses to
return any body, and all error information can be returned via
`WWW-Authenticate`.
Both auth0 and okta return empty bodies on error, though only okta
returns a useful www-authenticate, or relevant 40x statuses (auth0
seems to always return 400, okta has been observed to return both 400
and 401 depending on client error).
Error handling in `_auth_oauth_rpc` has been updated to only parse the
body as json on success (200), and fallback on a generic error payload
if `WWW-Authenticate` doesn't contain relevant information.
Nonce
=====
Okta requires a nonce to be provided.
Misc
====
A few improvements which are in no way required but should make things
simpler / clearer:
- update the default scope to match the standard for the implicit
flow's values (intersected with our requirements)
- update the default google configuration to use the v3 endpoints and
drop the tokeninfo request, remove the explicit scopes
- update the label of `validation_endpoint` to match the official
terminology, same with `auth_endpoint`
- add a label to `body` in order to explain what it's for (as that's
really confusing when the form just says `body` until you hover the
field)
Expected future updates
=======================
These issues were left out and may lead to degraded security, but were
considered too large changes fora stable compatibility-oriented
update:
* store and validate the nonce
* request and properly validate the id token, as well as validate the
access token (implicit guide sections 2.2.1, 2.2.2)
* implement "basic" flow[^basic], and / or "hybrid" flow, the implicit
flow[^implicit] is intended for purely client-side applications
(SPAs), the "authorization code" flow is intended as the primary
flow for normal web applications involving a server component,
the main advantage of the hybrid flow is that the id token *can*
contain the claims selected by `scope`, avoiding the need for the
userinfo request[^idtoken]
* remove support for query parameter requests
* remove support for Google's v1 oauth and subject identifiers other
than `sub`, facebook has not been tested but looks to support that
key as well in the OpenGraph API[^fb], this will require migrating
existing google providers to v3 implicitly (but would allow
simplifying their configuration)
References: RFC 6749, RFC 6750, Implicit Client Implementer's Guide
1.0 draft 23[^implicit]
Closes#88618, closes#64348, fixes#63963, closes#63970,
closes#69568
[^implicit]: https://openid.net/specs/openid-connect-implicit-1_0.html
[^basic]: https://openid.net/specs/openid-connect-basic-1_0.html also
known as "authorization code" flow
[^fb]: https://www.facebook.com/.well-known/openid-configuration
[^idtoken]: during testing, only auth0 returned the additional claims
as part of the id token, but this may be a configuration
issue
closesodoo/odoo#91262
X-original-commit: fb3c4845b1549bc2e1378620a5f01e52aa4dbbdb
Signed-off-by: Xavier Morel (xmo) <xmo@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
closesodoo/odoo#82315
Signed-off-by: David Beguin (dbe) <dbe@odoo.com>
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>
To ease onboarding on the knowledge application, this commit allows to generate
one tutorial/welcome article in the private section of each existing or new
user.
That tutorial article can directly be edited by the users to test all the
functionnality of the Knowledge App.
To avoid generating those articles, a context key can be used:
- knowledge_skip_onboarding_article
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>
This commit adds /articlde command that can be used in the html editor.
Editor Commands
---------------
- */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.
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>
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>
PURPOSE
Set the mailing contact list view multi editable. The editable fields
are 'title', 'country' and 'company name'. Along with that we add the
optional fields 'title_id' and 'country_id' to the view.
LINKS
Task-2832509
closesodoo/odoo#90184
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE:
When a website_event with a submenu is created, some default pages
contain an empty space to lower the footer (see odoo/odoo#89602).
On these pages, the sponsor icons are now at the bottom of the page,
on top of the footer, instead of just below the page title.
Task-2850546
closesodoo/odoo#91045
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Globally improve the main survey.user_input form view to make it more user
friendly.
This includes fields move, new computed fields, a ribbon, ...
SPECIFICATIONS
- Make the Survey User Input model support mail.thread and mail.activity.mixin
This lets us display the chatter on the form view and allows users to
schedule activities.
e.g: discuss a participation among colleagues, add activities to check some
participation because you think the person has cheated, ...
- Add a ribbon on the form view that says "passed" or "failed" according to the
user result
- Introduce a new "Answer" column for the questions list view that is a
modified 'display_name' that displays the answer based on the question type ;
This allows to see the answers at a quick glance without having to drill down
every question to look at the "value_char_box", "value_datetime", ...
- Add the attempts count information in a stat-button, when clicked, the user
is redirected to the list view of all survey attempts of that specific user
for that specific survey
- Re-organize and move some fields
- Hide some advanced information into debug mode
Task-2729604
closesodoo/odoo#83781
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The file extension detection previously used to determine whether a
filename required an extension was not very smart and in fact only
checked for a dot in the filename.
`mimetypes.guess_type` is now used on the filename to better determine
whether the filename still needs a file extension or not.
This commit is a follow-up to: https://github.com/odoo/odoo/pull/90614
Which aimed to fix the same issue.
TaskId-2826061
closesodoo/odoo#91254
X-original-commit: bf904a7f98ba5bcc0a8909cca3241e2965c4464c
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@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>
Before this commit, when hitting enter while not in composition mode,
the editor sometimes removed all the content that was added the previous
composition.
task-4720
closesodoo/odoo#91235
X-original-commit: eddc820417d97b4100a9fb2f9f8934a84bb2417c
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Before this commit, whenever the element that must be deleted by
`deleteBackspace` matches `isMediaElement` or `isNotEditableNode` and
the cursor was in the beginning of a `<p>` with inline content, the
inline content moved to the parent and the `<p>` was deleted.
Which is wrong.
Now, whenever the element that must be deleted by `deleteBackspace`
matches `isMediaElement` or `isNotEditableNode`, no inline content
moves.
Task-2781328
closesodoo/odoo#91233
X-original-commit: 34d06958d053b070b1e07541214899649602873a
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
fieldmany2many tags email test is redundant and error prone (multiple callbacks
relying on nextTick to be called in the right order). Let's remove it.
closesodoo/odoo#91226
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
That way, the method overrides are grouped with the new fields to
propagate between template lines/options and order lines/options.
Eases code comprehension and maintainability.
Part-of: odoo/odoo#91222
* Enforce line length for fields spec
* clean one little useless import
* prefer single quotes for strings not shown to the end user
Part-of: odoo/odoo#91222
Inserting `w.r.t` in the editor transformed it into an url.
This kind of content should not be considered as an url.
task-2795012
closesodoo/odoo#91221
X-original-commit: 75c146fac019b952543403736948b803689bd15b
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
How to reproduce the bug ?
- install hr_payroll and web_studio
- in Settings > Technical > Automated Actions, create a new action
linked to the Payslip model
- Go to the Payslip app and generate a payslip by choosing an employee
that has work entries
What is the bug ?
When you create an automated action, you will overwrite the origin write
function of the model. However, the origin write function will still be
called by the new write function.
In the new write function, the records will be filtered according to
their ids. This means that if a record has a NewId, it will not be
handled. This is the bug here since the payslip is under creation.
opw-2781751
closesodoo/odoo#91217
X-original-commit: 84775d1b261d3faa33b2d1abf4e2e016c718b398
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This provides the possibility to import/export simplified invoices.
Currently, the import of simplified invoices would not work and the export of invoice without customer address would be blocked.
Simplified invoice will be able to be imported and exported if the customer address is incomplete, it's a domestic invoice and the total amount is below 400€
freeze_time was removed as it was unnecesarry and posting invoice would not be done directly as the invoicing date is in the future wrt the frozen time.
closesodoo/odoo#91215
Task: 2800967
X-original-commit: 8dc17c29c7e032d94f45ec5e2e82f9dd871e4952
Signed-off-by: Josse Colpaert <jco@odoo.com>
Bug fixed where when the MRP subcontracting module was installed the merging of MO's would not open the MO form view.
Correctly displays the breadcrumbs as well.
Task: 2799674
Community PR: https://github.com/odoo/odoo/pull/88801
Part-of: odoo/odoo#88801
Prior to this commit the discountable amount on specific products was
not computed correctly when using fixed price discounts as it did not
take the taxes into account.
They will now be taken into account and result in the correct discount.
TaskId-2834863
closesodoo/odoo#91202
X-original-commit: 669f4cca94af0c022318f6cb508c1c197aae0846
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Before this commit, When user has sale order all docuements right, project user right
and try to open a sale order linked with private project then it raises an
access rights error when a user clicks on sales orders in a project, even
though the user has the correct rights due to invalid access on project_ids
field also only project manager was able to see the project stat button on sale order.
so in this commit, make the project stat button visible to project user
and fix the access error on private project for project user.
task-2792884
closesodoo/odoo#91167
X-original-commit: f4e371a4b0903cea92c947b3afc36deee05237da
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
- Show the Odoo version only in debug mode to logged in user, as we do
for the technical module name.
The purpose of this page is to generate some backlinks and improve
(does it really?) the SEO of Odoo.com.
The Odoo version doesn't bring any value and is another way to easily
retrieve DBs based on their version with a simple Google search.
While there is many other ways to do so, let's avoid this one.
- Prior to the introduction of `website.page` and the new page serve
mechanism, there could be template collision when an user would create
a page with the same key/name than the template of this controller.
This is not the case anymore.
We can remove the refresh meta tag.
See [1] and [2].
- The check to see if the template exists is useless, we don't do that
kind of check when rendering a controller, we just assume the view was
not manually deleted by the user.
I guess it was historically useful when people would not want that
/website/info page to be show. But now, there is a clean way to "hide"
this page by simply disabling it in the "Customize" option of the
website in the navbar.
[1]: https://github.com/odoo/odoo/commit/4cfd86edaa27d09f1066dd017bf466b8b30611e5
[2]: https://github.com/odoo/odoo/commit/7f6c669530ed7f9935de6516fadb7283ac00a9e4closesodoo/odoo#91131
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since [1] the l10n modules are displayed together at the bottom of the
page and redirect to the Odoo.com accounting page, regardless of the
localization author.
Now, if the localization was done by a third party, we use that author
website as link.
Note that this is already the case for the regular modules, like the
`payment_mollie` app for instance.
[1]: https://github.com/odoo/odoo/commit/562a2ac270ef8aac3afde05625008cef64f62f89
Part-of: odoo/odoo#91131
In a multi-company environment, a partner of company A should not be able
to make payments for company B. With this commit, if we detect a
mismatch between the companies, a UserError is raised.
Task - 2627751
closesodoo/odoo#91189
X-original-commit: 6064cf2e98f16b42f516dcd1b0793a62436bab33
Related: odoo/enterprise#27245
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>
Before this commit, if user does not follow the project then
while creating the task the creator(current user) is not added as
a follower of the task.
So in this commit, add the user creator of a task as follower
by default, even if (s)he is not following the project.
task-2784885
closesodoo/odoo#91170
X-original-commit: bc62557cc3bdcf792f6d3e19d0f0c87e34057f00
Related: odoo/enterprise#27234
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Purpose
Fix bugs in link replacement (html and text version)
1/ The replacement of urls in text (not html) was buggy when
* a string includes multiple urls, and
* `base_url` is one of them and not the first
* Also in SMS marketing when adding the sms `id`
When it came to base_url's turn, the replace function for the content would
replace the `base_url` part of a previously shortened url instead of the
distinct `base_url` link.
2/ Ampersand character
A) The ampersand character prevented replacement of an url inside a `Markup`.
Previous tests passed as the tracker was created but the url was not replaced.
B) The ampersand character was not recognized as part of an url for simple
strings.
3/ Replacement of already short links
A faulty logic made it possible to replace "/r/" urls when no "blacklist" was
passed.
Commit
* Ensures that only the base_url link would be replaced instead in this case.
* Adds support for urls with "&"
* Does prevent shortening short urls
* Improves link conversion performance (regex + avoid duplication when there
are several occurrences of the same url)
* Adds multiple unit tests
Task-2783844
closesodoo/odoo#91164
X-original-commit: 61026806d831b49a7cf5c44ffef3d762986781ce
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
- Install Recruitment module
- Set a valid outgoing mail server and archive it
- Go to Recruitment > Applications > All Applications
- Create a new application
- Set a Subject and email, then save
- Click on button 'Refuse'
- Select any reason (ensure "send email" is checked)
Issue:
The email is sent to the applicant through the archived email server.
Cause:
The current action have 'active_test' set to 'False' in the context
(useful when archiving an applicant though action menu, since it
trigger action 'action_refuse_reason_apply' and current applicant
will be archived at that point).
Therefore, the archived email server will be used (in case it's the
only one, or if it has more priority than any other one).
Solution:
Set 'active_test' to 'True' in the context when sending mail.
opw-2845545
closesodoo/odoo#91161
X-original-commit: c4f6bd121d242dca6eefa697dba23fd6f055bbe0
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps to reproduce the bug:
- Install sale_stock and invoicing
- Create a product tracked by serial number “P1”
- Create a SO:
- Select any customer
- Select the product “P1”
- Confirm the SO
- Confirm the linked picking
- Go back to the SO
- Create the invoice
- Post the invoice
- Give “sales” and “accounting“ rights to Marc Demo
- Connect with Marc
- Go to the posted invoice
- Try to print the invoice
Problem:
Traceback is triggered, to print the invoice we have to access the `Lot` field
which is defined in the stock module but as the user does not have access rights
an error is triggered:
https://github.com/odoo/odoo/blob/15.0/addons/stock_account/views/report_invoice.xml#L5
opw-2832396
closesodoo/odoo#91156
X-original-commit: 273671de7313e7560eed08391f50c1d2ee8755e0
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Current behavior:
When gift card module is activated for a certain PoS, and you use
customer account as the payment method without selecting a customer
the popup asking you to select a customer would appear 2 times.
Steps to reproduce:
- Activate gift cards for PoS A
- Start session in PoS A
- Add some products to the order
- Don't set any customer
- Go to the payment page
- Select "Customer account" as payment method
- Click on validate
- A popup will appear asking you to select a customer
- Click "Ok"
- The popup appears again
opw-2824675
closesodoo/odoo#91149
X-original-commit: bbb05cd9246b7478bcf1bb580dbe91ba4fb5856c
Signed-off-by: Masereel Pierre <pim@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
When the homepage was set to a different page than /, the resulting page
was blank.
The problem is related to a change of the rerouting algorithm, before
the httpocalypse it was re-dispatching the request itself, now it is up
to the called to do so. Here it is what `serve_path` does.
closesodoo/odoo#91034
X-original-commit: b00fefec2a26eb36be8a13cb845ee4f12f87d4eb
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Merlin (megu)