Friday, March 10, 2023
6 changes · master
Enhancements to existing features
Unit of Measure forms now show country-specific localization fields only for companies in the relevant countries. This reduces clutter and helps users avoid seeing fields that do not apply to their local accounting or tax requirements.
Original PR description
Currently, all localizations of UoM fields are visible in all countries. So in this commit, I have added a new compute field in UoM models, the field contains comma-separated company's country codes, and I have used this field for the hide/unhide fields. Enterprise PR: https://github.com/odoo/enterprise/pull/36572 Upgrade PR: https://github.com/odoo/upgrade/pull/4284 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sales dashboard amounts now display the company currency wherever they appear, making totals easier to interpret. This reduces confusion by ensuring monetary values in dashboards, lists, and forms are clearly labeled with the correct currency.
Original PR description
Amounts in the spreadsheet Sales dashboards are displayed without their currency even though the amounts are all correctly converted to the current company's currency. With this commit, amounts are displayed with their currency in the dashboard, list view and default form view. The hardcoded number format is removed on the dashboard cells to let the automatic format do the job Task 3167343 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customer receivables now include confirmed sales orders that have not yet been invoiced, giving businesses a fuller picture of customer exposure. This supports more accurate credit limit checks by accounting for remaining amounts still to be invoiced, while keeping the related field less prominent in order lists.
Original PR description
The goal is to take into account the confirmed and un-invoiced sales orders in the total receivable of a client. It will be useful in the scope of the credit limit trigger. This is broken down in 3 steps: 1. Add the Remaining Amount to Invoice (RAI) in the Invoice creation wizard of the Sales Order and store this data. 2. Add the RAI in the Total Receivable of the client. 3. The Remaining amount to invoice goes to optional="hide" in the "Orders to invoice" list view. task-3122390 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now assign or unassign people directly from kanban cards and similar board-style views, without opening the full record form. This makes pipeline, task, and activity management faster while keeping existing controls available when fields should remain read-only.
Original PR description
Purpose: Allow quick assignation of records in the kanban views (and other places by extension). Currently, if you want to work in a board-like env (e.g. tasks in kanban, crm in pipeline, that kind of thing), having the possibility to quickly assign/unassign records without having to open them fullscreen can be really useful => it should be possible to "quick edit" these fields in kanban views easily, without switching to form views. task-ID: 3121207
The German restaurant certification for Point of Sale was updated to stay compatible with the new cross-order flow. This helps ensure certified sales continue to work correctly after the broader Point of Sale change, and also fixes an issue in Mexican electronic invoicing test flows.
Original PR description
Related to https://github.com/odoo/odoo/pull/109216 This commit aims at adding the feature "cross-orders" of the PoS. This commit is related to a change made in community where the name of a function (_updateTableOrder) change into _updateOrder.
Knowledge users can now choose whether articles appear in the main article tree for everyone or only for article members. This helps busy teams keep the Knowledge sidebar focused without changing who can still access articles through search or direct links.
Original PR description
Purpose ======= Articles that need to be shared with multiple persons will most probably quickly end up being set in the workspace so that no further member update is required. As a consequence, we…
Purpose
=======
Articles that need to be shared with multiple persons will most probably
quickly end up being set in the workspace so that no further member update
is required.
As a consequence, we need a way to allow users to pick what is displayed in
their rightbar so that it is not crammed with root articles they'll never
click on.
Especially needed on crowded databases where each departments has many root
articles one does not actually need.
Specs
=====
We introduce the notion of `Visibility` for articles. The visibility of an
article is the fact whether or not the article will be listed in the hierarchy
tree (in the left panel of the knowledge main view). This does not modify the
access rights on those articles!
An article can be configured to be visible for *Everyone* or *For members only*.
When the visibility is set to:
* *Everyone*, every internal user is able to see the article without
doing anything.
* *Members*, the users cannot see the article if they're not a member of the
article.
To minimise DB impact, a boolean field has been added to reflect this :
`is_article_visible_by_everyone`. (If not, the article is visible for members
only)
Also, a new user dependant computed field as been added: `is_article_visible`.
An article is visible for a user if:
The user has access to it
AND
the visibility of the article is set to Everyone
OR
The user is member of this article (if article visibility = member Only)
A hidden article is still available for every user that can access it.
The 'standard' quick search does not display the hidden articles but
an hidden mode has been added to the palette to specifically search for them.
Hidden article can be accessible via the Search methods (quick search in hidden
mode / search in the tree view) or via direct links.
This feature is only meant for internal users, to trim their tree to what
is necessary to them. Share users already have a limited amount of
accessible articles. This visibility concept is then not necessary for them.
Performance notes:
We are also increasing the query counter of three performance tests because,
since we have two computed field, we have more queries to do when opening
a record and when moving an article.
Those increases in the number of queries comes from the fields: `user_can_see`
and `everyone_can_see`, plus the addition of a member when creating an article
triggers an additional query for the access.
Use Cases
=========
The usage of Visibility is quite complex and maybe better understood with
some 2 use cases, 1 simple and 1 more complex:
Use Case 1
==========
You hide articles that you can see inside of a hidden root to cleanup the
sidebar. This is useful for articles you do not want to see everyday such as
FAQs or less useful informations that could be interesting for a few selection
of people. (LAN Parties, Tennis Team, Band Practice, etc.)
Step 1
======
You create 3 Articles called *Root*, *Parent* and *Child* : when creating them,
their visibility is set to **Members**, they are thus only visible to members
of the articles including yourselves. (You are directly added as a Member of
the article when setting the Visibility to **Members**)
Step 2
======
You remove yourselves from *Root*, to hide it for you, and move the other 2
below it with the Move To option. This way all the articles are hidden for you
in the sidebar but you can easily search *Parent* and *Root* via the command
palette, since you can see them. (You are a member of these articles after all)
But you won't see *Root* using the classic search since you are not a member of
this article.
Use Case 2
==========
You create root articles corresponding to teams of people or departments.
Step 1
======
You create multiple articles for each of the teams in your enterprise: R&D,
Sales, Accounting, etc. and you create an article visible by all (e.g. HR FAQ).
Step 2
======
For each team you add children articles and adds all the corresponding members
for each department/team.
Step 3
======
When being connected as a user, member of the R&D team, you see that you don't
have the R&D root into the sidebar.
You can search for it using the advanced search either by typing **$** in the
classic search, or by using the button launching the search for hidden articles
and you open the R&D root.
Step 4
======
You can navigate inside of the hidden structure before joining the root as a
member in order for you to see it in your sidebar.
==
task-2900465