Search
Navigate
Branch
Thursday, October 10, 2024
125 changes
19 changes
Resolved issues and error corrections
Kitchen receipts in Point of Sale now show the complete product name, even when the name is very long. This helps kitchen staff clearly identify ordered items and reduces the risk of preparation mistakes.
Original PR description
Product with long names where not shown completely on the kitchen receipt Steps to reproduce: ------------------- * Add a kitchen printer to your PoS setup * Create a product with a really long name * Open PoS and complete an order with the product > Observation: The kithen receipt doesn't show the full name opw-4221336 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an internal web testing utility so it cleans up browser event handlers more reliably. It helps prevent test side effects and improves confidence in web interface quality checks without changing user-facing behavior.
Original PR description
This commit ensures that event listeners are removed using their prototype's `removeEventListener` method, as to ensure that any override will not be called during the cleanup. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The survey live session button styling was adjusted so the next or start button remains visible across different background choices. This helps participants navigate live surveys more reliably and reduces confusion during sessions.
Original PR description
Earlier next button in the live session was not visible for some backgrounds. This pr addresses the issue and adds a separate background color for the start button so it can be compatible with any background. Task-4210804
A broken step in the survey guided tour was corrected after a label change caused the tour to point to the wrong place. This helps keep the survey walkthrough reliable for users and reduces confusion during onboarding or testing.
Original PR description
**Before this commit:** - The existing selector fails due to the change in the the text of the `<a>` tag redirecting us to the survey. ref. to where it was changed--- https://github.com/odoo/odoo/pull/131710/files#diff-134fd6929e7c8db7a39038879bf9a01c9f4525ca8db1475974c74576ffd7e3fb --- **After this commit:** - The new selector ensures we get the tour pointer as desired. Task-**4207478**
Miscellaneous changes
On the purchase invoice form, the Italian localization adds a button that allows sending the tax EDI to the Italian administration. This depends on the field l10n_it_edi_is_self_invoice that is a computed field that will need access to the model account.report.line. In order to reproduce the issue, change the access rights of Marc Demo to Accounting: Billing, go to Accounting > Vendors > Bills and hit New. This commit fixes the issue by adding a sudo at the right place. Source: post-
Original PR description
On the purchase invoice form, the Italian localization adds a button that allows sending the tax EDI to the Italian administration. This depends on the field l10n_it_edi_is_self_invoice that is a computed field that will need access to the model account.report.line. In order to reproduce the issue, change the access rights of Marc Demo to Accounting: Billing, go to Accounting > Vendors > Bills and hit New. This commit fixes the issue by adding a sudo at the right place. Source: post-Odoo.com migration feedback Forward-Port-Of: odoo/odoo#176222
11 changes
Enhancements to existing features
70 changes
Enhancements to existing features
This update tightens the spacing in the inventory overview screens, making dashboard information fit more compactly on the page. It helps users see more stock-related information at once without changing workflows or business logic.
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
Add support for the Peppol PINT ANZ format, which will become active by the end of this year and required during the next one. Task id # 3758343 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177142
Original PR description
Add support for the Peppol PINT ANZ format, which will become active by the end of this year and required during the next one. Task id # 3758343 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177142
Add support for the Peppol PINT SG format, which will become active by the end of this year and required during the next one. Task id # 4122312 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177137
Original PR description
Add support for the Peppol PINT SG format, which will become active by the end of this year and required during the next one. Task id # 4122312 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177137
Currently we always try to add a string informing about the used declaration of intent to the invoice / sale order PDF. I.e. it also happens when no declaration of intent is selected. After this commit the string is only added in case there is actually a declaration of intent selected. opw-4237368 Forward-Port-Of: odoo/odoo#182913
Original PR description
Currently we always try to add a string informing about the used declaration of intent to the invoice / sale order PDF. I.e. it also happens when no declaration of intent is selected. After this commit the string is only added in case there is actually a declaration of intent selected. opw-4237368 Forward-Port-Of: odoo/odoo#182913
This commit fixes an issue that requires a very specific scenario to be reproduced: Go to Settings > Technical > Server Actions Add a Server Action on the "Contact" model with type "Execute Existing Actions" Add a child action on the "Contact" model and set a domain using the "country" field Save the dialog and save the record. Before this commit, it crashed. Indeed, we generated an update command (1) with a virtualId as record id. This happened because of the ReferenceField that was use
Original PR description
This commit fixes an issue that requires a very specific scenario to be reproduced: Go to Settings > Technical > Server Actions Add a Server Action on the "Contact" model with type "Execute Existing…
This commit fixes an issue that requires a very specific scenario to be reproduced: Go to Settings > Technical > Server Actions Add a Server Action on the "Contact" model with type "Execute Existing Actions" Add a child action on the "Contact" model and set a domain using the "country" field Save the dialog and save the record. Before this commit, it crashed. Indeed, we generated an update command (1) with a virtualId as record id. This happened because of the ReferenceField that was used in the dialog. When the record was saved, it was also reloaded (via web_save), and the `update_related_model_id` field was unset (the business logic unsets it, I don't know why). This field being the `modelField` for the reference field (`resource_ref`), the latter was unset by the ReferenceField (via useRecordObserver), which called record.update. This produced an update command on a record that had been saved meanwhile but was still referenced as a new record (hence the virtual_id). This commit fixes the issue by not reloading the record with web_save, as we're closing the dialog anyway, and that record is loaded for the x2many list view anyway. Moreover, we also ensure that if an update occurs on a record that was initially new but that has been saved meanwhile, the command is associated with the correct resId, not the virtualId. Closes #178541 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#182929
Before this commit, a regular expression was restricting the input units to `[A-Za-z%-]` characters. It made sense initially because those units were limited to technical terms with an untranslated name. But this makes "human" units such as "days" not recognized when using languages where the translated name either contains accents, or is not made of latin alphabet letters at all. This commit adapts the regular expression to consider a sequence of non-blank characters as the unit instead.
Original PR description
Before this commit, a regular expression was restricting the input units to `[A-Za-z%-]` characters. It made sense initially because those units were limited to technical terms with an untranslated name. But this makes "human" units such as "days" not recognized when using languages where the translated name either contains accents, or is not made of latin alphabet letters at all. This commit adapts the regular expression to consider a sequence of non-blank characters as the unit instead. Steps to reproduce: - Install Website - Drop a Popup inside the homepage - Switch user to Spanish - Edit the popup => The "Ocultar para" option did not display its value because "días" contains an accent. - Switch user to Japanese - Edit the popup => The "次のものに非表示" option did not display its value because "日" is not an alphabet letter. opw-4200520 Forward-Port-Of: odoo/odoo#182637
Steps to reproduce: - Project > New Task > Set 'Deadline' to today - 'Repeat Every' 1 week Until tomorrow - Save > Change task state to 'Done' A recurring task is created with a deadline beyond the limit date, this can be repeated indefinitely. This happens because we check he limit date against today instead of comparing it to the task deadline. This is most likely an artifact of 85e9290711c5376660941122dffb3b335b223091, where we allowed immediate recurring task creation (Which would have
Original PR description
Steps to reproduce: - Project > New Task > Set 'Deadline' to today - 'Repeat Every' 1 week Until tomorrow - Save > Change task state to 'Done' A recurring task is created with a deadline beyond the limit date, this can be repeated indefinitely. This happens because we check he limit date against today instead of comparing it to the task deadline. This is most likely an artifact of 85e9290711c5376660941122dffb3b335b223091, where we allowed immediate recurring task creation (Which would have previously been handled by the CRON at the appropriate date). opw-4210251 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182365
**Description of the issue/feature this PR addresses:** When all Lunch location records are deleted, the LunchLocation JS component fails to build, raising an error when accessing the Lunch App. **Steps to Reproduce:** - Install the `lunch` module - Go to Lunch > Configuration > Locations - Delete all records - Access the Lunch App again **Traceback:** OwlError ``` Invalid props for component 'AutoComplete': 'value' is not a string ``` This error occurs at [1], where the given p
Original PR description
**Description of the issue/feature this PR addresses:** When all Lunch location records are deleted, the LunchLocation JS component fails to build, raising an error when accessing the Lunch App.…
**Description of the issue/feature this PR addresses:** When all Lunch location records are deleted, the LunchLocation JS component fails to build, raising an error when accessing the Lunch App. **Steps to Reproduce:** - Install the `lunch` module - Go to Lunch > Configuration > Locations - Delete all records - Access the Lunch App again **Traceback:** OwlError ``` Invalid props for component 'AutoComplete': 'value' is not a string ``` This error occurs at [1], where the given props are empty. This commit will resolve the above error by displaying a text message instead of trying to build a `Many2XAutocomplete` with empty values. opw-4104561 [1]- https://github.com/odoo/odoo/blob/503c0d6f8fad09f5de678d8692fc283feac1b061/addons/lunch/static/src/components/lunch_dashboard.xml#L61 **Current behavior before PR:** Without any record in the `lunch.location` model, the Lunch App cannot be accessed **Desired behavior after PR is merged:** Without any record in the `lunch.location` model, the Lunch App can be accessed, but a message "_No lunch locations available._" will be displayed in spite of the location. **Screenshots** Behavior without fix, with locations not yet deleted:  Behavior with fix, with all locations deleted:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182332 Forward-Port-Of: odoo/odoo#176135
Issue: ====== mass mailing iframe size isn't correct. Steps to reproduce the issue: ============================= It doesn't alwyas happen because of race condition, so you may need to try multiple times. - Create a new mass mailing - Add 3 `image-text` snippets - You can't scroll down in the editable area because the size of the iframe is smaller than it's content. Origin of the issue: ==================== The function that resizes the iframe in mass mailing is defined in [
Original PR description
Issue: ====== mass mailing iframe size isn't correct. Steps to reproduce the issue: ============================= It doesn't alwyas happen because of race condition, so you may need to try multiple…
Issue: ====== mass mailing iframe size isn't correct. Steps to reproduce the issue: ============================= It doesn't alwyas happen because of race condition, so you may need to try multiple times. - Create a new mass mailing - Add 3 `image-text` snippets - You can't scroll down in the editable area because the size of the iframe is smaller than it's content. Origin of the issue: ==================== The function that resizes the iframe in mass mailing is defined in [1]. In `onDragStart` in [2] we call `addStyle` on the iframe to make sure it has `pointerEvents:auto` style. Now when the drag ends there are 2 events executing in parallel which are : - `onPointerUp` in [3]: which will call `dragEnd` which itself will call `cleanup` so it will assign the old style attribute to the iframe. - resizing of the iframe from the `_resizeObserver` Now if `_resizeMailingEditorIframe` is called first then it will have the new size and then the cleanup will assign the old style which have the wrong size which makes the editable smaller than its content and we can't scroll down the editable. Solution: ========= We use `addClass` instead of `addStyle`. task-4041275 [1]: https://github.com/odoo/odoo/blob/db29299d91111837d02bc62d573afb915fe673dd/addons/mass_mailing/static/src/js/mailing_mailing_view_form_full_width.js#L19 [2]: https://github.com/odoo/odoo/blob/db29299d91111837d02bc62d573afb915fe673dd/addons/web_editor/static/src/js/editor/drag_and_drop.js#L135 [3]: https://github.com/odoo/odoo/blob/db29299d91111837d02bc62d573afb915fe673dd/addons/web/static/src/core/utils/draggable_hook_builder.js#L752 Forward-Port-Of: odoo/odoo#179605
The issue: While running the test test_multi_edit_start_date_wo, the calendar is set to the Europe/Brussels timezone when demo data is loaded. However, when demo data is not loaded, the calendar defaults to the UTC timezone. The fix: Adapt the timezone runbot-56562 Forward-Port-Of: odoo/odoo#177235
Original PR description
The issue: While running the test test_multi_edit_start_date_wo, the calendar is set to the Europe/Brussels timezone when demo data is loaded. However, when demo data is not loaded, the calendar defaults to the UTC timezone. The fix: Adapt the timezone runbot-56562 Forward-Port-Of: odoo/odoo#177235
Steps to reproduce: - Have a draggable that uses an iframe - The iframe must be offset from the page (0,0) - The draggable must be outside of the iframe - Yank the mouse fast over the iframe, such that the mouse goes over the iframe before the dragged item can catch up. -> the dragged item is offset from the mouse so long as the mouse remains over the iframe. In 17.2 this issue affects the mailing editor inside marketing automation when editing an activity. This is because it does
Original PR description
Steps to reproduce: - Have a draggable that uses an iframe - The iframe must be offset from the page (0,0) - The draggable must be outside of the iframe - Yank the mouse fast over the iframe, such…
Steps to reproduce: - Have a draggable that uses an iframe - The iframe must be offset from the page (0,0) - The draggable must be outside of the iframe - Yank the mouse fast over the iframe, such that the mouse goes over the iframe before the dragged item can catch up. -> the dragged item is offset from the mouse so long as the mouse remains over the iframe. In 17.2 this issue affects the mailing editor inside marketing automation when editing an activity. This is because it does not inherit pe-none in that scenario, unlike inside form views. Drag and drop relies on `clientX` and `clientY` being in the coordinates of the viewport. When entering an iframe, mouse event coordinates (other than screen-based) are given relative to the viewport of the iframe. This means the position of the drag and drop does not match the position of the mouse. This can be fixed by preventing the iframe from becoming the target of the event using style="pointer-event: none;" on the iframe itself. task-4160857 Forward-Port-Of: odoo/odoo#181812
The domain set on the list datasource did not exclude the draft and cancelled invoices as it was for the other datasources. task-3999225 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#182624
Original PR description
The domain set on the list datasource did not exclude the draft and cancelled invoices as it was for the other datasources. task-3999225 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#182624
Steps to reproduce: - Payroll > Configuration > Working Schedules - Edit Monday morning to have shifts as follows -- 8:00-10:00, Overtime Hours type, 0.25 days -- 10:00-12:00, Attendance type, 0.25 days - Employees > Any with that schedule > Time Off - Take a day off on a Monday (Full day) - Time Off app > Management > Time Off - Try to validate this time off An error occurs when trying to read the morning's work entry type because both shifts have been merged (and thus the resulting s
Original PR description
Steps to reproduce: - Payroll > Configuration > Working Schedules - Edit Monday morning to have shifts as follows -- 8:00-10:00, Overtime Hours type, 0.25 days -- 10:00-12:00, Attendance type, 0.25…
Steps to reproduce: - Payroll > Configuration > Working Schedules - Edit Monday morning to have shifts as follows -- 8:00-10:00, Overtime Hours type, 0.25 days -- 10:00-12:00, Attendance type, 0.25 days - Employees > Any with that schedule > Time Off - Take a day off on a Monday (Full day) - Time Off app > Management > Time Off - Try to validate this time off An error occurs when trying to read the morning's work entry type because both shifts have been merged (and thus the resulting shift has 2 entry types). This happens because of the use of Intervals in resource_calendar's '_attendance_intervals_batch' method. When dealing with attendances we prefer using WorkIntervals which, unlike Intervals, keeps adjacent shifts separate. This is necessary to properly handle the entry type of leaves and attendances over contiguous periods. This also removes the need for fdd9247cb86a01cc8c0903e69b85aae311e7c1ad, as the attendances have already been separated (Shifts cannot overlap any more than at their bounds) according to their type. opw-4193334 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182574
The aim of this commit is to prevent test from failing when the error is coming from a missing CoA. We used this opportunity to add a docstring and a new assert. task-id: None Runbot-build-error: 100531 Forward-Port-Of: odoo/odoo#182571
Original PR description
The aim of this commit is to prevent test from failing when the error is coming from a missing CoA. We used this opportunity to add a docstring and a new assert. task-id: None Runbot-build-error: 100531 Forward-Port-Of: odoo/odoo#182571
The error occurred when the user was going to check in but didn't find any employee. Steps to reproduce: - Install ``hr_attendance`` module(without demo) - Employees > click on employee and remove ``Related User`` in ``HR Settings`` - Click on the ``systray`` button and ``Check-in`` Traceback: ``Expected singleton: hr.employee()`` The error occurred at [1] because we couldn't find an employee. This commit resolves the above error by disabling the button if there is no employee.
Original PR description
The error occurred when the user was going to check in but didn't find any employee. Steps to reproduce: - Install ``hr_attendance`` module(without demo) - Employees > click on employee and remove ``Related User`` in ``HR Settings`` - Click on the ``systray`` button and ``Check-in`` Traceback: ``Expected singleton: hr.employee()`` The error occurred at [1] because we couldn't find an employee. This commit resolves the above error by disabling the button if there is no employee. [1]- https://github.com/odoo/odoo/blob/b05e203aa8f6956d5bc6606d7df53d74442d727a/addons/hr_attendance/controllers/main.py#L164 sentry-5616192792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173829
This update standardizes the JavaScript code style across barcode-related inventory, manufacturing, batch picking, subcontracting, lookup, quality control, and expiry modules. It is an internal maintenance change that should make future development and reviews easier without changing day-to-day user workflows.
Original PR description
*: stock_barcode_mrp, stock_barcode_mrp_subcontracting, stock_barcode_picking_batch, stock_barcode_barcodelookup, stock_barcode_quality_control, stock_barcode_quality_control_picking_batch, stock_barcode_quality_mrp Following the community PR odoo/odoo#182955 , made all needed changes to follow eslint rules.
Several Odoo apps were updated to stop using an outdated window-opening option. Users should see the same practical behavior, while the system stays aligned with the latest platform standard.
Original PR description
In https://github.com/odoo/odoo/pull/182800, the selection value "inline" for the field "target" of "ir.actions.act_window" has been removed. Here we remove that value in some actions that used it. The default target "current" will be used for those actions with a similar result. Task ID: 3245566
Planning screens now use a direct user check to decide when certain buttons or elements should be shown. This simplifies the underlying setup without changing the intended user experience, making the feature easier to maintain.
Original PR description
Previous Implementation: The is_assigned_to_me field was initially created to control the visibility of certain elements (mostly buttons) in planning slot views, using it within the invisible domain. Refactor: This commit replaces the usage of the is_assigned_to_me field with a condition that directly compares user_id with uid. This change streamlines the logic for making elements invisible. task : 4073484
Project managers can now see the critical path directly in the Gantt view, highlighting the sequence of dependent tasks that must stay on schedule. This helps teams focus attention on the work that most affects the overall project deadline.
Original PR description
Purpose ======= The critical path shows those tasks that must be completed on time. It is the longest chain of tasks between the start and end dates of your project that cannot be compromised. It helps to know what sequence of tasks requires special attention, and how much it takes to complete your project on time. Implementation ============== The critical path is the longest path of dependent tasks of a given project. This commit introduces: - Backend methods to get the critical path of a group of tasks (based on a domain) - Frontend methods to display the critical path of a project in the Gantt view - Testing for those methods task-3391988
Resolved issues and error corrections
This fix ensures the holiday planning Gantt view has its required dependency available during testing and use. It prevents dependency errors caused by delayed loading, making the related planning functionality more reliable.
Original PR description
**Current behavior before PR:** before this PR dependency error encountered during test execution of planning_holidays it is due to lazy loading of gantt renderer and view. **Desired behavior after PR is merged:** hr_gantt is added into depends now the dependency problem is resolved.
Miscellaneous changes
Some "week" date filters show records of the wrong week if the current day is Monday. This PR fixes them. Task-4219531 Forward-Port-Of: odoo/enterprise#71490 Forward-Port-Of: odoo/enterprise#71044
Original PR description
Some "week" date filters show records of the wrong week if the current day is Monday. This PR fixes them. Task-4219531 Forward-Port-Of: odoo/enterprise#71490 Forward-Port-Of: odoo/enterprise#71044
The gantt view was not supposed to support fields of type 'date' but a view using such fields was introduced in the app "Project" (it is available in the first menu of the app when the option "Project Stages" is enabled). Here we make the gantt view manage correctly the date fields: display, drag and drop, or resize pills should now work as expected. Task ID: 3424435 Forward-Port-Of: odoo/enterprise#71587 Forward-Port-Of: odoo/enterprise#67971
Original PR description
The gantt view was not supposed to support fields of type 'date' but a view using such fields was introduced in the app "Project" (it is available in the first menu of the app when the option "Project Stages" is enabled). Here we make the gantt view manage correctly the date fields: display, drag and drop, or resize pills should now work as expected. Task ID: 3424435 Forward-Port-Of: odoo/enterprise#71587 Forward-Port-Of: odoo/enterprise#67971
Consider an unreconciled bank statement (line) in the bank reconciliation widget. Currently only the liquidity and suspense/transfer line of the associated move are shown. This means that some lines of the move are not shown. After this commit we show all the line (so i.e. the other lines). Since the diff is not the nicest: The commit just removes the outer `if wizard.st_line_id.is_reconciled`. Forward-Port-Of: odoo/enterprise#71592 Forward-Port-Of: odoo/enterprise#71236
Original PR description
Consider an unreconciled bank statement (line) in the bank reconciliation widget. Currently only the liquidity and suspense/transfer line of the associated move are shown. This means that some lines of the move are not shown. After this commit we show all the line (so i.e. the other lines). Since the diff is not the nicest: The commit just removes the outer `if wizard.st_line_id.is_reconciled`. Forward-Port-Of: odoo/enterprise#71592 Forward-Port-Of: odoo/enterprise#71236
**Steps to reproduce:** - Install l10n_au_aba - Switch to an Australian company (e.g. AU Company) - Configure batch payments according to this [documentation](https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/australia.html#aba-files-for-batch-payments) - Create a vendor with a special character in the name (e.g. a curly apostrophe `’`) - Configure a bank account for the vendor - Create a bill for that vendor - Confirm the bill - Register a payment with "A
Original PR description
**Steps to reproduce:** - Install l10n_au_aba - Switch to an Australian company (e.g. AU Company) - Configure batch payments according to this…
**Steps to reproduce:** - Install l10n_au_aba - Switch to an Australian company (e.g. AU Company) - Configure batch payments according to this [documentation](https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/australia.html#aba-files-for-batch-payments) - Create a vendor with a special character in the name (e.g. a curly apostrophe `’`) - Configure a bank account for the vendor - Create a bill for that vendor - Confirm the bill - Register a payment with "ABA Credit Transfer" as payment method - Go to the payments list - Select the created payment and create a batch payment - Validate it - Download the generated ABA file - Try to validate the file on an online [ABA validator](https://www.bcu.com.au/business-banking/payments/internet-banking/aba-file-validator/) **Issue:** The online ABA file validator finds an error because the accepted length for a row is not respected. **Cause:** Each row information is encoded with a specific number of characters where blank characters are added to reach that length. In this case, the name of the account holder is containing a special character that corresponds to 3 characters when converted to utf8 and too many blank characters are added. **Solution:** Compute the length in utf8 before adding the blank characters. opw-4059837 Forward-Port-Of: odoo/enterprise#71590 Forward-Port-Of: odoo/enterprise#71351
Before this PR, overseas transactions with GST were shown in the spreadsheet, but not in GSTR-1. After this PR, overseas transactions with GST will no longer be shown in the spreadsheet. **Technical Reason:-** In the `_get_exp_json` method, we retrieve journal items that meet the exp domain criteria. However, the `tax_details` are linked from `move_id` using `tax_details_by_move`, which applies the hsn domain. Consequently, all journal items are retrieved, necessitating the exclusion of t
Original PR description
Before this PR, overseas transactions with GST were shown in the spreadsheet, but not in GSTR-1. After this PR, overseas transactions with GST will no longer be shown in the spreadsheet. **Technical Reason:-** In the `_get_exp_json` method, we retrieve journal items that meet the exp domain criteria. However, the `tax_details` are linked from `move_id` using `tax_details_by_move`, which applies the hsn domain. Consequently, all journal items are retrieved, necessitating the exclusion of those involving CGST and SGST, as these are not relevant for overseas transactions. **Task**-4008149 Forward-Port-Of: odoo/enterprise#65280
The newly added button shortcut to edit a dashboard would only always open the active dashboard edition and not the one we clicked on. Task-4236307 Forward-Port-Of: odoo/enterprise#71380
Original PR description
The newly added button shortcut to edit a dashboard would only always open the active dashboard edition and not the one we clicked on. Task-4236307 Forward-Port-Of: odoo/enterprise#71380
This change adds a test setting that can introduce a delay during guided test tours, laying the groundwork for detecting inconsistent or unpredictable failures. It helps improve future test reliability, but does not change how business users use Odoo today.
Original PR description
In commit, we add an environment variable to launch a tour in which we will look for undeterministic errors. The environment variable is a delay (in seconds). You can then launch a tour with "check" parameter or set the environment variable ODOO_TOUR_DELAY to search for undeterminisms. The search for the undeterministic error in a tour is not yet implemented. This commit comes before this implementation. But here is how it will work: When the trigger of a step of a tour has been found, we wait this delay and then, we look again for the trigger in the DOM. If the element found is different from the first, then it triggers an error. 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
Resolved issues and error corrections
This fixes internal website test scripts so they continue to work after a recent change removed an older text-matching method. It helps keep automated checks reliable without changing what users see in the product.
Original PR description
This PR replaces the uses of ":text" by ":contains", following the recent changes that removed the ":text" pseudo-class. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The color picker now displays RGBA color values with proper spacing between the blue and alpha values. This small formatting fix makes color information easier for users to read and understand.
Original PR description
Before this commit, the value of the RGBA in the colorpicker display was missing a spacing after the value for blue. This commit add the spacing after this value to make the text more readable by the user. task-4242209
Point of Sale users can once again find products by searching for their internal reference code. This restores expected search behavior from the previous version and helps cashiers locate items faster at checkout.
Original PR description
Problem: In the PoS interface, searching for products using the `default_code` (internal reference) does not return any results, while this functionality was available in version 17.0. Steps to reproduce: - Open PoS. - Attempt to search for any product using its `default_code` (internal reference). - No results are displayed. opw-4232415 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where generated dates could be distributed incorrectly when a very large number of values was requested. The change improves the reliability of Odoo's internal data generation tools, reducing the risk of skewed or missing test data.
Original PR description
Before this commit `total_days/factor` could return 0 because PG truncates integer division. Casting total_days to a float and moving the floor's position fixes this issue, providing a correct date spread for `factors > (MAX_DATETIME-MIN_DATETIME).days` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale payment method settings now clear terminal-specific values when a user switches the integration type away from terminal payments. This prevents hidden or outdated terminal fields from blocking users from saving payment method changes.
Original PR description
[FIX] point_of_sale: ensure values are cleared when switching away from terminal payment method Problem: After a terminal provider is selected in "Integrate with" option, if the user change "Integration" option away from 'Terminal', the fields from terminal are still visible and getting validate. This makes record's changes cannot be saved if the fields are empty. Steps to Reproduce: 1. Install Point of Sale app. 2. Go to Configuration > Settings. Enable any "Payment Terminals". 3. Go to Configuration > Payment Methods. Click new or edit a record. 4. Select a journal 5. Select an "Integration" option "Terminal" 6. Select a terminal in "Integrate with" option 7. Switch an "Integration" option to None 8. Observe that the added fields does not disappear and is still getting validate when you save the record. Move from #182548: renaming branch --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Selected avatar tags now appear in bold within the dropdown list, making current choices clearer at a glance. This small visual fix helps users avoid confusion when reviewing or changing tag selections.
Original PR description
opw-4212924
The project burndown chart was adjusted to avoid an incorrect translation call. This reduces the risk of display or localization issues while keeping the chart behavior unchanged for users.
Original PR description
This PR removes a call to _t with a dynamic argument.
Merging accounts now keeps the translated account names from the accounts being combined. This prevents translated names, such as customer-facing labels in different languages, from being lost during account cleanup.
Original PR description
At the moment, when we merge accounts, we don't merge the account name's translations. This is a bit annoying since one account might have been called 'Account Receivable' in English, and another one might have been called 'Clientes' in Spanish. At the moment, the translations of the other accounts are lost. This commit makes us merge the translations when merging the accounts. taskid: 4210775
Repair order status badges now use distinct colors that better match each order state. This makes it easier for users to quickly identify whether a repair is draft, confirmed, under repair, done, or cancelled in list views.
Original PR description
Before: In list view, repair orders state badge is green when the state is 'done'. Otherwise, it is always blue. After: No change for state 'done'. Badge color is more adapted to other states: - blue remain for 'confirmed' - yellow is used for 'under_repair' - white/black is used for 'draft' - red is used for 'cancel' Task 4237694 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes an automated website event ticket sales test run more reliably by checking page elements sooner and waiting for them in the right order. It helps reduce false test failures without changing the customer-facing ticket purchase experience.
Original PR description
Decrease checkDelay to 100ms instead of 750ms by default. Add intermediate steps to ensure elements are in DOM before to continue the tour. Modify steps that are not logicals. 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 adds country information to HR work entries so country-specific fields and groups display correctly. It helps ensure HR teams see the right payroll or work-entry details based on the employee's country setup.
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
Creating an employee from a candidate with recorded skills no longer triggers an error. This prevents duplicate skill records during employee creation, helping recruiters complete the hiring workflow without interruption.
Original PR description
Steps --- * Create a candidate * Give them a skill * *Create Employee* * => Traceback -> "Two levels for the same skill is not allowed" Cause --- * on `hr.employee.skill` we have a unique constraint on the skill employee pair * but when creating an employee we would attempt to create the skills twice, once through regular create and once from the override of `_update_employee_from_candidate` call in the write
Inventory forecast reports now show formatted help text correctly instead of exposing raw HTML. The Replenishments side panel now starts collapsed, reducing visual clutter and making the screen easier to navigate.
Original PR description
Various v18 bugfixes for MRP before the feature freeze. Current behaviour: 1. HTML help string markup for empty reports don't get parsed in some cases (such as the forecasted inventory report). 2. Replenishments sidepanel is expanded by default. Desired behaviour: 1. HTML help string markup gets parsed for every report view. 2. Replenishments sidepanel is collapsed by default. Task ID: [4154879](https://www.odoo.com/odoo/966/tasks/4154879)
Installing a chart of accounts could fail for companies that already had Point of Sale payment methods. The fix ensures related POS payment records are handled correctly, allowing accounting setup to complete without blocking the user.
Original PR description
When trying to install a CoA on a company that already have pos payment methods the installing would fail because it's trying to delete a journal linked to the payment methods
Steps to reproduce:
-------------------
* Create a new company, do not install CoA
* Create a PoS payment method
* Install any CoA
> Observation: You get an error saying you cannot delete some records
Why the fix:
------------
When we are unlinking account_journal records with this context `{MODULE_UNINSTALL_FLAG: True}` we make sure to also delete the pos_payment_method and pos_payment linked to that journal. This is done here https://github.com/odoo/odoo/blob/854c3b27aa5476c208572f19e64f8f3364bfc381/addons/account/models/chart_template.py#L202
opw-4245944
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes a Time Off issue where accrual plans that grant leave at the start of a period did not immediately credit the current period when an allocation began. Employees can now see and request newly accrued leave correctly, including allocations that started at zero days but have since earned time off.
Original PR description
Steps to reproduce: - Time off > Configuration > Accrual Plan > New - Set 'Accrued Gain Time' to 'At the start' - New Milestone > Set 'Milestone reached' to 0 days after... - Accrue 1 day Monthly on…
Steps to reproduce:
- Time off > Configuration > Accrual Plan > New
- Set 'Accrued Gain Time' to 'At the start'
- New Milestone > Set 'Milestone reached' to 0 days after...
- Accrue 1 day Monthly on the last day of the month > Save
- Management > Allocations > New
- Tick 'Accrual allocation' > Set the 'Accrual Plan' to your newly created plan
- Set the start date to today
- 0 days of allocation for 'Time off type' of your choice > Validate
- My time > Dashboard > Use 'Balance at the mm/dd/yyyy'
The accrual grants 1 day of leave for the upcoming month on the last day of each month, you will however notice that no leave is granted for the current month until we reach its last day. According to the logic of our accrual, 1 leave day should have been granted on the last day of the previous month so we should get our partial credit for the current month immediately instead.
The first step is to simply add the leave days of the corresponding period but this leads to other issues. When computing accruals that are granted at the start of start of the accrual period we use the already_accrued flag to avoid recomputations, but this flag can be raised by a call chain in the write method of hr.leave.allocation starting from _get_consumed_leaves.
This call chain passes through _process_accrual_plans, and invalidates the cache on its way out though _get_future_leaves_on. This notably happens when computing leaves_taken in _process_accrual_plans which can mess with the record's fields, including but not limited to the already_accrued flag which induces errors in the number_of_days we are trying to compute.
Also, the domain we use to restrict the leaves type that can be picked when asking for a leave prevents us from using allocations that start with 0 days. ('max_leaves', '>', 0) rules out these leaves, even after they have accrued enough time off to legitimately request a leave of this type. Disabling max_leaves = 0 does not seem to serve much purpose as a non-accrual leave starting with 0 days should only be able to fulfill the other conditions if it has 'allows_negative', in which case we would want it to show up anyway.
opw-4192703
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes an issue where spreadsheet pivot tables could show a “see records” option for calculated fields when no underlying record existed. The change prevents users from opening an invalid record view and avoids a traceback, making spreadsheet reports more reliable.
Original PR description
Some methods in the pivot_model didn't handle the `NO_RECORD_AT_THIS_POSITION` constant returned by positional pivot formulas. This lead to a `see_record` visible where it shouldn't be, that caused a tracabeck. Task: [4210956](https://www.odoo.com/web#id=4210956&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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 change makes an automated website slides test wait until the page preview is fully ready before checking fullscreen mode. It reduces intermittent test failures, helping keep releases and updates more stable without changing user-facing behavior.
Original PR description
The tour full_screen_web_editor fails at step ":iframe .o_wslides_fs_main" (check we land on the fullscreen view) from time to time on the runbot. We could reproduce the problem locally by setting a timeout on that step below 1400 ms. As this step (like others) is loaded in the WebsitePreview iframe that set the attribute "is-ready" on the iframe node when some assets are loaded (website.assets_all_wysiwyg), we have added a step before, that wait for that (stepUtils.waitIframeIsReady()). With that change, the tour succeeed even if we set a very low timeout on the failing step. So it should solve the problem. Task-4222573
This fixes an issue where visitors booking appointments could be blocked from creating a contact record. Appointment scheduling now works more reliably for public users, reducing failed bookings and support friction.
Original PR description
Due to recent change introduced in 8b9a1a4462453bf64e7bc1307ededd0d127a27fa The customer variable can be non sudo for the public user when only using appointment module. Add a sudo to ensure contact creation. Task-4247116
This fixes an automated test for the Knowledge calendar command so it uses the standard editor tour helper. The change helps keep quality checks stable without changing how users work with Knowledge.
Original PR description
We use tour_helper editor instead of programmatic run().
This update improves manufacturing workflows by making Shop Floor entry behave consistently, showing clear pending status instead of a blank timer, and correcting weekly planning headers when weeks cross month boundaries. These fixes reduce confusion for production teams and make manufacturing planning displays more accurate.
Original PR description
Various v18 bugfixes for MRP before the feature freeze. Current behaviour: 1. Entering the Shop Floor from a WO searches the WOs in that workcenter by state by default. 2. The timer field is blank if the WO is in ready or pending states. 3. The month substring in the weekly MPS display column header shows the month of the starting date if the given period straddles two months. Desired behaviour: 1. Entering the Shop Floor from a WO reflects the same behaviour as entering from MO, which is the suppression of the default filter. (Depends on #68419) 2. 'Pending' text is displayed if the WO is in pending state. 3. It shows the month of the end date instead. Task ID: [4154879](https://www.odoo.com/odoo/966/tasks/4154879)
This fixes an issue where return transfers created from the Barcode app could fail because quantities were left empty. The app now pre-fills return quantities from the original transfer, helping warehouse staff process returns without errors.
Original PR description
Commit odoo/odoo@57b8b2487def4 make the return wizard fill the product quantity to 0 default. This break the return flow in the stock_barcode application as the return picking is created on the fly but empty so an error is raised. To encounter this, returns created via stock_barcode app have their quantities set to the original stock move ones. The return picking is thus fill according to the need.
This update corrects when Group S payroll options are shown for Belgian companies and improves related error handling. It helps payroll users see the right contract and work entry settings while reducing confusing errors.
Original PR description
In this commit, fixes visibility and error handling for belgium companies. task-4213306
This fix corrects a naming error that could cause recruitment document extraction to fail unexpectedly. It helps keep candidate processing stable and adds test coverage to prevent the issue from returning.
Original PR description
* traceback due to typo: applicant_id -> candidate_id task-4207776
The mobile app now handles the first-time permission response more cleanly when using native phone features. This prevents unnecessary startup errors, improving reliability for users opening the app or accessing permission-based features.
Original PR description
In the Native Mobile Apps when we use a Native method that requires a permission the promise is rejected on the first call. This commit avoids to generate `unhandledrejection` in this case.
When a new company is created, custom fields named x_company_id now receive the expected default company value. This keeps records aligned with the correct company and avoids manual setup or inconsistent defaults in Studio-created fields.
Original PR description
Create a field x_company_id on a model. Create a new Company. Before this commit, no ir_default was created for that field, studio only did for x_studio_company_id. After this commit, the fields named x_company_id have an ir_default created when a new company is created. task-4226351
Documentation and clarification updates
This pull request records that contributor mavi-tux has signed Odoo's Contributor License Agreement. It supports legal compliance for accepting their future contributions and has no direct effect on product functionality.
Original PR description
Description of the issue/feature this PR addresses: CLA Signature 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
Miscellaneous changes
The error occurred when the user was going to check in but didn't find any employee. Steps to reproduce: - Install ``hr_attendance`` module(without demo) - Employees > click on employee and remove ``Related User`` in ``HR Settings`` - Click on the ``systray`` button and ``Check-in`` Traceback: ``Expected singleton: hr.employee()`` The error occurred at [1] because we couldn't find an employee. This commit resolves the above error by disabling the button if there is no employee.
Original PR description
The error occurred when the user was going to check in but didn't find any employee. Steps to reproduce: - Install ``hr_attendance`` module(without demo) - Employees > click on employee and remove ``Related User`` in ``HR Settings`` - Click on the ``systray`` button and ``Check-in`` Traceback: ``Expected singleton: hr.employee()`` The error occurred at [1] because we couldn't find an employee. This commit resolves the above error by disabling the button if there is no employee. [1]- https://github.com/odoo/odoo/blob/b05e203aa8f6956d5bc6606d7df53d74442d727a/addons/hr_attendance/controllers/main.py#L164 sentry-5616192792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173829
The aim of this commit is to prevent test from failing when the error is coming from a missing CoA. We used this opportunity to add a docstring and a new assert. task-id: None Runbot-build-error: 100531 Forward-Port-Of: odoo/odoo#182571
Original PR description
The aim of this commit is to prevent test from failing when the error is coming from a missing CoA. We used this opportunity to add a docstring and a new assert. task-id: None Runbot-build-error: 100531 Forward-Port-Of: odoo/odoo#182571
Before this commit, two inheritance of hr.employee.base were done inside the hr_holidays module. This commit merges both inheritance in the hr_employee_base.py file Forward-Port-Of: odoo/odoo#182412 Forward-Port-Of: odoo/odoo#181129
Original PR description
Before this commit, two inheritance of hr.employee.base were done inside the hr_holidays module. This commit merges both inheritance in the hr_employee_base.py file Forward-Port-Of: odoo/odoo#182412 Forward-Port-Of: odoo/odoo#181129
Some "week" date filters show records of the wrong week if the current day is Monday. This PR fixes them. Task-4219531 Forward-Port-Of: odoo/odoo#182084
Original PR description
Some "week" date filters show records of the wrong week if the current day is Monday. This PR fixes them. Task-4219531 Forward-Port-Of: odoo/odoo#182084
In 2022, Republic of Turkey officially renamed itself to Republic of Türkiye. So, its name needed to be changed in its Odoo modules. Moreover, updated Turkish modules descriptions according to this excalidraw: https://link.excalidraw.com/readonly/rbesZEAkXUS8rVgXplgm?darkMode=true task-4182931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182988 Forward-Port-Of: odoo/odoo#180758
Original PR description
In 2022, Republic of Turkey officially renamed itself to Republic of Türkiye. So, its name needed to be changed in its Odoo modules. Moreover, updated Turkish modules descriptions according to this excalidraw: https://link.excalidraw.com/readonly/rbesZEAkXUS8rVgXplgm?darkMode=true task-4182931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182988 Forward-Port-Of: odoo/odoo#180758
Steps to reproduce: - Project > New Task > Set 'Deadline' to today - 'Repeat Every' 1 week Until tomorrow - Save > Change task state to 'Done' A recurring task is created with a deadline beyond the limit date, this can be repeated indefinitely. This happens because we check he limit date against today instead of comparing it to the task deadline. This is most likely an artifact of 85e9290711c5376660941122dffb3b335b223091, where we allowed immediate recurring task creation (Which would have
Original PR description
Steps to reproduce: - Project > New Task > Set 'Deadline' to today - 'Repeat Every' 1 week Until tomorrow - Save > Change task state to 'Done' A recurring task is created with a deadline beyond the limit date, this can be repeated indefinitely. This happens because we check he limit date against today instead of comparing it to the task deadline. This is most likely an artifact of 85e9290711c5376660941122dffb3b335b223091, where we allowed immediate recurring task creation (Which would have previously been handled by the CRON at the appropriate date). opw-4210251 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183054 Forward-Port-Of: odoo/odoo#182365
Problem: When sub-categories are sorted by ID in the PoS app, the order from the server is lost, which disrupts the intended category hierarchy. The expected behavior is that sub-categories appear immediately next to their parent, while preserving the server-defined order for all child categories. Steps to reproduce: - Create PoS categories with multiple levels of sub-categories. - Sort them in the backend list. - The same order should be preserved in the PoS app. opw-4212470 --- I
Original PR description
Problem: When sub-categories are sorted by ID in the PoS app, the order from the server is lost, which disrupts the intended category hierarchy. The expected behavior is that sub-categories appear immediately next to their parent, while preserving the server-defined order for all child categories. Steps to reproduce: - Create PoS categories with multiple levels of sub-categories. - Sort them in the backend list. - The same order should be preserved in the PoS app. opw-4212470 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182268
This commit removes the ":text" pseudo class as it is redundant with ":contains", and is a left-over from the development of Hoot-DOM. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182932
Original PR description
This commit removes the ":text" pseudo class as it is redundant with ":contains", and is a left-over from the development of Hoot-DOM. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182932
[FIX] website: fix Facebook snippet The goal of this commit is to solve three bugs introduced by [1]. The first one can be observed thanks to the `/website/demo/snippets` page: - Go on the `/website/demo/snippets` page. - Try to enter in edit mode. -> The system never enters in edit mode. The problem is that the Facebook snippet on this page does not have the `href` data attribute. Due to it, the public widget is started without creating `this.resizeObserver`. When the user tries
Original PR description
[FIX] website: fix Facebook snippet The goal of this commit is to solve three bugs introduced by [1]. The first one can be observed thanks to the `/website/demo/snippets` page: - Go on the…
[FIX] website: fix Facebook snippet The goal of this commit is to solve three bugs introduced by [1]. The first one can be observed thanks to the `/website/demo/snippets` page: - Go on the `/website/demo/snippets` page. - Try to enter in edit mode. -> The system never enters in edit mode. The problem is that the Facebook snippet on this page does not have the `href` data attribute. Due to it, the public widget is started without creating `this.resizeObserver`. When the user tries to enter in edit mode, the `FacebookPageWidget` public widget is destroyed and the system tries to disconnect `this.resizeObserver`. As it is not defined, the system fails in the `destroy()` method. Steps to reproduce the second bug: - Add an "Image-Text" snippet on the website. - Add a "Text-Image" snippet under the "Image-Text" one. - Save and edit. - Drop a "Facebook" snippet on the "Image-Text" snippet. - Move the "Facebook" snippet on the "Text-Image" snippet. - Click on the undo button. -> Two iframes are on the Facebook snippet. The problem is that since [1], the editor observer is not deactivated when removing the iframe in the `destroy()` method of the `FacebookPageWidget` widget. Finally, this commit also adds back the `frameborder` and `allowTransparency` attributes on the iframe (removed due to [1]) and sets the width and height in the style attribute. Although the `frameborder` and `allowTransparency` attributes are deprecated, this commit adds them back in case a potential customization relies on it. [1]: https://github.com/odoo/odoo/commit/707dd91d1e83342a328e50b5ad38e6ec1064ec25 task-4220972 Forward-Port-Of: odoo/odoo#182899 Forward-Port-Of: odoo/odoo#182134
Before this PR: slides_tour is broken maybe due to some recent changes in tour mechanisms After this PR: Tour is now working properly. Task-4161261 Forward-Port-Of: odoo/odoo#180296
Original PR description
Before this PR: slides_tour is broken maybe due to some recent changes in tour mechanisms After this PR: Tour is now working properly. Task-4161261 Forward-Port-Of: odoo/odoo#180296
When a point of sale has more than one rescue session and the user tries to open the rescue sessions, a traceback will appear. Steps to reproduce the error: - Make 2 or more rescue sessions for one point of sale - Click on the outstanding rescue session Traceback: ``` ValueError: Expected singleton: pos.session(22, 21) File "odoo/http.py", line 2383, in __call__ response = request._serve_db() File "odoo/http.py", line 1913, in _serve_db return self._transactioning(
Original PR description
When a point of sale has more than one rescue session and the user tries to open the rescue sessions, a traceback will appear. Steps to reproduce the error: - Make 2 or more rescue sessions for one…
When a point of sale has more than one rescue session and the user tries to open
the rescue sessions, a traceback will appear.
Steps to reproduce the error:
- Make 2 or more rescue sessions for one point of sale
- Click on the outstanding rescue session
Traceback:
```
ValueError: Expected singleton: pos.session(22, 21)
File "odoo/http.py", line 2383, in __call__
response = request._serve_db()
File "odoo/http.py", line 1913, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1976, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1943, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2187, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 227, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 757, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 40, in call_button
action = call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 459, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/point_of_sale/models/pos_config.py", line 669, in open_opened_rescue_session_form
'res_id': self.session_ids.filtered(lambda s: s.state != 'closed' and s.rescue).id,
File "odoo/fields.py", line 5215, in __get__
raise ValueError("Expected singleton: %s" % record)
```
https://github.com/odoo/odoo/blob/7638f1bdd6be52554ac4266291941ef0953edfd9/addons/point_of_sale/models/pos_config.py#L669
Here, ```session_ids``` have multiple records, so when it tries to access the ```id```,
It will lead to the above traceback.
sentry-5916215733
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#182352This commit fixes an issue that requires a very specific scenario to be reproduced: Go to Settings > Technical > Server Actions Add a Server Action on the "Contact" model with type "Execute Existing Actions" Add a child action on the "Contact" model and set a domain using the "country" field Save the dialog and save the record. Before this commit, it crashed. Indeed, we generated an update command (1) with a virtualId as record id. This happened because of the ReferenceField that was use
Original PR description
This commit fixes an issue that requires a very specific scenario to be reproduced: Go to Settings > Technical > Server Actions Add a Server Action on the "Contact" model with type "Execute Existing…
This commit fixes an issue that requires a very specific scenario to be reproduced: Go to Settings > Technical > Server Actions Add a Server Action on the "Contact" model with type "Execute Existing Actions" Add a child action on the "Contact" model and set a domain using the "country" field Save the dialog and save the record. Before this commit, it crashed. Indeed, we generated an update command (1) with a virtualId as record id. This happened because of the ReferenceField that was used in the dialog. When the record was saved, it was also reloaded (via web_save), and the `update_related_model_id` field was unset (the business logic unsets it, I don't know why). This field being the `modelField` for the reference field (`resource_ref`), the latter was unset by the ReferenceField (via useRecordObserver), which called record.update. This produced an update command on a record that had been saved meanwhile but was still referenced as a new record (hence the virtual_id). This commit fixes the issue by not reloading the record with web_save, as we're closing the dialog anyway, and that record is loaded for the x2many list view anyway. Moreover, we also ensure that if an update occurs on a record that was initially new but that has been saved meanwhile, the command is associated with the correct resId, not the virtualId. Closes #178541 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#183042 Forward-Port-Of: odoo/odoo#182929
**Steps to reproduce:** - Install Invoicing, l10n_eu_oss and l10n_es_edi_tbai - Switch to a Spanish company (e.g. ES Company) - Create an invoice for a Portugese customer: * Customer: [a Portugese customer] * Invoice Lines: [a line with OSS tax "23.0% PT VAT (Goods)"] - Make sure that "Tax Type (Spain)" of the tax is set to "No Sujeto por reglas de Localization" - Confirm the invoice - Process the invoice by E-invoicing service: TicketBAI (ES) - Check the generated EDI document *
Original PR description
**Steps to reproduce:** - Install Invoicing, l10n_eu_oss and l10n_es_edi_tbai - Switch to a Spanish company (e.g. ES Company) - Create an invoice for a Portugese customer: * Customer: [a Portugese customer] * Invoice Lines: [a line with OSS tax "23.0% PT VAT (Goods)"] - Make sure that "Tax Type (Spain)" of the tax is set to "No Sujeto por reglas de Localization" - Confirm the invoice - Process the invoice by E-invoicing service: TicketBAI (ES) - Check the generated EDI document **Issue:** The value of "Causa" in "NoSujeta" section is "RL". It should be "IE" for OSS taxes. opw-4034659 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182730 Forward-Port-Of: odoo/odoo#179289
### Issue: When validating a stock picking created with a sendcloud picking method the partner assocaited with the delivery has no parent_id, so that the code will raise an error the one raised by: https://github.com/odoo/enterprise/blob/070a780db047d849db268a40f1b488dce0a80c6a/delivery_sendcloud/models/sendcloud_service.py#L556-L560 see commit fbeefb5f7d1e429b22d8fd6fc06b7c28b9c236a6 ### Steps to reproduce: - Create a sendcloud delivery method - go to website and order a product, go to
Original PR description
### Issue: When validating a stock picking created with a sendcloud picking method the partner assocaited with the delivery has no parent_id, so that the code will raise an error the one raised by:…
### Issue: When validating a stock picking created with a sendcloud picking method the partner assocaited with the delivery has no parent_id, so that the code will raise an error the one raised by: https://github.com/odoo/enterprise/blob/070a780db047d849db268a40f1b488dce0a80c6a/delivery_sendcloud/models/sendcloud_service.py#L556-L560 see commit fbeefb5f7d1e429b22d8fd6fc06b7c28b9c236a6 ### Steps to reproduce: - Create a sendcloud delivery method - go to website and order a product, go to checkout - pick sendcloud delivery method - select a relay location - go to odoo backend, go the sale order created by the website - click the SO deliveries smart button - Validate the delivery #### > Invalid operation ### Cause of the issue: When the customer checkouts, it confirms the sale order and generate a delivery linked to that SO via the `_action_launch_stock_rule`: https://github.com/odoo/odoo/blob/a91da6a5e835c11f59a4847026ffc79ba97969c5/addons/sale_stock/models/sale_order.py#L153-L155 Later in this confirm, the `partner_shipping_id` of the SO is changed to be associated with a `res.partner` of type `delivery`: https://github.com/odoo/odoo/blob/a91da6a5e835c11f59a4847026ffc79ba97969c5/addons/delivery/models/sale_order.py#L178-L183 but the partner of the picking is not changed accordingly. However, the `delivery_sendcloud` module expects ti receive this delivery partner as a `partner_id` which raises. ### Note: The error is only reproducible after 17.4 even though the only change is that the piece of code creating the partner was moved from `website_sale` to `delivery` by commit 6a28ecf201acaa1e09d3f02184b49f9b3f17486a HOWEVER, this change has a huge impact as it change the inheritance chain of the `sale.order` model: more precisely, the overrides of the `_action_confirm` in which the stock move is created happens before the overrides creating the partner of type delivery while the flow use to be generated in the opposite order so that the picking was created with the updated partner data ! opw-4181787 opw-4188628 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182396
Steps to reproduce: - Have a draggable that uses an iframe - The iframe must be offset from the page (0,0) - The draggable must be outside of the iframe - Yank the mouse fast over the iframe, such that the mouse goes over the iframe before the dragged item can catch up. -> the dragged item is offset from the mouse so long as the mouse remains over the iframe. In 17.2 this issue affects the mailing editor inside marketing automation when editing an activity. This is because it does
Original PR description
Steps to reproduce: - Have a draggable that uses an iframe - The iframe must be offset from the page (0,0) - The draggable must be outside of the iframe - Yank the mouse fast over the iframe, such…
Steps to reproduce: - Have a draggable that uses an iframe - The iframe must be offset from the page (0,0) - The draggable must be outside of the iframe - Yank the mouse fast over the iframe, such that the mouse goes over the iframe before the dragged item can catch up. -> the dragged item is offset from the mouse so long as the mouse remains over the iframe. In 17.2 this issue affects the mailing editor inside marketing automation when editing an activity. This is because it does not inherit pe-none in that scenario, unlike inside form views. Drag and drop relies on `clientX` and `clientY` being in the coordinates of the viewport. When entering an iframe, mouse event coordinates (other than screen-based) are given relative to the viewport of the iframe. This means the position of the drag and drop does not match the position of the mouse. This can be fixed by preventing the iframe from becoming the target of the event using style="pointer-event: none;" on the iframe itself. task-4160857 Forward-Port-Of: odoo/odoo#181812
Commit that introduced the issue https://github.com/odoo/odoo/pull/128108/commits/33a04876cad58f413455bdc406c1ad4c70d73e1b Steps to reproduce the issue: ============================= - Create a new mass mailing - Add cover snippet - Test the email - Background image doesn't appear Origin of the issue: ==================== After the chnage of the mentioned commit, we add a div with a black background filter. It displays correclty in mass_mailing view since it has opacity 0.5 but afte
Original PR description
Commit that introduced the issue https://github.com/odoo/odoo/pull/128108/commits/33a04876cad58f413455bdc406c1ad4c70d73e1b Steps to reproduce the issue: ============================= - Create a new mass mailing - Add cover snippet - Test the email - Background image doesn't appear Origin of the issue: ==================== After the chnage of the mentioned commit, we add a div with a black background filter. It displays correclty in mass_mailing view since it has opacity 0.5 but after the `inline` process of the template we convert rgba colors to hex color with `rgbToHex` because some email engines doesn't support rgba. As a result, we will have a black div that covers the background image in the sent email. Solution: ========= Rever the change. task-4070400 Forward-Port-Of: odoo/odoo#182943 Forward-Port-Of: odoo/odoo#177174
Before https://github.com/odoo/odoo/pull/137691, select a groupby in the dropdown of a pivot header would close the dropdown. Now the dropdown stays open and it is possible to add several row/col groupbys at the same time but the pivot model is not updated correctly because the update of the model is based on the groupId of the header for which the dropdown was opened. The simpler/best solution to that problem is to restore the previous behavior. Task ID: 3985217 Forward-Port-Of: odoo/o
Original PR description
Before https://github.com/odoo/odoo/pull/137691, select a groupby in the dropdown of a pivot header would close the dropdown. Now the dropdown stays open and it is possible to add several row/col groupbys at the same time but the pivot model is not updated correctly because the update of the model is based on the groupId of the header for which the dropdown was opened. The simpler/best solution to that problem is to restore the previous behavior. Task ID: 3985217 Forward-Port-Of: odoo/odoo#182788 Forward-Port-Of: odoo/odoo#182746
**Steps to reproduce:** - Install Accounting - Create an invoice with any product - Go to "Journal Items" tab - Input a label for the payment term line (it should be empty) - Confirm the invoice **Issue:** The input label of the payment term line is replaced by the "Payment Reference" of the invoice. For bills, it is replaced by an empty string as there is no default value for the payment reference. **Solution:** Only use the payment reference of the invoice as label for the paymen
Original PR description
**Steps to reproduce:** - Install Accounting - Create an invoice with any product - Go to "Journal Items" tab - Input a label for the payment term line (it should be empty) - Confirm the invoice **Issue:** The input label of the payment term line is replaced by the "Payment Reference" of the invoice. For bills, it is replaced by an empty string as there is no default value for the payment reference. **Solution:** Only use the payment reference of the invoice as label for the payment term line if it has not been modified manually. This can be done by checking that their values in _origin are similar. opw-4173634 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182722 Forward-Port-Of: odoo/odoo#182136
The issue: While running the test test_multi_edit_start_date_wo, the calendar is set to the Europe/Brussels timezone when demo data is loaded. However, when demo data is not loaded, the calendar defaults to the UTC timezone. The fix: Adapt the timezone runbot-56562 Forward-Port-Of: odoo/odoo#177235
Original PR description
The issue: While running the test test_multi_edit_start_date_wo, the calendar is set to the Europe/Brussels timezone when demo data is loaded. However, when demo data is not loaded, the calendar defaults to the UTC timezone. The fix: Adapt the timezone runbot-56562 Forward-Port-Of: odoo/odoo#177235
Issue: ====== mass mailing iframe size isn't correct. Steps to reproduce the issue: ============================= It doesn't alwyas happen because of race condition, so you may need to try multiple times. - Create a new mass mailing - Add 3 `image-text` snippets - You can't scroll down in the editable area because the size of the iframe is smaller than it's content. Origin of the issue: ==================== The function that resizes the iframe in mass mailing is defined in [
Original PR description
Issue: ====== mass mailing iframe size isn't correct. Steps to reproduce the issue: ============================= It doesn't alwyas happen because of race condition, so you may need to try multiple…
Issue: ====== mass mailing iframe size isn't correct. Steps to reproduce the issue: ============================= It doesn't alwyas happen because of race condition, so you may need to try multiple times. - Create a new mass mailing - Add 3 `image-text` snippets - You can't scroll down in the editable area because the size of the iframe is smaller than it's content. Origin of the issue: ==================== The function that resizes the iframe in mass mailing is defined in [1]. In `onDragStart` in [2] we call `addStyle` on the iframe to make sure it has `pointerEvents:auto` style. Now when the drag ends there are 2 events executing in parallel which are : - `onPointerUp` in [3]: which will call `dragEnd` which itself will call `cleanup` so it will assign the old style attribute to the iframe. - resizing of the iframe from the `_resizeObserver` Now if `_resizeMailingEditorIframe` is called first then it will have the new size and then the cleanup will assign the old style which have the wrong size which makes the editable smaller than its content and we can't scroll down the editable. Solution: ========= We use `addClass` instead of `addStyle`. task-4041275 [1]: https://github.com/odoo/odoo/blob/db29299d91111837d02bc62d573afb915fe673dd/addons/mass_mailing/static/src/js/mailing_mailing_view_form_full_width.js#L19 [2]: https://github.com/odoo/odoo/blob/db29299d91111837d02bc62d573afb915fe673dd/addons/web_editor/static/src/js/editor/drag_and_drop.js#L135 [3]: https://github.com/odoo/odoo/blob/db29299d91111837d02bc62d573afb915fe673dd/addons/web/static/src/core/utils/draggable_hook_builder.js#L752 Forward-Port-Of: odoo/odoo#179605
Steps: - Install the hr_holidays module - Click on the `Pending Requests` from dashboard Description of the issue/feature this PR addresses: In the Time Off module, when clicking on Pending Requests, it opens the allocation with the only second approval filter. Fix: This PR resolves the issue by setting the default search filter to first approval along with second approval. task-4208036 Forward-Port-Of: odoo/odoo#181227
Original PR description
Steps: - Install the hr_holidays module - Click on the `Pending Requests` from dashboard Description of the issue/feature this PR addresses: In the Time Off module, when clicking on Pending Requests, it opens the allocation with the only second approval filter. Fix: This PR resolves the issue by setting the default search filter to first approval along with second approval. task-4208036 Forward-Port-Of: odoo/odoo#181227
On the IoT box, translations are not supported as there is no language context and no po/pot files. However, there were still some usages of the `_` function which will now log a warning in version 18.0+. In this PR we simply remove the usages of `_`, as it was not translating anyway and removes the warnings. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182911 Forward-Port-Of: odoo/odoo#182767
Original PR description
On the IoT box, translations are not supported as there is no language context and no po/pot files. However, there were still some usages of the `_` function which will now log a warning in version 18.0+. In this PR we simply remove the usages of `_`, as it was not translating anyway and removes the warnings. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182911 Forward-Port-Of: odoo/odoo#182767
Steps to reproduce : ==== - Install pos_sale module. - Create a quotation in sales and confirm it. - Open Point of Sale - Open Session and load orders from session. - Select the quotation and do 50% down payment. - Create new order and again load the same quotation. - Due balance remains same. Issue: ==== - Due balance is not updated, everytime it shows total amount. Fix : ==== - Instead of total amount , amount unpaid is displayed which show correct due balance. task- 42040
Original PR description
Steps to reproduce : ==== - Install pos_sale module. - Create a quotation in sales and confirm it. - Open Point of Sale - Open Session and load orders from session. - Select the quotation and do 50% down payment. - Create new order and again load the same quotation. - Due balance remains same. Issue: ==== - Due balance is not updated, everytime it shows total amount. Fix : ==== - Instead of total amount , amount unpaid is displayed which show correct due balance. task- 4204048 Forward-Port-Of: odoo/odoo#182939 Forward-Port-Of: odoo/odoo#181809
Since [1] when Bootstrap was upgraded to version 5.3, the `$table-bg` variable is obtained from `$body-bg` instead of being transparent as it was previously. Because of this, when a "Boxed", "Frame" or "Postcard" layout is used, and a background color is specified, that color is used as table background, even if they are nested within cards that have a white background. This commit restores the transparent table background. Steps to reproduce: - Install eCommerce - Set a "Postcard" layou
Original PR description
Since [1] when Bootstrap was upgraded to version 5.3, the `$table-bg` variable is obtained from `$body-bg` instead of being transparent as it was previously. Because of this, when a "Boxed", "Frame" or "Postcard" layout is used, and a background color is specified, that color is used as table background, even if they are nested within cards that have a white background. This commit restores the transparent table background. Steps to reproduce: - Install eCommerce - Set a "Postcard" layout - Specify a non-white background color - Add a product to the card - Proceed to the checkout page => The total area used the body background instead of the card background. [1]: https://github.com/odoo/odoo/commit/058212e12b5079eba870bde9775fe98f27928935#diff-b037a8f5f304da130ba183549bf6abf5126d1bc118033211aa865ae74d3bca51R739 opw-4203976 Forward-Port-Of: odoo/odoo#182735
Add support for the Peppol PINT SG format, which will become active by the end of this year and required during the next one. Task id # 4122312 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182980 Forward-Port-Of: odoo/odoo#177137
Original PR description
Add support for the Peppol PINT SG format, which will become active by the end of this year and required during the next one. Task id # 4122312 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182980 Forward-Port-Of: odoo/odoo#177137
Before this commit, a regular expression was restricting the input units to `[A-Za-z%-]` characters. It made sense initially because those units were limited to technical terms with an untranslated name. But this makes "human" units such as "days" not recognized when using languages where the translated name either contains accents, or is not made of latin alphabet letters at all. This commit adapts the regular expression to consider a sequence of non-blank characters as the unit instead.
Original PR description
Before this commit, a regular expression was restricting the input units to `[A-Za-z%-]` characters. It made sense initially because those units were limited to technical terms with an untranslated name. But this makes "human" units such as "days" not recognized when using languages where the translated name either contains accents, or is not made of latin alphabet letters at all. This commit adapts the regular expression to consider a sequence of non-blank characters as the unit instead. Steps to reproduce: - Install Website - Drop a Popup inside the homepage - Switch user to Spanish - Edit the popup => The "Ocultar para" option did not display its value because "días" contains an accent. - Switch user to Japanese - Edit the popup => The "次のものに非表示" option did not display its value because "日" is not an alphabet letter. opw-4200520 Forward-Port-Of: odoo/odoo#182637
Have a grouped kanban view with existing groups but no records s.t. sample records are displayed (e.g. in CRM pipeline with a default filter, or in Project in a new project). Click on the "+" icon in a column to quick create a record. The first time, it's fine. Click on the menu again to relaunch the action (do not reload the webclient), and do the same: there's a flickering as sample records briefly appear "as real records" (i.e. they're not displayed as ghosts), before completely desappearing.
Original PR description
Have a grouped kanban view with existing groups but no records s.t. sample records are displayed (e.g. in CRM pipeline with a default filter, or in Project in a new project). Click on the "+" icon in…
Have a grouped kanban view with existing groups but no records s.t. sample records are displayed (e.g. in CRM pipeline with a default filter, or in Project in a new project). Click on the "+" icon in a column to quick create a record. The first time, it's fine. Click on the menu again to relaunch the action (do not reload the webclient), and do the same: there's a flickering as sample records briefly appear "as real records" (i.e. they're not displayed as ghosts), before completely desappearing. This is even more obvious on a slow network. The difference between the first time and the others is that the form view used in the quick create must be loaded the first time, and is in cache afterwards. When we click on the "+" icon, the following happens: - we remove sample records from the groups and we enable the quick create in a column => triggers a rendering of the KanbanRenderer - in the same tick, we toggle the useSampleModel flag on the model => triggers a rendering of the Controller After its rendering, the Controller no longer has the classname `o_view_sample_data` which ensures that sample records are displayed as ghosts. After its rendering, the Renderer no longer contains sample records. The flickering occurs when the rendering of the Renderer is async (the one of the Controller being always sync, as it doesn't wait for his children to be re-rendered, as their props didn't change). Indeed, in that case, there's a small timeframe during which the controller no longer has the classname `o_view_sample_data` but the renderer still contains sample records. Normally, the rendering of the Renderer should always be sync. Indeed, we triggered the loadViews in its onWillStart but we didn't wait for the rpc to return (we have a `isLoaded` flag, and we have an empty rendering while `isLoaded` is false). However, when the loadViews is already in the cache, the promise is resolves in the next microTick, and we directly render the component with the state `isLoaded` true, i.e. with the KanbanQuickCreateController. But that component is always async, as it loads the form view data (onchange) in its onWillStart, and must wait for it. As a consequence, in that case, the whole rendering of the Renderer is delayed. To fix the issue, this commit simply ensures that the rendering of the KanbanRecordQuickCreate is **always** sync, by toggling the `isLoaded` flag in onMounted instead of onWillStart. That way, the Renderer is rendered without the sample records in the same animationFrame as the Controller, and only then we toggle the KanbanQuickCreateController. Closes #181743 Task~4196741 Forward-Port-Of: odoo/odoo#182437 Forward-Port-Of: odoo/odoo#182300
Currently we always try to add a string informing about the used declaration of intent to the invoice / sale order PDF. I.e. it also happens when no declaration of intent is selected. After this commit the string is only added in case there is actually a declaration of intent selected. opw-4237368 Forward-Port-Of: odoo/odoo#182913
Original PR description
Currently we always try to add a string informing about the used declaration of intent to the invoice / sale order PDF. I.e. it also happens when no declaration of intent is selected. After this commit the string is only added in case there is actually a declaration of intent selected. opw-4237368 Forward-Port-Of: odoo/odoo#182913
Add support for the Peppol PINT ANZ format, which will become active by the end of this year and required during the next one. Task id # 3758343 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177142
Original PR description
Add support for the Peppol PINT ANZ format, which will become active by the end of this year and required during the next one. Task id # 3758343 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177142
On the purchase invoice form, the Italian localization adds a button that allows sending the tax EDI to the Italian administration. This depends on the field l10n_it_edi_is_self_invoice that is a computed field that will need access to the model account.report.line. In order to reproduce the issue, change the access rights of Marc Demo to Accounting: Billing, go to Accounting > Vendors > Bills and hit New. This commit fixes the issue by adding a sudo at the right place. Source: post-
Original PR description
On the purchase invoice form, the Italian localization adds a button that allows sending the tax EDI to the Italian administration. This depends on the field l10n_it_edi_is_self_invoice that is a computed field that will need access to the model account.report.line. In order to reproduce the issue, change the access rights of Marc Demo to Accounting: Billing, go to Accounting > Vendors > Bills and hit New. This commit fixes the issue by adding a sudo at the right place. Source: post-Odoo.com migration feedback Forward-Port-Of: odoo/odoo#176222
Some "week" date filters show records of the wrong week if the current day is Monday. This PR fixes them. Task-4219531 Forward-Port-Of: odoo/enterprise#71044
Original PR description
Some "week" date filters show records of the wrong week if the current day is Monday. This PR fixes them. Task-4219531 Forward-Port-Of: odoo/enterprise#71044
In 2022, Republic of Turkey officially renamed itself to Republic of Türkiye. So, its name needed to be changed in its Odoo modules. Moreover, updated Turkish modules descriptions according to this excalidraw: https://link.excalidraw.com/readonly/rbesZEAkXUS8rVgXplgm?darkMode=true task-4182931 Forward-Port-Of: odoo/enterprise#71573 Forward-Port-Of: odoo/enterprise#70304
Original PR description
In 2022, Republic of Turkey officially renamed itself to Republic of Türkiye. So, its name needed to be changed in its Odoo modules. Moreover, updated Turkish modules descriptions according to this excalidraw: https://link.excalidraw.com/readonly/rbesZEAkXUS8rVgXplgm?darkMode=true task-4182931 Forward-Port-Of: odoo/enterprise#71573 Forward-Port-Of: odoo/enterprise#70304
**Steps to reproduce:** - Install l10n_au_aba - Switch to an Australian company (e.g. AU Company) - Configure batch payments according to this [documentation](https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/australia.html#aba-files-for-batch-payments) - Create a vendor with a special character in the name (e.g. a curly apostrophe `’`) - Configure a bank account for the vendor - Create a bill for that vendor - Confirm the bill - Register a payment with "A
Original PR description
**Steps to reproduce:** - Install l10n_au_aba - Switch to an Australian company (e.g. AU Company) - Configure batch payments according to this…
**Steps to reproduce:** - Install l10n_au_aba - Switch to an Australian company (e.g. AU Company) - Configure batch payments according to this [documentation](https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/australia.html#aba-files-for-batch-payments) - Create a vendor with a special character in the name (e.g. a curly apostrophe `’`) - Configure a bank account for the vendor - Create a bill for that vendor - Confirm the bill - Register a payment with "ABA Credit Transfer" as payment method - Go to the payments list - Select the created payment and create a batch payment - Validate it - Download the generated ABA file - Try to validate the file on an online [ABA validator](https://www.bcu.com.au/business-banking/payments/internet-banking/aba-file-validator/) **Issue:** The online ABA file validator finds an error because the accepted length for a row is not respected. **Cause:** Each row information is encoded with a specific number of characters where blank characters are added to reach that length. In this case, the name of the account holder is containing a special character that corresponds to 3 characters when converted to utf8 and too many blank characters are added. **Solution:** Compute the length in utf8 before adding the blank characters. opw-4059837 Forward-Port-Of: odoo/enterprise#71590 Forward-Port-Of: odoo/enterprise#71351
The gantt view was not supposed to support fields of type 'date' but a view using such fields was introduced in the app "Project" (it is available in the first menu of the app when the option "Project Stages" is enabled). Here we make the gantt view manage correctly the date fields: display, drag and drop, or resize pills should now work as expected. Task ID: 3424435 Forward-Port-Of: odoo/enterprise#71587 Forward-Port-Of: odoo/enterprise#67971
Original PR description
The gantt view was not supposed to support fields of type 'date' but a view using such fields was introduced in the app "Project" (it is available in the first menu of the app when the option "Project Stages" is enabled). Here we make the gantt view manage correctly the date fields: display, drag and drop, or resize pills should now work as expected. Task ID: 3424435 Forward-Port-Of: odoo/enterprise#71587 Forward-Port-Of: odoo/enterprise#67971
Before this PR, overseas transactions with GST were shown in the spreadsheet, but not in GSTR-1. After this PR, overseas transactions with GST will no longer be shown in the spreadsheet. **Technical Reason:-** In the `_get_exp_json` method, we retrieve journal items that meet the exp domain criteria. However, the `tax_details` are linked from `move_id` using `tax_details_by_move`, which applies the hsn domain. Consequently, all journal items are retrieved, necessitating the exclusion of t
Original PR description
Before this PR, overseas transactions with GST were shown in the spreadsheet, but not in GSTR-1. After this PR, overseas transactions with GST will no longer be shown in the spreadsheet. **Technical Reason:-** In the `_get_exp_json` method, we retrieve journal items that meet the exp domain criteria. However, the `tax_details` are linked from `move_id` using `tax_details_by_move`, which applies the hsn domain. Consequently, all journal items are retrieved, necessitating the exclusion of those involving CGST and SGST, as these are not relevant for overseas transactions. **Task**-4008149 Forward-Port-Of: odoo/enterprise#65280
### Issue: When validating a stock picking created with a sendcloud picking method the partner assocaited with the delivery has no parent_id, so that the code will raise an error the one raised by: https://github.com/odoo/enterprise/blob/070a780db047d849db268a40f1b488dce0a80c6a/delivery_sendcloud/models/sendcloud_service.py#L556-L560 see commit fbeefb5f7d1e429b22d8fd6fc06b7c28b9c236a6 ### Steps to reproduce: - Create a sendcloud delivery method - go to website and order a product, go to
Original PR description
### Issue: When validating a stock picking created with a sendcloud picking method the partner assocaited with the delivery has no parent_id, so that the code will raise an error the one raised by:…
### Issue: When validating a stock picking created with a sendcloud picking method the partner assocaited with the delivery has no parent_id, so that the code will raise an error the one raised by: https://github.com/odoo/enterprise/blob/070a780db047d849db268a40f1b488dce0a80c6a/delivery_sendcloud/models/sendcloud_service.py#L556-L560 see commit fbeefb5f7d1e429b22d8fd6fc06b7c28b9c236a6 ### Steps to reproduce: - Create a sendcloud delivery method - go to website and order a product, go to checkout - pick sendcloud delivery method - select a relay location - go to odoo backend, go the sale order created by the website - click the SO deliveries smart button - Validate the delivery #### > Invalid operation ### Cause of the issue: When the customer checkouts, it confirms the sale order and generate a delivery linked to that SO via the `_action_launch_stock_rule`: https://github.com/odoo/odoo/blob/a91da6a5e835c11f59a4847026ffc79ba97969c5/addons/sale_stock/models/sale_order.py#L153-L155 Later in this confirm, the `partner_shipping_id` of the SO is changed to be associated with a `res.partner` of type `delivery`: https://github.com/odoo/odoo/blob/a91da6a5e835c11f59a4847026ffc79ba97969c5/addons/delivery/models/sale_order.py#L178-L183 but the partner of the picking is not changed accordingly. However, the `delivery_sendcloud` module expects ti receive this delivery partner as a `partner_id` which raises. ### Note: The error is only reproducible after 17.4 even though the only change is that the piece of code creating the partner was moved from `website_sale` to `delivery` by commit 6a28ecf201acaa1e09d3f02184b49f9b3f17486a HOWEVER, this change has a huge impact as it change the inheritance chain of the `sale.order` model: more precisely, the overrides of the `_action_confirm` in which the stock move is created happens before the overrides creating the partner of type delivery while the flow use to be generated in the opposite order so that the picking was created with the updated partner data ! opw-4181787 opw-4188628 Forward-Port-Of: odoo/enterprise#71368
With an EC company setup Open POS Add a product Go to Payment screen Select Invoice and pay using a cash payment method with an excess amount Issue: On the invoice (and xml e-invoice) there will be 2 payments, both with a positive amount We should not report the change opw-4192615 Forward-Port-Of: odoo/enterprise#71493
Original PR description
With an EC company setup Open POS Add a product Go to Payment screen Select Invoice and pay using a cash payment method with an excess amount Issue: On the invoice (and xml e-invoice) there will be 2 payments, both with a positive amount We should not report the change opw-4192615 Forward-Port-Of: odoo/enterprise#71493
Before this commit: In a recent commit to allow sendcloud to generate labels without having to fetch rates. When the returned value for field `price` is `None` it was set as `0.0` with datatype `float` when it should be `str`. After this commit: Added a check when setting price to make sure correct datatype is set. opw-4222636 Forward-Port-Of: odoo/enterprise#71367
Original PR description
Before this commit: In a recent commit to allow sendcloud to generate labels without having to fetch rates. When the returned value for field `price` is `None` it was set as `0.0` with datatype `float` when it should be `str`. After this commit: Added a check when setting price to make sure correct datatype is set. opw-4222636 Forward-Port-Of: odoo/enterprise#71367
The search functionality in the Recurring Plan view was not working when users entered text. While custom filters worked, the search field failed to respond to user input because no fields were defined in the search view. OPW-4116088 Forward-Port-Of: odoo/enterprise#70464
Original PR description
The search functionality in the Recurring Plan view was not working when users entered text. While custom filters worked, the search field failed to respond to user input because no fields were defined in the search view. OPW-4116088 Forward-Port-Of: odoo/enterprise#70464
Consider an unreconciled bank statement (line) in the bank reconciliation widget. Currently only the liquidity and suspense/transfer line of the associated move are shown. This means that some lines of the move are not shown. After this commit we show all the line (so i.e. the other lines). Since the diff is not the nicest: The commit just removes the outer `if wizard.st_line_id.is_reconciled`. Forward-Port-Of: odoo/enterprise#71550 Forward-Port-Of: odoo/enterprise#71236
Original PR description
Consider an unreconciled bank statement (line) in the bank reconciliation widget. Currently only the liquidity and suspense/transfer line of the associated move are shown. This means that some lines of the move are not shown. After this commit we show all the line (so i.e. the other lines). Since the diff is not the nicest: The commit just removes the outer `if wizard.st_line_id.is_reconciled`. Forward-Port-Of: odoo/enterprise#71550 Forward-Port-Of: odoo/enterprise#71236
Add context key to be able to redefine the date used to select which subscription lines are invoiceable. This allows to generate invoices before the date of next invoice set on the subscription with the help of custom module. Forward-Port-Of: odoo/enterprise#70053
Original PR description
Add context key to be able to redefine the date used to select which subscription lines are invoiceable. This allows to generate invoices before the date of next invoice set on the subscription with the help of custom module. Forward-Port-Of: odoo/enterprise#70053
Problem: Once we set the product ID in `WebsiteSaleDaterangePicker`, it doesn't get updated if it has a truthy value. However, it should update because a different variant (product ID) can be selected. Steps to reproduce: - Install a database with website, eCommerce, and Rental (ensure the "website_sale_stock_renting" module is installed). - Create a product that can be rented with 3 variants. - Add a daily rate of your choice. - In the Sales tab, untick the option "Continue selling if
Original PR description
Problem: Once we set the product ID in `WebsiteSaleDaterangePicker`, it doesn't get updated if it has a truthy value. However, it should update because a different variant (product ID) can be selected. Steps to reproduce: - Install a database with website, eCommerce, and Rental (ensure the "website_sale_stock_renting" module is installed). - Create a product that can be rented with 3 variants. - Add a daily rate of your choice. - In the Sales tab, untick the option "Continue selling if out-of-stock." - Restock 1 quantity of each variant and publish the product on the website. - From the shop, rent the product with variant size S for one week. - Return to the shop and select another variant (M or L). The calendar will incorrectly show the rental days in red, as if M & L are also already rented. However, they can still be rented. opw-4115519 Forward-Port-Of: odoo/enterprise#68832