Syncing from upstream odoo/odoo (tmp.saas-18.2) #34230
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
We renamed the "Disconnect from current" button to "Disconnect", and removed the possibility to configure a new database if one is already configured. This eases user experience, by reducing the amount of information on the screen. closes #218253 Task: 4922634 X-original-commit: e27dc36 Signed-off-by: Yaroslav Soroko (yaso) <[email protected]> Signed-off-by: Louis Travaux (lotr) <[email protected]>
As saas-18.1 does not pip/apt install packages on checkout, a built image could not connect to a db in an upper version if new packages were required. closes #218244 X-original-commit: d48cc65 Signed-off-by: Louis Travaux (lotr) <[email protected]>
Before this commit: header color of `Dialog` on mobile was "community color" or white, depending on the version of Odoo the database is running. This was creating issues in in the front-end, where the user of the website would see back-end specific colors in different `Dialog`s. This commit removes the color customization of `Dialog`'header as it was fitting a design line we had before we introduced MILK. task-4001365 closes #218255 X-original-commit: ffd9c0f Signed-off-by: Pierre Paridans (app) <[email protected]> Signed-off-by: Antoine Sougné (anso) <[email protected]>
Purpose of this commit: - Backport a part of commit [1] which ensures that the font-size input now changes its color appropriately in dark mode. [1]-48c7cd1 task-4897771 closes #218226 X-original-commit: 2029920 Signed-off-by: David Monjoie (dmo) <[email protected]> Signed-off-by: Adnan Chaudhary (adch) <[email protected]>
…rated Currently, an error occurs when users print the E-Waybill without generating it. Steps to replicate: - Install `l10n_in_ewaybill` and switch to IN company. - Change the `Zipcode` on IN company to `aa`. - Go to `Invoicing > Customer > Invoices`. - Create an invoice, confirm and click Send E-WayBill. - Click on the Gear icon and Click on the report `Ewaybill`. Error: `ValueError: invalid literal for int() with base 10: '' QWebException: Error while render the template ValueError: invalid literal for int() with base 10: '' Template: ir.ui.view(2614,) Path: /t/t/t/t/div/t[3] Node: <t t-if='doc.state in ewaybill_states'/>` The error occurs because the report printing is available even when the `E-Waybill` is not yet generated. This causes the execution flow to skip all the necessary validations, leading to a `ValueError` at line [1]. [1] - https://github.com/odoo/odoo/blob/aa7dac87a3eebce1b300e1e3d04398d680325b5d/addons/l10n_in_ewaybill/models/l10n_in_ewaybill.py#L640 This commit solves this issue by adding a domain to the report, so that it appears only after the EwayBill is generated. sentry-6695761066 closes #218183 X-original-commit: 69b2d6c Signed-off-by: Ricardo Gomes Rodrigues (rigr) <[email protected]> Signed-off-by: Bhavya Ashesh Nanavati (bhna) <[email protected]>
- removed work email constraint as the partner is now created without the need of work email closes #218279 X-original-commit: b346885 Signed-off-by: Olivier Colson (oco) <[email protected]> Signed-off-by: Meet Bariya (meba) <[email protected]>
Before this commit: `pre` was not considered paragraph related element. Also it allowed flow content. After this commit: `pre` is considered paragraph related element and now it only allows phrasing content also anything pasted within `pre` is now pasted as plain text and list numbering and markers are preserved. task-4766648 closes #218211 X-original-commit: 216e9eb Signed-off-by: David Monjoie (dmo) <[email protected]>
In this commit, we change the login page step by a step with isActive property. So this step is only active when the input#login is not on the page and then expectUnloadPage will be only listen when this step is active. closes #218057 X-original-commit: 028832f Signed-off-by: Mathieu Duckerts-Antoine (dam) <[email protected]> Signed-off-by: Aaron Bohy (aab) <[email protected]>
The script failed to find the corresponding rows in the data files, leading to some translations being lost when migrating them to the new syntax. opw-4659964 closes #208454 Related: odoo/enterprise#84682 Signed-off-by: William André (wan) <[email protected]>
The fix at [1] did not fix the issue. This is another attempt. runbot-227759 [1]: 9a3c9ec closes #218227 X-original-commit: e0078d6 Signed-off-by: David Monjoie (dmo) <[email protected]>
We have recently introduced several new versions of the delivery connectors, based on the newer REST APIs introduced by the shipping companies (USPS, FedEx, UPS, DHL). However, in the settings we still link with installation checkboxes to the old modules. To avoid confusion for the user, we remove these checkboxes and refer the user to the Apps menu instead for manual installation of the preferred shipping connector. In the apps menu, we clarify that these new modules are only compatible with the new REST APIs, and we also hide the legacy modules by default by making them application: False. X-original-commit: 0832d9ee3cb821254b4ce30eedc05e32adc96332 [FIX] delivery_*_rest: update settings for delivery connectors We have recently introduced several new versions of the delivery connectors, based on the newer REST APIs introduced by the shipping companies (USPS, FedEx, UPS, DHL). However, in the settings we still link with installation checkboxes to the old modules. To avoid confusion for the user, we remove these checkboxes and refer the user to the Apps menu instead for manual installation of the preferred shipping connector. In the apps menu, we clarify that these new modules are only compatible with the new REST APIs, and we also hide the legacy modules by default by making them application: False. closes #218040 X-original-commit: 54c7cd0 Related: odoo/enterprise#89810 Signed-off-by: Arnold Moyaux (arm) <[email protected]> Signed-off-by: Claeys Pieter (clpi) <[email protected]>
Currently, with an MTSO rule, the smart button from the Sale Order
to the Manufacturing Order was available. However, the reverse link
(from the MO to the SO) was missing.
But they share the same link between object and people don't
understand. So we copy the condition to have the same SO<->MO
link.
It was missing the sale_id on the procurement group itself. Before
production.procurement_group_id.move_dest_ids.group_id.sale_id
was enough since mtso share move links but with the new MTSO it's
not the case anymore. But the sale_id is copied from a procurement
to the new ones.
Steps to reproduce:
- Enable multi-step routes in Inventory settings
- Unarchive the MTO route:
- Select the rule with the production usage
- Set its supply method to "MTSO"
- Create a storable product “P1”:
- routes: MTO + Manufacture
- Create and confirm a Sale Order with one unit of P1
- Confirm the SO
Problem:
The smart button from the SO to the MO appears correctly,
but the reverse link from the MO to the SO is missing.
opw-4619136
opw-4557138
opw-4875937
opw-4854581
opw-4887746
closes #217808
X-original-commit: 77159d4
Signed-off-by: Steve Van Essche <[email protected]>
Signed-off-by: Djamel Touati (otd) <[email protected]>
Issue --> The final step of the `_action_merge` method updates the `code` field of the account onto which the other accounts are merged. During the write call on `code`, a dependent field `always_tax_exigible` on `account.move` gets added to the compute chain. This causes a fetch of all `account.move` records related to journal items related to the account that is getting updated. This can lead to a MemoryError on databases with large `account.move` tables. Solution --> We delegate the write of the `code` field to SQL. In the account merge wizard, accounts that can be grouped are grouped by the keys --> `'account_type', 'non_trade', 'currency_id', 'reconcile', 'deprecated','name'`. Therefore, the `account_type` does not change after the merge. We can safely assume that any fields dependent on `account_type` do not need recomputation and hence, bypass the ORM for this update. Additional change --> Disable the prefetcher in the write call in `account.account` to optimize memory usage on databases with a large number of journal items/journal entries when writing on `code` or `account_type` in general. opw-4839985 closes #217804 X-original-commit: 8c5bfff Signed-off-by: Thomas Becquevort (thbe) <[email protected]>
Versions -------- - saas-18.2+ Steps ----- 1. Set up a company & website with Peruvian l10n; 2. add an identification type of "DNI" to your partner data; 3. set the identification number to "09123456"; 5. go to /shop; 6. add product to cart and go to checkout; 7. try to add a new billing address. Issue ----- Cannot save the address, as it thinks you selected the RUC identification type, which is not allowed. Cause ----- When a partner already has an identification type & number, they're not allowed to add new ones to alternate addresses. Issue is that the read-only field added via 5a93da8 is not an actual form field, and doesn't provide its value on submit. Solution -------- Add a hidden `input` element with `l10n_latam_identification_type_id`, after the read-only `t-else` element with a seperate `t-if` to prevent breaking xpaths in stable. opw-4817712 closes #216692 Signed-off-by: Josse Colpaert (jco) <[email protected]>
Before this commit: - Duplicate IRNs were not deeply verified if the response already contained a `SignedInvoice`. - Mismatches between government-returned IRNs and the system’s invoice data were not clearly logged or validated. After this commit: - If the `jwt` library is available and the response includes a `SignedInvoice`, the decoded content is compared against the invoice’s `Gstin` and `TotInvVal`. - A mismatch triggers a user-friendly error message about the duplicate IRN with non-matching data. - Decode errors are logged as warnings to aid in debugging. - A fallback message is shown when the `jwt` library is not installed, indicating that verification could not be performed. This ensures more robust validation of duplicate IRNs and improves user feedback in case of discrepancies or missing dependencies. closes #213909 Signed-off-by: Josse Colpaert (jco) <[email protected]>
Before this commit, test "Add the same reaction twice from the emoji picker" may fail non-deterministically in 18.1 on last step: the message reaction is sometimes kept, sometimes removed. The feature in 18.0 was keeping the emoji, whereas in 18.1 it now toggles the add / remove of reaction. This change of behaviour felt best with the addition of QuickReactionMenu, and for consistency this also works that way in emoji picker of message reaction. The test was not adapted but passed because the bus notifications were coming later than the burst of user actions to add emoji, thus there's flicker of showing message reaction at end when it's only temporarily and would be removed a fraction of seconds later. This commit fixes the test with the newer behaviour that it should toggle the reaction. Fixes runbot error 229340 closes #218199 X-original-commit: be3c561 Signed-off-by: Matthieu Stockbauer (tsm) <[email protected]> Signed-off-by: Alexandre Kühn (aku) <[email protected]>
Versions -------- - 16.0+ Steps ----- 1. Have a fiscal position with a country-based tax mapping; 2. go to `/shop` as a public user, 3. create a new account; 4. add a product to your cart; 5. go to user settings & add an address that matches the fiscal position; 6. go to checkout & pay for the cart. Issue ----- The fiscal position's taxes aren't applied to the order. Cause ----- The `_compute_fiscal_position_id` method is triggered when changing the `partner_id` or `partner_shipping_id` of an order. It does not trigger when modifying the address of the order's current partner. There is logic in place to recompute fiscal position & taxes when an address gets entered via checkout, but not via any other route. Solution -------- Adding address fields to the `api.depends` of the compute method could introduce the unintended behavior of changing taxes & fiscal position of confirmed sale orders. Instead, we can check for fields relevant to fiscal position in `write`, then search for unconfirmed website orders, and recompute their fiscal position & taxes if need be. opw-4844132 closes #218455 X-original-commit: 64a42f2 Signed-off-by: Levi Siuzdak <[email protected]>
Fix issue where minimum rights employee were able to put negative orderline qty in the cart with the `+/-` button closes #218201 Task-id: 4922318 X-original-commit: 037d103 Related: odoo/enterprise#89897 Signed-off-by: Stéphane Vanmeerhaeghe (stva) <[email protected]> Signed-off-by: Manu Vaillant (manv) <[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