before this commit:
record = env['model.name'].browse(id)
if record doesn't exist in the database and call
record.translated_field_name = value
Then _get_stored_translation will raise
TypeError: 'NoneType' object is not subscriptable
after this commit:
like write non-translated field, the value can be written to the cache, but not
the database and no error will be raised.
Note: The feature is only for the original ORM 'write', if the 'overriden write'
reads other fields of the non-existing record, a MissingError will be raised.
closesodoo/odoo#119202
X-original-commit: 3ba7ca28a68acccb8eb25f117900c1aa1980264a
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
The new SampleServer class was introduced in c67b9f9907
without dedicated tests. We fix this oversight.
closesodoo/odoo#119188
X-original-commit: 693f7bd74066fa9854db4ecef751f13ec5c7e7a6
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Unsupported operand type(s) for +: 'NoneType' and 'relativedelta'
occur when we create payment terms without a preview date (date_ref).
This is because date_ref has no value.
This commit solves the issue by adding a condition if date_ref is not
available, so it adds current date instead of it.
sentry-4068322613
closesodoo/odoo#119187
X-original-commit: a9f556c0d45c32574c94765462d4b59726fc3f19
Signed-off-by: William André (wan) <wan@odoo.com>
Before this commit the "This page" menu sub-section of the website's
menu is displayed as a clickable entry when it is empty.
After this commit any website custom menu sub-section title entry is
hidden if none of its children is displayed.
Steps to reproduce:
- Install website only
- Log in as a restricted editor
- Go to website
- Open the "Site" menu
=> "This page" appears as a clickable entry instead of being hidden.
task-3149639
closesodoo/odoo#119125
X-original-commit: 4625f717bdccd8eea851f74a87a102436627106b
Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>
Issue :
- When mass producing a tracked product, an User Error is raised on validation of splitted MO.
Reproduction :
- Create Serial storable product "Component A", Lot storable product "Component B", Serial Storable product "Finished Serial Product"
- Immediate Transfer 10 * "Component A" and 20 * "Component B"
- Create a BoM for "Finished Serial Product", consuming 1 * "Component A" and 2 * "Component B"
- Create a Manufacturing Order for 10 * "Finished Serial Product" and Confirm :
- Click on "Mass Produce", Set "First SN", Generate all the serials and Apply
- Click on "Produce All"
Task : 3274962
closesodoo/odoo#118592
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Steps to reproduce:
- Enable multi-warehouses (i.e. have a company with 2 warehouses:
warehouse_1 and warehouse_2)
- Set warehouse_2's view_location to a location within warehouse_1
- Check the warehouse_id of a location within warehouse_2
Expected result:
warehouse_id = warehouse_2
Actual result:
warehouse_id = warehouse_1
The issue with this is each warehouse may be configured with their
own routes/rules, therefore a product within warehouse_2 may not
follow the warehouse_2 routes/rules. Note that a nested warehouse
situation like this may occur with warehouses located in different
countries, but products from both warehouses are sold in the same
ecommerce store and `website_warehouse_id` only allows 1
warehouse to be assigned to it
closesodoo/odoo#119181
X-original-commit: 83613b56cadf1a12331db9d4d41ab688d68768e9
Signed-off-by: Tiffany Chang <tic@odoo.com>
Before this commit, content inside chat window could visually fuse
with the header in a way that makes it hard to see the separation
between the header and the content.
This commit fixes the issue by adding a small border below header
when there is some content.
closesodoo/odoo#119173
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Steps to reproduce the bug:
- Install purchase, then mrp (in this order)
- Create a storable product “P1”
- route: buy
- Add a supplier
- Add a BoM
- Create a delivery for the product “P1”
- A need is created
- Go to inventory > operation > replenishment
Problem:
An orderpoint is created with the preferred route: Manufacture instead
of buy
As the "Purchase" module was installed first, the override of
the `_set_default_route_id` function will be triggered first, the 'buy'
route will be set in the created order point because the product has a
supplier. Then, the function in the MRP module will be triggered and
since the product has a BoM, the 'buy' route will be replaced by
"Manufacture".
opw-3228971
closesodoo/odoo#119172
X-original-commit: 227d038efbadf25e3a7be7cceedd9159b71162a3
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Steps to reproduce:
- Install Sales.
- Go to any quotation and toggle mobile device mode in the browser.
- Go to Other Info > click in Sales Team field.
Issue:
We stop supporting the 'kanban_view_ref' in newer versions of odoo. So
we won't be able to get proper view.
Solution:
Changed the way we ref the kanban view to use context to get the
referenced kanban view.
Related to #39499
opw-3152174
closesodoo/odoo#116031
Related: odoo/enterprise#39499
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
If applied, this commit will solve the issue of the singleton when there are 2
quants with the same location and same products but one quant with a lot and
another quant without a lot number.
Steps to produce:
- Create one quant with location-1 and without lot number.
- Create another quant with location-1 but with the lot number.
- Create 3rd quant with location-1 with same lot number as step2.
The error will raise in 3rd step as it is not accepting the 2 quants where one
is with lot number and another is without lot number.
see - https://tinyurl.com/2hqrgmwm
sentry - 4024572562
closesodoo/odoo#119152
X-original-commit: 05a7f5c04804423cfc3a833a1b3f0b5eec3fc147
Signed-off-by: Tiffany Chang <tic@odoo.com>
When an orderpoint triggers a procurement for a product and the system does not find the procurement route, it schedules an activity remembering what was the error.
If a normal user without admin access rights, makes an action that triggers the orderpoints, like confirming a MO, the activity schedule is not creating due to an access error on 'write' operation to a Product Template.
So, all activity schedules triggered from an orderpoint should be created without checking access rights.
closesodoo/odoo#119066
X-original-commit: e7de0b7f88ad55f662319aabcc5d989367b8c659
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Use case to reproduce:
- Set "receive good in input and then stock" on the warehouse.
- Set two suppliers on a product. one from a partner (higher priority)
and one from a child partner (lower priority).
- Set the child partner as the vendor on the replenishment report.
- Order a replenishment for the product.
It happens due to an hack that use a field on `stock.move` in order
to temporaly store the partner among the moves until the RFQ.
But this field is a many2one on `res.partner` model and not on
`product.supplierinfo`
`_run_buy` receive a partner and still use `_select_seller` with the
partner in order to find the best pricelist. But it won't use the
specific supplier price list set on the orderpoint.
In order to fix, we don't store anymore the price list partner on the
intermediate move. In run_buy we receive the orderpoint if it's the
origin of the procurement. On the orderpoint the supplierinfo is set.
So we take it from there.
opw-3180945
closesodoo/odoo#119063
X-original-commit: 3cd5b9b7688ef7e6c6fa4fce1c0ad319fb577745
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
In this paragraph, we are trimming the string and then converting it to an int type. But there is no guarantee that value_string can be converted to int
closesodoo/odoo#119059
X-original-commit: 84fca48dfbabbaa928823d3a27621c77cc53d6dd
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, when opening Discuss from chat window and then
accessing the settings page of a channel, the breadcrumb showed
"Unamed" as the name of the App instead of "Discuss".
This happens because the client action was not named when expanding
the chat window by opening Discuss app.
closesodoo/odoo#118939
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Before this commit, when quick creating a new record in a kanban view,
the "read more" button is briefly shown (flickering). This issue occurs
because, when creating a new record, we increment the number of records
in the group before adding the record to the list of displayed records.
This means that for a brief moment the number of records of the group is
bigger than the number of displayed records, therefore the "load more"
button is show.
Note that this flickering was introduced due to the following
refactoring : https://github.com/odoo/odoo/commit/067bcac53336b5f66f695b1c10b333d8c722225d
Now, we increment the number of records on the group after we added the
record to the displayed records' list.
closesodoo/odoo#119142
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit,
The audio context used in media_monitoring was not
closed. Which could lead to memory leaks.
The source was not connected to the destination in the
script processor (used in old browsers that do not support
audioWorklets), which would prevent the monitored audio to be used as
an audio source.
closesodoo/odoo#119124
X-original-commit: f1c3f78dd6e17fe2a3f5a01d8510ca4343b880fe
Signed-off-by: Thanh Dodeur (tso) <tso@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit prevent the reset of password for de-activated partner
closesodoo/odoo#119114
X-original-commit: 71f4cf2da157d3457885339d116c38d673187b59
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Calling `fetch` with 'id' in the `fields_name`, will always generate
SQL query even if all requested field values are in the cache.
This is because we also look for values in the 'id' field cache,
but we don't ever fill the cache for `Id` fields.
closesodoo/odoo#119107
X-original-commit: 3ba8d0e5e57e1358cc8958abf511d514515eccb2
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
When Operation is 'Archive' and it is still in use as 'Consumed in Operation' in
bom while creating Manufacturing Order and confirming it, KeyError will be
generated.
Steps to Produce:-
1) Create a new product, create bom for that product, add components, and
create or add at least 2 operations to the BoM.
2) In the components of 'Consumed in Operation' add the newly created operation.
3) Now, Archive one operation.
4) Create new Manufacturing Order with a newly created BOM
5) Try to confirm it.
KeyError will be generated.
By applying this commit, if there are no operations left after archiving
one linked to the component then the server error won't occur
sentry - 4042593205
closesodoo/odoo#119098
X-original-commit: ba2364f9188ff44c68a1b86d5029884815a33216
Signed-off-by: Tiffany Chang <tic@odoo.com>
Current behavior:
When printing a bill in the restaurant you had an error poping.
Steps to reproduce:
- Open a restaurant session
- Go on a table and add some products
- Click on the bill button
- Click on the print button
- You get an error
opw-3259014
closesodoo/odoo#119041
X-original-commit: 1d1808e7136c6416fe88c28e7971e97707de2557
Signed-off-by: Heinz Robin (rhe) <rhe@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Since [this commit], a horizontal scrollbar appears on mega menus. This
is because Bootstrap position the dropdown automatically and the mega
menus are a bit shifted on the right (due to a `translate3d` added by
dynamic position of popper). This commit fixes the problem by removing
dynamic positioning for mega menus.
Steps to reproduce:
- Have a system setting that enlarges the texts size or zoom the page
- Have a mega menu
- Open the mega menu
=> There is a horizontal scrollbar.
[this commit]: https://github.com/odoo/odoo/commit/8689241f86e2d4ddb4e4510951f92b80e115b914
task-3133137
closesodoo/odoo#118842
Signed-off-by: loco-odoo <loco@odoo.com>
Since the upgrade to Bootstrap 5 and especially since this [BS5 commit],
there is a gap between the mega menu and the navbar when the user opens
a mega menu. This commit removes that gap.
Steps to reproduce the bug fixed by this commit:
- Have a mega menu on your website.
- Drop a block of a dark color at the top of the page (it helps to see
the problem).
=> When you open the mega menu, you can see a small piece of the block
of dark color between the navbar and the mega menu.
Technical explanation:
This [BS5 commit] introduces a new css rule that adds a
`margin-top: 0.125rem;` on the `.dropdown-menu[data-bs-popper]`. However
when [mega menus were introduced], another css rule prevents having a
gap between the nav and the mega menu (`margin-top: 0;` on
`.o_mega_menu`). This commit makes sure that it will be a `margin-top`
of 0 by making the property more important.
[BS5 commit]: https://github.com/odoo/odoo/commit/c48f57ea2538ad51e00ac27d58f8e191781444f3
[mega menus were introduced]: https://github.com/odoo/odoo/commit/1345702258adbfbee0d780dc22e552395e6d1df7
task-3133137
opw-3226013
X-original-commit: b41c76bd7583756ad059f77f0d3c1151720b0b0b
Part-of: odoo/odoo#118842
This commit allows to reopen submenus and mega menus if one of them was
opened when scrolling on a page of a website.
Steps to reproduce the bug fixed by this commit.
- Have a submenu or a mega menu in the navbar
- Open a dropdown of the navbar
- Scroll down
=> It is no longer possible to open the dropdown.
This commit fixes this issue and adds a test for this flow.
task-3133137
opw-3226013
X-original-commit: 9b1de9e28697edbb6e1fa88665294f983f60e37f
Part-of: odoo/odoo#118842
Purpose
=======
Allow to use favorite in Knowledge embedded view.
For that purpose, we need to hook some function in the web module
(because favorites are stored in view arc and not using ir.filters
records).
Task-3251129
closesodoo/odoo#117188
Related: odoo/enterprise#39057
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
# Editor changes to enable the collaborative mode in Knowledge
Here are the necessary changes to make it possible to enable the collaborative
mode in Knowledge. Knowledge commands introduce a new kind of editor blocks:
`Behaviors`, which are OWL `Component` which need to be mounted. This mounting
is asynchronous and this has to be supported, while not all nodes are observed
by the editor, meaning that parts of a `Behavior` can be collaborative while
others may not.
The following is a brief introduction for every commit in this PR, check them
out individually for more detail.
### [FIX] web_editor: notify current step when joining a collaborator
- Inserting an embedded view from a module in an automated process happens as
soon as the first collaborator connect. This commit notifies the step for the
embedded view during the following collaborators connections (to be sure they
actually received it).
### [IMP] web_editor: fully implement oeProtected and oeTransientContent
- Those attributes will allow a fine control on which nodes are NOT observed by
the editor (`oeProtected="true"`), and which nodes are NOT saved/serialized
for collaboration by the editor (`oeTransientContent="true"`). It can be a
better choice than using `observerUnactive` which stops the observer for all
nodes of the editor, in case a node should never be observed.
### [IMP] web_editor: prevent 'insert' command unwrapping in root
- Modify the 'insert' command of the editor so that it does not unwrap nodes
when the selection is directly inside the editable ('root'). Unwrapping a
paragraph in that case would put text nodes as direct childs of the editable,
which is not desirable with the current implementation.
### [IMP] web_editor: add a hook for historyResetFromSteps
- When joining an `html_field` in collaborative mode, there is no way to know if
there are connected collaborators before actually making said connection. This
is a problem when we want to automate the insertion of an embedded view from
another module in Knowledge. With the hook, it is now possible to execute a
specific action as soon as a collaborator is joined.
### [IMP] web_editor: force load collaborative on form view
- The collaborative mode loads lazily with the focus by default. In Knowledge it
should start as soon as possible, therefore this commit adds an option to do
so.
### [IMP] web_editor: make mocha tests odoo modules
- Since `web_editor` tests were not odoo modules, it was not possible to import
dependencies from i.e. `web`. This commit addresses that.
### [IMP] web_editor: buffer external steps during Component rendering
- In a collaboration, when applying a step requiring a custom OWL `mount`
(which is asynchronous), further external steps should be buffered while the
rendering is done, in case those following external steps should concern
"rendered" nodes which are not yet present in the editor. Once all nodes are
rendered and present in the editor, further steps can be applied safely.
See odoo/enterprise#33483
See odoo/upgrade#4384closesodoo/odoo#104680
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Add a mechanism to buffer external steps when some asynchronous rendering needs
to be done (i.e. OWL rendering). This is to prevent external steps occuring
inside the rendered result from being applied when the rendering is currently
ongoing.
Remove `historyResetFromSteps` and `onExternalHistorySteps` as they were only
introduced to trigger an update of Knowledge Behaviors, but now that update is
done through `checkForExtraRendering`.
Modify collaborative tests of the editor so that steps `afterCreate` and
`afterCursorInserted` can be asynchronous.
Task-2821374
Part-of: odoo/odoo#104680
In order to be able to use web dependencies for mocha tests, convert every
existing test to an `@odoo-module` and make a new asset
`web_editor.mocha_tests` that will be used for tests in `/web_editor/tests`
Task-2821374
Part-of: odoo/odoo#104680
Add an option to the html_field (collaborative_trigger) to allow to choose if
the peerTopeer connection of the collaborative mode should happen when the
html_field is loaded ('start') or when the field has the focus ('focus').
Will be used in Knowledge since the html_field of an article is the main focus
when opening the form in edit mode. The collaborative mode should be loaded as
fast as possible.
Task-2821374
Part-of: odoo/odoo#104680
When the current user connects to a collaborative peer, the content inside his
editor will be reset. When opening a record, there is no way to know if such a
connection will happen.
In Knowledge, when one wants to insert an embedded view in an article body from
elsewhere in Odoo, it is inserted programatically once the article is opened. At
that time the peerToPeer connection is not established. Then, if a collaborative
session is started with someone already editing the html_field, the content is
reset, and at that point, the insertedd element is removed, so it should be
inserted again.
This commit introduces a hook that can be used to execute some specific action
if the content of the editor is reset through `historyResetFromSteps` during
the collaboration first synchronization. It can be provided as an option of the
`wysiwyg`.
Task-2821374
Part-of: odoo/odoo#104680
Currently, the 'insert' command unpacks nodes from a lone paragraph, or from
the first and last node if there are multiple nodes.
In knowledge, to append an embedded view to the editable, there is a need to
insert two sibling nodes at once (without unpacking them). With the current
behavior of 'insert', it is possible to do so by inserting a paragraph
containing the 2 nodes that need to be inserted. The result will be that the
'insert' command unpacks the parent paragraph and correctly insert the 2 nodes.
This commit prevents the 'insert' command from unwrapping nodes if the
anchorNode of the selection is the editable itself.
Task-2821374
Part-of: odoo/odoo#104680
With the introduction of Knowledge Behavior Component, came a need to create
html nodes which would have limited interactions with the editor. i.e. an Odoo
view already has everything it needs to function properly, and when it is
inserted in the editor, any manipulation on the selection or on the style that
could be done with it should be prevented. Another example would be the
/template block (will be renamed /clipboard in the future) that has a
non-editable part (buttons which have a definite action in Odoo, and which
should not be interacted with) as well as an editable part inside of it).
To solve this use case, this commit proposes to mark specific html nodes with
a `data-oe-protected` attribute which could have one of three values:
- "true"
- Only mutations of type "attributes" can be registered on the node itself
which has the `data-oe-protected="true"` attribute
- Prevent mutations of children (and sub-children) from being registered by
the mutationObserver of the editor
- Prevent the selection handling when its anchor is inside a
`data-oe-protected="true"` element, even if it is `contenteditable="false"`
- Prevent the command hint
- Prevent the usage of the wysiwyg toolbar
- Prevent the dblClick tooltip
- Prevent the editor sanitization `Sanitize.js`
- "false"
- Designed to be contained inside a node with `data-oe-protected="true"`
- Re-enable all features disabled by a parent node with
`data-oe-protected="true" for the children of a node with
`data-oe-protected="false"
- ("")
- This is considered equivalent to have the `data-oe-protected` attribute
set to "true" (like other html attributes).
Another attribute is added: `data-oe-transient-content`, with the following
values:
- "true"
- Prevent the serialization of the children of the node, so they are not
shared during a collaboration.
- Transient nodes will be removed during `cleanForSave`, meaning that they
will never be part of the html_field value in the database
- ("")
- equivalent to "true"
The use case is an embedded view: there is a large quantity of nodes that
are not relevant to share nor to save, since it will be recreated with the
lastest data from the database, with the information relevant to the
currently active user each time it has to be rendered.
Note:
This commit does not handle the dynamic switch from a specific value for
`data-oe-protected` to another (i.e. switching from "false" to "" or "true").
This could cause a number of problems like:
- some mutations from when the value was "true" are not yet handled when the
switch (to "false") happens => those mutations will be registered as if they
were always under the "false" value, even though it is not the case.
- in collaborative, some nodes with oids that were not relevant (under the value
"true") won't necessarily have the same oids in between collaborators.
Therefore we cannot suddently listen to their mutations and expect the changes
to be shared by switching to "false".
In conclusion: the `data-oe-protected` attribute value should stay the same
during the entire edition.
Task-2821374
Part-of: odoo/odoo#104680
How to reproduce (scenario):
- Open 3 windows with 3 different sessions in Odoo
user_1 -> in CRM, My Pipeline
user_2 -> in Knowledge on article "target"
user_3 -> in Knowledge on article "target"
-> user_2 and user_3 are in a collaborative session
-> user_1 "insert view in article" "target" (via Favorites)
-> user_1 is redirected to knowledge to the target article
-> RTC_DATA_CHANNEL_OPEN between user_1 and user_2 happens
-> user_1 reset the html_field value from the history steps of user_2
-> the embedded view "My Pipeline" is inserted via `execCommand` and create a
step in user_1 editor
-> user_2 is notified via OE_HISTORY_STEP and receive the new nodes (view)
-> RTC_DATA_CHANNEL_OPEN between user_1 and user_3 happens
-> since user_3 was already synced with user_2, there is no
`historyResetFromSteps`
-> user_3 does not get the step from user_1 with the embedded view nodes now
-> user_3 makes multiple steps (i.e. write some text in a paragraph)
Current Behavior:
-> user_2 and user_1 are notified of those steps and add them to their histories
-> user_3 stil did not get the step with the embedded view nodes
-> now if user_1 and user_2 make some steps, user_3 will be notified, but those
steps "parents" are the steps from user_3, so user_3 may not request a full
history comparison and may never get the missing step
Fix:
-> when a RTC_DATA_CHANNEL_OPEN event happens, the connected client is notified
of the last registered step so it can call GET_MISSING_STEPS if it does not have
it
Note:
This fix solves the specific case mentioned above, but other cases of
desynchronization may happen, see Task-3208277 for a more complete fix.
Task-2821374
Part-of: odoo/odoo#104680
odoo/odoo#111651 improved and optimised triggers but dropped the
in-place cleanup of field dependencies. As a consequence, during
module uninstallation if a stored computed field is removed (because
it's part of a module being uninstalled), and one of its dependencies
is subsequently altered (e.g. it's itself removed, or written to) the
second update will break as the query trying to find out which
dependent records to update will error, either because of trying to
select / filter on a missing column, or because of trying to fetch
in a missing table.
The simplest examples of this issue are computed fields with a
dependency on `ir.model`:
- In `calendar`, `calendar.event.res_model` is a related on
`res_model_id.model`, this prevents the removal of *any* `ir.model`
record if it gets uninstalled.
As a result the `calendar.attendee` and `calendar.event` tables
don't get removed (just emptied of all their non-automatic fields),
their records remain as well, and when the non-automatic fields get
re-added during installation re-instating the NOT NULL constraints
fails, breaking the uninstall/reinstall test.
- In `payment`, `payment.provider.module_state` is a related on
`module_id.state`, this breaks *during* uninstallation, as after
`module_uninstall` first calls `_module_data_uninstall` which
removes the field, then it *updates the modules being uninstalled*
(sets their state), which tries to find out which
`payment.provider`'s `module_state` is should update, which breaks
because the `module_id` column has been removed.
This second one was worked around in odoo/odoo#118900, by marking
modules as uninstalled before actually gutting them, but as it turns
out the "actual" fix is needed anyway. So revert the workaround, and
actually fix the issue.
closesodoo/odoo#119130
X-original-commit: 48a420efcf7c7b46416bab006003553cc9d23846
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
If applied, this commit will solve the tuple index out of range error when the
'Percent' value is not set in the Due Terms and the user tries to add 'Fixed'
value in more than one line.
To reproduce this issue, follow the steps.
- Open Accounting -> Configuration -> invoicing -> payment terms.
- Open any payment term, and change the value from 'Percent' to 'Fixed' in Due
Terms.
- Add another line with a value as 'Fixed'.
see-https://tinyurl.com/22e2yj2a
sentry-4072967091
closesodoo/odoo#119131
X-original-commit: fcb3c237e24ec44fd6df0de5f2a0f329efb1bf13
Signed-off-by: William André (wan) <wan@odoo.com>
- Enable Cash Rounding in settings.
- Create the cash rounding as
- Rounding precision: 5.00
- Rounding Strategy: Add a rounding line
- Profit Account: Any
- Loss Account: Any
- Rounding Method: Half-up
- Enable "Lock Posted Entries with Hash" on Customer Invoices Journal.
- Create a draft invoice and set the cash rounding on it.
- Confirm
Error will raise
You cannot edit the following fields: Account, Label, Partner.
The following entries are already hashed
This occurs because cash rounding is recomputed during post,
after hash was written
opw-3235377
closesodoo/odoo#119126
X-original-commit: 5cb044dd8a2385c9a3c09520ed97eb4faa39216d
Signed-off-by: William André (wan) <wan@odoo.com>
Current behaviour:
When a pricelist discount with a % is present for the /shop, but
doesn't apply for the product, for some base prices that are not
easily representable as floats, the comparison between the base
price and the post-pricelist price may be different, when they are
not, due to floating point inaccuracy.
Expected behaviour:
Even if floats are not accurate, if the price is essentially the
same, it shouldn't be counted as a discount.
Steps to reproduce:
- Install eCommerce and Sales
- Settings > Activate all pricelist settings for discount and check
the "Comparison Price"
- For a product set the base price to `4,152.48`
- Create a price list that shows the discount of 25% that *doesn't*
apply for the product we set, set it selectable for the e-commerce.
- Go to the /shop, set the pricelist and look for your product, see
that the base price and discounted price are the same, but one is
strikedthrough as if there is a discount.
Reason for the problem:
Floating point inacuracy when computing the base price of the
product, and we compare with the "reduced" price, they are different
(4,152.48 vs 4,152.480000xx), so when we compare them, they are
different, when they shouldn't be.
Fix:
Use `compare_amount(...) != 0` of the currency to safely compare the 2
prices.
Affected versions:
- 16.0
- saas-16.1 (couldn't reproduce, but the line is present, so
possibly faulty)
- saas-16.2 (couldn't reproduce, but the line is present, so
possibly faulty)
- master (couldn't reproduce, but the line is present, so
possibly faulty)
opw-3246461
closesodoo/odoo#119072
X-original-commit: aaaae309d38651c9ce5cd63439695e858a7c047d
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Create a product category [FIFO] with:
- Costing Method: First In First Out (FIFO)
- Inventory Valuation: Automated
Create a product [PROD] having:
- Product category: [FIFO]
- Product Type: Storable Product
- Invoicing Policy: Delivered quantities
- Can be expensed: True
- Re-Invoice Expenses: At cost
Create a sales order with [PROD]
Confirm, Deliver
Open the created STJ journal entry:
- Reset to draft
- Add analytic account on a line
- Post again
To the sale order is added a reinvoice line with negative quantity.
This should not occur with cogs lines
opw-3199428
closesodoo/odoo#119048
X-original-commit: 347975d6d9b07db521e02ee12694aa834708abbe
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
We refactor the ModelFieldSelector and ModelFieldSelectorPopover
components.
We also improve a bit ModelFieldSelectorPopover:
- on first page, the button to go back is no longer available
(so that it is now more difficult to produce an invalid path)
- we always start with a page presenting the model where the last
selected field name belongs to
- the keyboard navigation is improved
- click on model field selector opens the popover with the focus in
the search input (if any)
- for relational fields in popover: the user can either click on the
relational field (and select it) or a special button that make him
follow the relation to the field comodel
We also refactor the hook useDynamicPlaceholder to make it use a new
component DynamicPlaceholderPopover that uses ModelFieldSelectorPopover.
Task ID: 3272798
closesodoo/odoo#117951
Related: odoo/enterprise#39673
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Make the public `read_group` depends of its private method `_read_group`
refactored to match the backend usage.
We try to keep the public API similar for this first part of the
rafactor, but there are still some API change:
- We cannot order by `id` anymore.
- The display_name of many2x group values are not lazy anymore.
Part-of: odoo/odoo#110737
Lot of override of read_group reimplement partially custom security
rule of `_search` method. In order to simplify these security check
and have a consistent behavior between the search and read_group method,
_read_group now use _search to create the from and where clause.
Part-of: odoo/odoo#110737
The new backend version of read_group can simplify the
current overrides of read_group. Do it for each of them and
avoid making extra search (done with __domain) when it is possible.
Part-of: odoo/odoo#110737
Chong Wang (cwg)