Syncing from upstream odoo/odoo (tmp.saas-18.3) #34231
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
…move to sale_order Step to reproduce: - Enable Analytic accounting in Accounting settings - Create a sale order - Show Analytic Distribution - Create an expense and put this sale order in the "Customer to Reinvoice" field. - Add an Analytic Distribution - Create Report - Submit to Manager - Approve - Post Journal Entries Curent behavior: - No analytic_distribution on the sale_order Expected behavior: - analytic_distribution form the expense should be copied to the sale_order Cause: analytic_distribution wasn't set at the creation of the sale order from the account_move closes #218263 X-original-commit: fbc4cd6 Signed-off-by: Xavier Bol (xbo) <[email protected]> Signed-off-by: Corentin Lombard (clom) <[email protected]>
This commit c5a98c7 removed custom `z-index` utilities. Replaces `z-index-1` with Bootstrap's default `z-1` class. Before this commit: - The icon used `z-index-1`, which is not a valid Bootstrap class. After this commit: - Replaced with `z-1`, the correct Bootstrap 5 utility class for `z-index: 1`. task-4903381 closes #218224 X-original-commit: ca44ff7 Signed-off-by: David Monjoie (dmo) <[email protected]>
Before this commit, tour "test_mail_composer_autosave_tour" could fail at end with the following error: ``` Tour finished with a dirty form view being open. Dirty form views are automatically saved when the page is closed, which leads to stray network requests and inconsistencies. ``` This happens because test creates a new record and posts a message in full composer. It checks that message is present in chatter and then leave the form view. When posting the message, the form view is saved, but this can happen with a small delay after message is visible on chatter like after tour has ended. This commit fixes the issue by awaiting form view is saved, so that tour doesn't panic at end there's a form view with unsaved changes, as the form view is properly saved with sending a message. Fixes runbot error 198583 Fixes runbot error 222676 closes #218241 X-original-commit: 75ef862 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 #218222 X-original-commit: 0d5b943 Signed-off-by: Alexandre Kühn (aku) <[email protected]> Signed-off-by: Matthieu Stockbauer (tsm) <[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 #218281 Task: 4922634 X-original-commit: e27dc36 Signed-off-by: Yaroslav Soroko (yaso) <[email protected]> Signed-off-by: Louis Travaux (lotr) <[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 #218198 X-original-commit: 69b2d6c Signed-off-by: Ricardo Gomes Rodrigues (rigr) <[email protected]> Signed-off-by: Bhavya Ashesh Nanavati (bhna) <[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 #218288 X-original-commit: 2029920 Signed-off-by: David Monjoie (dmo) <[email protected]> Signed-off-by: Adnan Chaudhary (adch) <[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 #218257 X-original-commit: ffd9c0f Signed-off-by: Pierre Paridans (app) <[email protected]> Signed-off-by: Antoine Sougné (anso) <[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 #218270 X-original-commit: 47c468d Signed-off-by: Sébastien Theys (seb) <[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 #218242 X-original-commit: bdfb81e Signed-off-by: Alexandre Kühn (aku) <[email protected]>
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 #218269 X-original-commit: 4455e2e Signed-off-by: Adrien Guilliams (adgu) <[email protected]> Signed-off-by: Pedram Bi Ria (pebr) <[email protected]>
Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the All MO tab > The operation was removed from the Assembly line - Click on "close production" > Nothing happends while the MO should be marked as done and disappear Cause of the issue: The issue has been introduced by commit [1]. To be more precise, clicking on the "Close production" button will launch a call of the `validate`. In case of `mrp.production` records, this call will first launch a call of the `pre_button_mark_done` and then (prior to the change) add the record to the validation Stack for real Validation: odoo/enterprise@10ed122#diff-7695d0af56f8efc3200fc5a693b797de9314165f4754bb2054d25809381c0ccdL504 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L530 Prior to commit [1], in our use case, the `pre_button_mark_done` would simply return `True` as no action need to be proceed prior to the `button_mark_done` and the porduction would be added and closed by the real validation. However, since commit [1], the record is simply set to the validated state and not added to the validation stack... That satement is simply incorrect: https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L503-L505 In the most general usecase, our mrp record is in `to_close` state and is not expected to be validated by the `pre_button_mark_done` even if this call returns `True``. What is true however, is that in the exceptional use case treated in [1] where you are in the `always` backorder setting and where you need to create a backorder, the MO will be entirely processed by the `pre_button_mark_done`: https://github.com/odoo/odoo/blob/6542b0a5a58324f532a4ae1e0c630ca4fe2f77d7/addons/mrp/models/mrp_production.py#L2142-L2145 and hence should not be marked as done once more (otherwise it would raise multiple errors such as sn uniqueness,... (as the mo has already been validated)). Fix: The double validation did not happen prior ot the change of [1] because we did not skip redirection at the time: odoo/enterprise@154eec9 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L497-L502 returning the record before even adding it to the real validation stack. However, since we do not want to be redirected to the back end we propose to return the information that the record has been validated by the `pre_button_mark_done` and avoid the call of the real validation using the mechanism already in place: https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L524 Commit [1]: 10ed12241365942914885dff953049303b9ed94f opw-4800147 closes #215848 X-original-commit: 0639f19 Related: odoo/enterprise#88525 Signed-off-by: William Henrotin (whe) <[email protected]>
- Create an invoice with price 1000 in a non-company currency (e.g., CHF). - Modify the currency rate after the invoice date, then generate the payment for this invoice. - This will generate three journal entries (invoice, payment, and currency exchange difference). - Export those journal entries and include in the export the `matching_number`, `currency`, and `amount_currency` fields. - Import those three entries with the matching number and post them. - In the Journal Items, the line corresponding to the currency exchange difference is not matched with the lines from the invoice and the payment, leading to an unbalanced credit and debit. In `_prepare_reconciliation_single_partial` within `account_move_line`, the reconciliation is stopped by checking whether the debit/credit is fully matched. However, this check only considers `amount_residual_currency` and not `amount_residual`, which, in the case of an exchange difference, are different. opw-4776188 closes #218112 X-original-commit: acc602f Signed-off-by: Thomas Becquevort (thbe) <[email protected]> Signed-off-by: Guillaume Teboul-Tornezy (gute) <[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 #218282 X-original-commit: 028832f Signed-off-by: Mathieu Duckerts-Antoine (dam) <[email protected]> Signed-off-by: Aaron Bohy (aab) <[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 #218308 X-original-commit: 8c5bfff Signed-off-by: Thomas Becquevort (thbe) <[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 #217947
X-original-commit: 77159d4
Signed-off-by: Steve Van Essche <[email protected]>
Signed-off-by: Djamel Touati (otd) <[email protected]>
Steps to reproduce: 1) Configure a product and allow selling when out of stock 2) Publish any delivery method 3) Publish the Pickup in-store delivery method 4) Check the product page of the created product Problem: It is shown that the product is not available for delivery even though we allow selling it when out of stock This commit shows that a product is available for delivery (not for in_store one) if allow selling when out of stock is enabled. opw-4792024 closes #218298 Signed-off-by: Valeriya Chuprina (vchu) <[email protected]>
Multi-edit was disabled from the WO list view by mistake in commit: 5767cf0 Therefore, it has been re-enabled. closes #216143 Task: 4900236 Signed-off-by: Tiffany Chang (tic) <[email protected]>
The fix at [1] did not fix the issue. This is another attempt. runbot-227759 [1]: 9a3c9ec closes #218361 X-original-commit: e0078d6 Signed-off-by: David Monjoie (dmo) <[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 #218324 X-original-commit: be3c561 Signed-off-by: Matthieu Stockbauer (tsm) <[email protected]> Signed-off-by: Alexandre Kühn (aku) <[email protected]>
Archive previously sold products to make sure they do not make the test fail when demo data are installed. runbot build error 163667 closes #218423 Signed-off-by: Victor Feyens (vfe) <[email protected]>
…tInvoicingCommon closes #217999 X-original-commit: 0ca692f Related: odoo/enterprise#89788 Signed-off-by: Claire Bretton (clbr) <[email protected]> Signed-off-by: Laurent Smet (las) <[email protected]>
Versions -------- - saas-18.3+ Steps ----- 1. Have a partnership product; 2. publish it on eCommerce; 3. as Portal or Public user, open /shop; 4. if visible, buy it & go back to /shop. Issue ----- Product is not available on /shop (anymore). Cause ----- Partnership tracking on service products isn't made saleable. Solution -------- Add `partnership` to `_get_saleable_tracking_types`. opw-4926679 closes #217863 Signed-off-by: Vallaeys Valentin (vava) <[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