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
In the main_flow_tour, we edit a related record of a many2one in a
one2many. A modal is displayed and we make some changes. We
then click on 'Save' in the dialog. The next step is to add a new record
in the one2many, so we click on 'Add an item'. However, we didn't
wait for the modal to be closed before clicking, which is actually not
possible in practice (because of the modal backdrop).
This made the tour fail when run from the browser, since commit
c300e5e, which produces a redraw of the line containing the
many2one that has been edited.
This rev. ensures that we wait for the modal to be closed before
adding a second record.
A `currency_id` field on a `hr.expense.sheet` only makes sense if all
expense lines are in the same currency. It is very likely to not be the
case, so don't format the total amount.
In master, the fild should simply be completely removed.
opw-761098
When a replying to an email, the matching alias should first verify access
via the parent record if exists (i.e. check on the project instead of
on the issue itself).
Use case to reproduce the bug:
- Create a PO line with 10 product -> validate the picking
- Edit the PO line and add 10 product -> it creates a new picking with a move line
- Edit the PO line and remove the 10 products
-> There still an empty picking that is not linked to the PO.
This happens because the _create_or_update_picking in purchase
only remove the stock move if it is empty but do not check anything
on the picking.
This commit add a check on the picking if there is no move inside,
delete it.
The new "My Activites" filter introduced by rev. 87e457158e
should not be in the same group of the search view as other activity
filters (Overdue/Today/Upcoming), otherwise they are combined with OR
instead of AND.
This is particularly misleading when coming from the Sales dashboard, as
the "Overdue" button of "My Pipeline" will lead to a list of
opportunities with "My Activities OR Overdue Activities", showing *all*
opps with overdue activities, not just yours.
When creating a customer invoice with description/reference with more than
64 characters, the description was cut to generate the name of the account move
lines. But it's possible to create an entry with more than 64 characters as name
by the interface. The limitation is deprecated.
opw:760316
Such buttons are not going to work on records that actually do not
exist yet. The behavior is now the same as in saas-15.
Steps to reproduce the bug:
Steps to reproduce the bug:
- 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
- Click on the little square with a + in the m2m list view, the
server will crash in the ensure_one of the function called by
the button since there is no record to run it on.
Previously, we did not handle the case where the result of the m2m
default get was a new record. In this case, we can't just send a
replace all command giving the ids since the new record has no id.
We decided to keep the replace all command even when it is empty
to stay consistent with the o2m implementation, even though saas-15
did not behave like that.
Steps to reproduce the bug:
- 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
- You'll get an error as the id given to the onchange is a virtual one,
rather than a create which would not include an id.
Previously, it used to create a virtual datapoint even though there was
no change on this field. If the field was a many2one, this datapoint
triggered a name_get call afterwards, but giving the virtual id of
the datapoint since there is no real record. The solution is to avoid
creating a virtual datapoint when it is not needed at all, thus fixing
the wrong name_get call.
Steps to reproduce the bug:
- 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
- You'll get an error as the web client tries to fetch the name_get of
this datapoint even though the record does not exist.
before this commit, when a portal SO was done with a product that hasn't been "website_published", a placeholder was displayed instead of the image
After this commit, the correct product image is displayed in base64 (always image_small though)
OPW 760880
Closes#18709
Since refactoring in saas-17 quant_ids are removed and
the logic is instead locate on stock_move_line. This commit
adapt the method by trying to undo the created move_line
during the MO.
This commit also add a default_uom_id in the view's context in order
to remove a traceback. Since 0469d2e
uom is mandatory on stock_move_line.
It also add a bunch of tests in order to check the behavior of unbuild
with 4 test: without tracking, consumed product tracking, produced product
tracking and everything tracking.
Know limitation of this commit:
-> No warning message when unbuild more than in stock.
-> Wrong result if trying to unbuild twice the same MO
with consumed product tracked with different lot/SN
Trying to set multiple lines with different lot on a MO
will raise an odoo server error with the field product_uom
on model stock.move.line.
This bug is linked to stock refactoring commit 0469d2e712
where the uom become required on move line. In order to get a default
value on create call the uom should be pass in the view's context.
On the production wizard when you are using a product tracked
by SN/lot and another not tracked as consumed element. You edit
the form view by settings the correct quantity -> Use the produce
wizard. It will display the tracked product (you can see the details
you entered before) -> validate. It will double the quantity done
for the not tracked product.
This commit will change the wizard behavior by only set the quantity
done on untracked product if it is not already set.
The traceability report in downstream was looking for newer move lines
instead of older ones, which leads to not showing all related traceable
moves.
We also changed the sort order of the move_lines in downstream
before this commit, when a product had its asset_category set, the account attachement to the asset_categ was righfully selected on the invoice line when creating the invoice from scratch
Though, that was not the case when the invoice was created from the po
after this commit the right symmetric behavior is back: the default account that will be selected on invoice line is the asset_category one.
opw 761033
Closes#18687
The purpose of this is to help stock manager in their quants analysis.
An overview of quants can be accessed via inventory menu and for specific
lot/SN via the locate button.
This commit add quants in every location (only internal location previously)
The purpose is to introduce a double entry for quant (add quants to a destination
location will always remove quant from a source location).
Quants in customers/suppliers location are shared between all customers/suppliers.
In order to know the amount of product that come from a specific customer/supplier
the tracability report should be used.
Unfortunately, ed60339 is incompatible with ebd1721 since
we once again do not send the values of readonly fields.
This is a partial revert of commit ed60339.
Onchange RPCs return an object that may contain a 'domain' key.
When it does, its value is an object whose keys are field names and
values are the new domain for the corresponding field.
Commit 8473bde8 added the support of the 'domain' key, but stored
it directly in the fieldsInfo (an object gathering information of
the fields in the view, and which is shared between all records).
This was wrong as the domain isn't necessarily the same for all
records. To reproduce, with the UOMs activated, go to Sales >
Quotation, in the form view, add an order line, set a product
(e.g. Graphic Card), the onchange sets the domain for the uom
field (matching uoms like 'unit', 'dozens'). Add a second line
with a service product, the onchange returns another domain for
the uom field (matching uoms like 'hours', days'). Click again on
the uom field of the first line, the domain is the one of the
second record, which is wrong.
This rev. directly stores the domains returned by the onchange on
the object representing the record, so that this information isn't
shared between records anymore.
There was an issue if you make a backorder for a reserved move while not
having any quantity done on it. The 0 move will have its `picking_id`
field set to the backorder, but not its move lines, and the result was
that a stock move could be considered `assigned` while not having any
move lines.
The test that could show this issue did not fail because of an unwanted
call to `_free_reservation` that would call `_recompute_state` on the
inconsistent stock move.
Commit 14d1f6f6c1 responded to the need to have clean server answers for SEO purposes
and specifically when the products on event tickets have been archived
BUT
it introduced an infinite redirect loop when the event was in state == done
This present commit normalize the behavior in a comprehensive manner and cleans up the code a bit
OPW 757117
Closes#18667
Before this commit, it was impossible to load the x2many fields subviews when
they were not defined inline.
Now it is possible to call the method "_loadSubviews" to do so.
Used mainly in studio, to be able to display the x2many fields without inline
views.
Before this revision, editing a many2one inside an x2many field did not
cause an update of the x2many field upon saving. This is due to the fact
that a field on a screen was deemed affected by a record change only if
its value or a directly related record has been updated.
This present revision looks for changes recursively, thereby including
the case where an x2many field contains a many2one.
The bug appeared for example in Manufacturing, when editing the product
name of a BOM line.
Use case:
- 2 invoices in foreign currencies, made at different times (and different exchange rates)
- 2 payments (same characteristics as invoices)
- allocate the 1st payment to inv A
- allocate the 2nd payment to inv A and then B so that A is fully paid, but B is not
- try to make the final payment on B to fully reconcile everything
Results (all in the payable account)
- let CB be the credit line of B
- let D2 be the debit line of 2nd payment
- let D3 be the debit line of the 3rd and final payment
Before this commit, the exchange difference computation dailed because:
- There were 2 amls that had an amount_residual and needed to be reconciled (CB and D2)
- Also, there was a structural flaw in the code that did not allow for multiple lines to have a residual
After this commit, we still make 1 move to log the exchange difference,
but we make exchange difference lines for each line that need to be reconciled: CB and D2
OPW 751710
Commit in master c36f70f6726e0c7ccca1002f78e4d402e27cae3d (2017-07-20)
Closes#18347
[FIX] account: testing partial and full reconciliation
To reproduce:
- Go Website Admin > Configuration > Settings
- Change the Website Name
- Click on 'Cancel'
The name is saved.
When the "Cancel" button is clicked, we automatically save the record
(which is a transient model). Since the field is a related to the
company, the name is changed even if we canceled.
opw-760749
The goal of the commit https://github.com/odoo/odoo/commit/c5bd509 is to update the etherpad content if the description field is updated.
However, if the pad is not initialized yet, we shouldn't try to do this obviously.
This patch modifies Root#dispatch() in order to keep the httprequest url
in the current thread's attribute and use if for dumpstacks and the
phantomjs tests remaining requests handling.
Also added a counter in order to avoid looping forever when trying to join unclosed http requests
in phantomjs test suite after a phantomjs failure + added a log.warning in such a case so it's easier to troubleshoot runbot's ir.logging.
Use case: click on "reconcile X items" on a journal which doesn't have its default credit or debit account set.
Result: Before this commit, a useless traceback popped to the user.
After this commit, move lines are searched without taking into account the journal's default accounts for debit or credit
OPW 760305
Closes#18485
Before this commit, the view selected to be edited by the html editor was the wrong one
This was caused by the simplification brought about by commit a2ae219d4e
which transfered from python to js the decision to make a view a header for the [customize] menu (on the website
In this case, the first view in the return list of python was the header, and the second the actual view
Now that python just sends a list of unique views without any distinction whatsoever, the right view to pick when entering the html editor is the first one, at index 0
opw 760279
Closes#18603
In anglosaxon accounting's stock valuation, the case where invoice and company currencies are different was not managed properly, because of a syntactic error in the condition checking this case.
(this has already been merged on saas-14, but the PR should have initially been made for 10.0 ... my mistake ! See https://github.com/odoo/odoo/pull/17259 )
Before this commit the key default_type in the context was messing with ir_attachment's own key of the same name
We change the key's name to avoid misreadings
OPW 757039
Closes#18515
Before this commit, the iframe tags were sanitized as the should, but never spawn back from JS.
Now, the iframe is actually created
opw 750830
Closes#18643
Sylvain GARANCHER