Syncing from upstream odoo/odoo (saas-18.2) #34221
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
Before this commit, the Point of Sale system failed to load archived products when retrieving missing products for loaded records. This caused various issues, for instance, when loading paid orders, any archived products included in those orders would not be loaded, leading to data inconsistencies and operational problems. opw-4904124 closes #217541 Signed-off-by: Adrien Guilliams (adgu) <[email protected]>
…rch panel Before this commit: - Long dashboard names were truncated in the search panel. - There was no way for the user to see the full name. After this commit: - A tooltip has been added to display the full dashboard name on hover. closes #218038 Task: 4903713 X-original-commit: b5c291a Signed-off-by: Pierre Rousseau (pro) <[email protected]> Signed-off-by: Ronakkumar Mukeshbhai Bharadiya (rmbh) <[email protected]>
Before this commit, when user presence changes, it was updating the write_date of user. This happens because any change of presence what doing a `Command.create()` on the presence_id field of user model. The presence object is automatically unlinked after 12 hours of inactivity, thus most users had their write_date every day because of the presence_ids being updated when logging in at least once a day. This commit fixes the issue by creating the presence rather than write on the user field, so that this is not considered a write on user object and thus it doesn't change the write_date of user. Other than not updating the write_date, the code behavior is functionally unchanged. closes #218182 Signed-off-by: Sébastien Theys (seb) <[email protected]>
Before this commit, the `website_livechat_chatbot_flow_tour` tour was sometimes failing. The intent it to ensure the chat bot stops until the user fully wrote his answer. The flow is the following: - User sends a message (first part of his answer) - User starts typing: the chat bot waits - After some time, the user didn't finish his answer afterall, the chat bot continues. The chat bot uses the `_processAnswerDebounced` function to delay the processing of the step. However, the tour relies on `setTimeout`, expecting to come after the debounce delay. However, multiple messages are sent, and the debounce delay is postponed. As a result, the assertion is made too early, making the test fail. This commit fixes the issue by awaiting a deferred, resolved when the chat bot actually executes the debounced function. fixes runbot-113948,227675 closes #218200 X-original-commit: 0d5b943 Signed-off-by: Alexandre Kühn (aku) <[email protected]>
…sons Steps to reproduce: - In the settings enable by-products - Create a product FP with a bill of material: - 1 operation: op 1 - 1 By-product line: cost share 3.3%, produced in op 1 - Create aand confirm an MO for 1 unit of FP - On the by product line produce 10 instead of 1 - Produce All > 19 units of by products were produced: The initial by-product move > was validated for 10 units and an extra move with a quantity of 9 > was automatically created and validated aswell. Cause of the issue: Since the quantity of the by-product move exceed its initial demand, its validation will create an extra move that is expected to be merge into the main move during its confirmation: https://github.com/odoo/odoo/blob/474ac02d03c17af0274422ecb1e97ca14a3e80e7/addons/stock/models/stock_move.py#L1922 https://github.com/odoo/odoo/blob/474ac02d03c17af0274422ecb1e97ca14a3e80e7/addons/stock/models/stock_move.py#L1844-L1865 However, while `cost_share` value of the original move floats is correctly encoded as 3.3, the copied value of the extra is 3.3000000000000003. This discrepency is a well known issue of the way the orm handles float and convert them to cache as it calls the `float_round` method, which can effectively change its value: https://github.com/odoo/odoo/blob/8c22e358840f02c5b1596e1fbe0d6cf7315754f7/odoo/fields.py#L1553-L1557 In particular, the `cost_share` of both moves differs in terms of strict equality and the move will not be merged with its extra move. Note: The issue should not be reproducible in saas17.4+ because the float_round issues have been erased by commit 784f151 opw-4846289 closes #217806 X-original-commit: 9f8c364 Signed-off-by: Quentin Wolfs (quwo) <[email protected]> Signed-off-by: Lancelot Semal (lase) <[email protected]>
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