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.
Before the new design, floats in kanban records were cleared using the
clearfix method. Now, the kanban color requires using the ::after
element, making the clearfix method unavailable. Hopefully, forcing the
creation of a block formatting context by forcing the display of kanban
records to `inline-block` should do the trick without affecting the
main layout.
The problem is present because there are more than 1000 variants for each
product. For display, the price of each product is recalculated (instead
of looking only at the last product)
opw-766897
In grouped list view, when a pager is clicked inside a group, a
'load' event is triggered to reload the data with the new offset.
The event is handled by the list's controller.
However, when the list is in the modal, the event must be stop
propagated by the controller of the modal, so that it doesn't go
up to the controller of the view displayed behind the modal. It
happens for example by reproducing the following steps:
- go to Lunch
- add a line
- search more products
- group by vendor in the modal
- unfold a group
- click on the pager (the group must contain more than 80 records)
Before this rev., it crashed because the controller of the form
view tried to handle the event.
Before this commit, a list containing a handle widget would only display
the handles associated with non-zero integer values. This is due to the
fact that unset fields are hidden in Odoo, while a field is by default
considered 'defined' if its value is truthy.
We override the isSet method for the handle widget to always return
true. This tells the handle widget that the associated integer value is
always defined, thereby ensuring that the handle will always be shown.
Lucas Perais (lpe)