Make sure '.o_invisible_modifier' table-cells are forced back to
`display: table-cell` to keep correct alignement. Indeed using the
`initial` value forced them to `inline` instead (creating some
obvious visual bugs in some cases).
The problem occurred on form views with an x2many field with a
default value containing CREATE commands, i.e. when opening such
a form view in create mode, the x2many field is pre-filled with
some (non-existing yet) subrecords.
If the user then edited those subrecords, and then clicked on
'Save' to create the main record, an 'UPDATE' command was sent
alongside the 'CREATE' one for the x2many, and the id of the
'UPDATE' command was a virtual id (as the subrecord didn't exist
yet), and it crashed.
This could happen in MRP:
- Enable lots in Iventory
- Choose a product which is a component of another (through mrp bom)
- Set this product as tracked by lot
- Set this product inventory quantity to 0
- Create a new manufacturing order for the product for which it is a
component
- Click on "Check Availability"
- click on Produce: the many2many already contains a subrecord
- edit the lot field of that subrecord
- click on 'Record Production'
When updating the quantity to produce on a MO, the quantity done
on finished/consumed moves that were not done was erased.
It happens due to write on stock move that always wanted to
unreserve the move and thus drop the move lines with qty_done.
This issue has been resolve in previous commit
This commit correct some mistakes in wizard methods in order
to correctly update open moves.
Write method on stock move always unreserve concerning move if
initial demand is modified. Unreserve will delete all move lines
linked to the move including those already modified.
Thus modify initial demand(unreserve) will destroy all the
job done by the user.
This commit will only unreserve move is the initial demand
is smaller than the quantity reserved (could be improved by dropping
only few move lines). If the initial demand is greater than the
reserved quantity it will not unreserve but only change the
state to partially avaialbe.
When the external button of a many2one field is clicked, the
related record is opened in a dialog. When the user clicks on
'Save' in this dialog, a 'reload' event is triggered to reload the
parent view (the one in the background), as the display name might
have changed.
However, when there is another many2one field in the opened dialog,
and if its external button is clicked, there are 2 opened dialogs,
and thus 3 nested form views. If the user clicks on 'Save' in the
third one, only the direct parent view must be reloaded (the one
in the first dialog).
Before this rev., the 'reload' event wasn't stopPropagated, so it
was handled by the view in the dialog, and by the one in the
background, which produced a crash.
This could happen for instance in Sales Order, edit a sale order
line, click on the external button of the product, in the dialog,
click on the external button of the category, edit some field and
click on 'Save'.
Closes#19052
Before this rev., when the user pressed 'TAB' in the last cell of
the last row of an editable list with attribute create="0", a new
line was added to the list, thus totally ignoring the attribute.
Now, it goes back to the first cell of the first row instead, as it
was before the new views.
Closes#19053
Previous tag design was a colored block with a text on hover. This
text was explicitely html-escaped as put as the 'title' attribute
value.
Since https://github.com/odoo/odoo/commit/89cbbe3b0d6800a89b4385965151ed368659424f:
The text is now always shown and is thus naturally html-escaped by
the jQuery `text` method... and should thus not be explicitely escaped
before.
- The generic form now support form & s2s payments.
- The generic form is now implemented to pay on e-commerce and online
quotation.
- Added icons of supported credit cards for each payment acquirers.
- Replaced e-commerce footer that was displaying payment acquirers by
supported credit cards icons.
- The payment form doesn't render s2s forms in python anymore.
- The payment form now display an error when credit cards credentials
are not filled.
- Fixed a bug where paying with a registered token on e-commerce would
crash.
- Fixed errors not displaying on the payment form.
Before this commit, when the shop was in multi images, the main image was not refreshed when changed in the back end.
This was because of the ?unique parameter that was computed on the product variant image. Hence, when the product image changed, the variant image did not, the hash neither, and the image wasn't refreshed
This commit fixes this by adding an option to the qweb.field.image
OPW 765287
closes#19133
-changing the date_invoice field do not reset anymore the sequence_number_next (it now only affects the prefix)
-the date_invoice is now passed as ir_sequence_date AND ir_sequence_date_range in the context, for sequences that use the date_range feature in prefixes
- Fixed 500 errors when trying to display payment form because of variables partner_id/acquirer_id missing.
- Accepted credit cards are now display next to the acquirer name on the payment form
- e-commerce and website_quote create a transaction with its reference when the user click on Pay.
So we need to render the inputs when the user click on pay and submit the form with the values
- Online quotation and e-commerce now use the new payment form.
- Added the ability to chose on an acquirer if it uses only form/s2s or both.
(Still need some code cleaning)
- Added the support of form payment.
- Fixed payment form's errors not being displayed.
- Fixed a crash when paying on e-commerce with a saved token.
(dev commit, need to clean the code)
- Added the most used payment option (credit cards) in the world and assigned which payment acquirers can use them.
- Added the form templates for each payment acquirer.
When re-launching Odoo on an existing database in Python 3.6[0] it's
possible that the scheduler will preempt the main thread
mid-module-import and run the cron thread which causes registry (and
module) initialisation with only a subset of the Python files loaded
and thus e.g. tries loading auth_crypt with a registry in which none
of res has been loaded makes for interesting situations.
Delay spawning the cron thread until *after* the registry preload at
least, though I don't think that actually entirely fixes the issue.
[0] and probably in any Python >= 3.3, I'm guessing it's related to
the per-module import locks which replaced the old global lock:
https://docs.python.org/3.3/whatsnew/3.3.html#a-finer-grained-import-lock
though since ir.cron has little reason to import anything it could
also just be Python 3 scheduler changes which allow/cause a
context-switch during imports while the Python 2 scheduler would
not allow that. IDK.
The function that checks if we need a back oder or not compares
the initial demand and the quantity processed on the picking.
When unit of measure are activated the initial demand (product_qty)
uses the uom of the product. However the quantity processed on the move
(quantity_done) uses the uom of the move.
This commit uses product_uom_qty instead of product_qty. Product_uom_qty
represents the initial demand transformed with the uom of the move.
It also add a small test with a back order that ensure the quantities
are correct.
It also repairs the test stock flow where in some case immediate transfer
return the back order wizard instead of processing the move. In these cases
we catch the back order wizard and run it.
Before this rev., when the value of a field with widget='domain'
was false, the search_count RPC made to display the number of
records matching the domain crashed, and the widget displayed that
the domain was invalid. This rev. adds a fallback on [] when the
domain is false.
Christophe Simonis