- When paying a sale order with a payment acquirer that saves tokens
after each payments (S2S mode or save token to "ask" or "always") and
while not connected.
The payment token is saved as either the sale order's partner (when the
acquirer is in form mode) or as the public user's partner (for S2S
acquirers).
To fix this issue, if the customer is not connected and pays the sale
order using a form acquirer, we do not create a token.
If the customer pays the sale order using a S2S acquirer, the created
token is then linked to the invoice's partner.
Canceling the delivery order created for a "Make to order" product
cancels the related procurement.
But canceling the receipt order created for a "Buy" product" with reordering rule
didn't cancel the related procurement. In some cases, it can block the application
of the reordering rules.
Now the related procurement is canceled when the receipt order is canceled.
opw:1845345
Steps to reproduce the bug:
-activate the pick-pack-ship route on the main warehouse
-activate the delivery packages option in Inventory > Configuration > Settings
-create a stockable product
-make a quick inventory for 10 unit(s) of this product
-sell 2.30 unit(s) of this product & confirm the sale
-process the done qty in the PICK operation and click the button "put in pack"
-validate the PICK operation
Bug:
check the PACK operation and the full package was not being transferred
opw:1858316
- When paying an invoice with a payment acquirer that saves tokens after each payments (S2S mode or save token to "ask" or "always") and while not connected.
The payment token is saved as either the invoice partner (when the acquirer is in form mode) or as the public user's partner (for S2S acquirers).
This should not happen.
To fix this issue, if the customer is not connected and pays the invoice using a form acquirer, we do not create a token.
If the customer pays the invoice using a S2S acquirer the created token is then linked to the invoice's partner.
The end time of a calendar event is constrained to never be before the start
of te event.
However when updating events, one path would first update the start of the event
before updating the end of the event.
So in case where (s_1, e_1) is updated by (s_2, e_2),
with respectively s_i < e_i,
if s2 > e1 then the update would violate the constraint and thus crash
the calendar update.
opw 1854394
When the initial inventory adjustement is made after the accounting
openeing entry, no AML is created with the initial quantities. The
valuation report is therefore wrong.
Partial revert of 21099f3eaf. Although the existing solution
has also flaws, the fix highlights them even more.
opw-1859204
- Change the one of the following default account on a product category:
Stock Input Account
Stock Output Account
Stock Valuation Account
- Upgrade stock_account
The account is changed back to the default value.
This was due to commit 1bf25fc018 which attempted to solve an error
in a test.
We fix the test by making sure we check the right accounts. We also make
sure to avoid creating 2 identical `ir.properties` (one `False`, the
other with a value). We only update the property if it is `False`.
opw-1859706
When clicking on an action button, the following steps are performed:
1. Buttons are disabled
2. The button call is performed
3. At the end of the call, the buttons are enabled
4. Extra RPC are performed (`read`, `name_get`)
5. When the RPC calls are finished, the form is reloaded
In the case of a validation of a SO, it means that the 'Confirm' button
is enabled at step 3, but hidden at step 5. On a slow network (or an
overloaded server), it means that the user has enough time (step 4) to
click again on the 'Confirm' button and trigger the action more than
once.
The root cause is that we don't retrieve the promise of the `reload`
mechanism (defined in `_callButtonAction`) when executing `on_close`
(triggered after the button call). We return a promise which is resolved
and enable the buttons too early.
We make sure to retrieve the promise of the `reload` and return it, so
that the promise of `saveAndExecuteAction` (defined in
`_onButtonClicked`) is correctly linked to it. This way,
`_enableButtons` is called when the reload is performed.
Co-authored-by: Aaron Bohy <aab@odoo.com>
(well, actually he did most of it)
opw-1859027
Steps to reproduce the bug:
- Create a recurring meeting, with a start date with time (not all day) (for example 09:00),
a duration (for example 5 hours) , each week for example on fridays, for 3 occurences.
-Save
Bug:
- The start_datetime ("Starting at") was increased with the duration of the meeting.
PS: The displayed start and stop in calendar view were computed in function "calendar_id2real_id"
with the virtual id.
opw:1858154
Prevent the modification of a tax which is used in an opened POS
session. This avoids inconsistency between the payment and the order
accounting entries.
opw-1859092
The token field is a technical data that the other users are not able to use.
It may be confusing for users to see token on the user interface.
Still show it to administrator for debug reasons.
The dateutil package uses lazy import to selectively expose its
features: `parser`, `relativedelta`, `rrule`, `tz`.
Depending on installed modules and order of initialization, there was no
guarantee that a given feature was already loaded during the preparation
of the action context.
This patch ensures that we always preload the feature set we need, and
only that feature set. This way we have a consistent `dateutil` lib in
the action context at all times.
When using sudo, the administrator is logged as deleting the action.
For audit reason, log the correct user.
To avoid access rights errors, only group system can delete the action.
An ir.attachment record can be served as a request's reponse if:
- a request triggers a 404
- the ir.attachment record has its url field matching the url of
the failed and is of binary type
Following rev[1], portal users have the right to create these kind of
records, and it is a security concern.
This patch restrict the ability to create and write on the ir.attachment
records that may be served through the dispatch's exception mechanism to
settings users.
As the asset bundles files are served through the use of these special
ir.attachment, we make sure to retrieve only ir.attachment records
created by the superuser in the `get_attachment` method.
As website administrators often need to play with these special
ir.attachment, we also let to this group the permission to manage them.
[1] 61065b6d04
Make sure building reports using local resources are disabled.
This avoids get different report result based on the system if the
given resources are or not present (e.g. custom style)
The token field is a technical data that the other users are not able to use.
It may be confusing for users to see token on the user interface.
Still show it to administrator for debug reasons.
The dateutil package uses lazy import to selectively expose its
features: `parser`, `relativedelta`, `rrule`, `tz`.
Depending on installed modules and order of initialization, there was no
guarantee that a given feature was already loaded during the preparation
of the action context.
This patch ensures that we always preload the feature set we need, and
only that feature set. This way we have a consistent `dateutil` lib in
the action context at all times.
When using sudo, the administrator is logged as deleting the action.
For audit reason, log the correct user.
To avoid access rights errors, only group system can delete the action.
An ir.attachment record can be served as a request's reponse if:
- a request triggers a 404
- the ir.attachment record has its url field matching the url of
the failed and is of binary type
Following rev[1], portal users have the right to create these kind of
records, and it is a security concern.
This patch restrict the ability to create and write on the ir.attachment
records that may be served through the dispatch's exception mechanism to
settings users.
As the asset bundles files are served through the use of these special
ir.attachment, we make sure to retrieve only ir.attachment records
created by the superuser in the `get_attachment` method.
As website administrators often need to play with these special
ir.attachment, we also let to this group the permission to manage them.
[1] 61065b6d04
Make sure building reports using local resources are disabled.
This avoids get different report result based on the system if the
given resources are or not present (e.g. custom style)
Before this commit, the discount on a so line was always brought to zero when changing the price
After this commit, we do this only when the pricelist is supposed to compute the discount
OPW 1867262
closes#25851
The POS uses a DomCache for various UI elements to avoid re-rendering
elements that are the same as the last render. One such cached UI
element is an entry in the client list.
When a partner is edited in the POS frontend the POS will write this
to the backend and then it will load all updated res.partner
records (new write_date > previously loaded most recent write_date).
To render the newly updated information *and* to ensure any other
partner edited (through backend or because it's a child contact) is
updated just clear the whole cache.
Fixes#13856
Facing the following cases, only the database admin can merge res_partners:
1. The email addresses are different.
2. The origin contact(s) is (are) linked to some account move lines.
This commit adds a kwarg in the merge function. This argument allows to skip the two tests.
So they can be bypassed when overloading the function (depending of the current user access
rights for instance) in order to merge partners even if they have different email addresses
or with account move lines on the origin one.
It can also be called programatically and bypass the checks.
This commit also makes the merge wizard correct any inconsistence in the
allowed companies/currency company of the merged contacts and the
related user(s).
Closes#24376
In LESS, 'fadeOut' function is used to make a color more transparent.
In SCSS, that function is called 'fade-out'.
Closes https://github.com/odoo/odoo/pull/25233
Before this commit, the user could lost some unsaved changes in a record when
posting a message in the chatter.
This is due to reloading the data on the record, which is necessary because
a `message_post` may make some changes on the record [1].
With this commit, a dialog will warn the user that the record will be reloaded
in the following cases:
a) posting a message in the basic composer that will reload the record
b) opening the full-composer when the record is dirty
Indeed, any operation after opening the full-composer will always refresh the
record (even closing the dialog).
Known issues:
- a record is not considered as dirty if we only make changes in its
description from a pad.
> the content of the pad will be erased without any warning...
[1] https://github.com/odoo-dev/odoo/commit/803d5cf04835fcf8e7ddb143e1ab140408beef93
opw-1825005
Revision on b09f0c99
The intent of the previous commit was to no drop records in a list
on discard in the following cases:
- when they have been created from a `default_get`
- when they have been created from an `onchange` that result
from a `default_get`
Before the commit above, the kind of records that were abandoned
in those cases are stated as invalid, which happens when a record
has a required field that is empty.
The case of an `onchange` that is not involved in a `default_get`
was not considered in the fixes above. In fact, this is the intent
behaviour in most cases. However, if the items in the list are
created from such an `onchange`, we should not drop them.
This commit fixes the bug where records in a list that are created
from an `onchange` are wrongly abandoned. Here is the new logic to
abandon a record on discard in a list:
- the record that is marked as "do not abandon" should not be
abandoned;
- a record that is registered as a "not new addition" in the
list should not be dropped;
- a record that is registered as a "new addition" in the list,
and has been updated afterwards, should not be dropped;
- a record that is not new should not be dropped;
opw-806650
Christophe Matthieu