Thursday, October 10, 2024
39 changes · saas-17.4
Enhancements to existing features
In Point of Sale, clicking the cross button on the close session popup no longer closes the session when there are open orders. This prevents accidental session closure and helps staff safely return to their current workflow.
Original PR description
Before this commit: == - When we have open orders, and pressing the "close" (cross) button while closing a session currently closes the session. After this commit: == - The session should not be closed when the cross button is pressed. it only dismiss the current dialog. Task-4243380 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Shipping addresses created for website orders using pickup points now show the pickup point name instead of duplicating the customer name. This makes orders easier for staff to identify and reduces confusion during delivery handling.
Original PR description
### Issue: When a sale order made from the website with a pickup point (for instance using a sendcloud delivery method) is confirmed, a new partner is created to mix the data of the partner making the order and the address of the pickup point. If the partner is named Bob, this new partner will be named Bob, Bob. It woul dbe much clearer if he was named: Bob, pickup point name. opw-4181787 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Peppol connection wizard no longer shows the demo mode choice to regular users. This keeps the setup experience simpler while still allowing internal teams to manage demo mode through system settings when needed.
Original PR description
The demo mode option in the Peppol connection wizard is primarily used by internal teams (BA, support, sales) for demonstrations or testing. It is more appropriate to manage this mode through a system parameter instead of exposing it to all users in the wizard interface. This commit mirrors the change from (commit 4791e95c958b274cbe3e9ce720cf71dcfc4e2e5b pr odoo/odoo#182893), but without removing the related fields, making it suitable for stable versions. task-4215904
Orders using pickup points now label the generated delivery contact with the pickup point name instead of repeating the customer name. This makes it easier for staff and customers to identify where the parcel should be collected and reduces confusion in order records.
Original PR description
Issue: When a sale order made from the website with a pickup point (for instance using a sendcloud delivery method) is confirmed, a new partner is created to mix the data of the partner making the order and the address of the pickup point. If the partner is named Bob, this new partner will be named Bob, Bob. It woul dbe much clearer if he was named: Bob, pickup point name. opw-4181787
Resolved issues and error corrections
Special products such as discounts are no longer shown in the self-order menu. This keeps the customer-facing menu cleaner and prevents shoppers from selecting items that are meant only for internal checkout use.
Original PR description
Before this commit, special products, such as discount, could appear in the self-order menu. This commit ensures that such special products are not displayed, maintaining a cleaner and more relevant product selection for customers. opw-4200540 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Steps to reproduce : - Add a second language in your website settings. - Drop a "Text" block in a new page. - Add a highlight to some text > Save. - Switch to the translation mode. - Select the highlighted text > The text highlight options are shown. - Select a text without any option > The highlight options remain displayed. Starting from [1], we allow using text options (text animations & text highlights) in the translation mode, mainly by allowing the creation of snippet editors
Original PR description
Steps to reproduce : - Add a second language in your website settings. - Drop a "Text" block in a new page. - Add a highlight to some text > Save. - Switch to the translation mode. - Select the…
Point of Sale now shows product attributes marked as free text even when no text has been entered. This makes POS order lines consistent with the Sales app and avoids missing product configuration details during checkout.
Original PR description
Before this commit, attribute values marked as "Free text" would not appear on the orderline unless text was added to them. This behavior was inconsistent with the Sale module, where such attributes are displayed regardless. opw-4218992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website editor no longer crashes when users reopen and show a popup after hiding certain page elements on desktop. This makes editing popup-based website content more reliable and prevents an error from interrupting the save-and-edit workflow.
Original PR description
Steps to reproduce traceback: 1.Drag and drop popup snippet (Top on all other snippet) 2.Select the inside column and make it 'Hide on desktop' 3.Drag any other snippet below popup and make it 'Hide on desktop' 4.Save the changes. 5.Open editor and try to make popup visible. You can see traceback of `cannnot read the properties of undefined data`. Issue: The error occurs because, in certain iterations, the widget returns an undefined value, which is stored in `this._customize$Elements`. This PR will resolves the traceback by preventing undefined values from being inserted into `this._customize$Elements`. task-4004873
The guided tour for website slides has been fixed after recent changes caused it to stop working. This helps ensure users can once again follow the intended onboarding or demonstration flow for slide-related website features.
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
This fixes an intermittent issue in the automated document deletion and restore test where the trash view could reload after a document was selected. The change helps keep quality checks reliable without changing day-to-day document management behavior for users.
Original PR description
Sometimes the following sequence happened after the steps in `restoreDocumentSteps` after those in `deleteWorkspaceSteps`: 1. We click on the trash section 2. Its header is re-rendered with the "active" class 3. We select the record 4. The kanban view is reloaded to actually show the trash now 5. We already selected the document, so we're at the step expecting to interact with the inspector. See runbot error 71617 Backport of #67154 X-Original-Commit: 279b3200d666f8a3ad1b5843c6f1de8c25cf3464
Steps to reproduce : - Add a second language in your website settings. - Drop a "Text" block in a new page. - Add a highlight to some text > Save. - Switch to the translation mode. - Select the highlighted text > The text highlight options are shown. - Select a text without any option > The highlight options remain displayed. Starting from [1], we allow using text options (text animations & text highlights) in the translation mode, mainly by allowing the creation of snippet editors if the target is a text option snippet. Another fix (from [2]) was added later to exceptionally authorize the editor's creation for "invisible" elements in translate mode, with a small adaptation on `_activateSnippet()` to prevent activating invisible snippets when their related sidebar buttons are clicked. This code unintentionally leads to keeping the old editors created for a text snippet when switching to another one in the DOM. To fix this behaviour, we still need to ensure existing editors are destroyed so we only create the ones we need in translate mode. [1]: https://github.com/odoo/odoo/commit/3a149e36f7e6deaf156a7ee35e654aad61cf2e5d [2]: https://github.com/odoo/odoo/commit/67efd1d98072f36caf9c473e97984631eb6bc8a3 task-3975683 Forward-Port-Of: odoo/odoo#177203 Forward-Port-Of: odoo/odoo#168642
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
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 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: - 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
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
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
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#182917 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#182917 Forward-Port-Of: odoo/odoo#180758
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#182849 Forward-Port-Of: odoo/odoo#181809
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
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
Community-side fix for creating move lines instead of moves for production backorders. This change ensures that product quantity which was *intended* to be used by one production will rightly get reserved by that production's backorder. Additionally, we now use more care when marking moves as picked because this field has an inverse which will mark all of the move's move lines as consumed / done, despite them being incomplete. opw-4148050 Forward-Port-Of: odoo/odoo#180617
Original PR description
Community-side fix for creating move lines instead of moves for production backorders. This change ensures that product quantity which was *intended* to be used by one production will rightly get reserved by that production's backorder. Additionally, we now use more care when marking moves as picked because this field has an inverse which will mark all of the move's move lines as consumed / done, despite them being incomplete. opw-4148050 Forward-Port-Of: odoo/odoo#180617
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#177174
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
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 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
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
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 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#71225 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#71225 Forward-Port-Of: odoo/enterprise#67971
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#71537 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#71537 Forward-Port-Of: odoo/enterprise#70304
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
**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#71351
- 17.0 ### Steps to reproduce: - Install documents_product - Create a project - Open the project form view, select use documents in the settings tab - Create a task in the project - Upload document - Share the project with edit access mode with the portal user - Open document application - Share the project workspace - Login with portal user - Select the shared project and open the task - There is no documents stat button ### Issue: Missing 'documents' stat button in project sh
Original PR description
- 17.0 ### Steps to reproduce: - Install documents_product - Create a project - Open the project form view, select use documents in the settings tab - Create a task in the project - Upload document - Share the project with edit access mode with the portal user - Open document application - Share the project workspace - Login with portal user - Select the shared project and open the task - There is no documents stat button ### Issue: Missing 'documents' stat button in project sharing for portal users. ### Cause: It only displayed to the particular group i.e group_documents_user. ### Solution: Removing the groups from the stat button. So, It will visible to the portal user also. task-3884424 Forward-Port-Of: odoo/enterprise#71194 Forward-Port-Of: odoo/enterprise#61644
**Current behavior:** If you have a production opened in barcode and consume part of a component line to produce part of the final product, leave the transfer, then re-open it and confirm -> create the backorder, the resulting backorder will have split the remaining raw moves in an unintuitive manner. **Expected behavior:** The backorder should have one move for the remaining component quantity. **Steps to reproduce:** 1. Create a production for 10 of some final product consuming 1
Original PR description
**Current behavior:** If you have a production opened in barcode and consume part of a component line to produce part of the final product, leave the transfer, then re-open it and confirm -> create…
**Current behavior:**
If you have a production opened in barcode and consume part of a
component line to produce part of the final product, leave the
transfer, then re-open it and confirm -> create the backorder,
the resulting backorder will have split the remaining raw moves
in an unintuitive manner.
**Expected behavior:**
The backorder should have one move for the remaining component
quantity.
**Steps to reproduce:**
1. Create a production for 10 of some final product consuming 10
some component -> Confirm
2. Open the production in barcode, add 5 of the final product to
its line and 5 of the component to its line -> exit the
transfer view
3. Reopen the production and validate it -> create backorder
4. Open the backorder to see the odd split of the component
product's moves
**Cause of the issue:**
When creating the backorder we normally expect each component
product to be encapsulated by a single line- so the split that
occurs when we leave the transfer initially without validating
which creates 2 moves for the same product means we get 2 moves
for the component for half of the remaining quantity for that
component.
**Fix:**
Incomplete barcode lines for production transfers should get
split into additional move lines as opposed to moves.
opw-4148050
Forward-Port-Of: odoo/enterprise#70003
Forward-Port-Of: odoo/enterprise#69149The 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
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