* can't compare a function and a float in Python 3 (it works in
Python 2, though it makes no sense and was just hiding a bug)
* no iteritems method on dict in Python 3 (use compat helper)
* P3-invalid "except" syntax (sadly pylint apparently does not have a
standard lint for that, though it's easy to catch... if you can run
the code under P3)
* web_editor, web_planner, website
The 'Dialog' class is used in both backend and frontend. Also, lots of
actions can be done without the use of any modal. It thus makes sense
to lazy load its related xml only when a first modal is opened.
This change also allows to get rid of the "base_common.xml" file as the
dialog template is the only remaining one in there and, in the future
website update, it will allow to not load any static XML file on website
page loadings.
Qweb rendering is great to render "complex" widget structures. However,
using it to render something as simple as a button was not very
meaningful. This commit deletes the "WidgetButton" template and replaces
it with an utility JS function to render buttons according to given
parameters.
Also, this change will allow a better change. Before this commit, the
only templates left in the "base_common.xml" file are the "WidgetButton"
and the "Dialog" ones. With the removal of "WidgetButton", the file can
now be lazy loaded only if necessary, on the first dialog instantiation.
This will allow to remove the need to load static XML files on each
frontend page loading.
Thanks to @xmo-odoo and its Python3 virtual machine for spotting this
one (and shame on Python2 that does not crash when comparing a method to
a float because voilà).
Add the 'xmlDependencies' key to the 'Widget' class. If defined, it is
an array of URLs to XML files that the widget will need to work.
Those are loaded in the `willStart` method so that they are available
before all rendering parts.
- Refactor the function and document it
- Multiple calls to the function with the same URL now load the
templates only once
- A call to the function with an URL now returns a deferred which
indicates when the given URL has been loaded (not when all the
calls to the function are finished)
In order to be sure website is loaded and to allow searches in DOM require
on website was necessary. This is a partial revert of e66ba3ce1e
that was a bit hasty.
A special case was made for products not available when running a search on
the qty_available field.
For domains like ('qty_available', '<=', 5), it should include non-available
products too.
Fixes#18336
Create a company, try to install a coa without specify an Interbank Transfer Account (required field):
The COA can't be installed due to the missing Interbank Transfer Account that will be created by the COA... that leads to a "deadlock".
-opw: 752928
Purpose
=======
It is possible to break the installation of any module if a module that creates a product should be installed.
to reproduce:
set "all" as category of one product
then change "all" category to view type
then install pos (because pos installs one product)
you will get the error message in a traceback
See https://www.odoo.com/web#id=748876&view_type=form&model=project.issue&action=963&active_id=49&menu_id=4720
Specs
=====
remove "Category type" in categories
it seems to me the only usefulness of this was the deprecated tree view of product categories (no longer exists)
When we validate a SO with an MTO product, then an RFQ and a delivery
picking are created. The status of the delivery picking is in state
'confirmed', but should be 'waiting' as the delivery waits for a
specific delivery input.
The problem is caused by the unreserve method, which is called in the
'procurement_jit' module. This method only checks that a move has
ancestors to determine if the move should be in waiting or in confirmed,
which is not the case for our delivery move because the RFQ has not been
validated yet so there is not ancestors yet.
To fix this issue, we check the 'procure_method' of the move, and if it
is in 'make_to_order' we put it in 'waiting' instead of 'confirmed'.
We also fixed the function recalculate_move_state that could cause the
same problem.
- Create a tax using the tax template 'GST + QST for sales'
- Create a SO with the following lines:
Product 1 100 Units @ 0.1
Product 2 2000 Units @ 10.334
Product 3 2000 Units @ 10.334
Product 4 5000 Units @ 0.1
Product 5 1500 Units @ 0.1
- The totals are:
Amount without taxes: 41996.00
Taxes: 6288.90
When printed, the quotation gives:
Amount without taxes: 41996.00
Taxes: 6286.52
This is due to the method `_get_tax_amount_by_group`, which is using
`line.price_reduce` for tax computation. Since it is a Monetary field,
it is automatically rounded to the currency precision, while it should
be rounded with the same precision as `price_unit`.
Introduced in 99743cc4aa
opw-752487
- Create a tax using the tax template 'GST + QST for sales'
- Create a SO with the following lines:
Product 1 100 Units @ 0.1
Product 2 2000 Units @ 10.334
Product 3 2000 Units @ 10.334
Product 4 5000 Units @ 0.1
Product 5 1500 Units @ 0.1
- The totals are:
Amount without taxes: 41996.00
Taxes: 6288.90
When printed, the quotation gives:
Amount without taxes: 41996.00
Taxes: 6286.52
This is due to the method `_get_tax_amount_by_group`, which is using
`line.price_reduce` for tax computation. Since it is a Monetary field,
it is automatically rounded to the currency precision, while it should
be rounded with the same precision as `price_unit`.
To avoid breaking overrides, changing the field type is done in master
branch.
Introduced in 99743cc4aa
opw-752487
This fix previous commit a29f7f671b.
(1) Some objects have no color field.
(2) There was an issue when two many2many tags were instantiated:
If the first one had the 'color_field' attribute the second one
had it too even if this attribute weren't specified.
Now, it's fixed in data_manager
The field 'payment_acquirer_id' is added on the sale.order model
in the website_sale module, which may not be installed when this
code runs since it is higher up in the dependency tree.
Either way, it's quite convoluted to go fetch the acquirer on the
quote since it's already available on the transaction itself anyway.
opw-755998
Before this fix, the base64 image are remove and never send. The images
were in the body increasing the size of the database unnecessarily
(cfr some odoo users with the chatter)
NB: According to the prophecy Khoi will come and dominate the world,
ask him anything
The old behavior was to call wkhtmltopdf for each report and to put all of them together
using the merge_pdf method. It was a very slow approach because all report needs
5 temporary files, one subprocess and then, a merge.
The new behavior is to perform a single call to wkhtmltopdf by putting all the footers/headers
html together and so, avoid call to merge_pdf to greatly improve the performances of the reporting.
The state of the search bar (expanded or not) is supposed to be saved
into a local storage variable which is retrieved whenever loading a view
that has the search bar in it and it is expanded automatically if it was
done previously in any other view, this didn't happen previous to this
commit because the variable wasn't being set properly (missing key).
Some reports require additional information to render. When
accessed in Odoo, the user has to fill a wizard to provide those
information. However, when these reports were opened in Studio,
it crashed as those information were missing (we don't pass
through the configuration wizard in this case).
This fix checks if all the required information are given before
trying to render those reports, and it displays a warning in
the logs in they are missing, which is better than a traceback.
backported in v10 for opw-753036
Steps to reproduce:
-Create a PO with two lines L1 and L2
-L1 has product P with qty=10 for a scheduled date=23/07/2017
-L2 has product P with qty=10 for a scheduled date=30/07/2017
-Confirm the PO
When delivering 5P of L1, the scheduled date of the picking is the
right date which is 23/07/2017
But when delivering the other 5P of L1, the scheduled date of the
second picking was 30/07/2017 instead of 23/07/2017.
opw:752192
Before this revision, multiline links in form views had a different
colour depending on whether we were editing a record, or merely
viewing it.
As an example, the 'customer' field (containing both the name and the
address) in the form view of 'invoice' is affected. When editing the
invoice, all lines have @link-color as colour. However, when viewing it,
only the first line does, while the address is in @odoo-main-text-color.
Since f963500a9f, users of the ecommerce
were able to select carriers even if they actually were not shipping to
their address.
Also, using an integrated carrier (eg: Fedex) caused a crash at the
payment page.
With this commit, delivery price is now computed only on the payment
page and when selected.
Editing the cart after selecting a delivery method will now be much
faster, since delivery prices are not recomputed anywhere else than on
the payment page
(we also fix minor CSS and JS issues)
The module is described in either static/description/index.html, either in
README.md file.
It is ok to have both README.md and index.html as index.html is for a formated
description and README.md is displayed in github
e.g. https://github.com/odoo/odoo/tree/10.0/addons/stockCloses#18036
This commit aims to replicate saas-15 behaviour when adding columns in
a Kanban view by not folding the column quick create widget when
creating a new column, thereby allowing users to add multiple columns in
one go.
Following the previous commit, it appears than the scrap mechanism needs
some rigorousness when looking for quants characteristics (i.e. if we
look for a quant without `lot_id`, it should not return one with one)
but some flexibility with the location (i.e. we can look in sublocations
to find one with the given characteristics).
Before this commit, we centralized everything related to quant's search
in stock_quant.py and the `_gather` method, which has a `strict` kw. As
we exposed the `_get_quantity` method but is only used in stock_scrap,
and that the `strict` flag does not fulfill the needs of stock_scrap, we
inline the appropriate search, as it was done previously.
When updating the quantity on hand in a location without quant but
where one of its sublocations has onee, it will increase the available
quantity in the sub location instead of the defined location.
This happens because _gather method in quant search on child_of location
in any case.
This commit change the domain by using '=' on the locations if `strict` is
passed as True in _gather, or 'child_of' if it is set as False. It also
removes the strict argument on _update_avaible_quantity since it does
not make sense to change the quantity on an undefined quant. And it was
never used in our code for good reasons.
A previous revision[0] forbid to scrap consumables. The rationale at the
time was that, since consumables do not have quant, scrapping them does
not make sense. It appears that people use this feature on consumable
for traceability reason, so we bring back the old behavior.
A slight change was done in stock_scrap.py: if the product is a
consumable, do not raise the error if the quantity to scrap is not
available in stock for obvious reasons.
Also, a leftover todo in the code indicate that we should unreserve the
any move having reserved the scrapped product. This is actually already
done, since this mechanism is in the move line `action_done` and a scrap
uses a classical stock move and stock move lines.
We introduce some test to prove that it is possible to scrap a stockable
product and the quant are impacted, to scrap a consumable product and
the stock is not impacted and to scrap something that was reseved by a
move and that the move changes its state.
[0] 86f08c091e
PURPOSE
=======
Currently 'Sales Analysis' report have by default group by creation date. here matters if confirmed SO is the confirmation date(for sales commission, etc), not the creation date.
SPECIFICATION
=============
'Sales Analysis' have default group by 'Confirmation Date' instead of 'Creation Date'
PS: Validate 2 SO to have a confirmation date.
When creating a new line in a picking, the initial demand should be 0.
When editing a move line and changning the product, the initial demand
should not be reset to 1.
The rationale is that when creating a picking by hand, most users do
want to skip the reservationm and, by forcing the initial demand at 1,
we force the user to enter to encode two times what he's doing.
The owner was not correctly passed to the move lines, and indeed it was
written as a "to do". So we do it. We correctly indent all the
move_line_ids block and add a testcase.
Before, it was possible to have a move without move line / pack
operations and the `restrict_lot_id` was used in this case. Now, every
move has move lines / pack operations and this field was unused. Let's
remove it.
Consignment worked in backend but there was no
tools in front end in order to use it.
This commit update the views and add consignment in picking
and stock move lines
Martin Trigaux