Wednesday, July 24, 2024
51 changes · master
Enhancements to existing features
The developer tools menu now shows the view model before the view fields, making related technical information easier to find in the intended order. This is a small usability improvement for teams using Odoo's debug and developer tools.
Original PR description
Specification: In the developer tools, change the sequence so that the view model appears before the view fields. Task-3867703
This update improves how Odoo calculates certain fields when user context and elevated permissions are involved. It helps ensure records are updated correctly in cases where calculations depend on the current user, reducing errors in internal data processing.
Original PR description
A `_compute` method depending on context `uid` for a field with `compute_sudo=True` was not able to assign values to records without sudo env. Task-10888
The document upload process has been simplified by removing unnecessary error-handling code around file reading. This makes the upload code easier to maintain while keeping any real upload issues visible to users through the normal web interface.
Original PR description
Based on file sources, we have determined that errors will never occur during the file reading process. If it fails, it will be naturally reported to the web client. This PR simplifies the code and eliminates unnecessary exception handling. Task-3973319
This update converts field service-related automated tests to a newer testing framework. It improves maintainability and reliability of internal quality checks without changing day-to-day user workflows.
Original PR description
_*= industry_fsm_stock, industry_fsm_sale task-3935514
Resolved issues and error corrections
This fix renames an internal accounting field so it clearly represents multiple reversal entries rather than a single one. The change reduces confusion for teams and integrations working with refunds, reversals, expenses, sales, purchases, and local electronic invoicing flows, without changing business functionality.
Original PR description
Miscellaneous changes
Currently if there are no IR rules preventing a low right user to write on a record, no error notification will appear when the user tries to add a property field to the child model since no error is raised in the checkDefinitionWriteAccess method. If this user does not have access rights on the model of the parent record an unwanted traceback will appear since nothing prevents him from trying to add a property field to the model Here we're using the canChangeDefinition which is loaded
Original PR description
Currently if there are no IR rules preventing a low right user to write on a record, no error notification will appear when the user tries to add a property field to the child model since no error is raised in the checkDefinitionWriteAccess method. If this user does not have access rights on the model of the parent record an unwanted traceback will appear since nothing prevents him from trying to add a property field to the model Here we're using the canChangeDefinition which is loaded by checkingAccessRight on the user at the start of the component startup Task-3815748 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173630 Forward-Port-Of: odoo/odoo#158165
…_move_ids *: hr_expense, l10n_es_edi_facturae, l10n_hu_edi,l10n_id_efaktur, l10n_it_edi_doi, purchase_stock, sale_mrp, sale_stock We introduced this field with a typo, now it causes misunderstanding as it is interpreted as a many2one and not a one2many. Related: https://github.com/odoo/odoo/commit/09a6a4da116059414baeb7e663d8a503c3ae082e task-no 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
This fix reduces unnecessary memory messages when developers run browser tests manually, keeping the console easier to read. It also ensures automated test memory logs use more precise data, helping teams diagnose test behavior more reliably.
Original PR description
This commit does 2 things: - memory information logs (i.e. [MEMINFO]) were always logged, even when running JS unit tests in the browser manually. This was polluting the console with information that is available either way in the "memory" tab. Now these logs only appear when the garbage collector is exposed (i.e. when running unit tests through test_js.py); - since the "enable-precise-memory-info" flag wasn't applied, these memory logs were always displaying the same info accross multiple calls. This has been fixed by also checking that flag for all builds, along with the previously exposed "gc" flag. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an intermittent timing issue in the Documents deletion test that could cause automated checks to fail even when the product behaved correctly. The change helps keep quality checks stable and reduces false alarms during development.
Original PR description
Sometimes the following sequence happened after the steps in `restoreDocumentSteps` after those in `deleteWorkspaceSteps`: 1. We click on the trash section 2. Its header is re-rendered with the "active" class 3. We select the record 4. The kanban view is reloaded to actually show the trash now 5. We already selected the document, so we're at the step expecting to interact with the inspector. See runbot error 71617
The document deletion test now waits until the expected deleted item is actually loaded before continuing. This prevents false failures under slow network conditions and helps keep automated quality checks stable.
Original PR description
In this tour, there is a step that is supposed to check that the elements in trash are loaded.
.o_search_panel_field header.active:contains("Trash")
However, this is incorrect. If we put the network in slow 3G, we can see that the header has the active class while the trash elements are not yet loaded.
In this commit, we therefore ensure that chouchou is in the loaded elements before selecting it.This fixes an issue in Documents spreadsheets where renamed pivot measures were not properly supported. Business users can now rely on custom measure names appearing correctly, making spreadsheet reports clearer and easier to interpret.
This fixes a misleading internal field name used to track reversal entries across several accounting-related apps. The change reduces confusion for developers and maintainers without changing how business users work in Odoo.
Original PR description
…rsal_move_ids *: account_asset, account_reports, helpdesk_account, hr_payroll_expense, sale_subscription We introduced this field with a typo, now it causes misunderstanding as it is interpreted as a many2one and not a one2many. Related: https://github.com/odoo/odoo/commit/09a6a4da116059414baeb7e663d8a503c3ae082e task-no
Fixed an error that could occur when selecting or assigning tasks from the Project Gantt view. This keeps project planning workflows stable and avoids interruptions for users managing task schedules.
Original PR description
Steps to Reproduce: 1. Go to the Gantt view in tasks in the Project module. 2. Select a task. 3. Observe the traceback error. Cause: - The `Task.web_gantt_write()` method received an unexpected keyword in the data argument, causing a TypeError. Solution: - Updated the call of the `Task.web_gantt_write()` method to handle the data argument correctly. effected commit-https://github.com/odoo/enterprise/commit/214b52cb7d6d2087d2b18c2ff32a7b59b9b2e21b task-4057377
Steps to reproduce: - Install planning and switch to calendar view - try resizing the pill that is already resizable (pills that span for multiple days) Issue: pill resizing is not working as expected. Cause: the end date wasn't being calculated correctly for this. Fix: after this commit, the end date is calculated correctly. task-3326281 Forward-Port-Of: odoo/odoo#173628 Forward-Port-Of: odoo/odoo#139893
Original PR description
Steps to reproduce: - Install planning and switch to calendar view - try resizing the pill that is already resizable (pills that span for multiple days) Issue: pill resizing is not working as expected. Cause: the end date wasn't being calculated correctly for this. Fix: after this commit, the end date is calculated correctly. task-3326281 Forward-Port-Of: odoo/odoo#173628 Forward-Port-Of: odoo/odoo#139893
A VAT number in Spain is a concatenation of the country prefix ES and another code, either: NIF - Número de Identificación Fiscal for individuals. CIF - Certificado de Identificación Fiscal for registered companies. The `res_partner.vat` field in Odoo is labelled "NIF" in the UI, and supports both the full VAT code with ES prefix and the shorter one without. This fix addresses two cases where the code assumed the ES prefix was present and incorrectly trimmed the first two characters away.
Original PR description
A VAT number in Spain is a concatenation of the country prefix ES and another code, either: NIF - Número de Identificación Fiscal for individuals. CIF - Certificado de Identificación Fiscal for registered companies. The `res_partner.vat` field in Odoo is labelled "NIF" in the UI, and supports both the full VAT code with ES prefix and the shorter one without. This fix addresses two cases where the code assumed the ES prefix was present and incorrectly trimmed the first two characters away. Reference: https://www.strongabogados.com/tax-id-spain.php Ticket [link](https://www.odoo.com/odoo/project.task/3891248) opw-3891248 Forward-Port-Of: odoo/odoo#168052
Steps: - Create group tax (20%) and add two tax in it (10% each) with Tax included true. - Create product with 100 price and and set that 20% tax on it. - Create coupon program with 90 amount on order and generate coupon. - Create SO and add SOL with that product now apply coupon on that SO. Issue: - Amount computation is wrong for coupon value which is greater then that product's tax_excluded(80) and it is only applying 80 instead of 90 because we were not properly computing amount
Original PR description
Steps: - Create group tax (20%) and add two tax in it (10% each) with Tax included true. - Create product with 100 price and and set that 20% tax on it. - Create coupon program with 90 amount on order and generate coupon. - Create SO and add SOL with that product now apply coupon on that SO. Issue: - Amount computation is wrong for coupon value which is greater then that product's tax_excluded(80) and it is only applying 80 instead of 90 because we were not properly computing amount of child taxed. Cause: - Discountable was not properly computed in commit [1]. it was not taking child tax values into account. Fix: - Add condition to properly check discountable values and take child tax amount into consideration. [1] https://github.com/odoo/odoo/commit/443097b4db29a4909bb0d0c44040140f08d1e433 opw-4033803 Forward-Port-Of: odoo/odoo#174196 Forward-Port-Of: odoo/odoo#173659
The sequence field was added to `stock_location` for incorrect reasons. Because of this, the field has no value and results in potentially incorrect ordering of the locations (e.g. in field dropdown) and also potentially results in unexpected ordering since ordering by `complete_name` typically results in easier grouping by location > sublocation, e.g.: parent parent > child 1 parent > child 1 > subchild 1 parent > child 2 parent > child 2 > subchild 2 Task: 4013661 Description of t
Original PR description
The sequence field was added to `stock_location` for incorrect reasons. Because of this, the field has no value and results in potentially incorrect ordering of the locations (e.g. in field dropdown) and also potentially results in unexpected ordering since ordering by `complete_name` typically results in easier grouping by location > sublocation, e.g.: parent parent > child 1 parent > child 1 > subchild 1 parent > child 2 parent > child 2 > subchild 2 Task: 4013661 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 Forward-Port-Of: odoo/odoo#174202
Allow customization to retrieve the user used to authenticate by adding the user attribute. opw-4059147 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174208
Original PR description
Allow customization to retrieve the user used to authenticate by adding the user attribute. opw-4059147 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174208
Steps to reproduce: ------------------- * Activate discount on lines on user parameters * Change the pricelist config to show discount to the customers * Open a PoS session with the modified pricelist * Create an order and apply some discount on the lines * Invoice and pay the order > Observation: On the invoice pdf you should have a line saying "Price discount from X -> X" but it's not there Why the fix: ------------ Before the fix we were comparing the `price_unit` on the line and
Original PR description
Steps to reproduce: ------------------- * Activate discount on lines on user parameters * Change the pricelist config to show discount to the customers * Open a PoS session with the modified pricelist * Create an order and apply some discount on the lines * Invoice and pay the order > Observation: On the invoice pdf you should have a line saying "Price discount from X -> X" but it's not there Why the fix: ------------ Before the fix we were comparing the `price_unit` on the line and the `lst_price` of the product. But if a discount was applied on the line the price unit is not affected, and so the line was never shown. To fix this we compare the `total_price` of the line with the `lst_price` multiplied by the quantity on the line. opw-4019107 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174127 Forward-Port-Of: odoo/odoo#172754
- Changed pos_display background to follow odoo 17's default one, updated all colors/logo to fit, - Moved error message to console as it's almost never relevant to users, - Added hostname on top of the page. Task: 3947355 Forward-Port-Of: odoo/odoo#174169
Original PR description
- Changed pos_display background to follow odoo 17's default one, updated all colors/logo to fit, - Moved error message to console as it's almost never relevant to users, - Added hostname on top of the page. Task: 3947355 Forward-Port-Of: odoo/odoo#174169
Summary ----- In the method load in models.py, when there is an error when we try to create a recordset with at least 2 records, we try to create each record separately. Only the errors caught by creating these single records are displayed which is confusing. Steps to Reproduce ----- 1. In Accounting > Configuration > Accounting > Chart of Accounts, create an account with the type "Off-Balanced Sheet" 2. On the same page, import a Chart of Account (import journal items
Original PR description
Summary ----- In the method load in models.py, when there is an error when we try to create a recordset with at least 2 records, we try to create each record separately. Only the errors caught by…
Summary
-----
In the method load in models.py, when there is an error when we try to create a recordset with at least 2 records, we try to create each record separately.
Only the errors caught by creating these single records are displayed which is confusing.
Steps to Reproduce
-----
1. In Accounting > Configuration > Accounting > Chart of
Accounts, create an account with the type "Off-Balanced Sheet"
2. On the same page, import a Chart of Account (import journal
items) by uploading a file which contains the following lines
(example available on the ticket):
[
['move_id','account_id','balance' 'journal_id','date'],
[<move_name>,<account_code_1>,1,<journal_name>,2021-01-01],
[<move_name>,<account_code_2>,-1,<journal_name>,2021-01-01]
]
such that:
- move_name cannot exist
account_code_1 is the code of the created account at
first step
account_code_2 is not the code of an account with the
type "Off-Balanced Sheet"
- journal_name is the name of an existing journal
3. Test or import the uploaded file and see the error which does
not mention the "Off-Balanced Sheet" account.
Cause
-----
If a journal entry contains a line with an "Off
Balanced Sheet" account, then all the other lines must have an account with the same type.
So when we try to load the lines of the uploaded file, it raises a UserError which is caught (which is not added to the list 'messages'). Then we try to create the lines one by one which and that raises an error too because the balance is not null.
Only these errors are added to the list 'messages' which contains the displayed error messages.
Fix
-----
Add the first error to 'message', and ensure that the next errors are not already in 'messages'.
opw-3945687
Forward-Port-Of: odoo/odoo#169083In https://github.com/odoo/odoo/commit/f1749d3299957e2949e0b78653266a5397bb213c, we forgot to prepare a bundle for the dark mode. Here we add a bundle 'web.assets_backend_lazy_dark'. It will be first used in enterprise and soon in community. Forward-Port-Of: odoo/odoo#173620
Original PR description
In https://github.com/odoo/odoo/commit/f1749d3299957e2949e0b78653266a5397bb213c, we forgot to prepare a bundle for the dark mode. Here we add a bundle 'web.assets_backend_lazy_dark'. It will be first used in enterprise and soon in community. Forward-Port-Of: odoo/odoo#173620
Current behavior: In hr_expenses, list and kanban views have different buttons being shown: list view displays 'New', 'Scan' and 'Create Report', while kanban view displays only 'New' and 'Upload'. In mobile, list view shows only 'New', and kanban shows 'Scan' and 'New'. Expected behavior: 'Create Report' button should be displayed in both list and kanban view, in mobile or desktop. In mobile list view, 'Scan' should also be displayed. Cause of the issue: The static view for list includ
Original PR description
Current behavior: In hr_expenses, list and kanban views have different buttons being shown: list view displays 'New', 'Scan' and 'Create Report', while kanban view displays only 'New' and 'Upload'.…
Current behavior: In hr_expenses, list and kanban views have different buttons being shown: list view displays 'New', 'Scan' and 'Create Report', while kanban view displays only 'New' and 'Upload'. In mobile, list view shows only 'New', and kanban shows 'Scan' and 'New'. Expected behavior: 'Create Report' button should be displayed in both list and kanban view, in mobile or desktop. In mobile list view, 'Scan' should also be displayed. Cause of the issue: The static view for list includes only button 'Scan' with display utility classes that hide the button in mobile. Similarly for 'Create Report' button in list. In Kanban, the button 'Create Report' has not been added. Fix: In the list view, 'Upload' button was added for desktop view, and the classes of the 'Scan' button were changed to display it in mobile view. The display utility classes for 'Create Report' were removed, so the button is displayed in mobile. In kanban view, button 'Create Report' was added. The main div of web.KanbanView.Buttons is replaced to ensure that the mobile view buttons are also displayed correctly. Without replacing it, the buttons 'New' and 'Scan' do not match the height of 'Create Report'. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173565 Forward-Port-Of: odoo/odoo#169396
Before this commit : In Draft Invoice/bill if we change fiscal position then it's not updating tax and account in existing lines. After this commit : In the Draft Invoice/bill if we change in fiscal position then it will update the tax and account in existing lines. Task - 3619055 Forward-Port-Of: odoo/odoo#174228 Forward-Port-Of: odoo/odoo#153172
Original PR description
Before this commit : In Draft Invoice/bill if we change fiscal position then it's not updating tax and account in existing lines. After this commit : In the Draft Invoice/bill if we change in fiscal position then it will update the tax and account in existing lines. Task - 3619055 Forward-Port-Of: odoo/odoo#174228 Forward-Port-Of: odoo/odoo#153172
Description of the issue/feature this PR addresses: This PR fixes the incorrect styling applied by the css when reporting the client_order_ref field. Current behavior before PR:  Desired behavior after PR is merged:  --- I confirm I have signed the CLA and read the PR guidelines at ww
Original PR description
Description of the issue/feature this PR addresses: This PR fixes the incorrect styling applied by the css when reporting the client_order_ref field. 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 Forward-Port-Of: odoo/odoo#172741 Forward-Port-Of: odoo/odoo#172366
Currently, when website snippets were translated and they had special characters in them, they would be escaped before adding them as the `data-name` attribute of the snippet, which escaped them again. When the snippet would be selected, the sidebar would get that `data-name` attribute and use it as the title, resulting in the characters still being escaped. This commit fixes that by not escaping the name beforehand, but only when used in raw HTML. Example of the problem (Mur d'images): !
Original PR description
Currently, when website snippets were translated and they had special characters in them, they would be escaped before adding them as the `data-name` attribute of the snippet, which escaped them again. When the snippet would be selected, the sidebar would get that `data-name` attribute and use it as the title, resulting in the characters still being escaped. This commit fixes that by not escaping the name beforehand, but only when used in raw HTML. Example of the problem (Mur d'images):  Forward-Port-Of: odoo/odoo#174156 Forward-Port-Of: odoo/odoo#173808
1) Adapt rpc call to delivery controller following changes introduced by a1e58e9. 2) For demo fix fw commit 47a255d that was not adapted to the changes. Forward-Port-Of: odoo/odoo#174254
Original PR description
1) Adapt rpc call to delivery controller following changes introduced by a1e58e9. 2) For demo fix fw commit 47a255d that was not adapted to the changes. Forward-Port-Of: odoo/odoo#174254
**Current behavior before PR:** When initiating searches quickly in discuss channels or chatter, overlapping requests can occur before previous searches finish. This race condition leads to errors and causes issues with destructuring properties like count, loadMore, and messages.( see: [Discuss](https://www.awesomescreenshot.com/video/29801496?key=44057f8e37a2f394f20e8fc790f80537)) **Desired behavior after PR is merged:** This commit updates the `useMessageSearch` hook to handle sim
Original PR description
**Current behavior before PR:** When initiating searches quickly in discuss channels or chatter, overlapping requests can occur before previous searches finish. This race condition leads to errors and causes issues with destructuring properties like count, loadMore, and messages.( see: [Discuss](https://www.awesomescreenshot.com/video/29801496?key=44057f8e37a2f394f20e8fc790f80537)) **Desired behavior after PR is merged:** This commit updates the `useMessageSearch` hook to handle simultaneous requests more robustly by checking that search results are defined before processing them. This prevents errors and improves stability during rapid searches. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174296 Forward-Port-Of: odoo/odoo#174174
In the mail composer, the title of the modal changes to "Odoo" when the user clicks on the "SAVE AS NEW TEMPLATE" button. This commit will ensure that the modal will keep the title "Compose email" after the user clicks on the button. Steps to reproduce the issue: 1. Open a lead from the CRM module 2. Open the mail composer from the chatter 3. In the composer, click on the "SAVE AS NEW TEMPLATE" button => The modal title changes from "Compose Email" to "Odoo" TO BE: The modal title sh
Original PR description
In the mail composer, the title of the modal changes to "Odoo" when the user clicks on the "SAVE AS NEW TEMPLATE" button. This commit will ensure that the modal will keep the title "Compose email"…
In the mail composer, the title of the modal changes to "Odoo" when the user clicks on the "SAVE AS NEW TEMPLATE" button. This commit will ensure that the modal will keep the title "Compose email" after the user clicks on the button. Steps to reproduce the issue: 1. Open a lead from the CRM module 2. Open the mail composer from the chatter 3. In the composer, click on the "SAVE AS NEW TEMPLATE" button => The modal title changes from "Compose Email" to "Odoo" TO BE: The modal title should display "Compose Email" after creating the template. When the user clicks on the button, the system re-opens the composer by executing a dynamic action. This action does not specify any title. As a result, the modal fallbacks to the default title "Odoo" after executing the action. To fix the issue, we will simply set a name to the dynamic action. task-3748652 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174044 Forward-Port-Of: odoo/odoo#172765
Before this commit, validating an order in the PoS restaurant module with a customer note attached would result in a KeyError. This issue occurred because the customer note was incorrectly processed in the note history, leading to unexpected behavior. Enterprise PR: https://github.com/odoo/enterprise/pull/67210 opw-4059220 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174249
Original PR description
Before this commit, validating an order in the PoS restaurant module with a customer note attached would result in a KeyError. This issue occurred because the customer note was incorrectly processed in the note history, leading to unexpected behavior. Enterprise PR: https://github.com/odoo/enterprise/pull/67210 opw-4059220 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174249
Specification: In the daterange widget, if the second date field is required and left empty, the field should be marked as invalid and be colored red. Expected behavior: if the second field is empty so that fields should be highlighted in red. Task-3786540 Forward-Port-Of: odoo/odoo#174231 Forward-Port-Of: odoo/odoo#162000
Original PR description
Specification: In the daterange widget, if the second date field is required and left empty, the field should be marked as invalid and be colored red. Expected behavior: if the second field is empty so that fields should be highlighted in red. Task-3786540 Forward-Port-Of: odoo/odoo#174231 Forward-Port-Of: odoo/odoo#162000
Some fields related to Italian invoicing are included in XML but missing from the invoice PDF. Added these fields to report_invoice for users to have more visibility for what's included in the XML submitted to Sdl. Task [link](https://www.odoo.com/odoo/project.task/3794551) task-3794551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168447
Original PR description
Some fields related to Italian invoicing are included in XML but missing from the invoice PDF. Added these fields to report_invoice for users to have more visibility for what's included in the XML submitted to Sdl. Task [link](https://www.odoo.com/odoo/project.task/3794551) task-3794551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168447
This commit adds the missing neutralization necessary for the l10n_ro_efactura module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly
Original PR description
This commit adds the missing neutralization necessary for the l10n_ro_efactura module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] https://github.com/odoo/odoo/pull/144061 Forward-Port-Of: odoo/odoo#174274 Forward-Port-Of: odoo/odoo#174013
[IMP] l10n_cz: Fill accounting date with 'taxable_supply_date' In CZ, they need to use the taxable supply date as accounting date and rely on it when we are calculating the currency rate 1- Set default value for 'taxable_supply_date' as the invoice date and allow the user to modify it. Also, fill the accounting date but using the taxable supply date as reference in place of invoice date. 2- Use taxable_supply_date/accounting date to compute the currency rate task-id#3983749 enterpr
Original PR description
[IMP] l10n_cz: Fill accounting date with 'taxable_supply_date' In CZ, they need to use the taxable supply date as accounting date and rely on it when we are calculating the currency rate 1- Set default value for 'taxable_supply_date' as the invoice date and allow the user to modify it. Also, fill the accounting date but using the taxable supply date as reference in place of invoice date. 2- Use taxable_supply_date/accounting date to compute the currency rate task-id#3983749 enterprise-pr: https://github.com/odoo/enterprise/pull/67149 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174247 Forward-Port-Of: odoo/odoo#168933
[IMP] l10n_cz_reports: Adapt cz test on taxable date CZ is going to rely on taxable_supply_date and not the invoice date So, We need to adapt the tests on the new behavior task-id#3983749 odoo-pr: https://github.com/odoo/odoo/pull/168933 Forward-Port-Of: odoo/enterprise#67149
Original PR description
[IMP] l10n_cz_reports: Adapt cz test on taxable date CZ is going to rely on taxable_supply_date and not the invoice date So, We need to adapt the tests on the new behavior task-id#3983749 odoo-pr: https://github.com/odoo/odoo/pull/168933 Forward-Port-Of: odoo/enterprise#67149
Before this commit, validating an order in the PoS restaurant module with a customer note attached would result in a KeyError. This issue occurred because the customer note was incorrectly processed in the note history, leading to unexpected behavior. Community PR: https://github.com/odoo/odoo/pull/174249 opw-4059220 Forward-Port-Of: odoo/enterprise#67210
Original PR description
Before this commit, validating an order in the PoS restaurant module with a customer note attached would result in a KeyError. This issue occurred because the customer note was incorrectly processed in the note history, leading to unexpected behavior. Community PR: https://github.com/odoo/odoo/pull/174249 opw-4059220 Forward-Port-Of: odoo/enterprise#67210
Before this commit, after we drag a sign item out of bounds, it would disappear until we refresh the page. This was happening because we were hiding the item at drag start, then it would only get re-rendered after dropping it inside the page. Thus, if we dragged the item out of bounds instead of inside the page, the item would never get re-rendered. After this commit, the sign item can be dragged anywhere, even out-of-bounds. It works properly because now when the item is dragged out-of-bound
Original PR description
Before this commit, after we drag a sign item out of bounds, it would disappear until we refresh the page. This was happening because we were hiding the item at drag start, then it would only get re-rendered after dropping it inside the page. Thus, if we dragged the item out of bounds instead of inside the page, the item would never get re-rendered. After this commit, the sign item can be dragged anywhere, even out-of-bounds. It works properly because now when the item is dragged out-of-bounds, we make the item visible again even though the the invalid operation is discarded. task-4037888 Forward-Port-Of: odoo/enterprise#66155
### **Steps to reproduce:** - install Timesheets module. - Go to To Validate. - Click on All Timesheets. ### **Issue:** - The notification message is not displaying when clicking on validate in pivot and kanban views ### **Solution:** - The problem seems to be from a mismatch in parameters when triggering the validation action. PR-https://github.com/odoo/enterprise/pull/44455 task-3925639 Forward-Port-Of: odoo/enterprise#67235 Forward-Port-Of: odoo/enterprise#62945
Original PR description
### **Steps to reproduce:** - install Timesheets module. - Go to To Validate. - Click on All Timesheets. ### **Issue:** - The notification message is not displaying when clicking on validate in pivot and kanban views ### **Solution:** - The problem seems to be from a mismatch in parameters when triggering the validation action. PR-https://github.com/odoo/enterprise/pull/44455 task-3925639 Forward-Port-Of: odoo/enterprise#67235 Forward-Port-Of: odoo/enterprise#62945
## Issue: - When adjusting inventory for a product with packages from the barcode app, quantities that are not whole numbers will be rounded to the nearest whole number. ## Steps To Reproduce: - Create a product and include two other products in its packaging, specifying a non-whole number for the contained quantity. - In the barcode app, adjust the inventory by adding the created product and then save the changes. - Click on the small pen icon to modify the product's details. - Observe
Original PR description
## Issue: - When adjusting inventory for a product with packages from the barcode app, quantities that are not whole numbers will be rounded to the nearest whole number. ## Steps To Reproduce: -…
## Issue: - When adjusting inventory for a product with packages from the barcode app, quantities that are not whole numbers will be rounded to the nearest whole number. ## Steps To Reproduce: - Create a product and include two other products in its packaging, specifying a non-whole number for the contained quantity. - In the barcode app, adjust the inventory by adding the created product and then save the changes. - Click on the small pen icon to modify the product's details. - Observe that when adding the quantities with decimal values, they get rounded up to the nearest whole number. ## Solution: - In the `_increment` function, when the initial `value` is not a decimal (it does not contain a '.'), the fraction variable is not set, and the rounding defaults to 0. It's important to note that this issue does not occur when the `value` is a decimal, as the split function operates correctly. - To resolve this issue, instead of relying on the number of digits after the '.' in the `value`, we set the precision based on what is defined in the 'decimal.precision' model. This approach not only addresses the current issue but also resolves the underlying problem initially discussed in this PR https://github.com/odoo/enterprise/pull/53378 opw-3896929 Forward-Port-Of: odoo/enterprise#67075 Forward-Port-Of: odoo/enterprise#62505
In https://github.com/odoo/odoo/commit/f1749d3299957e2949e0b78653266a5397bb213c, we forgot to prepare a bundle for the dark mode. As a consequence, the grid view does not have the style it should have in dark mode. Here we use the newly introduced bundle 'web.assets_backend_lazy_dark' in https://github.com/odoo/odoo/pull/173620 to fix that and make studio use that bundle too in dark mode. In this forward port we also fix the style of the gantt view in dark mode. Forward-Port-Of: odoo/enterpr
Original PR description
In https://github.com/odoo/odoo/commit/f1749d3299957e2949e0b78653266a5397bb213c, we forgot to prepare a bundle for the dark mode. As a consequence, the grid view does not have the style it should have in dark mode. Here we use the newly introduced bundle 'web.assets_backend_lazy_dark' in https://github.com/odoo/odoo/pull/173620 to fix that and make studio use that bundle too in dark mode. In this forward port we also fix the style of the gantt view in dark mode. Forward-Port-Of: odoo/enterprise#66908
Community: https://github.com/odoo/odoo/pull/172269 Upgrade: https://github.com/odoo/upgrade/pull/6227 Task-4014022
Original PR description
Community: https://github.com/odoo/odoo/pull/172269 Upgrade: https://github.com/odoo/upgrade/pull/6227 Task-4014022
This PR fixes a test that was relying on the user being in a certain timezone. This timezone is now set before the test. Task-4038158 Forward-Port-Of: odoo/enterprise#66889
Original PR description
This PR fixes a test that was relying on the user being in a certain timezone. This timezone is now set before the test. Task-4038158 Forward-Port-Of: odoo/enterprise#66889
Update legacy tests importing mail/test_utils.js to use HOOT instead of Qunit. Task-3818666 Forward-Port-Of: odoo/enterprise#66751
Original PR description
Update legacy tests importing mail/test_utils.js to use HOOT instead of Qunit. Task-3818666 Forward-Port-Of: odoo/enterprise#66751
Previously, we added support for self-withholding taxes, which do not need to be reported in the XML file. Hence, tax lines that contain a tax with a code ZZ (for customer invoices)/ ZZ, 07 (for vendor bills) are filtered out. However, when we compute the total amounts these are not filtered out, leading to a discrepancy in sums. We should filter out such tax lines when computing totals as well. See other commit: https://github.com/odoo/enterprise/commit/af8f364cc1f09cc1f9159b326a7f59
Original PR description
Previously, we added support for self-withholding taxes, which do not need to be reported in the XML file. Hence, tax lines that contain a tax with a code ZZ (for customer invoices)/ ZZ, 07 (for vendor bills) are filtered out. However, when we compute the total amounts these are not filtered out, leading to a discrepancy in sums. We should filter out such tax lines when computing totals as well. See other commit: https://github.com/odoo/enterprise/commit/af8f364cc1f09cc1f9159b326a7f59c6524380be opw-3958518 Forward-Port-Of: odoo/enterprise#67100 Forward-Port-Of: odoo/enterprise#66918
Steps to reproduce: - Projects > Field Service > New - Pick a customer but no assignee - Products > Add any product - Back to task > Sale order > Other info tab What happens: No salesperson is set. Expected behavior: salesperson is the first assignee on the task if any, current user if not (first assignee as in the first listed on the task, which sorts them alphabetically). opw-4026074 opw-4015184 (duplicate) Forward-Port-Of: odoo/enterprise#67184 Forward-Port-Of: odoo/enterprise#6
Original PR description
Steps to reproduce: - Projects > Field Service > New - Pick a customer but no assignee - Products > Add any product - Back to task > Sale order > Other info tab What happens: No salesperson is set. Expected behavior: salesperson is the first assignee on the task if any, current user if not (first assignee as in the first listed on the task, which sorts them alphabetically). opw-4026074 opw-4015184 (duplicate) Forward-Port-Of: odoo/enterprise#67184 Forward-Port-Of: odoo/enterprise#66404
Before, when the subscription cron create recurring invoices, it might create a credit note in case some already invoiced non recurring product had his ordered quantity set back to zero. The payment transaction created for this credit note will take the absolute total without taking into account the type of the entry process. This leads to a transaction charging the amount to the client instead of refunding him. As we don't want to allow automatic refund because it could lead to catastrophe
Original PR description
Before, when the subscription cron create recurring invoices, it might create a credit note in case some already invoiced non recurring product had his ordered quantity set back to zero. The payment transaction created for this credit note will take the absolute total without taking into account the type of the entry process. This leads to a transaction charging the amount to the client instead of refunding him. As we don't want to allow automatic refund because it could lead to catastrophe if a bug occurs, we decide to prevent the payment request if the amount is negative. In that case, we keep the draft invoice and keep the "payment_exception" flag to avoid running the subscription invoice cron again on that contract. opw-3874964 Forward-Port-Of: odoo/enterprise#67103 Forward-Port-Of: odoo/enterprise#64098
Step to reproduce: 1. Install Accounting and l10n_dk 2. View the balance sheet in comparison to last year and check the current profit & loss 3. create a bill reversal for 2023 and confirm it 4. View the balance sheet and observe how the 2024 adds the 2023 total into its total Expected behavior: The PnL from the previous year should not be added to the total of that report line. Solution: Add the missing `date_scope` field on the formula to make sure it only considers the PnL f
Original PR description
Step to reproduce: 1. Install Accounting and l10n_dk 2. View the balance sheet in comparison to last year and check the current profit & loss 3. create a bill reversal for 2023 and confirm it 4. View the balance sheet and observe how the 2024 adds the 2023 total into its total Expected behavior: The PnL from the previous year should not be added to the total of that report line. Solution: Add the missing `date_scope` field on the formula to make sure it only considers the PnL from the start of the fiscal year, therefore getting the current year's PnL opw-3957488 Forward-Port-Of: odoo/enterprise#66883
Before this commit: For multi-label shipment tracking references are stored in field carrier_tracking_ref as "1Zxxxxxxxxxxxxxxxx+1Zxxxxxxxxxxxxxxxx+..." When cancelling the shipment, the ShipmentIdentificationNumber is the tracking reference of first package. carrier_tracking_ref is being sent as ShipmentIdentificationNumber with all the tracking references. resulting in error 'Shipment not found'. After this commit: Only the tracking reference for the first package is sent as
Original PR description
Before this commit: For multi-label shipment tracking references are stored in field carrier_tracking_ref as "1Zxxxxxxxxxxxxxxxx+1Zxxxxxxxxxxxxxxxx+..." When cancelling the shipment, the ShipmentIdentificationNumber is the tracking reference of first package. carrier_tracking_ref is being sent as ShipmentIdentificationNumber with all the tracking references. resulting in error 'Shipment not found'. After this commit: Only the tracking reference for the first package is sent as ShipmentIdentificationNumber in cancel request. Reference ups documentation: https://developer.ups.com/api/reference?loc=en_US#operation/Shipment Methods > Shipment Methods > Void Shipment opw-3974794 Forward-Port-Of: odoo/enterprise#67158
This traceback occurs when the user changes the `resource` of an existing The `planning slots` record has a `repeat` enabled. To reproduce this issue: 1) Install `planning_contract` 2) Open the planning module in `year` mode 3) Change the `resource` of any existing slot with `repeat` enabled record 4) Now run the corn job (`generate next recurring shifts`) to produce the issue for instance Error:- ``` ValueError: Expected singleton: hr.employee(2, 8) File "odoo/tools/safe
Original PR description
This traceback occurs when the user changes the `resource` of an existing The `planning slots` record has a `repeat` enabled. To reproduce this issue: 1) Install `planning_contract` 2) Open the…
This traceback occurs when the user changes the `resource` of an existing
The `planning slots` record has a `repeat` enabled.
To reproduce this issue:
1) Install `planning_contract`
2) Open the planning module in `year` mode
3) Change the `resource` of any existing slot with `repeat` enabled record
4) Now run the corn job (`generate next recurring shifts`)
to produce the issue for instance
Error:-
```
ValueError: Expected singleton: hr.employee(2, 8)
File "odoo/tools/safe_eval.py", line 390, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "ir.actions.server(344,)", line 1, in <module>
File "home/odoo/src/enterprise/saas-17.2/planning/models/planning_recurrency.py", line 71, in _cron_schedule_next
recurrencies._repeat_slot(now + delta)
File "home/odoo/src/enterprise/saas-17.2/planning/models/planning_recurrency.py", line 89, in _repeat_slot
misc_recurrence_stop = recurrency._get_misc_recurrence_stop()
File "home/odoo/src/enterprise/saas-17.2/planning_contract/models/planning_recurrency.py", line 15, in _get_misc_recurrence_stop
('employee_id', '=', self.slot_ids.resource_id.employee_id.id),
File "odoo/fields.py", line 5183, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: <class 'ValueError'>: "Expected singleton: hr.employee(2, 8)" while evaluating
'model._cron_schedule_next()'
File "odoo/addons/base/models/ir_cron.py", line 388, in _callback
self.env['ir.actions.server'].browse(server_action_id).run()
File "home/odoo/src/custom/trial/saas_trial/models/sentry.py", line 33, in run
res = super().run()
File "odoo/addons/base/models/ir_actions.py", line 971, in run
res = runner(run_self, eval_context=eval_context)
File "odoo/addons/base/models/ir_actions.py", line 801, in _run_action_code_multi
safe_eval(self.code.strip(), eval_context, mode="exec", nocopy=True, filename=str(self)) # nocopy allows to return 'action'
File "odoo/tools/safe_eval.py", line 404, in safe_eval
raise ValueError('%s: "%s" while evaluating\n%r' % (ustr(type(e)), ustr(e), expr))
```
When the user changes the slot resource, the corn job runs based on recurrence.
Each recurrence may have multiple recordsets of slots which might have multiple resources.
But in the commit[1] a search query was used in which `id` is used instead of ids.
which leads to the traceback from [2].
Commit[1]: https://github.com/odoo/enterprise/pull/64845/commits/ff4cb88199349ac7507f7e526aeb3ed21c114c96
[2]
https://github.com/odoo/enterprise/blob/40711df5a635a9d2fd690ca53b271f0e7890cdb6/planning_contract/models/planning_recurrency.py#L15
After applying this commit, it will resolve this issue by using ids instead of id
sentry-5608817801
Forward-Port-Of: odoo/enterprise#66812Steps to reproduce: - Start the tour and continue till the worksheet step - Click on worksheet stat button in the tour - Click on the worksheet name field Issue: - The tour continues. - An input fields needs to be inputted with something before moving on. Reason: - Incorrect configuration of trigger for this step Fix: - Re-target the trigger on input field and fix the run function task-3709542 Forward-Port-Of: odoo/enterprise#67059 Forward-Port-Of: odoo/enterprise#649
Original PR description
Steps to reproduce: - Start the tour and continue till the worksheet step - Click on worksheet stat button in the tour - Click on the worksheet name field Issue: - The tour continues. - An input fields needs to be inputted with something before moving on. Reason: - Incorrect configuration of trigger for this step Fix: - Re-target the trigger on input field and fix the run function task-3709542 Forward-Port-Of: odoo/enterprise#67059 Forward-Port-Of: odoo/enterprise#64956
The button is misaligned in the modal of the planning slot's portal view. This PR will realign it correctly. task-3943384 Forward-Port-Of: odoo/enterprise#63592
Original PR description
The button is misaligned in the modal of the planning slot's portal view. This PR will realign it correctly. task-3943384 Forward-Port-Of: odoo/enterprise#63592
Before this commit: The budget's committed and achieved calculations considered all categories of analytic lines, leading to incorrect calculations of the budget line's committed and achieved amounts. After this commit: - If the budget type is `expense` it will consider only analytic lines with the category vendor_bill. - If the budget type is `revenue` it will consider only analytic lines with the category invoice. - If the budget type is `both` it will consider analytic lines with b
Original PR description
Before this commit: The budget's committed and achieved calculations considered all categories of analytic lines, leading to incorrect calculations of the budget line's committed and achieved amounts. After this commit: - If the budget type is `expense` it will consider only analytic lines with the category vendor_bill. - If the budget type is `revenue` it will consider only analytic lines with the category invoice. - If the budget type is `both` it will consider analytic lines with both categories. Expected result: - Purchase order lines should not be considered in case of revenue budget. - In expense budget, income should not affect this budget at all. - In revenue budget, expense should not affect this budget at all. - In both budget, income and expense both should affect this budget. Task - 4002306 Forward-Port-Of: odoo/enterprise#65205