Merged from upstream 14 221001 01 #545
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Steps to reproduce the bug:
- Create a storable product “B1”:
- Costing Method: average
- With BOM:
- BOM Type: Kit
- Components:
- 3 units of “C1” (cost c1 = $2)
- Go to the “B1” product form:
- Click on “Compute Price from BOM”
- Cost = 3 * $2 = $6
- Create a storable product A1:
- Costing Method: average
- BOM
- BOM Type: Kit
- Components:
- 2 units of B1
- Go to the “A1” product form:
- Click on “Compute Price from BOM”
So: 1 unit of A1 → 2 units of B1 → 3 units of C1
- Cost = (2 * 3 * $2) = $12
- Create a SO:
- Add 1 unit of “A1”
- save
- cost(`purchase_price`) = $12
- Confirm the SO
- The cost is recomputed and becomes = $6
Problem:
When the SO is created and the product “A1” is added, the cost is
retrieved from the product: https://github.com/odoo/odoo/blob/14.0/addons/sale_margin/models/sale_order.py#L27
But when the SO is confirmed, a picking is created, therefore the
cost is recomputed: https://github.com/odoo/odoo/blob/14.0/addons/sale_stock_margin/models/sale_order_line.py#L18
So The `_compute_average_price` function is called, in which a loop is
made for each move related to the `sale.order.line`, but the
`bom_line.product_qty` is used for each component (in this case the qty
necessary of the product `C1 ` to make a single unit of `B1`, but this
is not multiplied by the number of units needed to be used in the
parent's bom_line
opw-2971248
closes odoo#100126
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
To reproduce: Video: https://drive.google.com/file/d/1bAh7KA_5UhhIrr-qF5A5gOVWhk3_9clj/view 1. Have multi-language website 2. Event with one ticket 3. Reload page and click the "Register" button -> in some cases there is a traceback `/event/great-reno-ballon-race-2/registration/new: Function declared as capable of handling request of type 'json' but called with a request of type 'http'` Reason of the issue: As the button "Register" in the form is defined with `type="submit"` it will send the form as plain HTTP if clicked. This behavior is modified in the JavaScript to prevent this default behavior. However, if the button is clicked before the JS load, the HTTP behavior is used which does create the above traceback (as the `registration/new` route accept only `json` type). Solution proposed: Prevent the button default behavior and make it deactivated and let the JS activate it when it is ready Note on stability: As JS code and XML view is modified, this fix was thought so that the JS won't have an impact if the view isn't updated. There is theoretically no way that the XML view would be updated without the JS being updated (except manual modification in the view or rollback on the version revision after performing a module update on odoo.sh). If it was the case then the button will be deactivated until the user change the number of ticket. OPW-2946706 closes odoo#100490 X-original-commit: 34db500 Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
complementary to odoo@523cfc4 closes odoo#101061 Signed-off-by: William André (wan) <wan@odoo.com>
Reproduction: 1. Install eCommerce and accounting 2. Go to Accounting->Configuration->Taxes, add one sale tax 15%, and one 0%. Both taxes are included in the price. 3. Go to Configuration-> Fiscal Position, create a new one “test” which applies the tax mapping from 15% sale tax to the 0%. Check “Detect Automatically”, set country group as Europe 4. Go to Website->Orders->Customers, set the country of the portal user, Joel Willis, as Luxembourg. In Sales&Purchase->Fiscal Information set the fiscal position as “test” 5. Go to Website->Products->Product Variants, create a new one “test_tax_prod” with price 110, and sale tax 15%, can be sold, can be purchased and consumable. 6. Go to Website->Configuration->Attribute, create a new product attribute “test” with Display Type as Ratio, Variant Creation Mode as Never. Create a value “a” in its attribute values 7. Go to Website->Products->Products, find test_tax_prod, go to its variant tab, set attribute as “test” with value “a”, publish this product 8. Open an incognito tab, login as “portal” pwd: portal, search the product “test_tax_prod”, set the price list as “public price list”, the price is 95.65 on the page. Add it to the cart, the price is 110 Reason: When we update the order_line, we should update the price based on the fiscal position for the no_variant products too. However, based on the current workflow, the price is computed in method _website_product_id_change before an order line is created. Thus for no_variant products, the price is not updated. Fix: This issue is fixed in saas-15.3 by rewriting the workflow and calculating the price through an on_change function here: https://github.com/odoo/odoo/blob/saas-15.3/addons/sale/models/sale_order_line.py#L588-L605 In v13, we don’t have this on_change method to compute the new price, so a similar price update can be created in the cart update for website_sale. This fix solution was created here: odoo@ea25921 However, new price computation issues can happen when combining two pricelists, here: odoo@8d6a2ca Thus the fix is eventually done in _website_product_id_change. Added a new parameter to force checking the orderlines based on the domain. The orderline is created but only can be searched based on the domain. This ensures the price is computed correctly for pricelists and for tax. Added fiscal position test for no variant product opw-2856956 Fix by re-writing in saas-15.3: https://github.com/odoo/odoo/blob/saas-15.3/addons/sale/models/sale_order_line.py#L588-L605 First related fix: odoo@ea25921 Second fix to patch for the first fix: odoo@8d6a2ca closes odoo#101087 X-original-commit: d8a730f Signed-off-by: William Braeckman (wbr) <wbr@odoo.com> Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>
A "thematic break"[1] is composed of 3 or more characters (-, _, or *). The current separator using only 2 characters between the main body of the PR and the footer / addendum makes it more difficult to interpret the message. Update to 3 so e.g. the mergebot can strip the footer. [1]: https://spec.commonmark.org/0.30/#thematic-breaks closes odoo#101100 X-original-commit: c7bf932 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com> Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
If website content has a <title> html tag the initial title value in "Promote - Optimize SEO" receives all title values on the page and not only the <title> value inside the <head> tag. <title> tag is valid html for example inside an <svg> element: https://developer.mozilla.org/en-US/docs/Web/SVG/Element/title In order for Optimize SEO Title value to correctly receive the main <title> tag inside <head> we need to target it specifically. Part-of: odoo#101209
closes odoo#101209 Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Issue : - `account.move.state` has only 3 possible values cancel, draft, posted - the wrong value was used Fix: - Use the correct value `posted` OPW-2991389 closes odoo#100902 X-original-commit: 1a46b6b Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com> Signed-off-by: Mohamed Megahed Abbas Megahed SALLAM (mome) <mome@odoo.com>
# How to reproduce: - Delete external ID "purchase_stock.route_warehouse0_buy" - Try to create a Product "purchase_stock.route_warehouse0_buy" was meant to be optional. We can only get the id after checking that it exist. OPW-2972494 closes odoo#99687 Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
The default value of max_time_between_keys_in_ms in barcode is 55 ms. The default value of 55 ms is too low and creates an issue for RFID readers. The default value of max_time_between_keys_in_ms is increased to 100 ms. task-2996072 closes odoo#101233 X-original-commit: df4f5a8 Signed-off-by: Kevin Baptiste <kba@odoo.com> Signed-off-by: phwa-odoo <phwa@odoo.com>
…eriod Currently, the user can resequence invoices that are in a locked period. This is not desirable, this commit fixes this. closes odoo#100954 Related: odoo/enterprise#31695 Signed-off-by: Quentin De Paoli <qdp@odoo.com>
closes odoo#101362 Signed-off-by: Laurent Smet <las@odoo.com>
Due to a recent fix (fae6997), the price subtotal of the downpayment lines (which, on the final invoice, should be negative) are positive in the generated xml. To fix this, we remove the condition that inverts the downpayment line value. Since the correct (negative) value of the downpayment lines is ascertained. Only the value of the reverse charge refund lines should remain inverted, since in this case, the price subtotal is positive, but the amount on the document should be negative. closes odoo#101289 Signed-off-by: Josse Colpaert <jco@odoo.com>
With [1], the frontend main scrollbar was moved to the #wrapwrap element and with that change came many scroll utils and code adaptation. The goal was for the code to be generic but after multiple bug fixes, only the case of #wrapwrap being the element which scrolls (this stable version's standard case) was actually working. As the scroll is being moved back out the #wrapwrap in master (see [2]), those non-properly working generic features were found. This commit solves the stable utils in preparation for that master merge. Indeed even if the standard 14.0 case was not impacted by those faulty utils, they were still wrong and could impact users migrated from 13.0 and earlier. Note: some adaptation actually handles the case of multi-documents in the page (like triggering a scroll in an iframe from out-of-the-iframe JS code). This is not needed here in 14.0 but will be in the forward- ported version in master for the 'website-in-backend' features merged at [3]. This actually includes some (parts of) fixes that were done in the wrong version, like [4]. [1]: odoo@4e7be69 [2]: odoo#98429 [3]: odoo@31cc10b [4]: odoo@f240a42 Part-of: odoo#98514
Before this commit, when you clicked on a link which was supposed to reach the top or the bottom of the page, the animation looked strange. This was because the scrollTo util cannot handle fixed-positioned elements correctly, which the header and footer can both be. While the animation did look strange, it was still working. So the time was never took to investigate. However, if [1] was to be reverted (as it will partially be in master to restore the scrollbar at its rightful place now that it can be done (see [2])), using scrollTo on those elements simply did not work at all anymore. This commit fixes the problem by making an exception for those elements specifically. Notice that there is another "bug": if the header or footer is removed (as there are options to do so), not only scrolling to "top" or "bottom" cannot work properly but the option also does not show up in the editor panel. This will be considered as a limitation for stable versions and be fixed later in master. [1]: odoo@4e7be69 [2]: odoo#98429 closes odoo#98514 Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce:
1- activate developer mode
2- add an extra language
3- generate missing terms
4- filter by text: 'On product with following tax'
Bug:
'On product with following tax:' and 'On product with following taxes:'
are missing on transifex
Fix:
removed those strings and reused existing translation
("Discount: %(program)s - On product with following taxes: %(taxes)s")
opw-2945810
closes odoo#100317
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Steps to reproduce the bug:
- Install purchase_requisition and accounting
- Enable `Analytic Accounting` and `Purchase Agreement` in the settings
- Create a Purchase Agreement:
- Add any product with any analytic account and tag
- save and click on “New Quotation”
Problem:
1:/The product is added with the values set in the `”purchase Agreement”`
except for the “Analytic account” and “analytic Tag” which are empty.
They are correctly got from the `”purchase.requisition.line”` in the
`”_prepare_purchase_order_line”` function:
https://github.com/odoo/odoo/blob/14.0/addons/purchase_requisition/models/purchase.py#L73-L76
https://github.com/odoo/odoo/blob/14.0/addons/purchase_requisition/models/purchase_requisition.py#L267-L268
But then the default values are computed:
https://github.com/odoo/odoo/blob/15.0/addons/purchase/models/purchase.py#L1096-L1120
And since there are no default values in the product, both fields are
empty.
Bug introduced by this commit: odoo@eadd0be
2:/ The product's default analytic account and analytic tag must be
computed when a new requisition line is added.
opw-2990711
closes odoo#101145
Signed-off-by: Tiffany Chang <tic@odoo.com>
Steps to reproduce: - Activate Dropship and multi routes - Create a SO and select the route Dropship - Confirm the SO - Confirm the purchase - Click on Customer Preview Issue: In the customer preview, if the customer click on the do, vendor's info will be displayed. opw-2961884 closes odoo#100276 Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Tests for - e6a1e24 - fd22fe2 Part-of: odoo#100565
…bcontract
A user can not buy a subcontracted product and directly deliver it
(dropship) to another subcontractor. Moreover, in such situation, the
received quantity is not correctly computed.
To reproduce the issue:
(Enable debug mode)
1. In Settings, enable "Storage Locations"
2. Create three products:
- P1:
- Storable
- With a vendor V1
- P2:
- Storable
- With a vendor V2
- P3:
- Consumable
3. Edit V1:
- Customer Location: Physical Locations/Subcontracting Location
4. Create two BoMs:
- Product: P1
- Type: Subcontracting
- Subcontractors: V1
- Components: 1 x P2
- Product: P2
- Type: Subcontracting
- Subcontractors: V2
- Components: 1 x P3
5. Create a PO:
- Vendor: V2
- Deliver To: Dropship
- Drop Ship Address: V1
- Products: 1 x P2
6. Confirm the PO
Error: a Validation Error is raised at `mrp.production` creation because
of a missing field (`picking_type_id`).
In some cases, when getting the values to create the MO, the basic
`_prepare_subcontract_mo_vals` does not return any `picking_type_id`.
That's the reason why an override has been added in
`/mrp_subcontracting_dropshipping` (see [1] for more details). Thanks to
this override, if the usage of the destination location is `customer`,
we know that we are in a "dropship" situation and we manually define the
`picking_type_id`:
https://github.com/odoo/odoo/blob/d73e70f22e47e81e59aff0c9f578aff260447256/addons/mrp_subcontracting_dropshipping/models/stock_picking.py#L15-L17
However, in the above case, the subcontracted stock move starts from a
subcontracted location and also goes to a subcontracted location
(because of step 3). As a result, the if-condition is not respected and
the `picking_type_id` is not defined.
Once this issue is solved, there is a second one: suppose the PO
confirmed. The user validates the transfer. New error: the received
quantity on the PO is not updated. This is because of an incorrect
condition in `/purchase_stock._compute_qty_received`:
https://github.com/odoo/odoo/blob/d0537e32e5aa4b0fe2ad674ab3ec7c42ae1a12f9/addons/purchase_stock/models/purchase.py#L306-L315
Added by [2] and modified by [3], this condition checks that:
- the destination location usage is `internal` (correct, this is a
subcontracting location)
- the source location usage is not `supplier` (correct, this is a
subcontracting location, so it is `internal`)
- the destination location is not part of the warehouse children (here
is the issue: the SM does not have any warehouse, so it gives a false
positive)
So, because of the incorrect third condition, the condition is
respected. And because `to_refund` is `False` (which is correct), we
don't do anything. That's the reason why the received quantity is not
updated.
[1] d73e70f
[2] e6a1e24
[3] fd22fe2
OPW-2922546
closes odoo#100565
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
If a user imports a FacturX where an item has a name but no description, the invoice is not created. We now use the item name as a fallback in case there is no description. opw-2951705 closes odoo#101545 Signed-off-by: Josse Colpaert <jco@odoo.com>
- Go to accounting/Report/Invoices Analysis - Open studio - enable list view - empty view This code bellow compute count_field as `__count` because group_by_no_leaf is in the context. But in the basic_model we don't consider this case. https://github.com/odoo/odoo/blob/5797fd80a63309269f15bcbe4948d4429a53eec2/odoo/models.py#L2293-L2297 opw-2980923 closes odoo#101530 X-original-commit: e88602f Signed-off-by: Aaron Bohy (aab) <aab@odoo.com> Signed-off-by: Achraf <abz@odoo.com>
Those constraints are an incorrect leftover from 0a42a9d which removed the size constraints on a number of core tables including 'name' and 'model' of ir_model_data. Temporary table tmp_ir_translation_import limits columns size (imd_name and imd_model). Those columns are only used to match columns 'model' and 'name' in ir_model_data. But in ir_model_data, columns 'model' and 'name' are VARCHAR, no reasons to restrict the temporary table. opw-2983422 closes odoo#101521 X-original-commit: db53038 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
closes odoo#101628 X-original-commit: 047f878 Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit fixes 2 issues with the position of the dropdown with the suggested links in the url picker input of the snippet options. (e.g. redirect url input of the countdown snippet). 1- Before this commit the dropdown went over the input while editing the url. 2- Before this commit the position of the dropdown (when above the input) was a little too low if there were images in the dropdown. It was because the images are loaded after the positioning of the dropdown and no height was defined for these images. task-2900529 closes odoo#97305 Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Steps to reproduce: 1. change system and admin's time zone to one with a different date than UTC 2. enable multi-currency in the accounting module 3. add rates for the current date in local time zone and UTC 4. go to settings > currencies 5. the rate for the UTC date is displayed To fix this, we should use a time zone aware field in `res_currency`. opw-2945108 closes odoo#101640 X-original-commit: 2f1d8d6 Signed-off-by: William André (wan) <wan@odoo.com> Signed-off-by: Khanalizadeh Ahmad (khah) <khah@odoo.com>
This PR odoo#97805 wrongly assumed that self contained a single workorder. This would raise an error if there were multiple records in self. Solution: Modify calls on `self` to `workorder` (as we already iterate through them) closes odoo#101706 X-original-commit: f6a66d7 Signed-off-by: William Henrotin (whe) <whe@odoo.com> Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Fixup for d823033 Portal user should not modify partner's name if an invoice for this partner is already issued. However, delivery address contact may have empty name, while eCommerce UI requires filling out the name. This blocks checkout process. Fix it by allowing name changes, when it's not set. opw-2981455 closes odoo#100797 Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
If the components of the manufacturing order are in done or cancel state you should NOT define the status of the manufacturing order as done. It should only be set as done if components and finished moves are done/cancel. TT38551 closes odoo#98105 Signed-off-by: William Henrotin (whe) <whe@odoo.com>
royle-viindoo
changed the title
royle-viindoo
changed the title
royle-viindoo
changed the title
royle-viindoo
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr