Thursday, February 6, 2025
67 changes · saas-18.1
Enhancements to existing features
The point of sale payment screen now aligns remaining amounts, change, and payment line totals more consistently. This makes the screen easier for cashiers to read and helps reduce confusion during checkout.
Original PR description
In this commit: ========== - Improved the alignment of the remaining amount, change amount, and payment line amount. - Ensured all amounts were consistently aligned on the same line for better readability. task-4517934
Resolved issues and error corrections
Guest users in public chat channels no longer see contacts they cannot access when using the command palette. This prevents confusing access error messages and creates a smoother guest experience.
Original PR description
**Current behavior before PR:** when we are in public channel by guest and hit ctrl+k then click on partners which are not accessible by guest it shows access error. **Desired behavior after PR is merged:** now we are not displaying partners which removes the access error. task-4518228 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
The Partner Autocomplete service was unreliable when used on a database hosted under a subdomain of odoo.com (i.e. from *.odoo.com). This was caused by a combination of the CORS policy of the Autocomplete API of Clearbit and the caching of the browser. If the user performed a first request with search query "Odoo" from https://a.odoo.com, the browser would cache the results, including the `Access-Control-Allow-Origin` header set to `https://a.odoo.com`. The same request performed from h
Original PR description
The Partner Autocomplete service was unreliable when used on a database hosted under a subdomain of odoo.com (i.e. from *.odoo.com). This was caused by a combination of the CORS policy of the Autocomplete API of Clearbit and the caching of the browser. If the user performed a first request with search query "Odoo" from https://a.odoo.com, the browser would cache the results, including the `Access-Control-Allow-Origin` header set to `https://a.odoo.com`. The same request performed from https://b.odoo.com would lead to a CORS policy error as the browser would use the cached response from earlier request. This commit addresses the issue by disabling the caching of the requests made to the Clearbit Autocomplete API. Forward-Port-Of: odoo/odoo#196480
Chat action menus and notification settings now stay within the visible screen more reliably. This prevents popovers from being cut off, making chat and channel settings easier to use for users on different screen sizes.
Original PR description
Purpose of this Commit: This commit resolves the issue of the action menu popover and the notification settings popover overflowing off the screen. Previously, before this PR, the popovers could flip to all four directions, but now they are restricted to only two directions. However, in some cases, the correct position is not among these two directions. This commit addresses and fixes this behavior. task-4454161
Uploading documents in a new quotation template is now blocked until the template has been saved. This prevents an error from appearing when users try to use the Quote Builder before the template exists in the system.
Original PR description
When attempting to upload a file in the ``Quotation Templates`` without saving the template first, an error occurs in the terminal. Steps to reproduce: --- - Install the ``sale_management`` module - Sales > Configuration > Sales Order > Quotation Templates - Create New > Add a name(Don't save)> Quote Builder > Click on Upload - Try to upload a file Traceback: --- ``ValueError: invalid literal for int() with base 10: 'false'`` Previous Behaviour: --- When entering the name of ``Quotation Templates`` (Don't Save), the Notebook page of ``Quote Builder`` appears, and an error occurs upon uploading the document. Solution: --- Initially, we were checking for invisibility based on the name. However, we now display the view when an ID is retrieved, ensuring the page remains hidden until it is saved. sentry-5963406254 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Preparation tickets in Point of Sale now display the configuration or location name at the intended text size. This makes kitchen or preparation tickets easier to read and keeps printed receipts visually consistent.
Original PR description
This commit ensures that the config name is printed with the correct size on the preparation ticket.
The emoji picker now recognizes “+1” as a way to find the thumbs-up emoji. This makes reactions easier to enter for users who rely on common text shortcuts.
Original PR description
task-4552346
This fix prevents an accounting process from failing when it encounters an empty or null value while reading stored data. It improves reliability by allowing the process to continue instead of raising an error for affected records.
Original PR description
literal_eval cannot evaluate null values, it will give a `malformed node error` if one is passed. `ValueError: malformed node or string: False` 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
Opening the Overview page for a Manufacturing Order no longer fails because of mismatched date formats. This prevents an error screen and lets users review production planning information reliably.
Original PR description
Currently a `TypeError` appears when the user opens 'Overview' of an 'Manufacturing Order'. ### Error: ```TypeError: can't compare datetime.datetime to datetime.date``` The error occurs because when 'Overview' is opened of an MO, a comparison is made between `Datetime & Date`,i.e `mo_planned_start` and `receipt['date'],` which raises the above error. This commit resolves the issue by keeping date format same of both the fields. sentry-6250719075
This fix restores the default setup data for timesheet rounding and minimum duration settings. It helps ensure timesheet behavior is configured correctly after a previous refactoring accidentally left this data out.
Original PR description
During odoo/enterprise@ca5a67c4faaf refactoring, the data file with default ICP for timesheet rounding/min duration was renamed but got removed from the manifest. This commit re-add it into the manifest.
This fixes an error that occurred when users copied and pasted a field in a Sign template. The change restores the expected editing flow so users can continue preparing documents without interruption.
Original PR description
**Steps to Reproduce:** 1. Open a sign template. 2. Open a PDF. 3. Copy and paste a sign item. **Issue:** An error occurs when pasting a sign item. **Cause:** The saveChanges function was replaced with setTemplateChanged to manage the template's state, but the old function was still being referenced. **Solution:** Replace saveChanges with setTemplateChanged to ensure proper state management. task-4531219
This update ensures the Timesheet Grid setup includes the configuration needed for 15-minute time rounding when a timer is stopped early. It helps keep automated checks reliable and reduces the risk of timer-related behavior being missed during releases.
Original PR description
The test tour mainly fails due to the file containing ir parameter to add 15 min step time in case of premature time stop not being in the manifest. task-4555814
**Steps to reproduce:** - Install Accounting - Create a tax with the following configuration: * Tax Type: Purchases (also reproducible with Sales) * Included in Price: [any] * Affect Base of Subsequent Taxes (include_base_amount): [checked] * Base Affected by Previous Taxes (is_base_affected): [checked] * Distribution: | % | Based On | Account | Tax Grids | | ------ | ------------- | ------------ | -------------- | | | Base | | +Tag
Original PR description
**Steps to reproduce:** - Install Accounting - Create a tax with the following configuration: * Tax Type: Purchases (also reproducible with Sales) * Included in Price: [any] * Affect Base of…
**Steps to reproduce:**
- Install Accounting
- Create a tax with the following configuration:
* Tax Type: Purchases (also reproducible with Sales)
* Included in Price: [any]
* Affect Base of Subsequent Taxes (include_base_amount): [checked]
* Base Affected by Previous Taxes (is_base_affected): [checked]
* Distribution:
| % | Based On | Account | Tax Grids |
| ------ | ------------- | ------------ | -------------- |
| | Base | | +Tag_1 +Tag_2 |
| 100.00 | of tax | Account X | +Tag_3 |
| -100.00 | of tax | Account Y | -Tag_4 |
(Or FR localization and "20% EU G" purchase tax can be used)
- Create a bill
- Add a line with the created tax
- Check journal items
**Issue:**
The tax tags of the base line are also added to first tax line.
**Cause:**
When a tax is "include_base_amount", the tags of its base line is propagated to the tax lines of the following taxes. However in this case, as there are several tax lines for the same tax, the system propagate the tags to the second one as if it was coming from another tax.
**Solution:**
Check if the tags are coming from another tax before adding them.
opw-4510882
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#195837- Create a sale order and confirm it - Create two partial down payments for that sale order and confirm them - Create a invoice for the remaining amount and confirm it - Send and print the invoice (with Send to Tax Agency selected) - Traceback <a/> File "addons/account/models/account_tax.py", line 2475, in _dispatch_negative_lines line.setdefault('discount_amount', line['discount_amount_before_dispatching']) KeyError: 'discount_amount_before_dispatching' bbe04fb
Original PR description
- Create a sale order and confirm it
- Create two partial down payments for that sale order and confirm them
- Create a invoice for the remaining amount and confirm it
- Send and print the invoice (with Send to Tax Agency selected)
- Traceback
<a/>
File "addons/account/models/account_tax.py", line 2475, in _dispatch_negative_lines
line.setdefault('discount_amount', line['discount_amount_before_dispatching'])
KeyError: 'discount_amount_before_dispatching'
bbe04fb62916ae326c830e89b2664dfd32b62b75 removes elements from base_list while looping over it.
In `17.0` this doesn't cause this error because we have two loops; one that sets 'discount_amount_before_dispatching' and after that one that remove downpayment from base_lines. But the fix should still be backported because it works by chance.
Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4496310)
opw-4496310
Forward-Port-Of: odoo/odoo#194949Purpose: -------- Currently, when posting a scheduled message failed due to an error, the cron interrupts and will attempt to resend the message on each of its subsequent runs and fail again, preventing any scheduled message to be posted. This commit changes the cron behavior to catch any exceptions raised during message posting, notify the author of the message about the failure, and delete the failed scheduled message. This prevents infinite retry attempts. The notification to the
Original PR description
Purpose: -------- Currently, when posting a scheduled message failed due to an error, the cron interrupts and will attempt to resend the message on each of its subsequent runs and fail again, preventing any scheduled message to be posted. This commit changes the cron behavior to catch any exceptions raised during message posting, notify the author of the message about the failure, and delete the failed scheduled message. This prevents infinite retry attempts. The notification to the author of the scheduled message contains the content of the scheduled message. The rationale is that the posting might fail because the user does not have access to the record it will be posted on anymore, and won't be able to see the scheduled message again. The scheduled messages will now be unlinked when unlinking the record on which they are scheduled. Task-4531402 Forward-Port-Of: odoo/odoo#195964
This commit fixes a few issues in multi-company context: - only show the GSTIN status/update button when user has at least one IN companies selected - only allow the update when user's active company is an IN company (to ensure we correctly determine the EDI test/production status) opw-4367302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194978
Original PR description
This commit fixes a few issues in multi-company context: - only show the GSTIN status/update button when user has at least one IN companies selected - only allow the update when user's active company is an IN company (to ensure we correctly determine the EDI test/production status) opw-4367302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194978
Current behavior: The previous closing amount is used instead of the cash opening when printing the session report so the expected cash amount is wrong. Steps to reproduce: Open a PoS session with 100€ in the cash register and close it. Reopen the session and enter 50€ in the cash register. Make a sale for 10€, using cash payment. Close the session and print the session report. The expected cash amount will be 110€ when it should be 60€. Fixes opw-4497263 Forward-Port-Of: odoo/odoo#
Original PR description
Current behavior: The previous closing amount is used instead of the cash opening when printing the session report so the expected cash amount is wrong. Steps to reproduce: Open a PoS session with 100€ in the cash register and close it. Reopen the session and enter 50€ in the cash register. Make a sale for 10€, using cash payment. Close the session and print the session report. The expected cash amount will be 110€ when it should be 60€. Fixes opw-4497263 Forward-Port-Of: odoo/odoo#196395
**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today, receiving the product, then dating the vendor bill to some future date with a different exchange rate will result in exchange difference journal entries when the bill is posted. **Expected behavior:** We shouldn't see exchange difference entries, as there are pending corrective valuation entr
Original PR description
**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today,…
**Current behavior:** With Anglo-Saxon accounting, for some tracked product, with FIFO and real-time valuation: Making a purchase order in some foreign currency, having some exchange rate for today, receiving the product, then dating the vendor bill to some future date with a different exchange rate will result in exchange difference journal entries when the bill is posted. **Expected behavior:** We shouldn't see exchange difference entries, as there are pending corrective valuation entries which have simply not been posted yet. Reconciliation should be deferred until these moves are no longer in draft. **Steps to reproduce:** 1. Activate another currency, define some rate for today and another (different) rate for tomorrow 2. Create a product with FIFO and real-time costing & valuation 3. Create an initial purchase for the product, receive then bill normally 4. Create another purchase order and receive the product 5. Create the invoice, set the invoie date for tomorrow 6. Post the invoice -> Open the `Exchange Difference` journal to see the entries which should not have been generated **Cause of the issue:** After creating the AMLs which represent the difference in reception/bill unit price of the product, they are caught here: https://github.com/odoo/odoo/blob/971400771a31c05641a8672f6b1d85afaa9c4a19/addons/account/models/account_move.py#L3575 and designated as future moves, not to be posted at this time. At the end of the `_post()` stack: https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L229 where there would normally be some `correction_amls`, they weren't created here because the AMLs for the price diff were not posted- so the price diff entry is generated. **Fix:** Wait for pending (`state == 'draft'`) AMLs that are part of some `AccountMove`'s valuation to be no longer in draft before allowing reconciliation with a currency exchange difference. opw-4266652 Forward-Port-Of: odoo/odoo#196140 Forward-Port-Of: odoo/odoo#193971
This commit adds python 3.13 opcodes that would be necessary to use safe_eval and qweb Forward-Port-Of: odoo/odoo#196645
Original PR description
This commit adds python 3.13 opcodes that would be necessary to use safe_eval and qweb Forward-Port-Of: odoo/odoo#196645
Steps to reproduce: ------------------- - In a Spanish company, make sure l10n_es_edi_tbai is installed. - Create an invoice with one product and add 2 taxes for that line (for example, the 21% goods and the 5.2 ES tax). - Confirm and send the invoice with TBAI. - In the TBAI xml you will find the total amount wrong as the base amount was calculated twice, one time for each tax. Cause: ----- Since (#180062), the tax details calculation process was reworked. the total amount is calcula
Original PR description
Steps to reproduce: ------------------- - In a Spanish company, make sure l10n_es_edi_tbai is installed. - Create an invoice with one product and add 2 taxes for that line (for example, the 21% goods…
Steps to reproduce: ------------------- - In a Spanish company, make sure l10n_es_edi_tbai is installed. - Create an invoice with one product and add 2 taxes for that line (for example, the 21% goods and the 5.2 ES tax). - Confirm and send the invoice with TBAI. - In the TBAI xml you will find the total amount wrong as the base amount was calculated twice, one time for each tax. Cause: ----- Since (#180062), the tax details calculation process was reworked. the total amount is calculated inside a loop with this formula ``` for values in values_per_grouping_key.values(): total_amount += values['base_amount'] + values['tax_amount'] ``` In case one invoice line has 2 taxes of different tax groups, this code will add the base_amount twice in the total_amount calculation. Fix --- Move the base amount addition in a separate loop with a new aggregation (with no grouping) to add the base amount to the total. opw-4501051 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195561
This commit removes the module_sms field from the settings view. When it was present unchecking it could potentially remove all the apps installed on a DB. Depending on what was installed. The main issue was that user misinterpreted the use of this checkbox leading to situation where the DB needed to be restarted from a backup. To fix this issue it was decided for now to remove the checkbox from the settings view. This will prevent these situations to happen again in the future. task-45261
Original PR description
This commit removes the module_sms field from the settings view. When it was present unchecking it could potentially remove all the apps installed on a DB. Depending on what was installed. The main issue was that user misinterpreted the use of this checkbox leading to situation where the DB needed to be restarted from a backup. To fix this issue it was decided for now to remove the checkbox from the settings view. This will prevent these situations to happen again in the future. task-4526115 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196449
Before this commit: 1. Install `ressource` module 2. In debug, open "Run unit tests" debug menu 3. Error pop-up: ```js Global Error: stack trace available in the console Missing dependencies: @mail/../tests/mail_test_helpers ``` After this commit: No error and units tests can proceed Related runbot task: https://runbot.odoo.com/odoo/runbot.build.error/72187 Forward-Port-Of: odoo/odoo#196488 Forward-Port-Of: odoo/odoo#195824
Original PR description
Before this commit: 1. Install `ressource` module 2. In debug, open "Run unit tests" debug menu 3. Error pop-up: ```js Global Error: stack trace available in the console Missing dependencies: @mail/../tests/mail_test_helpers ``` After this commit: No error and units tests can proceed Related runbot task: https://runbot.odoo.com/odoo/runbot.build.error/72187 Forward-Port-Of: odoo/odoo#196488 Forward-Port-Of: odoo/odoo#195824
In the current implementation, updating translations for a `blog.post` via the route `/web/dataset/call_kw/blog.post/web_update_field_translations` fails to apply changes when the post has already been translated once. This issue is caused by how the system fetches `website.default_lang_id` from the request. __Current behavior before commit:__ When editing a previously translated field for `blog.post` or `product.template`, the system retrieves the website from the request to determin
Original PR description
In the current implementation, updating translations for a `blog.post` via the route `/web/dataset/call_kw/blog.post/web_update_field_translations` fails to apply changes when the post has already…
In the current implementation, updating translations for a `blog.post` via the route `/web/dataset/call_kw/blog.post/web_update_field_translations` fails to apply changes when the post has already been translated once. This issue is caused by how the system fetches `website.default_lang_id` from the request. __Current behavior before commit:__ When editing a previously translated field for `blog.post` or `product.template`, the system retrieves the website from the request to determine the `source_lang`. This is used to search for the original term in the source language and update its translation. However, due to the `website=True` parameter not being set for the controller,the system defaults to English (`source_lang = 'en_US'`). As a result: 1. The system searches for the original word in English, even if it exists in another language. 2. The translation update fails because the original word cannot be found in English. __Description of the fix:__ A new controller was introduced to specifically handle translation updates, ensuring the correct language is fetched and the translation logic is applied correctly. __Steps to reproduce the issue:__ 1. Add 2 or more languages to the website. 2. Set the default language to any language other than English (US). 3. Create a blog post and write text in the default language. 4. Switch to another language, translate the text and save. 5. Edit the translated text again. The last edits are not saved. - bug introduced in: [#06346b0][1] - opw-4239512 Forward-Port-Of: odoo/odoo#195352 Forward-Port-Of: odoo/odoo#184415 [1]: https://github.com/odoo/odoo/commit/06346b049a3a13a9a8b63a4f60151ec24fabb59e
Currently, when multiple taxes type are applied to the same invoice line, the netAmount and totalAmount fields in the ETA file are incorrectly calculated. Steps to reproduce: 1. Install the module l10n_eg_edi_eta. 2. Create a new invoice with multiple tax types applied to the same product. 3. Generate the ETA JSON file. Issue: The resulting file contains incorrect values for netAmount and totalAmount because these amounts were calculated by summing the base_amount from values_per_group
Original PR description
Currently, when multiple taxes type are applied to the same invoice line, the netAmount and totalAmount fields in the ETA file are incorrectly calculated. Steps to reproduce: 1. Install the module l10n_eg_edi_eta. 2. Create a new invoice with multiple tax types applied to the same product. 3. Generate the ETA JSON file. Issue: The resulting file contains incorrect values for netAmount and totalAmount because these amounts were calculated by summing the base_amount from values_per_grouping_key. However, since grouping is done by tax type, the base_amount is duplicated (once per tax type), leading to incorrect totals. This fix ensure that base_amount is not counted multiple times. See official documentation for more details: https://sdk.invoicing.eta.gov.eg/document-validation-rules/#validation-on-level-of-invoice opw-4457780 Forward-Port-Of: odoo/odoo#195589
This error occurs when ``content-type`` is not found in the response when attaching any file with the type ``URL``. Traceback: --- ``` KeyError: 'content-type' File "odoo/http.py", line 2366, in __call__ response = request._serve_db() File "odoo/http.py", line 1894, in _serve_db return self._transactioning( File "odoo/http.py", line 1957, in _transactioning return service_model.retrying(func, env=self.env) File "odoo/service/model.py", line 137, in retrying
Original PR description
This error occurs when ``content-type`` is not found in the response when attaching any file with the type ``URL``. Traceback: --- ``` KeyError: 'content-type' File "odoo/http.py", line 2366, in…
This error occurs when ``content-type`` is not found in the response when attaching any file with the type ``URL``.
Traceback:
---
```
KeyError: 'content-type'
File "odoo/http.py", line 2366, in __call__
response = request._serve_db()
File "odoo/http.py", line 1894, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1957, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1924, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2171, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 329, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 727, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/html_editor/controllers/main.py", line 355, in add_url
attachment = self._attachment_create(url=url, res_id=res_id, res_model=res_model)
File "addons/html_editor/controllers/main.py", line 256, in _attachment_create
mime_type = response.headers['content-type']
File "requests/structures.py", line 52, in __getitem__
return self._store[key.lower()][1]
```
https://github.com/odoo/odoo/blob/2fe55ae592e5812c5ee5e39ed1e8332bde608cb2/addons/html_editor/controllers/main.py#L257
sentry-6015024235
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#192073@qrtl QT5121 Forward-Port-Of: odoo/odoo#193910
Original PR description
@qrtl QT5121 Forward-Port-Of: odoo/odoo#193910
Before this commit, refreshing the browser and creating a new order could yield a duplicate tracking number, causing confusion. This commit addresses the issue by preventing the sequence from resetting within the same session on a single device. opw-4501048 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194495
Original PR description
Before this commit, refreshing the browser and creating a new order could yield a duplicate tracking number, causing confusion. This commit addresses the issue by preventing the sequence from resetting within the same session on a single device. opw-4501048 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194495
Steps to reproduce the bug: - Create two delivery transfers. - Add them to a single batch transfer. - Assign a responsible person to the batch transfer. - The assigned responsible person will automatically be updated in all related transfers. - Now, remove the responsible person from the batch transfer. Problem: When a responsible person is assigned or modified in a batch transfer, the update is correctly reflected in all related transfers within that batch. However, if the responsible
Original PR description
Steps to reproduce the bug: - Create two delivery transfers. - Add them to a single batch transfer. - Assign a responsible person to the batch transfer. - The assigned responsible person will automatically be updated in all related transfers. - Now, remove the responsible person from the batch transfer. Problem: When a responsible person is assigned or modified in a batch transfer, the update is correctly reflected in all related transfers within that batch. However, if the responsible person is removed from the batch transfer, this change is not applied to the individual transfers linked to it. opw-4519994 Forward-Port-Of: odoo/odoo#196487 Forward-Port-Of: odoo/odoo#196333
Previously, adjusting the width of a form field within a large box resulted in excessive padding being applied above and below the form field. This commit refines the CSS rules, ensuring the padding is applied only to the outer large box and not to the inner elements. task-4370763 Forward-Port-Of: odoo/odoo#196451 Forward-Port-Of: odoo/odoo#193008
Original PR description
Previously, adjusting the width of a form field within a large box resulted in excessive padding being applied above and below the form field. This commit refines the CSS rules, ensuring the padding is applied only to the outer large box and not to the inner elements. task-4370763 Forward-Port-Of: odoo/odoo#196451 Forward-Port-Of: odoo/odoo#193008
When forcefully unreserving then reserving products coming from a same package for multiple pickings, the source package is wrongly propagated as destination package on the multiple pickings. To reproduce: - `-i sale_stock,sale_management` - Create a storable product (I) with 30 qty on hand - Create and confirm an internal transfer to put the product I in a pack (P) - Create and confirm two SO : - Sell 10 I - Sell 20 I - Check the 2 SO delivery pickings (D): - Each are r
Original PR description
When forcefully unreserving then reserving products coming from a same package for multiple pickings, the source package is wrongly propagated as destination package on the multiple pickings. To reproduce: - `-i sale_stock,sale_management` - Create a storable product (I) with 30 qty on hand - Create and confirm an internal transfer to put the product I in a pack (P) - Create and confirm two SO : - Sell 10 I - Sell 20 I - Check the 2 SO delivery pickings (D): - Each are reserved from pack P - They don't have any 'Destination Package' [Expected] - From the picking list view, by selecting the 2 pickings D : - 'Unreserve' them both - 'Check Availability' them both - Check the pickings D: - Each are reserved from pack P - Each have 'Destination Package' P [Faulty] opw-4272573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193745
Previous commit ([1]) tried to simplify with less technical names the Peppol EAS but introduced small errors. [1]: https://github.com/odoo/odoo/commit/5c7eefed412e676c6ddf67f62bce514e5bade44c task-no Forward-Port-Of: odoo/odoo#196624
Original PR description
Previous commit ([1]) tried to simplify with less technical names the Peppol EAS but introduced small errors. [1]: https://github.com/odoo/odoo/commit/5c7eefed412e676c6ddf67f62bce514e5bade44c task-no Forward-Port-Of: odoo/odoo#196624
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Configuration / Accounting / Journals" - Open "Bank" Journal - Go to "Outgoing Payments" tab - Set a check layout - For "Checks" line, set "101401 Bank" (i.e. an account that doesn't allow reconciliation) as outstanding payments account - Create a vendor bill and confirm it - Pay the bill with "Checks" as payment method => The bill is directly marked as "PAID" and not "IN PAYMENT" because the "Bank" account doesn't allow
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Configuration / Accounting / Journals" - Open "Bank" Journal - Go to "Outgoing Payments" tab - Set a check layout - For "Checks"…
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Configuration / Accounting / Journals" - Open "Bank" Journal - Go to "Outgoing Payments" tab - Set a check layout - For "Checks" line, set "101401 Bank" (i.e. an account that doesn't allow reconciliation) as outstanding payments account - Create a vendor bill and confirm it - Pay the bill with "Checks" as payment method => The bill is directly marked as "PAID" and not "IN PAYMENT" because the "Bank" account doesn't allow reconciliation - Go the the check payment **Issue:** It is not possible to print it. The same configuration allows to print the check in previous versions. **Cause:** As the check payment is using an account that doesn't allow reconciliation, the payment is set in "Paid" state directly, but the printing is disabled for checks in that state. **Solution:** As it should be harmless to allow to print the check even if it is already paid, we will allow to print it to keep a consistent behavior with previous versions. Only printing the check will be allowed. Voiding or rejecting will still be impossible. opw-4498446 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195722
The slide course member tour tests use a channel called `Basics of Gardening - Test`. When the course is completed, clicking on `End course` will redirect the user to the courses home page. Since there is already a course (from demo data) called `Basics of Gardening`, the selector in the tour test actually selects this as the first match not the test course and the tour continues with the wrong course. It doesn't crash because both demo and test courses are public, so it's possible for demo a
Original PR description
The slide course member tour tests use a channel called `Basics of Gardening - Test`. When the course is completed, clicking on `End course` will redirect the user to the courses home page. Since there is already a course (from demo data) called `Basics of Gardening`, the selector in the tour test actually selects this as the first match not the test course and the tour continues with the wrong course. It doesn't crash because both demo and test courses are public, so it's possible for demo and portal users to access them anyway and add/update a comment is done on the demo course. By this commit: - Demo data is removed in the tests to ensure that there is no collision between demo data and test data. - Since there are no predefined messages in the test data (the tour flow relied on the demo data messages before), the `update` does not happen in the tour without demo data. Some extra steps are also added to check the update message . Forward-Port-Of: odoo/odoo#196445
Before this commit, when a new res.user is created after signing in with auth_ldap, there was no email on the linked res.partner, which may cause issues in modules such as helpdesk, where partner email is used to find related tickets. res.users created through the form view will trigger the onchange which sets the 'email' = 'login', which does not happen when creating a user directly through the ORM. This commit adds 'email' as a key which is returned by the method _map_ldap_attributes, wh
Original PR description
Before this commit, when a new res.user is created after signing in with auth_ldap, there was no email on the linked res.partner, which may cause issues in modules such as helpdesk, where partner email is used to find related tickets. res.users created through the form view will trigger the onchange which sets the 'email' = 'login', which does not happen when creating a user directly through the ORM. This commit adds 'email' as a key which is returned by the method _map_ldap_attributes, which is used to create new partners with the correct email associated with the res.user login. opw-4378487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193835 Forward-Port-Of: odoo/odoo#193495
Initialize the synchronization class at startup of the PoS before making any request to the server. This will ensure that the synchronization class is ready to handle the requests. Forward-Port-Of: odoo/odoo#196450
Original PR description
Initialize the synchronization class at startup of the PoS before making any request to the server. This will ensure that the synchronization class is ready to handle the requests. Forward-Port-Of: odoo/odoo#196450
Before this commit, we was using fuzzy search which was creating a score for each partner and then sorting the partners based on that score. This was causing error in search result. Now we use exact match search which will search for the exact match of the search string in the partner name, phone, mobile, email, street, city, state, country, zip, vat, and barcode. taskId: 4517586 Forward-Port-Of: odoo/odoo#195971
Original PR description
Before this commit, we was using fuzzy search which was creating a score for each partner and then sorting the partners based on that score. This was causing error in search result. Now we use exact match search which will search for the exact match of the search string in the partner name, phone, mobile, email, street, city, state, country, zip, vat, and barcode. taskId: 4517586 Forward-Port-Of: odoo/odoo#195971
Versions -------- - 17.0+ Steps ----- 1. Enable Adyen as payment provider in test mode; 2. do an eCommerce checkout; 3. select Adyen as payment option; 4. use the following card details[^1]: - card number: 4111111111111111 - expiry: 03/30 - cvc: 737 - name on card: CARD_EXPIRED 5. click Pay Now; 6. check order chatter on the backend. Issue ----- > Error: Adyen: Received data with invalid payment state: Refused Refusal shouldn't be an invalid payment state.
Original PR description
Versions
--------
- 17.0+
Steps
-----
1. Enable Adyen as payment provider in test mode;
2. do an eCommerce checkout;
3. select Adyen as payment option;
4. use the following card details[^1]:
- card number: 4111111111111111
- expiry: 03/30
- cvc: 737
- name on card: CARD_EXPIRED
5. click Pay Now;
6. check order chatter on the backend.
Issue
-----
> Error: Adyen: Received data with invalid payment state: Refused
Refusal shouldn't be an invalid payment state.
Cause
-----
Commit 04f75728fd3e accidentally removed an `elif` branch that was added by commit 4d340a330462e specifically to handle refused payments.
Solution
--------
Re-add the `elif` branch.
opw-4481602
[^1]: https://docs.adyen.com/development-resources/testing/result-codes#values-for-testing-result-reasons
Forward-Port-Of: odoo/odoo#196394In this PR, - Set the default department for the Plans smart button. - If there is no plan, it will open the form view. Task-4356557 Forward-Port-Of: odoo/odoo#196602 Forward-Port-Of: odoo/odoo#190938
Original PR description
In this PR, - Set the default department for the Plans smart button. - If there is no plan, it will open the form view. Task-4356557 Forward-Port-Of: odoo/odoo#196602 Forward-Port-Of: odoo/odoo#190938
Steps to reproduce: - Go to the "/blog" page. - Click on "Configuration > Blogs" in the main navbar. - Create at least 15 new blogs with "Astronomy" as the name. - Go back to the "/blog" page. - Bug: The navbar overflows the page to the right, causing a horizontal scrollbar to appear. After this commit, the navbar no longer overflows, and the list items are displayed on multiple lines. [opw-4507558](https://www.odoo.com/web#id=4507558&cids=1&menu_id=4720&action=333&active_id=1695&
Original PR description
Steps to reproduce: - Go to the "/blog" page. - Click on "Configuration > Blogs" in the main navbar. - Create at least 15 new blogs with "Astronomy" as the name. - Go back to the "/blog" page. - Bug: The navbar overflows the page to the right, causing a horizontal scrollbar to appear. After this commit, the navbar no longer overflows, and the list items are displayed on multiple lines. [opw-4507558](https://www.odoo.com/web#id=4507558&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#196452 Forward-Port-Of: odoo/odoo#195859
**Issue:** Users are able to delete timesheets associated with public holidays, unlike regular time off requests **Steps to Reproduce:** - Ensure "Time Off" is enabled in the Timesheet settings. - Time Off > Configurations > Public Holidays. - Create a new public holiday. - Timesheet > My Timesheet (list view). - Attempt to delete the timesheet entry corresponding to the public holiday. The entry is deleted without any warning. opw-4464411 --- I confirm I have s
Original PR description
**Issue:** Users are able to delete timesheets associated with public holidays, unlike regular time off requests **Steps to Reproduce:** - Ensure "Time Off" is enabled in the Timesheet settings. - Time Off > Configurations > Public Holidays. - Create a new public holiday. - Timesheet > My Timesheet (list view). - Attempt to delete the timesheet entry corresponding to the public holiday. The entry is deleted without any warning. opw-4464411 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196506 Forward-Port-Of: odoo/odoo#195379
Fixes an issue with the renaming of the attachment after detaching to not change the extension. task-4500319 Forward-Port-Of: odoo/odoo#196456
Original PR description
Fixes an issue with the renaming of the attachment after detaching to not change the extension. task-4500319 Forward-Port-Of: odoo/odoo#196456
Steps to reproduce: - Enter edit mode. - Drag and drop a carousel into the page. - Use the arrow keys to slide the carousel. - Bug: a traceback occurs. Just like we disabled Bootstrap for sliding the carousel in edit mode and instead handle it manually (see this commit [1]), in this commit, we also disable sliding the carousel by pressing the left and right arrow keys on the keyboard. [1]: https://github.com/odoo/odoo/commit/93ec3ac285dc9ffd363e185a1dc238c6135d79dd opw-4373535 Fo
Original PR description
Steps to reproduce: - Enter edit mode. - Drag and drop a carousel into the page. - Use the arrow keys to slide the carousel. - Bug: a traceback occurs. Just like we disabled Bootstrap for sliding the carousel in edit mode and instead handle it manually (see this commit [1]), in this commit, we also disable sliding the carousel by pressing the left and right arrow keys on the keyboard. [1]: https://github.com/odoo/odoo/commit/93ec3ac285dc9ffd363e185a1dc238c6135d79dd opw-4373535 Forward-Port-Of: odoo/odoo#196486 Forward-Port-Of: odoo/odoo#196433
Since commit [1], which moved the scroll out of the `#wrapwrap`, when we resize an element, the size of the scroll bar increases suddenly for no apparent reason, creating a flicker effect. This happens because when we start resizing, a `div` is added at the end of the body, with a `height` set at `100%`. It was added in commit [2], when the website was moved in an iframe, in order for the mouse events to not be absorbed by it. The scroll bar flicker is therefore due to the addition of this
Original PR description
Since commit [1], which moved the scroll out of the `#wrapwrap`, when we resize an element, the size of the scroll bar increases suddenly for no apparent reason, creating a flicker effect. This…
Since commit [1], which moved the scroll out of the `#wrapwrap`, when we resize an element, the size of the scroll bar increases suddenly for no apparent reason, creating a flicker effect. This happens because when we start resizing, a `div` is added at the end of the body, with a `height` set at `100%`. It was added in commit [2], when the website was moved in an iframe, in order for the mouse events to not be absorbed by it. The scroll bar flicker is therefore due to the addition of this `div` in the body, which makes the page bigger. Before commit [1], the body had its `overflow` property set to `hidden`, which is why adding the `div` had no visual effect, since it was hidden. (Note that the body has a fixed size, which is the size of the viewport with no overflow.) But with commit [1], this property has been removed, making the `div` appear at the bottom of the page. To fix this issue, we could simply set this `div` height to `0px` or its `top` position to 0, so it would never overflow the body. But in fact, it appears that this `div` is simply not necessary anymore since commit [3], which restored the overlay computation. This commit therefore removes the handler in charge of adding this `div` when we start resizing, as it is not needed anymore. [1]: https://github.com/odoo/odoo/commit/189a7c96e6e26825dc05c0c6466576fe63aa091e [2]: https://github.com/odoo/odoo/commit/03c552690b15cbf2e7d6b7812386ac64042219af [3]: https://github.com/odoo/odoo/commit/2ae4e6434112a676c1cfa100e88fd756fe17f000 task-4190506 Forward-Port-Of: odoo/odoo#185163
Previously, the Mail Failure icon was a .JPG, which lacked transparency. While this was not noticeable in Odoo Light Mode, it resulted in a visible white background in Dark Mode. This commit replaces the JPG with an SVG, ensuring proper transparency. | Current (17.0) | Fix | |--------|--------| |  |  | |  |  | |  |  | task-4531425 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196400
### Steps to reproduce: - Install "l10n_ch" and switch to a Swiss company - Create a new invoice with a Swiss customer - Confirm - In the actions, select "PDF without payments" - The generated PDF has a blank page at the end ### Cause: The report "account.report_invoice" does not have a field `is_invoice_report` set to `True`. When generating an invoice with Swiss localization. It reads the field `is_invoice_report` to add or not the QR code. The bug appears after this [commit](https
Original PR description
### Steps to reproduce: - Install "l10n_ch" and switch to a Swiss company - Create a new invoice with a Swiss customer - Confirm - In the actions, select "PDF without payments" - The generated PDF has a blank page at the end ### Cause: The report "account.report_invoice" does not have a field `is_invoice_report` set to `True`. When generating an invoice with Swiss localization. It reads the field `is_invoice_report` to add or not the QR code. The bug appears after this [commit](https://github.com/odoo/odoo/commit/bb60952c944db27d71d7fe32ead2dff05c3fe922#diff-b6e108b605fbefba066e3b20f8e030ea78881bbed816f8ac5cb38e745c542739R50) which modified the `_is_invoice_report` method to use the field, but only added the field in "account_invoices". ### Solution: Set the field to True for the report. opw-4467250 Forward-Port-Of: odoo/odoo#194911
**Problem**: Removing spaces impacts composed values like (`padding: 10px 20px` → `padding: 10px20px`), making them invalid. **Solution**: Replace multiple spaces with a single space instead of removing them, to ensure composed values remain intact. **Steps to Reproduce**: 1. Open Email Templates > any template. 2. Add `padding: 10px 20px` to a `tr` element. 3. Save the template. 4. Observe that padding is not applied. --- I confirm I have signed the CLA and read the PR guidelin
Original PR description
**Problem**: Removing spaces impacts composed values like (`padding: 10px 20px` → `padding: 10px20px`), making them invalid. **Solution**: Replace multiple spaces with a single space instead of removing them, to ensure composed values remain intact. **Steps to Reproduce**: 1. Open Email Templates > any template. 2. Add `padding: 10px 20px` to a `tr` element. 3. Save the template. 4. Observe that padding is not applied. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196564 Forward-Port-Of: odoo/odoo#196376
…nt reference for Dutch users The VAT payment reference in the Netherlands changes with each return and can be computed using a specific formula. This commit enables Odoo to automatically generate and propose the correct reference by default when users pay their VAT settlement from the dashboard. This feature streamlines the process for accounting firms, reducing the need to repeatedly log in to the Dutch Tax Authorities portal. task-4063832 Forward-Port-Of: odoo/enterprise#74770
Original PR description
…nt reference for Dutch users The VAT payment reference in the Netherlands changes with each return and can be computed using a specific formula. This commit enables Odoo to automatically generate and propose the correct reference by default when users pay their VAT settlement from the dashboard. This feature streamlines the process for accounting firms, reducing the need to repeatedly log in to the Dutch Tax Authorities portal. task-4063832 Forward-Port-Of: odoo/enterprise#74770
Description of the issue/feature this PR addresses: This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label. Current behavior before PR: If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with "-". Desired behavior after PR is merged: If an electronic invoice is sent to DGI with a line without product id but with a lab
Original PR description
Description of the issue/feature this PR addresses: This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label. Current…
Description of the issue/feature this PR addresses:
This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label.
Current behavior before PR:
If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with "-".
Desired behavior after PR is merged:
If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with the product description.
Steps to reproduce the issue:
- Create an electronic invoice on an uruguayan company.
- Add a line without a product and add a label, a unit price, quantity and tax.
- Confirm the invoice and create CFE.
- Check that the field "NomItem" is field with a "-" instead of the product label like this:
```
<Item>
<NroLinDet>4</NroLinDet>
<IndFact>2</IndFact>
<NomItem>-</NomItem>
<DscItem>PRODUCT X</DscItem>
<Cantidad>1.000</Cantidad>
<UniMed>N/A</UniMed>
<PrecioUnitario>20.000000</PrecioUnitario>
<MontoItem>20.00</MontoItem>
</Item>
```
Forward-Port-Of: odoo/enterprise#78551Translate this new module. Translations were provided by MADI. task-4298921 Forward-Port-Of: odoo/enterprise#78659
Original PR description
Translate this new module. Translations were provided by MADI. task-4298921 Forward-Port-Of: odoo/enterprise#78659
Since https://github.com/odoo/enterprise/commit/b198b60d337d2ea6a5d17872fb621322df57a20f get_invoiced should also return the invoice linked with the subscription based on the field account.move.line.subscription_id. Unfortunatly, if the query based on sale_line_ids found no invoice for a given origin_order_id, the invoice found based on subscription_id were not added. This can easily happen when the invoice are read by a user (for example odoo bot) that doesn't belong to the company of the
Original PR description
Since https://github.com/odoo/enterprise/commit/b198b60d337d2ea6a5d17872fb621322df57a20f get_invoiced should also return the invoice linked with the subscription based on the field account.move.line.subscription_id. Unfortunatly, if the query based on sale_line_ids found no invoice for a given origin_order_id, the invoice found based on subscription_id were not added. This can easily happen when the invoice are read by a user (for example odoo bot) that doesn't belong to the company of the invoice. Solution: Invoice by origin_order_id should come from the result of the query + move_by_origin Forward-Port-Of: odoo/enterprise#78603
Before this commit, validating an order resulted in an error because the wrong model "account_move" was used instead of "account.move". opw-4543705 Forward-Port-Of: odoo/enterprise#78579
Original PR description
Before this commit, validating an order resulted in an error because the wrong model "account_move" was used instead of "account.move". opw-4543705 Forward-Port-Of: odoo/enterprise#78579
This commit aims to ensure that the expected working hours for flexible resources are not rounded to the hours when displayed on the Gantt progress bar. Previously, the total hours were being rounded to the hours, which could lead to inaccuracies in the representation of the expected working hours on the gantt view. By changing the rounding to the minutes, we ensure that the Gantt progress bar accurately reflects the precise hours worked by flexible resources. Steps to reproduce: -----------
Original PR description
This commit aims to ensure that the expected working hours for flexible resources are not rounded to the hours when displayed on the Gantt progress bar. Previously, the total hours were being rounded to the hours, which could lead to inaccuracies in the representation of the expected working hours on the gantt view. By changing the rounding to the minutes, we ensure that the Gantt progress bar accurately reflects the precise hours worked by flexible resources. Steps to reproduce: ------------------- 1. Create an employee with flexible hours ex. 42:30h per week (8:30h per day) 2. Create a shift for the same employee on planning. 3. In the gantt view, when setting the date range to a week, the expected working hours of the period is showing 42h instead of 42:30h task-id: 4506633 Forward-Port-Of: odoo/enterprise#77782
Subscriptions with multiple lines and tax-included prices introduced a rounding error in some cases. This commit fixes the _compute_recurring_total method by using the same rounding method as _compute_amounts in the sale/ module, based on AccountTax helper methods. opw-[4460812](https://www.odoo.com/odoo/all-tasks/4460812) Forward-Port-Of: odoo/enterprise#76686
Original PR description
Subscriptions with multiple lines and tax-included prices introduced a rounding error in some cases. This commit fixes the _compute_recurring_total method by using the same rounding method as _compute_amounts in the sale/ module, based on AccountTax helper methods. opw-[4460812](https://www.odoo.com/odoo/all-tasks/4460812) Forward-Port-Of: odoo/enterprise#76686
Issue: in testing with freeze_time if the date is None in `_get_parameter_from_code` arguments it takes the real today's date - change the `date` argument while getting the `public_transport_max_amount` parameter because if it is None is gets the real date not the freeze one Task: 4509216 Forward-Port-Of: odoo/enterprise#78115
Original PR description
Issue: in testing with freeze_time if the date is None in `_get_parameter_from_code` arguments it takes the real today's date - change the `date` argument while getting the `public_transport_max_amount` parameter because if it is None is gets the real date not the freeze one Task: 4509216 Forward-Port-Of: odoo/enterprise#78115
As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box. However, the Worldline related files are being downloaded and unzipped under 'sudo' command which means that the user "odoo" doesn't have access to them This is an issue when trying to delete the old IoT handlers as it's done with the user "odoo" but Worldline files present in the 'ctep' directory belong to 'root': ``` 2025-02-05 10:29:03,827 4815 ERR
Original PR description
As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box. However, the Worldline related files are being downloaded and…
As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box.
However, the Worldline related files are being downloaded and unzipped under 'sudo' command which means that the user "odoo" doesn't have access to them
This is an issue when trying to delete the old IoT handlers as it's done with the user "odoo" but Worldline files present in the 'ctep' directory belong to 'root':
```
2025-02-05 10:29:03,827 4815 ERROR ? odoo.addons.hw_drivers.tools.helpers: Failed to delete old IoT handlers
Traceback (most recent call last):
File "/home/pi/odoo/addons/hw_drivers/tools/helpers.py", line 435, in delete_iot_handlers
unlink_file(*filenames)
File "/home/pi/odoo/addons/hw_drivers/tools/helpers.py", line 534, in unlink_file
path.unlink()
File "/usr/lib/python3.11/pathlib.py", line 1148, in unlink
os.unlink(self)
PermissionError: [Errno 13] Permission denied: '/home/pi/odoo/addons/hw_drivers/iot_handlers/lib/ctep/libeasyctep.so'
```
This PR runs Worldline related script under user "odoo" which fixes the ownership/access issues and allows Odoo service to delete the files.
task-4527243
Forward-Port-Of: odoo/enterprise#78544If a warehouse has multi-steps deliveries, the actual demand of a product only takes the real outgoing move into account: the move that goes directly to the customer location. Since moves are not created in advance anymore, we need to take the earlier moves in the chain into account instead while making sure that we only use a single move at a time. The move used will be the last created in the chain, the one without `move_dest_ids`. task 4510137 Forward-Port-Of: odoo/enterprise#77787
Original PR description
If a warehouse has multi-steps deliveries, the actual demand of a product only takes the real outgoing move into account: the move that goes directly to the customer location. Since moves are not created in advance anymore, we need to take the earlier moves in the chain into account instead while making sure that we only use a single move at a time. The move used will be the last created in the chain, the one without `move_dest_ids`. task 4510137 Forward-Port-Of: odoo/enterprise#77787
Fix runbot error: 113710 Forward-Port-Of: odoo/enterprise#78543
Original PR description
Fix runbot error: 113710 Forward-Port-Of: odoo/enterprise#78543
The new module introduces these 2 reports: 1. VAT control statement (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1 2. VIES report (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV The new module also has the tax report XML export logic. The logic was moved here because the new field of tax office was needed in tax repor
Original PR description
The new module introduces these 2 reports: 1. VAT control statement (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1 2. VIES report (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV The new module also has the tax report XML export logic. The logic was moved here because the new field of tax office was needed in tax reports XML export. Documenation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHDP3 task-3698642 task-3762956 task-4087283 Forward-Port-Of: odoo/enterprise#78391 Forward-Port-Of: odoo/enterprise#56896
Steps to reproduce: ------------------- 1. Install the Planning App 2. Pick a week and assign a shift from Monday to Friday for a resource A 3. Create two time offs for resource A: one on Tuesday and one on Thursday of the week after you created the shift 4. Now, in the planning gantt view, move to the next week (the week after you created the shift) 5. Use the copy previous week action 6. The copied shifts are split in a way they shouldn't. On Monday, Wednesday and Friday, there are two
Original PR description
Steps to reproduce: ------------------- 1. Install the Planning App 2. Pick a week and assign a shift from Monday to Friday for a resource A 3. Create two time offs for resource A: one on Tuesday and…
Steps to reproduce: ------------------- 1. Install the Planning App 2. Pick a week and assign a shift from Monday to Friday for a resource A 3. Create two time offs for resource A: one on Tuesday and one on Thursday of the week after you created the shift 4. Now, in the planning gantt view, move to the next week (the week after you created the shift) 5. Use the copy previous week action 6. The copied shifts are split in a way they shouldn't. On Monday, Wednesday and Friday, there are two copied slots instead of just one. Fix: ------------------- Currently, the _merge_slots_values() method is called when we use copy previous week on a forecasted slot (> 24 hours), which is the case here. This method takes work intervals and unavailabilites in parameters, and returns merged slots by taking into account the unavailabilites. To fix the issue mentioned above, we removed a condition that only allows slots to be merged if their combination creates a forecasted slot (> 24 hours). But we argue that we should also be able to merge smaller slots (< 24 hours). task-4368919 version-18.0 Forward-Port-Of: odoo/enterprise#76714
After this commit https://github.com/odoo/enterprise/commit/574d608b21199d5590d2335f4360a0a6470d1257, The workflow actions have been removed and replaced by server actions and this PR is responsible for handling the migration of workflow actions into server actions.(see https://github.com/odoo/upgrade/pull/6729) ``` AttributeError: 'int' object has no attribute 'create_document_from_attachment' ``` We created server actions sending to `journal_id` as `int` when migrating dbs to 18.0. Wh
Original PR description
After this commit https://github.com/odoo/enterprise/commit/574d608b21199d5590d2335f4360a0a6470d1257, The workflow actions have been removed and replaced by server actions and this PR is responsible for handling the migration of workflow actions into server actions.(see https://github.com/odoo/upgrade/pull/6729) ``` AttributeError: 'int' object has no attribute 'create_document_from_attachment' ``` We created server actions sending to `journal_id` as `int` when migrating dbs to 18.0. While the method originally supported only recordsets, it's actually convenient to support `int`s here to avoid browse in the action (more readable and more accessible to end-users). opw-4453249 Forward-Port-Of: odoo/enterprise#76599
In this PR odoo/enterprise/pull/64323, certificates were refactored. However, one method has passed through the net and was left using the old way. This commit fixes that by removing the call and using the new refactored certificates opw-4423435 Forward-Port-Of: odoo/enterprise#77959
Original PR description
In this PR odoo/enterprise/pull/64323, certificates were refactored. However, one method has passed through the net and was left using the old way. This commit fixes that by removing the call and using the new refactored certificates opw-4423435 Forward-Port-Of: odoo/enterprise#77959
Steps: - create a BOM for product A: component product B, ration 1.0, lead time 1 day - put 4 as the on-hand qty of product A - in the MPS, create records for products A & B with manufacture route for product A - put 6 as the forecasted demand of product A on the 2nd period or further (this is so that the indirect demand of B is shown on the previous period) Issue: The indirect demand of product B will be 6 instead of 2 (6-4). This is because it uses `date_stop` with the lead time, see
Original PR description
Steps: - create a BOM for product A: component product B, ration 1.0, lead time 1 day - put 4 as the on-hand qty of product A - in the MPS, create records for products A & B with manufacture route for product A - put 6 as the forecasted demand of product A on the 2nd period or further (this is so that the indirect demand of B is shown on the previous period) Issue: The indirect demand of product B will be 6 instead of 2 (6-4). This is because it uses `date_stop` with the lead time, see https://github.com/odoo/enterprise/pull/70232 Fix: Subtract the starting qty from the indirect demand qty for the corresponding subproduct. This is to make sure that the real `subproduct_indirect_demand` is compared to the 'ratioed' `replenish_qty` of the subproduct when selecting the date to use. task 4381021 Forward-Port-Of: odoo/enterprise#75141
The following `response` was being returned when checking the CFDI status: ``` (Pdb++) response {'CodigoEstatus': 'N - 601: La expresión impresa proporcionada no es válida.', 'EsCancelable': None, 'Estado': 'No Encontrado', 'EstatusCancelacion': None, 'ValidacionEFOS': None} ``` Since `CodigoEstatus` is already a string, there is no need to parse it again. Removing the extra line prevents the error that occurred when trying to re-parse text from a string and ensures the SAT status is h
Original PR description
The following `response` was being returned when checking the CFDI status:
```
(Pdb++) response {'CodigoEstatus': 'N - 601: La expresión impresa
proporcionada no es válida.', 'EsCancelable': None, 'Estado': 'No
Encontrado', 'EstatusCancelacion': None, 'ValidacionEFOS': None}
```
Since `CodigoEstatus` is already a string, there is no need to parse it again. Removing the extra line prevents the error that occurred when trying to re-parse text from a string and ensures the SAT status is handled correctly.
Forward-Port-Of: odoo/enterprise#78552When sending templates en masse to multiple recipients they may sometimes have the same number. If their numbers are the same, and the template resolves to the same value there is no need to send them the template multiple times which could be considered as spam. Now if all template variables resolve to the same value, messages will be canceled immediately Similarly to what is done for emails. task-4029026 Forward-Port-Of: odoo/enterprise#78548 Forward-Port-Of: odoo/enterprise#66033
Original PR description
When sending templates en masse to multiple recipients they may sometimes have the same number. If their numbers are the same, and the template resolves to the same value there is no need to send them the template multiple times which could be considered as spam. Now if all template variables resolve to the same value, messages will be canceled immediately Similarly to what is done for emails. task-4029026 Forward-Port-Of: odoo/enterprise#78548 Forward-Port-Of: odoo/enterprise#66033
Steps to reproduce: CRM > Sales > Teams > Pipeline > Graph View >Insert Into Spreadsheet => Boom: Name 'active_id' is not defined. The action context contains a dynamic value, which needs the *current* to be evaluated. Task: 4548431 opw-4491590 opw-4500397 Forward-Port-Of: odoo/enterprise#78539
Original PR description
Steps to reproduce: CRM > Sales > Teams > Pipeline > Graph View >Insert Into Spreadsheet => Boom: Name 'active_id' is not defined. The action context contains a dynamic value, which needs the *current* to be evaluated. Task: 4548431 opw-4491590 opw-4500397 Forward-Port-Of: odoo/enterprise#78539
When you reduce the screen width or view the page on devices with small screens, the control panel button group rearranges itself in an unsightly way (e.g. excessive button height). For mobile devices, we use overflow auto on the action btns of the panel. Then they keep their aspects and are still accessible to users. FW-PORT until 18.1 task-4471881 Forward-Port-Of: odoo/enterprise#77039
Original PR description
When you reduce the screen width or view the page on devices with small screens, the control panel button group rearranges itself in an unsightly way (e.g. excessive button height). For mobile devices, we use overflow auto on the action btns of the panel. Then they keep their aspects and are still accessible to users. FW-PORT until 18.1 task-4471881 Forward-Port-Of: odoo/enterprise#77039
Issue: Mobility budget is shown in every contract if it is installed on the db - make the budegt only visible for BE Task: 4529227 Forward-Port-Of: odoo/enterprise#78159
Original PR description
Issue: Mobility budget is shown in every contract if it is installed on the db - make the budegt only visible for BE Task: 4529227 Forward-Port-Of: odoo/enterprise#78159