Navigate
Branch
Monday, March 11, 2024
66 changes
13 changes
Resolved issues and error corrections
A bug preventing the partner autocomplete from appearing during invoice creation has been fixed. This update ensures users can quickly and easily find and select partners when entering invoice data, improving efficiency. The fix addresses a change in how new invoices are created.
Original PR description
Steps to reproduce: [account, iap credit] - create a new invoice - start to write "test" for the partner Issue: The partner autocomplete is not displayed Cause: in https://github.com/odoo/odoo/pull/150106 we add a condition for the quickCreate bypassing the possibility of having createEdit set to true opw-3698400 Forward-Port-Of: odoo/odoo#154771 Forward-Port-Of: odoo/odoo#153608
This update addresses a warning that appears when modules incorrectly configure post-load methods. The change ensures that post-load methods are handled consistently, preventing potential issues during module loading and testing. This improves the stability and reliability of Odoo.
Original PR description
-Step to reproduce: add a post_load method in the init of any module, specify in the manifest like : 'post_load': 'post_load'. Run test_manifests of the test_lint module and we will get warning 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#156347 Forward-Port-Of: odoo/odoo#154316
This update fixes an issue where exchange rate differences were being incorrectly recorded as journal entries, leading to reconciliation problems. The change ensures that exchange rate differences are handled correctly, preventing duplicate AML creation and improving the accuracy of financial reporting. It adjusts the currency of exchange difference AMLs to zero, aligning with best practices.
Original PR description
When mixing anglo-saxon accounting and multi-currency, it sometimes leads to incorrect AMLs in the stock-in account To reproduce the issue: (Company in USD) 1. Setup some currency rates: - Yesterday:…
When mixing anglo-saxon accounting and multi-currency, it sometimes leads to incorrect AMLs in the stock-in account To reproduce the issue: (Company in USD) 1. Setup some currency rates: - Yesterday: 1000 EUR = 4335.1 USD - Today: 1000 EUR = 4348.0 USD 2. Create an auto-avco product 3. (Yesterday) Buy one product at 1000 EUR and receive it 4. Deliver the product 5. Bill the PO 6. Open the journal items of stock-in account Error: The AML for the exchange difference has been created twice When posting the bill, it leads to `_generate_price_difference_vals` where we generate AML/SVL in case of price differences. There, we also generate such records in case of exchange difference. This is what we do in the above use case. However, the AML is wrongly encoded, we need to respect some specific conditions: https://github.com/odoo/odoo/blob/d780a2fc73259244411329027349fad1cb353f34/addons/account/models/account_move_line.py#L1773-L1779 Otherwise, the reconciliation process won't work correctly and will generate its own AMLs for the exchange difference (hence the above error). On top of that, to ensure a full reconciliation, we need to first reconcile the exchange diff AML with the bill one. This is what we are supposed to do in `/stock_account`: we split all stock-in AMLs into three recordsets: `correction_amls`, `invoice_aml`, `stock_aml`. However, we don't correctly isolate the correction AMLs. Therefore, we try to reconcile all AMLs at once, which will not work. Note: This commit brings a behaviour change since the amount currency of exch-diff AML will now be zero, as it should (again, see the comment of the code quoted above in the reconciliation process). This also explains why this commit modifies an existing test: comparing the `balance` and the `amount_currency` of such AML is incorrect. OPW-3544318 Forward-Port-Of: odoo/odoo#156951 Forward-Port-Of: odoo/odoo#155421
This update allows users to select a temporary account when creating a branch company within Point of Sale. Previously, this setting was unavailable, leading to inconsistencies in accounting. Now, branch companies can be properly configured for accurate financial reporting.
Original PR description
**Before this PR:** When the user creates a branch company, the pos(accounting) setting does not allow the selection of a default temporary account for the user. **After this PR:** The user is allowed to choose a temporary account from the branch company. **Task**-3775873 Forward-Port-Of: odoo/odoo#156478
This update enhances the accuracy of location data recorded during employee attendance. Previously, location information was limited, now it provides a more precise record of where employees are working, improving attendance tracking and reporting. This change ensures better data for payroll and operational insights.
Original PR description
task-3764355 Forward-Port-Of: odoo/odoo#155159
This update fixes an issue where the order confirmation page and preparation display weren't activated when orders had a zero total amount. Now, the confirmation page and order sending process are consistently triggered upon order confirmation, regardless of the order total.
Original PR description
The confirmation page wasn't displayed and the order wasn't sent to the preparation display when confirming an order with a total of 0. Now the confirmation page is displayed and the order is send to the preparation display when the order is confirmed regardless of the total amount. Forward-Port-Of: odoo/odoo#157028
This update fixes an issue where invoices received into Odoo with an empty MISC journal would incorrectly assign a sequence number, regardless of the invoice type. The fix ensures the sequence is recalculated when the move's type is set, guaranteeing accurate VAT processing for Italian businesses. This improves the reliability of financial data.
Original PR description
Currently, if you have an empty MISC journal and receive a document, that document will be assigned a MISC sequence, regardless of the actual document's type. ### Cause When a document is received, it is processed in two steps: 1. An empty account move is created and linked with the document. 2. The newly created move is populated with data extracted from the document. At stage 1, when the move is created, it is temporarily placed in the MISC journal. In the event that this journal is empty, a sequence is assigned to the move. Consequently, even if the move's journal is subsequently changed, the sequence remains unaltered. ### Fix Manually recompute the sequence when the move's type is set. opw-3663873 Forward-Port-Of: odoo/odoo#155887
This update resolves an issue where the old job search route (`/jobs`) caused errors due to changes in how search parameters were handled. The fix automatically redirects users to the new route, preserving any search criteria entered to ensure a seamless and accurate job search experience.
Original PR description
__Current behavior before commit:__ `/jobs` routes have been modified in [this commit][1]. Old ones are deprecated but are still working for backward compatibility. When searching on this page,…
__Current behavior before commit:__ `/jobs` routes have been modified in [this commit][1]. Old ones are deprecated but are still working for backward compatibility. When searching on this page, search params are now just added at the end of the URL (instead of being part of the path like before). If the URL of the page is a deprecated one, this can create a conflict with the previous way the params were handled and produce an error. __Description of the fix:__ Redirect the user to the new route any time he tries to reach the deprecated ones. Any parameters included in the old URL will be carried over to the new route to maintain expected behavior. If a parameter is provided both in the path and as a kwarg, the kwarg value will take precedence. __Steps to reproduce the issue on runbot:__ 1. Go to `/jobs/country/20` 2. Make a search using the search bar -> Crash opw-3781374 [1]: https://github.com/odoo/odoo/commit/54f246f9c75b8f1ebdc637c6000f3e4773d702d5 Forward-Port-Of: odoo/odoo#157079 Forward-Port-Of: odoo/odoo#156918
This update resolves an issue where Odoo invoices were failing due to timezone discrepancies between the server and user locations. Specifically, when creating invoices near midnight, a date check triggered an error. The fix ensures the system correctly handles timezones, preventing these errors and improving invoice processing reliability.
Original PR description
When trying to process invoices at a time close to Midnight, and the user is using the system from a location different from the hosting location of Odoo, the system tries to check that the date of…
When trying to process invoices at a time close to Midnight, and the user is using the system from a location different from the hosting location of Odoo, the system tries to check that the date of the invoice is the same as the current date of the system. This creates problems when the hosting server's timezone is different than that of the user. For example: If the hosting location is in Middle East (India), and the user is using Odoo from Saudi Arabia, there is a difference of 2.5 hours due to the timezone, so when the system creates the Invoice at 11 PM and tries to check the date, the date of the server is actually 29th of February, 11 PM while the date on the user's machine is 1st of March, 01:30 AM, which triggers a UserError from the _check_move_configuration function. Description of the issue/feature this PR addresses: When trying to process invoices at a time close to Midnight, and the user is using the system from a location different from the hosting location of Odoo, the system tries to check that the date of the invoice is the same as the current date of the system. This creates problems when the hosting server's timezone is different than that of the user. For example: If the hosting location is in Middle East (India), and the user is using Odoo from Saudi Arabia, there is a difference of 2.5 hours due to the timezone, so when the system creates the Invoice at 11 PM and tries to check the date, the date of the server is actually 29th of February, 11 PM while the date on the user's machine is 1st of March, 01:30 AM, which triggers a UserError from the _check_move_configuration function. Current behavior before PR: If user is in Saudi and tries to create an invoice at a time close to Midnight, for example at 11 PM, the system throws an error since the timezone of the server and that of the user using the POS are different. Desired behavior after PR is merged: The system checks the invoice date against `fields.Date.context_today(self)` instead of `date.today()` and successfully processes the invoice. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157048 Forward-Port-Of: odoo/odoo#155824
This update fixes an incorrect translation within the Serbian language version of Odoo. Previously, the 'Specific VAT rate 10%' tax group was translated as an invalid term. Now, it correctly displays as 'Opšta stopa PDV-a 10%', ensuring accurate tax reporting for Serbian users.
Original PR description
Description of the issue/feature this PR addresses: This PR fixes translation of the tax group `Specific VAT rate 10%` Current behavior before PR: When using Serbian language tax group `Specific VAT rate 10%` is translated as `ZALIHE MATERIJALA` which is invalid. Desired behavior after PR is merged: When using Serbian language tax group `Specific VAT rate 10%` will be translated as `Opšta stopa PDV-a 10%` which is correct. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155198
This update fixes an issue where the quantity of components consumed during MO unbuilding was incorrectly displayed. Previously, the system showed the full planned quantity even after consuming a smaller amount. This change ensures that the unbuild process accurately reflects the actual component usage, improving inventory accuracy.
Original PR description
Step: * Create BoM A: product A - qty 1, bom line: product = Component X, qty = 20 * Create MO with Bom A and produced_qty = 1: + on components: To Consume = 20, Consumed = 15 + Unbuild MO, check Unbuild, check Product Moves of Unbuild, check line product Component X has Quantity = 20, in fact quantity must = 15 **I consumed a smaller quantity of components than planned, but when I unbuild MO, move lines of unbuild has quantity done = quantity planned, not the actual quantity consumption. I think this is a bug** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156952 Forward-Port-Of: odoo/odoo#152805
A recent update to asset depreciation calculations caused a sorting issue when viewing asset entries. This was triggered by modifying the dates of asset entries, specifically when using new entry IDs. This fix ensures that asset entries are correctly sorted regardless of their creation date, preventing incorrect display of depreciation schedules.
Original PR description
To reproduce: - Install account_accountant - Create an asset (monthly for example) - Compute Depreciation - Modify the date of the first entry to 2 months later - Modify the date of the second entry to 1 month later (so same month) => Traceback The problem is that sorted does not work with ids of NewId. We should look at its _origin. There is a PR that would try to fix it in general, but it's in master (and is not sure to be merged https://github.com/odoo/odoo/pull/155850) The problem only began to occur in 17.0 because of the changes of the onchange function. opw-3759153 (in chatter) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156874
This update adds logging for when cron jobs are run manually through the Odoo interface. Previously, these manual runs weren't tracked, leading to confusion when issues like duplicate emails occurred. By logging these actions, our support team can better diagnose and resolve problems related to concurrent cron executions.
Original PR description
The INFO "Starting job x" and "Job x done" logs are only logged for the automatic executing of the cron by the cron worker. When running the cron manually via its form view, no INFO was logged. The technical support is reporting problems where a cron server action is running twice at a same moment leading to problems such as mass-mailing sending emails twice. There is a mutual exclusion mechanism for cron workers but no exclusion mechanism seems in place for http worker vs cron worker. Logging the "run manually" actions will help us figuring out the problems. --- **[[FIX] base: concurrent cron worker and manual run](https://github.com/odoo/odoo/pull/154763/commits/3b74c9af776311e38a1712ab64cb42cd25188db4)** It is possible for a cron to be executed twice at a same moment if the cron is currently being executed by a cron worker and that a user click on the "run manually" button from its form view. Forward-Port-Of: odoo/odoo#156914 Forward-Port-Of: odoo/odoo#154763
16 changes
Enhancements to existing features
This update adapts many Enterprise apps to Odoo's new path-based web navigation. It makes default app pages and internal links work more reliably with the updated web client routing, reducing broken or inconsistent navigation after the platform change.
Original PR description
*: account_consolidation, appointment, approvals, data_merge, documents, documents_spreadsheet, frontdesk, helpdesk, hr_appraisal, hr_payroll, hr_referral, industry_fsm, industry_fsm_sale, iot,…
*: account_consolidation, appointment, approvals, data_merge, documents, documents_spreadsheet, frontdesk, helpdesk, hr_appraisal, hr_payroll, hr_referral, industry_fsm, industry_fsm_sale, iot, knowledge, marketing_automation, marketing_automation_crm, mrp_plm, mrp_workorder, quality_control, quality_mrp_workorder, room, sale_renting, sale_subscription, sign, social, social_youtube, spreadsheet_edition, stock_barcode, timesheet_grid, web_enterprise, web_mobile, web_studio, whatsapp The corresponding community commit overhauls the client-side routing in the web client to use path-based routing. This commit adapts some things in enterprise to benefit from this new feature. Notably it: - adds the "path" field on the default action for most apps - fixes some urls to start with a "/", these relative urls will no longer work since the path can contain more than one segment task-3557575 Co-authored-by: Samuel Degueldre <sad@odoo.com> Community: https://github.com/odoo/odoo/pull/142007
The India payroll payment advice screens have been made easier to use by reorganizing list fields, simplifying the name input, and highlighting the main creation action. This helps payroll users create and review payment advice more quickly and with less confusion.
Original PR description
We have done the following points: ----------------- - Rearrange the fields on the advice list view. - Remove the name title and add a placeholder. - Make the primary advice creation button. task-3679450
This update removes obsolete internal module markers from JavaScript files in accounting-related frontend code and tests. It does not change product behavior, but keeps the codebase cleaner and easier to maintain.
Original PR description
As the /* odoo-module */ statement isn't required anymore in both `static/src` and `static/tests` folders we can remove them.
Users can no longer create new company records directly from selected Planning and Helpdesk screens. This helps prevent accidental or duplicate company setup by requiring company creation through the proper process.
Original PR description
Disable on the fly creation for companies in some views: - `planning.slot.form`: Planning > List View > View Button - `helpdesk.team.form`: Helpdesk > Configuration > Helpdesk Teams > New - `resource.resource.tree`: Planing > Configuration > Materials task-3507965
Room booking notifications now include the specific room they relate to. This prevents booking pages for different rooms opened at the same time from reacting to each other’s updates, reducing inconsistent room booking displays.
Original PR description
Purpose: -------- The bus service uses a single websocket connection that is shared across multiple tabs. Therefore, sending a notification to one tab actually sends it to every tab. Currently, the notification type is the same regardless of which room sends it. Therefore if 2 (or more) different room frontend views are opened at the same time, they will both handle the same notification, even though it was only concerning one of the rooms, leading to inconsistent states. This commit adds the room id in the bus notifications types. This allows for the roomBookingView component to only listen for the notifications intended for its room. Task-3698135
The calendar event form now hides the appointment type field when it is not already set. This encourages users to configure appointment details through the dedicated Appointment Types flow, helping avoid confusing or inconsistent event setup.
Original PR description
While creating a calendar event record, different field duration, reminders, etc are expected to be filled with values **(when we select appointment type in the form view)** same manner as we create appointment type records via the front end. It's more effective to fill such field values directly from the Appointment Types (via the front end). so the appointment_type_id field is hidden when we create a calendar event record via form view. Task-3768152
Resolved issues and error corrections
Restores previously skipped mobile-related test coverage that was accidentally left out after an earlier change. This helps ensure mobile web behavior continues to be checked automatically and reduces the risk of regressions reaching users.
Original PR description
Some class relying on the inherited test side effect where forgotten during #148660 Enabling them again.
Copying a spreadsheet chart now preserves its link to the related Odoo menu. This prevents users from losing navigation context when duplicating charts, making copied spreadsheet content behave as expected.
Original PR description
## Task Description: When copying a chart in a spreadsheet, the link to the Odoo menu is not kept. This PR aims to fix it by taking advantage of the new clipboard refactoring,with a new clipboard handler saving the odooMenuLink in the clipboard data and putting it back in the newly created chart. ## Related Task: - Task: 3380568 - https://github.com/odoo/o-spreadsheet/pull/3670 (need to be merged to have the base class exported)
The Helpdesk website page now shows the "Optimize SEO" option in the Site menu again. This lets website managers adjust search engine settings for helpdesk pages, helping maintain visibility and consistency with earlier versions.
Original PR description
Description of the issue/feature this PR addresses: The "Optimize SEO" is missing in the site menu for the helpdesk page. It should be there (as before the v17) Current behavior before PR: The menu is missing Desired behavior after PR is merged: "Optimize SEO" menu available in the "Site" menu on the Helpdesk page To reproduce: Install website_helpdesk Go to the help page of the website, on the form fixes: opw-3766163
Miscellaneous changes
The button "insert in spreadsheet" added in the pivot view would display a tooltip of "0" when the button was active. The tooltip was only meant to be present when the button was disabled due to the presence of duplicated group bys in the pivot. This revision fixes the tooltip presence on the button and also removes a test that: - had a description that did not match the actual test - was in fact testing the same behaviour as another test -> useless redundancy Task: 3790072 Forward-Port
Original PR description
The button "insert in spreadsheet" added in the pivot view would display a tooltip of "0" when the button was active. The tooltip was only meant to be present when the button was disabled due to the presence of duplicated group bys in the pivot. This revision fixes the tooltip presence on the button and also removes a test that: - had a description that did not match the actual test - was in fact testing the same behaviour as another test -> useless redundancy Task: 3790072 Forward-Port-Of: odoo/enterprise#58323 Forward-Port-Of: odoo/enterprise#58160
…of SEPA Forward-Port-Of: odoo/enterprise#57981
Original PR description
…of SEPA Forward-Port-Of: odoo/enterprise#57981
Purpose: ------- If you open different frontend room booking views using the same browser profile, all rooms will receive and handle all bus notifications, which leads to rooms views showing bookings created for other rooms. This is due to the bus service using a single websocket connection that is shared across the different tabs. A simple workaround to display several frontend rooms views using one device consists in using different browser profiles. This commit adds a warning at the t
Original PR description
Purpose: ------- If you open different frontend room booking views using the same browser profile, all rooms will receive and handle all bus notifications, which leads to rooms views showing bookings created for other rooms. This is due to the bus service using a single websocket connection that is shared across the different tabs. A simple workaround to display several frontend rooms views using one device consists in using different browser profiles. This commit adds a warning at the top of the frontend view when several tabs are detected, that asks the user to close the other tabs . Task-3698135 Forward-Port-Of: odoo/enterprise#55018
Steps to reproduce ================== - Go to the barcode app - Click on "Batch transfers" - Open a record - Add a new product and confirm - Click on the pencil next to the newly added product - Click on the delete button => `Cannot read properties of undefined (reading 'suggested_package')` Cause of the issue ================== When deleting a line, it is removed from the state [0] Solution ======== We simply need to check that the line exists --- [0]: https://gi
Original PR description
Steps to reproduce ================== - Go to the barcode app - Click on "Batch transfers" - Open a record - Add a new product and confirm - Click on the pencil next to the newly added product - Click on the delete button => `Cannot read properties of undefined (reading 'suggested_package')` Cause of the issue ================== When deleting a line, it is removed from the state [0] Solution ======== We simply need to check that the line exists --- [0]: https://github.com/odoo/enterprise/blob/5ef4a85febcde0a690a71cb1886a8a74daf31f47/stock_barcode/static/src/models/barcode_model.js#L390 opw-3688415 Forward-Port-Of: odoo/enterprise#58341 Forward-Port-Of: odoo/enterprise#57691
This commit improves the '_get_social_stream_post' method to make it use a complete domain instead of relying on pathing through the stream, then the account, then the media (= 3 records fetch), to get the media type. This will save a lot of requests as it is a central method used in the controllers of all social media implementations. Forward-Port-Of: odoo/enterprise#58286
Original PR description
This commit improves the '_get_social_stream_post' method to make it use a complete domain instead of relying on pathing through the stream, then the account, then the media (= 3 records fetch), to get the media type. This will save a lot of requests as it is a central method used in the controllers of all social media implementations. Forward-Port-Of: odoo/enterprise#58286
Issue: ------ In the helpdesk application, when a timesheet is added to a helpdesk ticket, it does not have a commercial partner (we can add the field with studio to see this behaviour). There may be one if a commercial partner exists for the helpdesk project. This behaviour is contradictory to that found in project. Solution: --------- Add the `helpdesk_ticket_id` field invisibly in the view so that this field is in the fields to be updated with the onchange. It will be correctly up
Original PR description
Issue: ------ In the helpdesk application, when a timesheet is added to a helpdesk ticket, it does not have a commercial partner (we can add the field with studio to see this behaviour). There may be one if a commercial partner exists for the helpdesk project. This behaviour is contradictory to that found in project. Solution: --------- Add the `helpdesk_ticket_id` field invisibly in the view so that this field is in the fields to be updated with the onchange. It will be correctly updated during the onchange. Override the compute method to obtain the `commercial_partner_id` field in order to take the commercial partner from the helpdesk ticket and not from the task. opw-3759824 Forward-Port-Of: odoo/enterprise#58292 Forward-Port-Of: odoo/enterprise#58043
Currently in Odoo on the Swiss Balance Sheet: 1. Reserven und Jahresgewinn oder Jahresvelust (Main Group) (Reserves and profit or loss for the year) 1.1 Gesetzliche Reserven (Legal Reserves) (2950) 1.1.1 Accounts 2900-2991 What they expect for CH: 1. Reserven und Jahresgewinn oder Jahresvelust (Main Group) (Reserves and profit or loss for the year) 1.1 Gesetzliche Reserven (Legal Reserves) (2950) 1.1.1 Accounts 2900-2991 1.2 Test: Jahresgewinn oder Verlust (Profit or loss for the year (A
Original PR description
Currently in Odoo on the Swiss Balance Sheet: 1. Reserven und Jahresgewinn oder Jahresvelust (Main Group) (Reserves and profit or loss for the year) 1.1 Gesetzliche Reserven (Legal Reserves) (2950) 1.1.1 Accounts 2900-2991 What they expect for CH: 1. Reserven und Jahresgewinn oder Jahresvelust (Main Group) (Reserves and profit or loss for the year) 1.1 Gesetzliche Reserven (Legal Reserves) (2950) 1.1.1 Accounts 2900-2991 1.2 Test: Jahresgewinn oder Verlust (Profit or loss for the year (Annual profit and loss) 1.2.1 Accounts 2992-2999 opw-3668192 Forward-Port-Of: odoo/enterprise#58178
37 changes
Enhancements to existing features
This update improves the clarity and wording of the holiday attestation document in the Belgian payroll module. The changes make the termination holidays report easier to understand for employees and HR staff by refining the language used in the document.
Original PR description
task-3610704
A new warning has been added to the payroll dashboard that alerts users when time off requests are affected by changes to allocation amounts. When an allocation's number of days is modified after time off has been taken against it, the dashboard now displays a warning and provides a convenient link to view all affected leaves grouped by employee.
Original PR description
When a time off for a few days is taken using a certain allocation but then the number of days of the allocation is changed, there should be a warning on the dashboard of payroll to show the leaves affected. The warning redirects the user to a list of leaves concerned and grouped by employees. Task: 3729563
This update improves how error messages are displayed when bank account synchronization encounters issues. Instead of always showing a generic redirect warning that suggests contacting support, the system can now display specific user-friendly error messages when appropriate. This gives users clearer guidance on what went wrong without unnecessary support escalation.
Original PR description
…ct warning * a regular user error can be displayed user-side instead of the redirect warning, in case we don't want to propose to contact the support (in case there's no need) Forward-Port-Of: odoo/enterprise#57090 Forward-Port-Of: odoo/enterprise#56935
This update improves how the social media module retrieves information about social posts, making it significantly faster. Instead of looking up data through multiple linked records, the system now uses a more direct approach, which reduces the number of database queries and improves overall performance for all social media features.
Original PR description
This commit improves the '_get_social_stream_post' method to make it use a complete domain instead of relying on pathing through the stream, then the account, then the media (= 3 records fetch), to get the media type. This will save a lot of requests as it is a central method used in the controllers of all social media implementations. Forward-Port-Of: odoo/enterprise#58286
Resolved issues and error corrections
A warning message now appears when users open multiple room booking views in different browser tabs using the same browser profile. This prevents confusion caused by bookings from other rooms appearing in the wrong view. Users are prompted to close extra tabs or use different browser profiles to view multiple rooms simultaneously.
Original PR description
Purpose: ------- If you open different frontend room booking views using the same browser profile, all rooms will receive and handle all bus notifications, which leads to rooms views showing bookings created for other rooms. This is due to the bus service using a single websocket connection that is shared across the different tabs. A simple workaround to display several frontend rooms views using one device consists in using different browser profiles. This commit adds a warning at the top of the frontend view when several tabs are detected, that asks the user to close the other tabs . Task-3698135
This fix allows Peruvian export invoices to use document type 01, which was previously restricted. The system now correctly recognizes export transactions and permits the appropriate document type selection, ensuring compliance with Peru's electronic invoicing requirements for international sales.
Original PR description
In commit 355250d, the domain was adjusted to automatically select the invoice document type for customers with a RUC and limit others to the "boleta" document type. This generally holds true, except for export invoices requiring the 01 document type. This commit addresses the current restriction, allowing the selection of document type 01 other than "boleta" or "debit note boleta." For this, inherit the compute method, and extend the depends to add the operation type and allow generate invoice for exportation cases. [Odoo PR related](https://github.com/odoo/odoo/pull/154511)
This fix resolves an issue where Peruvian electronic invoices (UBL 2.1) were being rejected during validation due to improper handling of special characters like line breaks and non-breaking spaces in invoice notes. The system now properly formats these characters to comply with Peru's EDI requirements, allowing invoices with multi-line terms and conditions to process successfully.
Original PR description
Steps to reproduce:
- Install Accounting and l10n_pe_edi
- Switch to a Peruvian company (e.g. PE Company)
- Configure Peruvian localization (https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/peru.html)
- Create an invoice:
* Customer: Comercial Constructora los Patitos S.A.
* Operation Type: [0101] Internal sale
* Invoice Lines:
- Product: Arroz descascarillado (arroz cargo o arroz pardo)
- Taxes: 18% - Terms and Conditions: [text containing several consecutive spaces and/or several lines]
- Confirm the invoice
- Process UBL 2.1
Issue:
The service responds with an error because the <cbc:Note> node doesn't comply with the supported format.
Special characters like '\n' and '\u00A0' are not supported.
opw-3744946
Linked community PR: https://github.com/odoo/odoo/pull/155081Fixed an issue where payroll reports would display in English even when employees had no language preference set. The system now correctly uses the database's default language instead of always falling back to English. This ensures payroll documents print in the appropriate language for your organization.
Original PR description
**Current behavior:** If a payslip report is printed for an employee with no set language, it will be printed in English. **Expected behavior:** The primary fallback language should be that of the database before going to the base level default of English. **Steps to reproduce:** 1. Activate spanish and spanish MX languages on the DB, set all users' language to Spanish 2. Deactivate the default English language pack 3. In the Nómina (Payroll) app, go to `Recibos de nómina` -> `Todos los recibos de nómina`, then select any report and click the Imprimir (Print) button 4. Observe some sections are in English **Cause of the issue:** When an employee's language is not set, English is used as a default. **Fix:** Look to use the environment's language if the Employee's is False. Ammended to fix other situations in hr_payroll where an employee language is accessed without using `env.lang` as a primary fallback. opw-3747839
The appointment booking tour feature was not functioning correctly due to recent changes in the mail and appointment systems. This fix restores the tour to work as intended, ensuring customers can properly experience the guided appointment booking process.
Original PR description
**Issue** website_appointment_tour was not working properly because of some changes done in the mail.py and appointment app. **After this PR** Now the appointment tour is working perfectly as expected. Task-3774280
Fixed a crash that occurred when users clicked on scheduling slots in the planning view without demo data installed. The issue happened because the system was trying to reference non-existent role records. The fix ensures the system properly handles sample data by ignoring temporary IDs when demo data is not available.
Original PR description
Steps to reproduce: ------------------- 1. Install sale_planning (without demo data) 2. Create a service product with "Plan Services" activated 3. Create an SO with this product and confirm the SO 4. Click on "To Plan" stat button 5. Click on any pill to create a new slot 6. The traceback occurs The traceback also occurs in the following scenario: ------------------- 1. Install sale_planning (without demo data) 2. Open Planning > Schedule > By Role 3. Click on any pill to create a new slot 4. The traceback occurs Fix: ------------------- When there is no demo data/records, the gantt view uses sample data. In which for instance, the role_id field is randomly generated. So when clicking on the pill to create a new slot with the given role_id, the corresponding 'planning.role' record is not found, resulting in a traceback. To fix that, we check if the sample data is enabled, in which case we ignore the "fake" ids given by the sample records. task-3777485
This fix resolves a problem where temporary comment boxes were not being properly removed when creating comments in the Knowledge panel, which could cause the application to crash or behave unexpectedly. The issue was corrected by ensuring the panel uses the correct function when adding comments, preventing boxes from being mishandled.
Original PR description
This commit fixes an issue with the comments panel when creating comment. When you have the panel opened and you want to create a comment, after logging your message the temporary box is not removed, leading to issues like boxes not being handled or crashes. This is caused because when syncing the handler and the panel when creating the comment, the insertion function was still the one from the handler meaning that the KnowledgeComment was not using the correct function which led to those issues. Now when the panel is adding the comment from the handler we change the function so that it uses the correct one. task-3792116
This update fixes the payroll system to properly track additional fields on employee payslips that were previously not being monitored. By ensuring all relevant payslip data is tracked, the system now provides more complete and accurate payroll records for auditing and compliance purposes.
This fix corrects the Swiss Balance Sheet report structure to properly display account groupings for the 2900-2999 account range. Previously, accounts 2992-2999 were not shown as a separate category under "Profit or loss for the year." The update enables proper grouping so Swiss companies can now see the complete and correctly organized financial structure in their balance sheet reports.
Original PR description
Currently in Odoo on the Swiss Balance Sheet: 1. Reserven und Jahresgewinn oder Jahresvelust (Main Group) (Reserves and profit or loss for the year) 1.1 Gesetzliche Reserven (Legal Reserves) (2950) 1.1.1 Accounts 2900-2991 What they expect for CH: 1. Reserven und Jahresgewinn oder Jahresvelust (Main Group) (Reserves and profit or loss for the year) 1.1 Gesetzliche Reserven (Legal Reserves) (2950) 1.1.1 Accounts 2900-2991 1.2 Test: Jahresgewinn oder Verlust (Profit or loss for the year (Annual profit and loss) 1.2.1 Accounts 2992-2999 opw-3668192 Forward-Port-Of: odoo/enterprise#58178
This fix resolves an issue where users were unable to refund Point of Sale orders in Mexico. The problem occurred because a validation check was running before order items were properly copied to the refund, causing an incorrect error message. Now the validation correctly waits until the refund order contains items before checking.
Original PR description
Current behavior: When trying to refund a pos order you had an error saying you can't refund the order. Steps to reproduce: - Create a pos order - Validate the order - Go in the backend without closing the session - Try to refund the order This was happening because here (https://github.com/odoo/odoo/blob/c1b86a946d74ea6fbd1d1932da5221ec770ed3a8/addons/point_of_sale/models/pos_order.py#L1050) we trigger this constrains (https://github.com/odoo/enterprise/blob/cc86cdefb375c60b0d1f26e747bb5c2bc3b7f9e3/l10n_mx_edi_pos/models/pos_order.py#L269) but at this point in the code the lines aren't copied in the refund order and so it is triggering the error. To fix it we make sure to check that the order contains atleast one order line. opw-3750165
This update standardizes the spacing of alert messages displayed above forms across Odoo, ensuring a consistent visual appearance. Following the recent Milk redesign, all alerts now use the same bottom margin as the status bar, removing previous inconsistencies in how alerts were displayed throughout the system.
Original PR description
Since Milk redesign the margin bottom on the alerts displayed above the sheet in a form view should be mb-2 (equivalent of the margin-bottom of the statusbar). Some alerts across Odoo were still inconsistent. This PR adapts the alerts from enterprise to remove the margin customizations on the impacted alerts. Letting the CSS variable introduced in the community counterpart PR handling the margin. task-3577058 Community PR: https://github.com/odoo/odoo/pull/146196 Forward-Port-Of: odoo/enterprise#58168 Forward-Port-Of: odoo/enterprise#52726
This fix resolves a bug that prevented users from resetting debit or credit values to zero when importing opening balances for accounts. It also enables the creation of opening balances for accounts that use foreign currencies, which was previously not supported.
Original PR description
Allow the user to set back the debit or credit to 0. It's a bug introduced by https://github.com/odoo/odoo/commit/c3793357d823273cb4297b0eb31308ad73a9dff8 Allow to create an opening balance for an account having a foreign currency. opw: 3665557 Forward-Port-Of: odoo/enterprise#58392 Forward-Port-Of: odoo/enterprise#56520
This update fixes a problem with the mobile menu where clicking on links to different sections of the same page (anchor links) was causing unexpected scrolling behavior. Users will now be able to navigate smoothly between different sections on a page using the mobile menu without experiencing erratic scrolling.
Original PR description
This commit addresses the erratic behavior of the mobile menu, specifically when clicking on menu items linked to anchors instead of navigating to different pages. The issue occurs in mobile view and can be reproduced by following these steps: 1. Create a page longer than the height of the screen with 3 blocks. 2. Add 3 links to target different sections on the page. 3. Create 3 menu items linked to the newly created anchors (/#...). 4. Save to apply the modifications. 5. Switch to mobile view. 6. Open the hamburger menu. 7. Click on the first menu item, then the second, then the third, and again on the first one. Upon reproducing these steps, the scrolling event would pass through all the anchors, causing unexpected behavior. This commit introduces fixes to ensure proper navigation when clicking on menu items in mobile view, resolving the described issue. opw-3652930
This fix addresses a restriction in Peru's tax document type selection that was preventing export invoices from using document type 01. Previously, the system only allowed "boleta" document types for certain customers, but export refunds require the 01 document type. This change restores the ability to select document type 01 for export transactions while maintaining the existing rules for other invoice types.
Original PR description
In commit 355250d, the domain was adjusted to automatically select the invoice document type for customers with a RUC and limit others to the "boleta" document type. This generally holds true, except for export invoices requiring the 01 document type. This commit addresses the current restriction, allowing the selection of document type 01 other than "credit note boleta." [Enterprise PR related](https://github.com/odoo/enterprise/pull/56465) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update allows regional localization modules to customize how invoice notes are formatted in electronic documents. Previously, certain special characters in invoice notes could cause issues in specific regions like Peru. Now, localization modules can override the note formatting to ensure compliance with regional requirements.
Original PR description
In UBL 2.0, the Note node can contain the narration field of an invoice. Its content can be some complex HTML. Some localization (e.g. l10n_pe) doesn't support special characters like '\n' or '\u00A0'. This fix allows the localization modules to format the value used by Note node. opw-3744946 Linked enterprise PR: https://github.com/odoo/enterprise/pull/57268 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects an incorrect Serbian translation for the 10% VAT tax rate in Odoo's Serbian localization module. The tax group label is now properly translated to "Opšta stopa PDV-a 10%" instead of the previous invalid translation, ensuring accurate tax documentation and compliance for Serbian users.
Original PR description
Description of the issue/feature this PR addresses: This PR fixes translation of the tax group `Specific VAT rate 10%` Current behavior before PR: When using Serbian language tax group `Specific VAT rate 10%` is translated as `ZALIHE MATERIJALA` which is invalid. Desired behavior after PR is merged: When using Serbian language tax group `Specific VAT rate 10%` will be translated as `Opšta stopa PDV-a 10%` which is correct. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug where free product rewards were not working correctly in Next Order Coupon loyalty programs. Customers can now properly receive free products as rewards when using these coupons, improving the loyalty program functionality and customer experience.
Original PR description
Before this commit, the free product reward feature in a Next Order Coupon program was not functioning as expected. This commit fixes this issue, ensuring that free product rewards are correctly applied in Next Order Coupon programs. opw-3703485 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155400 Forward-Port-Of: odoo/odoo#153268
This fix resolves a validation warning that appears when modules use the post_load hook in their manifest file. The post_load default value is now aligned with other initialization hooks, eliminating false warnings during module testing and ensuring consistent behavior across Odoo versions.
Original PR description
-Step to reproduce: add a post_load method in the init of any module, specify in the manifest like : 'post_load': 'post_load'. Run test_manifests of the test_lint module and we will get warning 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#156347 Forward-Port-Of: odoo/odoo#154316
This fix resolves a crash that occurs when modifying depreciation entry dates for assets in the accounting module. The issue happened when sorting newly created entries, which wasn't properly handled in version 17.0. Users can now successfully adjust depreciation dates without encountering errors.
Original PR description
To reproduce: - Install account_accountant - Create an asset (monthly for example) - Compute Depreciation - Modify the date of the first entry to 2 months later - Modify the date of the second entry to 1 month later (so same month) => Traceback The problem is that sorted does not work with ids of NewId. We should look at its _origin. There is a PR that would try to fix it in general, but it's in master (and is not sure to be merged https://github.com/odoo/odoo/pull/155850) The problem only began to occur in 17.0 because of the changes of the onchange function. opw-3759153 (in chatter) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects a bug in the manufacturing module where unbuilding a production order was using the originally planned component quantities instead of the actual quantities that were consumed. Now when you unbuild a manufacturing order, the system correctly reflects the actual components used rather than the planned amounts, ensuring accurate inventory tracking.
Original PR description
Step: * Create BoM A: product A - qty 1, bom line: product = Component X, qty = 20 * Create MO with Bom A and produced_qty = 1: + on components: To Consume = 20, Consumed = 15 + Unbuild MO, check Unbuild, check Product Moves of Unbuild, check line product Component X has Quantity = 20, in fact quantity must = 15 **I consumed a smaller quantity of components than planned, but when I unbuild MO, move lines of unbuild has quantity done = quantity planned, not the actual quantity consumption. I think this is a bug** Note: A test was added in `17.0` as the issue only appears from this version onwards. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152805
This update ensures consistent spacing for alert messages displayed above form sections across Odoo. The change introduces a unified margin standard (matching the status bar spacing) and removes conflicting spacing rules that were causing visual inconsistencies. This improves the overall appearance and user experience when alerts are shown in forms.
Original PR description
Since Milk redesign the margin bottom on the alerts displayed above the sheet in a form view should be mb-2 (equivalent of the margin-bottom of the statusbar). Some alerts across Odoo were still inconsistent. This PR introduces a custom property `--alert-margin-bottom` which allows the customization of the alert's margin bottom depending on its context. This ensure that an alert rendered in the form view above the form_sheet will receive the appropriate margin as long as there is no utility class or override on the alert with this property, which is why this PR removes the mb-x classes or inner styling on the impacted alerts. task-3577058 Enterprise PR: https://github.com/odoo/enterprise/pull/52726 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156717 Forward-Port-Of: odoo/odoo#146196
This fix corrects an accounting issue where internal transfers between bank accounts were incorrectly reducing the total Bank and Cash Accounts balance in financial reports. When money is transferred from one bank account to another, the combined balance should remain the same, but the system was showing a reduced total. This update ensures accurate financial reporting for cash and bank accounts.
Original PR description
When you have an internal transfer of money, your accounting report Balance Sheet, report line Bank and Cash Accounts will be reduced 30/12 journal end bank A: $100 31/12 internal transfer $10 from bank A to bank B, and 01/12 bank B receive money. Balance Sheet/ report line Bank and Cash Accounts: $90 expec: Balance Sheet/ report line Bank and Cash Accounts: $90 + $10 = $100 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 update enhances the HR Contract module to properly track additional fields on employee contracts. By capturing more field changes, the system now maintains better audit trails and ensures all important contract modifications are recorded for compliance and record-keeping purposes.
Original PR description
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 update ensures that scheduled actions (crons) are properly logged when run manually through the user interface, not just when executed automatically. This helps identify and prevent issues where the same scheduled action runs multiple times simultaneously, such as mass emails being sent twice, by providing better visibility into when and how these actions are executed.
Original PR description
The INFO "Starting job x" and "Job x done" logs are only logged for the automatic executing of the cron by the cron worker. When running the cron manually via its form view, no INFO was logged. The technical support is reporting problems where a cron server action is running twice at a same moment leading to problems such as mass-mailing sending emails twice. There is a mutual exclusion mechanism for cron workers but no exclusion mechanism seems in place for http worker vs cron worker. Logging the "run manually" actions will help us figuring out the problems. --- **[[FIX] base: concurrent cron worker and manual run](https://github.com/odoo/odoo/pull/154763/commits/3b74c9af776311e38a1712ab64cb42cd25188db4)** It is possible for a cron to be executed twice at a same moment if the cron is currently being executed by a cron worker and that a user click on the "run manually" button from its form view. Forward-Port-Of: odoo/odoo#156914 Forward-Port-Of: odoo/odoo#154763
This fix resolves an error that occurred when guest (public) users attempted to make payments through the Xendit payment system after entering their email address. The issue prevented public users from completing donation payments and other transactions, which is now corrected to ensure a smooth payment experience for all users regardless of account status.
Original PR description
When there's a payment that involves public user, an error will occur when they've input the email. An example is as you can see on the task when user wants to send donation as a public user task-3789416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed a bug where saving custom snippets from event pages would preserve hidden branding markers, making the snippets impossible to remove and breaking page content when reused. The fix now cleans these internal markers before saving snippets, ensuring they work properly when added to other pages.
Original PR description
Steps to reproduce the bug: - Go to an event "Introduction" page - Enter edit mode - Click on the pre-existing "Introduction" title (note that it cannot be removed because of the way the page is built, we might want to improve that in master) - Save it as a new custom snippet - Go to your homepage - Drop that new custom snippet that was saved => It cannot be removed, the rest of the content is kinda broken as wells, etc etc. This is because the original branding was saved with the snippet. Indeed the event pages are made in such a way those pre-defined titles are snippets but which are "editable root elements", i.e. elements whose ancestors cannot be edited since themselves or their neighbors contain dynamic elements. opw-3633326 Forward-Port-Of: odoo/odoo#157189 Forward-Port-Of: odoo/odoo#157110
This fix prevents a system error that occurred when users pressed Enter while editing fields in the Accounting reconciliation module. The issue was caused by duplicate update requests being sent simultaneously, which could delete records unexpectedly. The fix ensures only one update is processed per keystroke, making the application more stable and reliable.
Original PR description
Steps to reproduce ================== In 16.4: - Go to Accounting > Reconcile 8 items - Click on the first line on the right - Edit the label and then press Enter - Switch to another line => Odoo…
Steps to reproduce ================== In 16.4: - Go to Accounting > Reconcile 8 items - Click on the first line on the right - Edit the label and then press Enter - Switch to another line => Odoo Server Error Cause of the issue ================== When pressing Enter, two events are triggered: keydown and change. In the useInputField hook, there is a listener for both of those events, and they both end up calling `record.update` with the current value from the input. In the relational model, the update is locked inside a mutex. So the first update (triggered by the keydown) does an onchange. This onchange deletes the current records (Command.CLEAR) and returns new records. Once this is done, the mutex is released. The second update (triggered by the change event) then tries the same update. Since the value was obtained when queuing for the mutex, it uses the old (now deleted) record. Solution ======== If the keydown handler was called and it was dirty at the time, isDirty would be reset to false. So we can simply check if the field is still dirty in the "change" handler. This was initially done in https://github.com/odoo/odoo/pull/154991 but got lost in a conflict resolution. opw-3726818 Forward-Port-Of: odoo/odoo#157105
This fix resolves an issue where users in different timezones from the Odoo server would encounter errors when creating invoices near midnight. The system now correctly checks invoice dates using the user's local timezone instead of the server's timezone, preventing false validation errors for international teams.
Original PR description
When trying to process invoices at a time close to Midnight, and the user is using the system from a location different from the hosting location of Odoo, the system tries to check that the date of…
When trying to process invoices at a time close to Midnight, and the user is using the system from a location different from the hosting location of Odoo, the system tries to check that the date of the invoice is the same as the current date of the system. This creates problems when the hosting server's timezone is different than that of the user. For example: If the hosting location is in Middle East (India), and the user is using Odoo from Saudi Arabia, there is a difference of 2.5 hours due to the timezone, so when the system creates the Invoice at 11 PM and tries to check the date, the date of the server is actually 29th of February, 11 PM while the date on the user's machine is 1st of March, 01:30 AM, which triggers a UserError from the _check_move_configuration function. Description of the issue/feature this PR addresses: When trying to process invoices at a time close to Midnight, and the user is using the system from a location different from the hosting location of Odoo, the system tries to check that the date of the invoice is the same as the current date of the system. This creates problems when the hosting server's timezone is different than that of the user. For example: If the hosting location is in Middle East (India), and the user is using Odoo from Saudi Arabia, there is a difference of 2.5 hours due to the timezone, so when the system creates the Invoice at 11 PM and tries to check the date, the date of the server is actually 29th of February, 11 PM while the date on the user's machine is 1st of March, 01:30 AM, which triggers a UserError from the _check_move_configuration function. Current behavior before PR: If user is in Saudi and tries to create an invoice at a time close to Midnight, for example at 11 PM, the system throws an error since the timezone of the server and that of the user using the POS are different. Desired behavior after PR is merged: The system checks the invoice date against `fields.Date.context_today(self)` instead of `date.today()` and successfully processes the invoice. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157048 Forward-Port-Of: odoo/odoo#155824
This fix resolves an issue where only the first and last links in a list were being colored when applying color formatting to multiple links. The update ensures that when coloring list items, the formatting is properly applied to all links in the list by creating the font element inside each link element, and aligns background colors with font sizes correctly.
Original PR description
Currently, when we color a list of links with more than three items in the list, only the first and last links are colored. Now when the li element is colored in a list, the font element is created inside the link. We also make sure when the font size is defined the font element is created inside so that the background color is aligned with the font size task-3677214 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156932 Forward-Port-Of: odoo/odoo#149056
Fixed an issue where event ticket price ranges displayed in the registration dialog were not respecting the company's tax display settings. Previously, prices would always show without tax even when the system was configured to display prices with tax included. Now the price display correctly follows the configured tax setting, ensuring consistency across the website.
Original PR description
**Current behavior:** When enabling the option which specifies that products should be displayed with their prices including tax, the dialog which appears when a user is buying tickets for an event…
**Current behavior:**
When enabling the option which specifies that products should
be displayed with their prices including tax, the dialog which
appears when a user is buying tickets for an event has a label
at the top of the window which lists the range of prices for
the available tickets. This price range does not include tax
irrespective of the status of the aforementioned option.
**Expected behavior:**
Displayed prices should adhere to the configuration which has
been selected in the db settings.
**Steps to reproduce:**
1. In the Settings app, give the `Display Product Prices`
configuration setting the `Tax Included` selection
2. In the Event app, select an event and give at least one
ticket type a nonzero cost
3. Go to the website, select the event which has the modified
ticket prices, and click the Register button
4. The label atop the dialog window displays pretax prices
**Cause of the issue:**
The database setting does not affect anything in the XML which
is responsible for displaying this price range label.
**Fix:**
Set the all_prices value to be calculated respective to the
account group that indicates their setting about including or
excluding taxes in display prices.
opw-3734299
Forward-Port-Of: odoo/odoo#153619This update fixes translation issues in the Italian stock DDT (Documento di Trasporto) module where legally required labels were not appearing correctly for clients. The fix ensures that the reason field on DDT documents now displays the proper Italian translations that comply with Italian regulations.
Original PR description
Some translations was unusable by the clients, who didn't find the law-required labels on the DDT reason field. Link: https://www.odoo.com/web#model=project.task&id=3604549 opw-3604549 Forward-Port-Of: odoo/odoo#153109
Fixed an issue where clicking on time-off allocations in the time-off analysis report was not opening the allocation record. The fix restores the ability to view allocation details by using an alternative method to identify and retrieve the correct allocation record in the system.
Original PR description
Steps to reproduce: ------------------- - go to time-off analysis (by type); - group by "Requet Type" and use list view; - click on an allocation; Issue: ------ We don't have the record for this allocation. Cause: ------ Commit [^1] removes the `allocation_id` field, so it is no longer possible to retrieve a record from the `hr.leave.allocation` model. Solution: --------- Place the allocation id in the `leave_id` field and use the `leave_type` field to determine the model (`hr.leave` or `hr.leave.allocation`). opw-3748884 [^1]: a1949ca541d760462add25995f139d1fb59f27d8
This fix resolves issues with setting up opening balances for accounts in Odoo. Users can now properly reset debit or credit values to zero, and can create opening balances for accounts that use foreign currencies. This addresses a bug that was preventing proper account initialization.
Original PR description
Allow the user to set back the debit or credit to 0. It's a bug introduced by https://github.com/odoo/odoo/commit/c3793357d823273cb4297b0eb31308ad73a9dff8 Allow to create an opening balance for an account having a foreign currency. opw: 3665557 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157147 Forward-Port-Of: odoo/odoo#148305