commit 0a960c08757a8ba5e1dc1dd36c17a35de8913975 introduced change about
reserved quantity that set it to 0 once the move is done.
This commit add views improvement. If the move lines are done
reserved quantity does not really matter and thus it is better
to not display it.
Modify the decorator on stock picking that change the font to red
if the quantity processed is greater than the reserved quantity.
This decorator does not trigger if the picking is in state done since
reserved quantity is always 0.
When validating a stock picking there were 2 different cases:
(1) If all qty are equal to 0 it will display a wizard asking
if the user want to set the quantity done to the reserved quantity
for all moves. If the user accept it will automatically perform the
moves after setting the quantity done.
(2) If the user set a quantity on a move, it will check if there is
a need for a back order. If yes it will display a wizard asking if
a back order is needed or not.
However the check if a back order was needed or not was never perform
in case 1. If the quantity reserved was lower than the initial demand
a back order was automatically created.
This commit add the step 2 in the procedure of step 1 (after setting the
quantity done).
The quantity reserved for move was never modified once the move
is done. It is a nonsense to have a reserved quantity for a done
move.
This commit add a constraint that ensure the quantity of
move line to be 0 if it is in state done. Also it add a write
on move_line's 'action_done' function that set the reserved quantity
to 0 for all move line processed.
It does not introduce any change on the stock move itself since the
reserved quantity is the sum of all its move lines's reserved quantity.
- When registering a payment token, validating it using a payment of a small amount (~1.50€) followed by a refund allows ensuring
that the payment method is valid (i.e. checksumming the card number simple ensure the number is valid but not that the card exists).
This commit introduces a generic approach that must be implemented for each acquirer that has tokenization support.
This commit also introduces a generic payment token registration/usage template that can be adapted according to one's need.
- Introducing a new payment form that handles payment, deletion and adding payment method (only for server2server for the moment).
- On /my/payment_method, changed strings 'Payment Acquirers' to 'Payment Methods' which is more clear.
- Stripe can now be used to pay subscriptions.
It happens because the function still use the old fields
utilized before refactoring introduced by commit b3180c8411
This commit adapt the function by using quantity instead of qty.
When deciding to prefetch records (getting records from the cache with
no value for the field being fetched), if the field was computed
`determine_value` would just get all records, not limited by the normal
prefetch limit; for large recordsets this would generate gigantic
prefetch lists for records we may not need at all.
Fix by applying the `PREFETCH_MAX` limit to records from the cache as is
done in `_prefetch_field`.
Complementarily, when traversing related fields the prefetch
environment would be lost and every record would get an empty prefetch
environment, so the values would ultimately be read one by one.
Example: select (search) 1000 product.product records, access a
related field (e.g. categ_id) in a loop, on the first iteration the
system would first read 1000 templates, then it would read each
categ_id individually, resulting in >1000 SQL queries rather than the
~2 we would expect.
Fixes#18511
A form view record may be saved even if the record is displayed in
readonly (e.g. when a button in the form view is clicked). When
this happened, if there were an html field with html_frame widget
in the form, it crashed (e.g. in Email Marketing > Mass Mailings >
open one > click on Test Mailing).
Commit 7cd2f6370 (in 10.0) recently added attribute special='cancel'
on the 'Cancel' buttons of the Settings views in Odoo. The attribute
wasn't really supported in this case by the old web framework, so
this commit also slightly adapted it, and made it reload the whole
webclient when such a button is clicked.
This commit now needs to be forwardported in saas-16, so we have to
handle the case in the new views as well. Before this rev., it
crashed, because the BasicModel tried to reload a new record (the
one of the Settings form view), so basically it performed a 'read'
RPC on a virtual ID like 'virtual_123', and the server didn't really
appreciate.
This rev. handles the case where a new record is reloaded, and
simply performs a 'default_get' instead of a read. Bonus point:
with the new views, we don't have to reload the whole webclient.
IE11 seems to be always using cache when doin an XHR request with the
same GET request.
It can be changed in several ways:
- returning a header: "Cache-Control: no-cache"
- altering the GET request with a nonce
- using the POST method instead of GET
to solve it, in this change the HTTP header is added on the response.
opw-752270
closes#18787
Before this rev., when the user opened a form view
containing a pad widget, with a pad url already configured,
a dialog directly popped asking "The record has been
modified, your changes will be discarded. Are you sure you
want to ?".
This is because of an unconventional behavior of this
widget: the field actually encodes an url, the one of the pad
to display. When the user saves, a write is forced so that
the server can retrieve the pad's content and store it in DB.
To force the write, the widget always notifies a fake change
on the url. However, we don't want this change to trigger
the confirm dialog. With this rev., this fake change doesn't
make the record 'dirty'.
Computation of the field 'Difference amount' was wrong as it was converting amounts in base currency in the following use case:
- company currency USD
- invoice currency EUR
- payment's journal currency USD but payment's currency EUR
- invoice of 100€, payment of 20€: difference was not 80€ because it was converting to USD
*account_asset
When a button of type 'action' is clicked (execute a given action),
special keys must be set in the context (active_id, active_ids and
active_model). They must be computed regarding the record containing
the clicked button, i.e. if we are in a modal, it must be the id
and model of the record displayed in the modal.
Before this rev., we always sent the id and model of the record
displayed in the background (i.e. the id and model of the url).
This caused a bug in MRP that could be reproduced as follows:
- open a manufacturing order in form view
- click on edit
- click on one of the line of the one2many, and click on the green
icon to edit a product
- click on the update product quantity button on top of it
- the product field must be correctly filled, which was not the
case before this rev.
Date fields have magic grouping methods to specify how to group on
them like date:month, date:weeks, date:days for example. It needs
to be handled properly since date:month is not a valid field name
but date is.
Steps to reproduce the issue:
- Go to Sales/Dashboard
- Click on My Pipeline
- Group by "Creation Month"
Basically, this can be triggred from any view which has a search
view which defines a group using the magic date grouping methods.
Backport of 0de067cae9
(and 9b8bc5e5a1)
Rev. c5bd509274 attempted to improve the
pad sync mechanism when merging records (tasks), but failed to consider
the case where the pad_url field is not set yet.
This happens at create(), due to the chicken-and-egg problem with the
pad URL depending on the record ID, and therefore set *after* creation.
Ignoring the sync when the URL is not yet set should be enough, as the
URL generation method also takes care of that first sync.
Rev. c5bd509274 attempted to improve the
pad sync mechanism when merging records (tasks), but failed to consider
the case where the pad_url field is not set yet.
This happens at create(), due to the chicken-and-egg problem with the
pad URL depending on the record ID, and therefore set *after* creation.
Ignoring the sync when the URL is not yet set should be enough, as the
URL generation method also takes care of that first sync.
A stock user is not allowed to save a picking. It happens
because the picking view use the field show_operations that is
a related to stock.picking.type.show_operations. Since stock user
do not have right to write on picking type it will fail.
This commit add a readonly on show_operation on the picking view
(already invisible). With that change the field will not be send
to the server and thus not writed.
This commit is not retro-compatible with existing database.
Moreover, the underlying issue (opw-757039) has been fixed via commit
baca743cc0.
This reverts commit 8510c0ce37.
When a mix of quants and move lines is displayed in traceability report,
they are not correctly ordered by date.
To fix this we sort them after having all quants and move lines
Before this commit, when creating a pos_order_line_pro_forma, which inherits from pos_order_line but in a different table, the create confused an overriden field (order_id)
When pos_blackbox was installed, pro forma lines would search for an pos_order instead of a pos_order_proforma upon their creation
This commit allows an inheritant of pos_order_line to use the super.create function
OPW 745685
Closes#18755
When an operation has the check for create new lots/serial numbers
activated and it exists a return that use this operation. The return
with serial number is not possible since it will display the view for
creating new serial number while we are returning some of them.
Trying to add the serial number name will fail due to the constraint
that ensure maximum one specific serial number by product.
This commit change the context before calling the view in order to
always display the many2one lot_id if the move is a return.
Steps to reproduce the bug:
On an empty database, install the sale module
-Activate product variants : Sales > Settings > Check Products can have
several attributes, defining variants (Example: size, color,...)
-Activate advanced pricelists : Sales > Settings > Check Advanced pricing based
on formulas (discounts, margins, rounding)
-Activate the developer mode
-Go to the product.templates list : Sales > Products
-Go to the debug menu > Edit TreeView and add the price field in the view
-Go to the debug menu > Edit Action and add the value 'uom': 1 in the context field
-Search for a pricelist : Type the name of an existing pricelist, then go to the pricelists
proposal, open the list of proposed pricelists, and select the pricelist
Bug:
The wrong value was sometimes displayed in the price field. To be more exact, the displayed
value for each product.template was the price of the product.product that has the same id.
If a product.template has an id which doesn't exist in the product_product table,
this product disapears from the list.
opw:762663
Steps to reproduce the bug:
-On an empty database, install the sale module
-Activate product variants : Sales > Settings > Check Products can have several attributes, defining variants (Example: size, color,...)
-Activate advanced pricelists : Sales > Settings > Check Advanced pricing based on formulas (discounts, margins, rounding)
-Activate the developer mode
-Go to the product.templates list : Sales > Products
-Go to the debug menu > Edit TreeView and add the price field in the view
-Search for a pricelist : Type the name of an existing pricelist, then go to the pricelists proposal,
open the list of proposed pricelists, and select the pricelist
Bug:
A traceback was raised.
opw:762663
amoyaux