Syncing from upstream odoo/odoo (tmp.saas-18.1) #34191
Merged
Conversation
This file contains hidden or 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
…rt layout Steps to Reproduce: 1. Go to Settings > Companies > Configure Document Layout. 2. Choose layout Boxed or any layout that horizontally places the company logo and address. 3. Edit the address block choose long string. 4. Save the layout and click Preview Document or print SO or invoice. Issue: Observe in PDF output the long text overlaps into logo or extend outside the layout bound(differ in layouts) — even though enough space is visually available Cause: A previous change in PR #201198 added the text-nowrap class to address blocks to fix a minor wrapping issue. However, this unintentionally caused layout overflow issues with long lines. Solution: - Added width to the address block to ensure balanced layout structure. - Removed text-nowrap from all layouts, as the original issue is now resolved by applying proper width sizing. - Removed float-end from Boxed layout, as it was contributing to misalignment. Additional Notes: All behaviors addressed by PR #201198 were re-tested to ensure this fix does not reintroduce previous issues. opw-4764975 closes #217812 X-original-commit: 0a45a1e Signed-off-by: Bastien Fafchamps (bafa) <[email protected]> Signed-off-by: Khushi Srivastava (khsr) <[email protected]>
Issue: Copying a bom with an operation will not reassign the copied operation to the by product lines. Steps to reproduce: - In the settings enable operations and by-products - Create a bom with an operation op1 and a by product produced in op1 - Copy the bom > The copied by product line refer to the operation of the original bom > this can be checked by archiving the copied operation which should > erase its link with the copied by product line but will not Cause of the issue: When a bom is copied, the new operation is reassigned to the new bom lines by these lines: https://github.com/odoo/odoo/blob/9cb4230a6b2252243a8e0546a1a8f5bc52e74009/addons/mrp/models/mrp_bom.py#L230-L247 However, nothing is made for the by product lines. opw-4788252 closes #217813 X-original-commit: 75668dd Signed-off-by: William Henrotin (whe) <[email protected]> Signed-off-by: Lancelot Semal (lase) <[email protected]>
Before this commit: 1. Create an expense paid by company 2. Create an empty expense report (not through the expense form view) 3. Add the expense to the report (Updates the payment_method and payment_method_line_id but not the journal_id) 4. Try to move forward to create the move 5. Error (The selected payment method is not available for this payment, please select the payment method again.) After this commit: The right journal_id is set when adding an expense to an empty expense report. task-4804970 closes #217832 X-original-commit: 7a93e28 Signed-off-by: Julien Alardot (jual) <[email protected]> Signed-off-by: Léo Leclerc (leol) <[email protected]>
In 0f3a9de we added helpers to create test taxes in `AccountTestInvoicingCommon`, not realizing that they were already in `TestTaxCommon`. This commit removes them from `TestTaxCommon` to avoid the duplication. task-none closes #217765 X-original-commit: aae91c9 Signed-off-by: Laurent Smet (las) <[email protected]> Signed-off-by: Antoine Dupuis (andu) <[email protected]>
Steps to reproduce: - Install l10n_it_edi - Switch to an Italian company (e.g. IT Company) - In Accounting settings, activate "Fattura Elettronica (FatturaPA)" - When saving the settings, the system tries to create an EDI proxy user if there is no existing EDI proxy user in "test" or "prod" mode - Neutralize the database with the following command: odoo-bin neutralize -d [db_name] - Go the settings and save Issue: Upon save, the system will try to create an EDI proxy user in "prod" mode (or "test" mode if "l10n_it_edi.proxy_user_edi_mode" system parameter is set to "test"). The database is neutralized. It should not create an EDI proxy user in "prod" mode by default. Cause: An EDI proxy user is created in "prod" mode automatically when there is no existing proxy user in that mode and "FatturaPA" is activated. During the neutralization of the database, all proxy users are switched to "demo" mode, but "FatturaPA" is not deactivated. Therefore, the configuration is set to create a "prod" EDI proxy user. Solution: As we want to create an EDI proxy user in "prod" mode by default on a non-neutralized database, we can deactivate "FatturaPA" option during the neutralization to prevent the creation of an EDI proxy user on a neutralized database when saving the settings. opw-4795396 closes #217866 Signed-off-by: Paolo Gatti (pgi) <[email protected]>
Before, the previous document chaining was not sent in the XML because with the t-if, if the variable name is unknown, it will not complain and just see it as False. (like for the first invoice that has no previous) Now, passing the correct variable name, the previous document will be included opw-4814241 closes #217766 X-original-commit: 4aa87ad Signed-off-by: Ruben Gomes (rugo) <[email protected]> Signed-off-by: Josse Colpaert (jco) <[email protected]>
Before this commit: When calculating the `price_unit` for stock moves from purchase order lines, the `remaining_qty` and `remaining_value` could be imprecise. Standard float comparisons for these remaining amounts could lead to incorrect `price_unit` calculations if, for example, `remaining_qty` was a very small float near zero. This could result in inaccurate stock valuations, particularly when currency conversions were involved or when landed costs were applied. For example, 70.00000003 is rounded **up** to 70.00001 (with 5 digits), resulting in a quantity difference of 0.00001, which incorrectly inflates the unit cost. After this commit: Change the rounding method to 'HALF-UP' instead of the default 'UP' to improve precise result for quantities. Steps to reproduce: 1. Configure a product with AVCO real time. Set decimal precision for price and UoM to 5 digits. 2. Create a Purchase Order (e.g., 190 units @ $110/unit). 3. Receive 70 units and create a backorder 4. Create and post a bill for the initially received quantity. 5. Apply a landed cost to the picking of the first 70 units. 6. Create a draft bill for the remaining quantity on the PO. 7. Receive the remaining 120 units from the backorder. 8. The product's cost explodes opw-4705224 closes #217691 X-original-commit: af91ffc Signed-off-by: Tiffany Chang (tic) <[email protected]> Signed-off-by: Walravens Mathieu (wama) <[email protected]>
The test in this module imports a common setup from account_reports which is not a dependency, and is not auto installed when the test runs with comunity modules only. This fix replaces the setup by the community one AccountTestInvoicingCommon. closes #217764 X-original-commit: 591acd3 Signed-off-by: Jinane Maksoud (maji) <[email protected]>
…tInvoicingCommon closes #217767 X-original-commit: 717676f Related: odoo/enterprise#89658 Signed-off-by: Claire Bretton (clbr) <[email protected]> Signed-off-by: Laurent Smet (las) <[email protected]>
…ed from sale In Hungary the rate of the currency of an invoice is based on the delivery date. When creating an invoice from Sale, the `currency_rate` of the lines is the one of the invoice date not of the delivery. Steps to reproduce: - Install l10n_hu_edi and witch to Hungarian company - Have two different rates for EUR<->HUF - Create a pricelist in EUR - Create a quotation with the pricelist and confirm - Validate the delivery on another date (which has a different rate from today) - In the sale order click "Create Invoice" - The generated invoice has lines using the rate for today Cause: The field `delivery_date` is `precompute=True` but on creation of the invoice, at the time of the precompute, `line_ids` is still `False`. So the invoice is first computed without the delivery date, the currency rate used is the one of the invoice date. When the delivery date is written on the invoice, the line balance is not recomputed as the field `balance` is marked as `protected`. Solution: As the field `delivery_date` was implemented in `account_move` for localizations including l10n_hu, there are no reason to contain the fix only to l10n_hu. So we add the value of `delivery_date` in the dictionnary used to create a new invoice from sale with the method `_create_invoices`. This way the delivery date is there on creation of the invoice and is used for the currency rate. opw-4756568 closes #217814 X-original-commit: 459803b Signed-off-by: Ruben Gomes (rugo) <[email protected]> Signed-off-by: Mathieu Coutant (mcou) <[email protected]>
bug introduced in: ea48070 Steps to reproduce the bug: - Go to "Inventory" → "Operations" menu → "Replenishment" - Click "New" to create a new replenishment rule Problem: Traceback is triggered: ``` in _float_check_precision assert precision_rounding > 0,\ ^^^^^^^^^^^^^^^^^^^^^^ AssertionError: precision_rounding must be positive, got 0.0 ``` As the product is not set, the `product_uom` is not set either, which leads to a `product_uom.rounding` of 0.0. Opw-4925719 Opw-4928957 Opw-4926504 Opw-4925919 Opw-4928684 Opw-4925080 Opw-4928788 Opw-4926719 Opw-4927440 opw-4928540 closes #217959 X-original-commit: 6218559 Signed-off-by: Quentin Wolfs (quwo) <[email protected]> Signed-off-by: Djamel Touati (otd) <[email protected]>
This commit adjusts setting `product_uom_id` field on the generated purchase order line in the 3 main scenarios: manual purchase order, procurement from MTO, and procurement from replenishment wizard. The intended behavior is as follows: * Manual PO: The selected pricelist must respect the uom of the PO line. Even if the quantity of the line matches a pricelist with a cheaper price (but different uom), it should not be selected. If there is no pricelist with the unit of the line, the pricelist with the product base unit is chosen. If it doesn't exist too, no pricelist is chosen, and the price is left to the user (default value of 0). * Procurement from MTO: The selected pricelist must be the cheapest pricelist that respects the requested quantity, even if that cheaper pricelist has a different uom than the source of procurement (SO, MO, etc.). However, the generated PO line uses the uom of the pricelist not the source. * Replenishment Wizard: The behavior is similar to manual PO. The selected unit in the wizard must be respected, even if there is a cheaper pricelist that matches the requested quantity (with different uom). Also now, the selected vendor in the wizard doesn't affect the chosen priclist. It's only used to look for pricelists with the same partner. Task-4471379 closes #205525 Signed-off-by: Arnold Moyaux (arm) <[email protected]>
Before this commit, tour "test_discuss_channel_public_page_as_guest" would crash in test after posting a message in which we attempt to add a reaction. This happens because the step is a `hover && click 'Add a reaction'`, so it hovers on selector `o-mail-Message:contains(cheese)` then clicks on the 'Add a reaction' action. In discuss channels, when sending a message, the message is immediately shown on UI before there's a genuine message that is created in DB. This optimistic behavior gives impression the app is fast, but some actions require a genuine message like 'Add a reaction'. The problem of test is that selector `.o-mail-Message:contains(cheese)` passes with temporary / transient message of optimistic behavior, so the `hover` step would be triggered on the temporary / transient message and 'Add a reaction' action is awaited for click. Problem is that when genuine message data is received, implementation detail deletes the temporary / transient message and then shows the genuine message. Because the genuine message is different, component identity is different (it uses message.localId in `t-key`), thus it awaits `Add a reaction` on UI but it's not visible because we need to hover again, this time on genuine message. This commit fixes the issue by awaiting message is shown on UI is the persistent, i.e. non-temporary and non-transient, so that hover and click on the 'Add a reaction' action works without issue. fixes runbot errors 181660 fixes runbot errors 222093 fixes runbot errors 227756 closes #217982 Signed-off-by: Alexandre Kühn (aku) <[email protected]>
When modifying or deleting an Analytic Account on an Analytic Item, it is not reflected on the Analytic Distribution of the Journal Item. The user can be mislead, given on the business objects (invoice lines), he sees the initial Analytic Distribution but there is no guarantee that the related Analytic Item remains consistent. task-4378407 closes #218030 X-original-commit: 8194c6e Signed-off-by: William André (wan) <[email protected]>
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.
bt_gitbot