Daily updates from Odoo
Navigate
Branch
Friday, July 19, 2024
72 changes
23 changes
Enhancements to existing features
This update improves Odoo's internal Hoot testing interface so development teams can see more tests, clearer errors, and more helpful dashboard information. It matters because stronger and easier-to-use test tools help teams catch issues earlier while keeping the changes limited to the testing ecosystem.
Original PR description
## Pull Request HOOT (PRHOOT) - part 20 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…
## Pull Request HOOT (PRHOOT) - part 20 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 Part 15.5: https://github.com/odoo/odoo/pull/166463 Part 16: https://github.com/odoo/odoo/pull/166311 Part 17: https://github.com/odoo/odoo/pull/168328 Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657 Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767 Enterprise: https://github.com/odoo/enterprise/pull/66895 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix helps Odoo recover when many browser sessions are waiting for live notifications at the same time. It reduces overload on the connection pool and spaces out reconnection attempts, lowering the risk of users being disconnected during busy periods or server restarts.
Original PR description
When no cursor is available to fetch bus notifications, websockets retry up to 10 times to acquire one. However, when many websockets try to acquire a cursor, the chances of getting one are very slim. Some will disconnect and will need a cursor to reconnect, worsening the cursor drought. As a result, there is minimal chance of recovery when the connection pool is full. This PR fixes this issue by wrapping cursor acquisition with a semaphore. This way, trying to acquire a cursor when none is available will make the caller wait until one is available.
The spreadsheet component was updated to the latest version for this Odoo release. This fixes an issue where COUNTIF did not correctly handle dates, helping users get more reliable spreadsheet calculations.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/9e0ea2429 [REL] 17.2.17 Task: 0 https://github.com/odoo/o-spreadsheet/commit/f82ac1750 [FIX] functions: COUNTIF does not handle dates Task: 4045506 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
The Point of Sale now handles cases where a sale order includes products that are not available in the PoS and the user lacks product editing rights. This prevents the order loading process from failing, helping staff continue sales workflows without needing extra permissions.
Original PR description
Before this commit, attempting to load a sale order into the PoS with products not available in the PoS would fail if the user lacked write access to the product, preventing the sale order from being loaded. opw-4057869 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Restaurant staff can now scroll through the floor view when there are more tables than fit on the screen. This restores access to hidden tables, making it possible to select and manage all tables in larger restaurant layouts.
Original PR description
Currently, if a restaurant has so many table that some are hidden down the screen, it is impossible to scroll down to select the hidden table. Steps to reproduce: ------------------- * Open the **Poin of sale** App * Open restaurant session * Switch floor view * Edit plan * Add many tables such as some are not visible on the screen * Try scrolling > Observation: Unable to scroll Why the fix: ------------ For some reason, the ability to scroll in the floor view was removed with this commit https://github.com/odoo/odoo/commit/b42b0f8b541a13621b671b0b7e57812ef11fc1b2 The value changed from `overflow-auto` to `overflow-hidden` here https://github.com/odoo/odoo/blob/fb4d758ed78211a61ea797759e1fb3b02b51be60/addons/pos_restaurant/static/src/app/floor_screen/floor_screen.xml#L66 opw-4051308
Miscellaneous changes
Saskatchewan tax report was missing a line for `Total before Sales` opw-3955926 Forward-Port-Of: odoo/odoo#171033
Original PR description
Saskatchewan tax report was missing a line for `Total before Sales` opw-3955926 Forward-Port-Of: odoo/odoo#171033
Description of the issue/feature this PR addresses: [CLA] add corporate samadeva.md to contribute as developper Current behavior before PR: Desired behavior after PR is merged: --- v I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173597
Original PR description
Description of the issue/feature this PR addresses: [CLA] add corporate samadeva.md to contribute as developper Current behavior before PR: Desired behavior after PR is merged: --- v I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173597
Forward-Port-Of: odoo/odoo#173617
Original PR description
Forward-Port-Of: odoo/odoo#173617
Steps to reproduce: 1) Install and enable wire transfer. 2) Disable and enable it again. 3) Go to the payment form and see that wire transfer is not in the list of available payment methods. Reason: No default payment method codes were defined to activate with the provider. opw-4042165 Forward-Port-Of: odoo/odoo#173637
Original PR description
Steps to reproduce: 1) Install and enable wire transfer. 2) Disable and enable it again. 3) Go to the payment form and see that wire transfer is not in the list of available payment methods. Reason: No default payment method codes were defined to activate with the provider. opw-4042165 Forward-Port-Of: odoo/odoo#173637
Introduced in 5f4add917a55f62c024a7a79c9240dc628a9f14f, we allowed filtering on 'done' activities. This induced a change in the search method of activity_user_id field, now readonly, to allow searching on done activities. As user_id is required on mail.activity, we can do as we do for the activity_date_dateline search method (date_dateline being required too on mail.activity): when using 'is not set' as a custom domain (~ '= False'), return records having no activities, and therefore no activ
Original PR description
Introduced in 5f4add917a55f62c024a7a79c9240dc628a9f14f, we allowed filtering on 'done' activities. This induced a change in the search method of activity_user_id field, now readonly, to allow searching on done activities. As user_id is required on mail.activity, we can do as we do for the activity_date_dateline search method (date_dateline being required too on mail.activity): when using 'is not set' as a custom domain (~ '= False'), return records having no activities, and therefore no activity_user_id. A small test is added in test_mail Task-4027928 Forward-Port-Of: odoo/odoo#172082
Steps to reproduce: - Add a product to your cart (not a service) - Try to pay with express checkout with payment_demo - Validation Error:No shipping method is selected. After this PR the first available shipping method will be assigned to the order when payment with demo express checkout. opw-4010925 Forward-Port-Of: odoo/odoo#173297 Forward-Port-Of: odoo/odoo#171180
Original PR description
Steps to reproduce: - Add a product to your cart (not a service) - Try to pay with express checkout with payment_demo - Validation Error:No shipping method is selected. After this PR the first available shipping method will be assigned to the order when payment with demo express checkout. opw-4010925 Forward-Port-Of: odoo/odoo#173297 Forward-Port-Of: odoo/odoo#171180
In the list view of the Chart of Accounts, the only available tags in the field Tags are the ones applicable to Accounts. In the list view of journal items, the only available tags in the field Tax Grids are the ones applicable to Taxes. task-4016899 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173686 Forward-Port-Of: odoo/odoo#173138
Original PR description
In the list view of the Chart of Accounts, the only available tags in the field Tags are the ones applicable to Accounts. In the list view of journal items, the only available tags in the field Tax Grids are the ones applicable to Taxes. task-4016899 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173686 Forward-Port-Of: odoo/odoo#173138
Since https://github.com/odoo/odoo/issues/113974, Properties fields can contain separator (virtual `<group>`) information inside its value. But in the view list, these separator can be selected in the optional fields. It doesn't make sense because there no value associated. Also it avoids a warning in the JS console ("Missing widget: separator for field of type separator"). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/o
Original PR description
Since https://github.com/odoo/odoo/issues/113974, Properties fields can contain separator (virtual `<group>`)
information inside its value. But in the view list, these separator can be selected in the optional fields. It doesn't make sense because there no value associated.
Also it avoids a warning in the JS console ("Missing widget: separator
for field of type separator").
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#173362Purpose ======= Fix the undo button in the website snippets which is enabled after choosing a template from the theme selector. The undo button shouldn't be enabled as the first selected theme is meant to be the first history step. Specification ============= After selecting a theme in the theme selector, the history steps are reset. However the undo/redo buttons of the website snippets aren't being updated with the reset. This happens because the method which updates the undo/redo but
Original PR description
Purpose ======= Fix the undo button in the website snippets which is enabled after choosing a template from the theme selector. The undo button shouldn't be enabled as the first selected theme is meant to be the first history step. Specification ============= After selecting a theme in the theme selector, the history steps are reset. However the undo/redo buttons of the website snippets aren't being updated with the reset. This happens because the method which updates the undo/redo buttons is triggered on the 'historyStep' event and this event is only trigerred when adding a new step in the history, not when resetting the history. Fixing the issue by trigerring the 'historyStep' event after reseting the history so that the undo/redo buttons are correctly being updated with the reset. Task-4000990 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170998
Before this commit, some calendar didn't show multiple days events in day and week modes. This commit enables the day slots in every calendar to show these events. opw-3933140 opw-3981108 Forward-Port-Of: odoo/odoo#172729
Original PR description
Before this commit, some calendar didn't show multiple days events in day and week modes. This commit enables the day slots in every calendar to show these events. opw-3933140 opw-3981108 Forward-Port-Of: odoo/odoo#172729
Issue: ====== We can update the content of the editable before we choose the theme which results in unexpected behaviors. Steps to reproduce the issue: ============================= - Open the email marketing app - In the browser dev tools, set a big network throttle - Create a new mailing - Write in the editable zone before the template selection has had a chance to appear - Click on design tab in the sidebar - Traceback Spec: ===== We should not be able to write in the edi
Original PR description
Issue: ====== We can update the content of the editable before we choose the theme which results in unexpected behaviors. Steps to reproduce the issue: ============================= - Open the email…
Issue: ====== We can update the content of the editable before we choose the theme which results in unexpected behaviors. Steps to reproduce the issue: ============================= - Open the email marketing app - In the browser dev tools, set a big network throttle - Create a new mailing - Write in the editable zone before the template selection has had a chance to appear - Click on design tab in the sidebar - Traceback Spec: ===== We should not be able to write in the editable zone before choosing a template. Solution: ========= We add a new option `waitForSnippets` for the `wysiwyg` to force the editable element as `contenteditable="false"` until the snippets are loaded. Once the snippets are loaded we set `contenteditable="true"` back again. Note 1: Removing the line of `this._activatecontenteditable` from `_onMouseDown` in `odooEditor` because it keeps setting the editable element as `contenteditable="true"` everytime we click. The line can be safely removed because it's a leftorver from when clicking on links would set everything to `contenteditable=false` except the link itself, then clicking somewhere else would reactivate it. (introduced here https://github.com/odoo/odoo/commit/72dd8d6e3c95f614353b1e87322a67c877c255c7) . When it was outside the condition, it was hard to guess that it was not needed anymore when we removed that `contenteditable` hack for links. Note 2: the `odoo-editor` div in website have `contenteditable=false` so dropped snippets will not be editable too. We call `activatecontenteditable` after the drop of the snippets. task-3901534 Forward-Port-Of: odoo/odoo#173642 Forward-Port-Of: odoo/odoo#168008
Issue: ====== Half of the colorpicker isn't visible in the sidebar toolbar. Steps to reproduce the issue: ============================= - Go to mass mailing and choose any template with a button. - Click on the button, make it a link. - Choose style as custom in the sidebar - Click on the circles for text color or fill color - Colorpicker is not position correctly. Origin of the issue: ==================== See commit: https://github.com/odoo/odoo/commit/88c16966b6b2d29d464ac3b43c
Original PR description
Issue: ====== Half of the colorpicker isn't visible in the sidebar toolbar. Steps to reproduce the issue: ============================= - Go to mass mailing and choose any template with a button. -…
Issue: ====== Half of the colorpicker isn't visible in the sidebar toolbar. Steps to reproduce the issue: ============================= - Go to mass mailing and choose any template with a button. - Click on the button, make it a link. - Choose style as custom in the sidebar - Click on the circles for text color or fill color - Colorpicker is not position correctly. Origin of the issue: ==================== See commit: https://github.com/odoo/odoo/commit/88c16966b6b2d29d464ac3b43cc4998d3f4fe0e2 Solution: ========= Fixing this issue properly would require huge changes to how the SnippetsMenu is constructed and would most likely require going back to the slow iframe with all the assets inside. That would not be a desirable outcome, especially in a stable version. With that in mind, and considering the issue doesn't exist in saas-17.1, we decided it was a prime example where a local change in the popper.js library was actually the best fix. The library is very unlikely to be updated in a stable version and the change won't reach saas-17.1. co-authored with dmo-odoo opw-3984170 Forward-Port-Of: odoo/odoo#170278
Steps to reproduce: - Go to Contact - Select Abigail Peterson - Set her as a company, don't fill the field country - In Partner assignment, set partner level, activation, level weight - Cick on go to website - Back to Resellers What happens: Error with traceback ending in "TypeError: 'bool' object is not subscriptable". This is due to the country field of a reseller not being filled in, the resellers page tries to load the list of all countries with resellers and displays either res
Original PR description
Steps to reproduce: - Go to Contact - Select Abigail Peterson - Set her as a company, don't fill the field country - In Partner assignment, set partner level, activation, level weight - Cick on go to website - Back to Resellers What happens: Error with traceback ending in "TypeError: 'bool' object is not subscriptable". This is due to the country field of a reseller not being filled in, the resellers page tries to load the list of all countries with resellers and displays either resellers of the user's country or all resellers if no match is found. If any reseller's country is not filled in there is no 'country.id' to access leading to the error above. Expected behavior: Fallback: Show all partners when user's country has no resellers (as described in the file itself by comments). opw-4042404 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173086
In the contact form view, click on "Add" in the x2many on a record that isn't a company. In the dialog, select the type "Contact" and click on the "Title" label. Before this commit, the many2one autocomplete dropdown of the title field behind the dialog (in the main form view) opens, instead of the one inside the dialog. This is because the id associated with that occurrence of the field and used as "for" attribute of the label isn't unique cross form views (we only ensured it to be unique in
Original PR description
In the contact form view, click on "Add" in the x2many on a record that isn't a company. In the dialog, select the type "Contact" and click on the "Title" label. Before this commit, the many2one…
In the contact form view, click on "Add" in the x2many on a record that isn't a company. In the dialog, select the type "Contact" and click on the "Title" label. Before this commit, the many2one autocomplete dropdown of the title field behind the dialog (in the main form view) opens, instead of the one inside the dialog. This is because the id associated with that occurrence of the field and used as "for" attribute of the label isn't unique cross form views (we only ensured it to be unique inside a given form view). There are several ways to fix this, but to minimize the diff and to comply with stable policy, this commit temporarily removes the ids that are already in the DOM (behind the dialog), and resets them when the dialog is closed. In master, we may explore alternative solutions, like generate (globally) unique ids in the arch parser. opw 3996642 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#173689 Forward-Port-Of: odoo/odoo#173584
A VAT number in Spain is a concatenation of the country prefix ES and another code, either: NIF - Número de Identificación Fiscal for individuals. CIF - Certificado de Identificación Fiscal for registered companies. The `res_partner.vat` field in Odoo is labelled "NIF" in the UI, and supports both the full VAT code with ES prefix and the shorter one without. This fix addresses two cases where the code assumed the ES prefix was present and incorrectly trimmed the first two characters away.
Original PR description
A VAT number in Spain is a concatenation of the country prefix ES and another code, either: NIF - Número de Identificación Fiscal for individuals. CIF - Certificado de Identificación Fiscal for registered companies. The `res_partner.vat` field in Odoo is labelled "NIF" in the UI, and supports both the full VAT code with ES prefix and the shorter one without. This fix addresses two cases where the code assumed the ES prefix was present and incorrectly trimmed the first two characters away. Reference: https://www.strongabogados.com/tax-id-spain.php Ticket [link](https://www.odoo.com/odoo/project.task/3891248) opw-3891248 Forward-Port-Of: odoo/odoo#168052
Backport of #171924 `git cherry-pick 61a166af43cfc0d7659626c664f89d1cd4163a7c..0414da47d3548270380c9d577f84fbbcd0d5967e` Conflict notes: - requirements.txt conflicted on Babel and chardet, kept as the target Forward-Port-Of: odoo/odoo#173788
Original PR description
Backport of #171924 `git cherry-pick 61a166af43cfc0d7659626c664f89d1cd4163a7c..0414da47d3548270380c9d577f84fbbcd0d5967e` Conflict notes: - requirements.txt conflicted on Babel and chardet, kept as the target Forward-Port-Of: odoo/odoo#173788
Before this commit, the avatar for the employees in the org chart is loaded by the URL but also when we fetched the data. This commit avoid fetching image fields with `hierarchy_read`. Forward-Port-Of: odoo/odoo#173040 Forward-Port-Of: odoo/odoo#172934
Original PR description
Before this commit, the avatar for the employees in the org chart is loaded by the URL but also when we fetched the data. This commit avoid fetching image fields with `hierarchy_read`. Forward-Port-Of: odoo/odoo#173040 Forward-Port-Of: odoo/odoo#172934
This commit's purpose is to keep the user input when he creates an sol from the formview sol. Step to reproduce : - open project update - cilck on 'sols' stat button - click on 'new' to create a new sol - give a name 'youpi' to the sol - save the sol The name of the sol will be overwritten with a default one. Expected behavior: The name of the sol should be the one the user has set. Source of the problem: The name of sol is used for some computation in some use case when the fo
Original PR description
This commit's purpose is to keep the user input when he creates an sol from the formview sol. Step to reproduce : - open project update - cilck on 'sols' stat button - click on 'new' to create a new…
This commit's purpose is to keep the user input when he creates an sol from the formview sol. Step to reproduce : - open project update - cilck on 'sols' stat button - click on 'new' to create a new sol - give a name 'youpi' to the sol - save the sol The name of the sol will be overwritten with a default one. Expected behavior: The name of the sol should be the one the user has set. Source of the problem: The name of sol is used for some computation in some use case when the form view of sol from the sale_project module is used. But this form view is also used in the use case where the name override is not needed. Solution: add a context key to differentiate the 2 use cases. task - 4031977 version : 17.0 - master 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#171786
30 changes
Enhancements to existing features
This update simplifies how the Knowledge app prepares a user-facing message by removing an unnecessary intermediate step. It does not change functionality, but helps keep the code easier to maintain and less prone to future issues.
Original PR description
Also inline the local as there doesn't seem to be a point to it.
The Helpdesk ticket card layout has been adjusted to make the status selection button larger and easier to use. The status control and assignee icon positions now better match the Project app, creating a more consistent experience across Odoo.
Original PR description
The purpose of this commit is to make the UI of helpdesk ticket's state selection easier for the users by increasing the size of the button. The position of this button and the icon of the assigned user is swapped to be coherent with the Project module UI. This increase of button size is also applied to the dropdown menu of the state selection, which appears when the user presses the state selection button. Task: 3861440
Appointment invite codes now avoid exposing raw technical identifiers and are generated only when needed. This keeps invite references cleaner for users while slightly reducing unnecessary processing behind the scenes.
Original PR description
Also don't compute an entire uuid4 for just 4 random bytes, and don't compute anything if we don't need to
The Helpdesk ticket form now shows helpful placeholder text in the description field. This gives users clearer guidance on what information to enter, making ticket creation easier and more consistent.
Original PR description
Prior to the this commit, the description of a ticket was empty in the helpdesk's ticket view form. This PR adds a placeholder to the description in order to help users understand better its usage. Task-3858665
The grid view now shows its header even when displaying sample data. This makes it easier for users to move to the previous or next day and improves day-to-day navigation.
Original PR description
Currently, the grid header is not visible, preventing users from navigating to the next or previous day. This commit ensures that the grid header is displayed with sample data to improve navigation and usability. task-3972806
Timesheet-related screens now show the correct label for the unit amount field directly in each view. This removes an older workaround and makes the wording more consistent for users across helpdesk, sales timesheets, and timesheet grid screens.
Original PR description
With task 3330297, the override made to set the right label to unit_amount field is no longer needed. This PR will remove the override and set the correct label for this field in every view. task-3911485
Debit notes now use their own numbering sequence, helping businesses keep credit and debit documents easier to distinguish and audit. Related localization test data was updated to reflect the new debit note references in supported electronic reporting flows.
Original PR description
updating the below-mentioned test cases and test data: - test_gstr1_debit_note_json - debit_note_30.xml - accepted_debit_note_2.xml - accepted_debit_note.xml task-3906389
This update improves how Knowledge article names are prepared by ensuring all relevant information is tracked upfront. It helps avoid unnecessary background lookups, which can make related Knowledge views load more efficiently.
Original PR description
Some fields are missing in the display_name dependencies resulting in additional queries.
Field service tasks will no longer create a blank timesheet sales line when products are added but no time is recorded before the task is completed. This keeps sales orders cleaner and avoids confusing or unnecessary billing lines.
Original PR description
With this commit, we prevent the creation of an empty sol for timesheets when products are added to the task but no timesheet entries are made. and, the task is marked as done. task-3995703
Payroll teams can now link salary rules more flexibly to other payroll inputs, including salary attachments, without relying on matching technical codes. This helps prevent missed or incorrectly counted payroll amounts and supports clearer country-specific payroll setup.
This update centralizes how Odoo creates and reads web links so apps can generate links consistently even when website-related features are not installed. It helps prevent incorrect links in messages and pages across appointments, helpdesk, events, eLearning, Studio, Twitter wall, and WhatsApp templates.
Original PR description
Addons such as mail use the http_routing slug method without depending on it. The links sent do not correspond to what the server should receive. The slug and unslug methods are moved to ir.http in order to be used everywhere with behavior corresponding to the installed addons.
Helpdesk portal users can now sort and group support tickets by related sales orders, making it easier to review service activity in a business context. The portal also shows clearer customer company information and sales order labels so users can identify tickets faster.
Original PR description
Currently, helpdesk portal users cannot group tickets with sale orders. In this commit, we've made the following improvements: - Added functionality to group by and tickets by sale orders. - Display the name of the partner's company for customer, - Added sale order name along with its label. (Ex: Sale Order - S0005) task- 3703165
Customers renewing a subscription from the portal now get a new invoice created for that renewal instead of having their payment applied to an older unpaid or disputed invoice. This prevents renewal payments from being misdirected and helps ensure the subscription is extended as expected.
Original PR description
Before this commit, when the customer paid on the subscription form in the portal, the system tried to find an invoice requiring a payment. It would be an issue if one previous invoice was disputed but the customer wanted to renew his subscription. The disputed invoice would be paid and the subscription would not be extended. subscription_transaction route is still used for invoice payment but it is now possible to have different behavior depending on the form we use. After this commit, the customer who pais on the subscription portal, will automatically create a new invoice. taskid: XXX
Users can now connect a Six payment terminal directly from the Point of Sale payment method screens instead of entering the terminal ID on the IoT box homepage. This streamlines setup for stores and reduces configuration steps for payment hardware.
Original PR description
Previously, to configure a Six terminal the ID had to be entered on the IoT box homepage. After this change, a wizard is added to the Payment Methods list view to connect a Six terminal. https://www.odoo.com/odoo/project/1428/tasks/4028139
Resolved issues and error corrections
Spreadsheet pivot tables and related menus were updated to align with the latest spreadsheet engine changes. This improves data consistency in pivot measures and supports smoother future spreadsheet upgrades without changing day-to-day workflows.
Original PR description
See https://github.com/odoo/odoo/pull/173681
This update corrects internal code imports used by accounting reports and removes an unused reference. It helps keep the reporting module compatible and easier to maintain without changing day-to-day user workflows.
Original PR description
- `parse_version` should never have been imported from `odoo.tools.misc` because it was never intentionally exported from there (misc just used it internally, and has not done that since 2021) - remove unused `_lt` import - fix imports organisation
Code cleanup and technical improvements
The Mexican electronic delivery guide functionality has been reorganized by merging the version-specific extension back into its parent module. This keeps the same business capabilities while simplifying maintenance and reducing module complexity for future updates.
Original PR description
`l10n_mx_edi_stock_extended_31` was added in version `15.0` as a dedicated module for the stable versions. This PR merges it back into its parent module. task-4000227
Miscellaneous changes
The trust widget was missing a prop causing a client stacktrace when in debug mode. It appears in saas-17.2 due to https://github.com/odoo/enterprise/commit/47434fba1acd9b7bcc0a4eb74f6b2dc4454f0068 opw-4058127 Forward-Port-Of: odoo/enterprise#66891
Original PR description
The trust widget was missing a prop causing a client stacktrace when in debug mode. It appears in saas-17.2 due to https://github.com/odoo/enterprise/commit/47434fba1acd9b7bcc0a4eb74f6b2dc4454f0068 opw-4058127 Forward-Port-Of: odoo/enterprise#66891
This commit changes the user for the test `:TestWKnowledgeSecurity.test_models_as_user` which should test ACLs for internal users. Initially it used `portal_user`, which is not internal but portal. It is now replaced by `employee`. task-4059967 Forward-Port-Of: odoo/enterprise#66948 Forward-Port-Of: odoo/enterprise#66869
Original PR description
This commit changes the user for the test `:TestWKnowledgeSecurity.test_models_as_user` which should test ACLs for internal users. Initially it used `portal_user`, which is not internal but portal. It is now replaced by `employee`. task-4059967 Forward-Port-Of: odoo/enterprise#66948 Forward-Port-Of: odoo/enterprise#66869
We send the name of an old blackbox Now we send a generic name for blackbox device "blackbox" Forward-Port-Of: odoo/enterprise#66920
Original PR description
We send the name of an old blackbox Now we send a generic name for blackbox device "blackbox" Forward-Port-Of: odoo/enterprise#66920
The accounting date is used as acquisition date instead of bill date. Steps: 2 flows leads to the bug: 1) - Create and confirm a bill with different accoutning and bill dates - Open a new asset form and click on "select related purchases" button - Select the bill -> The acquisition is set as the accounting date instead of the bill date 2) - Set the expense account to create an asset - Create and confirm a bill with line using the expense account - An asset should be
Original PR description
The accounting date is used as acquisition date instead of
bill date.
Steps:
2 flows leads to the bug:
1) - Create and confirm a bill with different accoutning and bill dates
- Open a new asset form and click on "select related purchases"
button
- Select the bill
-> The acquisition is set as the accounting date instead of the bill
date
2) - Set the expense account to create an asset
- Create and confirm a bill with line using the expense account
- An asset should be created, open it
-> Same as before
Cause:
In the `_compute_acquisition_date`, we use the field `date` from
`account.move.line` which is a related field to the `date` field of
`account_move`
Fix:
In the compute, we get the `invoice_date` field from the related move
of each `original_move_line_ids` then fallback to `date` if it is not
set (case of journal entries)
opw-4000259
Forward-Port-Of: odoo/enterprise#66921
Forward-Port-Of: odoo/enterprise#65769churned Before this commit, if a renewal was churned then canceled, the parent order was not reopened. taskid: 4024437 Forward-Port-Of: odoo/enterprise#66862 Forward-Port-Of: odoo/enterprise#65826
Original PR description
churned Before this commit, if a renewal was churned then canceled, the parent order was not reopened. taskid: 4024437 Forward-Port-Of: odoo/enterprise#66862 Forward-Port-Of: odoo/enterprise#65826
When you select a city from the city list (city_id field) on the res.partner the cities are filtered by country in standard. However this is complicated to use because more often than not there are many cities with the same name. This is specially frequent in large countries. So simply changing it to domain="[('state_id', '=', state_id)]" solves the issue. task: 4027290 Forward-Port-Of: odoo/enterprise#66582 Forward-Port-Of: odoo/enterprise#66495
Original PR description
When you select a city from the city list (city_id field) on the res.partner the cities are filtered by country in standard. However this is complicated to use because more often than not there are many cities with the same name. This is specially frequent in large countries.
So simply changing it to domain="[('state_id', '=', state_id)]" solves the issue.
task: 4027290
Forward-Port-Of: odoo/enterprise#66582
Forward-Port-Of: odoo/enterprise#66495We get a singleton error in multicompany setup when opening the accounting dashboard Steps: - Have at least two companies, one with l10n_fr_reports installed - Select the two companies in the caompany selector - Go to accounting dashboard -> singleton error opw-4053554 Forward-Port-Of: odoo/enterprise#66866 Forward-Port-Of: odoo/enterprise#66757
Original PR description
We get a singleton error in multicompany setup when opening the accounting dashboard Steps: - Have at least two companies, one with l10n_fr_reports installed - Select the two companies in the caompany selector - Go to accounting dashboard -> singleton error opw-4053554 Forward-Port-Of: odoo/enterprise#66866 Forward-Port-Of: odoo/enterprise#66757
**Current behavior before PR:** In mobile view, whatsapp tab had no search button. **Desired behavior after PR is merged:** In mobile view, added a search button to find whatsapp channel. task-id:3525542 Forward-Port-Of: odoo/enterprise#66861 Forward-Port-Of: odoo/enterprise#59530
Original PR description
**Current behavior before PR:** In mobile view, whatsapp tab had no search button. **Desired behavior after PR is merged:** In mobile view, added a search button to find whatsapp channel. task-id:3525542 Forward-Port-Of: odoo/enterprise#66861 Forward-Port-Of: odoo/enterprise#59530
In [1], a limit was introduced to the amount of records that can be displayed at the same time in the shop floor app. However, it was not always very clear to the user that they may only be viewing a subset of the available records. It was also impossible to show any records beyond the first 40 that conform to the filter criteria. In this commit, we introduce a pager to resolve these issues. The pager will only be displayed when relevant (ie when not all available records are displayed). Usin
Original PR description
In [1], a limit was introduced to the amount of records that can be displayed at the same time in the shop floor app. However, it was not always very clear to the user that they may only be viewing a subset of the available records. It was also impossible to show any records beyond the first 40 that conform to the filter criteria. In this commit, we introduce a pager to resolve these issues. The pager will only be displayed when relevant (ie when not all available records are displayed). Using this new pager it is also possible for the user to dynamically increase or decrease the default limit of 40, which was not possible before. [1] https://github.com/odoo/enterprise/pull/64551 (and forward ports) Forward-Port-Of: odoo/enterprise#66848 Forward-Port-Of: odoo/enterprise#65995
Before this commit, when clicking on the action with the hierarchy enabled, the parent line were not unfolded which cause the purpose of the action to be useless. task-3839845 Forward-Port-Of: odoo/enterprise#66531 Forward-Port-Of: odoo/enterprise#63965
Original PR description
Before this commit, when clicking on the action with the hierarchy enabled, the parent line were not unfolded which cause the purpose of the action to be useless. task-3839845 Forward-Port-Of: odoo/enterprise#66531 Forward-Port-Of: odoo/enterprise#63965
Steps to reproduce: - Install "Field Service" - Open a random task - Click on "Navigate To" Issues: The link is constructed using the coordinates, however Google will convert those coordinates back to an address which will cause a potential discrepancy between the two. opw-4004846 Forward-Port-Of: odoo/enterprise#66691 Forward-Port-Of: odoo/enterprise#65893
Original PR description
Steps to reproduce: - Install "Field Service" - Open a random task - Click on "Navigate To" Issues: The link is constructed using the coordinates, however Google will convert those coordinates back to an address which will cause a potential discrepancy between the two. opw-4004846 Forward-Port-Of: odoo/enterprise#66691 Forward-Port-Of: odoo/enterprise#65893
Fixes a commit e3d7b06 Should look at the `self.order_id` creator instead of `self`. opw-3933511 Forward-Port-Of: odoo/enterprise#66791 Forward-Port-Of: odoo/enterprise#66748
Original PR description
Fixes a commit e3d7b06 Should look at the `self.order_id` creator instead of `self`. opw-3933511 Forward-Port-Of: odoo/enterprise#66791 Forward-Port-Of: odoo/enterprise#66748
When a user tries to validate an invoice of the refunded order a traceback will occur. Steps to produce: - Install 'l10n_mx_edi_pos' module. - Switch to a company whose country code is 'MX'(Mexico). - Open 'Point of Sale' and New Session. - Select any products > payment > Select payment method > Invoice > Select customer > Validate. - Click on 'Next Order'. - Click on 'Refund and select your order. - Click on refund > payment > Select payment method > Invoice > Validate. - Error wil
Original PR description
When a user tries to validate an invoice of the refunded order a traceback will occur. Steps to produce: - Install 'l10n_mx_edi_pos' module. - Switch to a company whose country code is 'MX'(Mexico).…
When a user tries to validate an invoice of the refunded order a traceback will occur.
Steps to produce:
- Install 'l10n_mx_edi_pos' module.
- Switch to a company whose country code is 'MX'(Mexico).
- Open 'Point of Sale' and New Session.
- Select any products > payment > Select payment method > Invoice > Select customer > Validate.
- Click on 'Next Order'.
- Click on 'Refund and select your order.
- Click on refund > payment > Select payment method > Invoice > Validate.
- Error will be generated.
Traceback on sentry:
```
TypeError: can only concatenate str (not "bool") to str
File "odoo/http.py", line 2252, in __call__
response = request._serve_db()
File "odoo/http.py", line 1828, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1848, 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 1826, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1833, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2058, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 42, in call_button
action = self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "home/odoo/src/enterprise/saas-17.1/l10n_mx_edi_pos/models/pos_order.py", line 108, in action_pos_order_invoice
action_values = super().action_pos_order_invoice()
File "addons/point_of_sale/models/pos_order.py", line 856, in action_pos_order_invoice
res = self._generate_pos_order_invoice()
File "addons/point_of_sale/models/pos_order.py", line 873, in _generate_pos_order_invoice
move_vals = order._prepare_invoice_vals()
File "addons/pos_sale/models/pos_order.py", line 32, in _prepare_invoice_vals
invoice_vals = super(PosOrder, self)._prepare_invoice_vals()
File "home/odoo/src/enterprise/saas-17.1/l10n_mx_edi_pos/models/pos_order.py", line 150, in _prepare_invoice_vals
vals['l10n_mx_edi_cfdi_origin'] = '03|' + self.refunded_order_id.account_move.l10n_mx_edi_cfdi_uuid
```
This is because 'l10n_mx_edi_cfdi_uuid' is empty at [1] and a string concatenate with it.
link [1]: https://github.com/odoo/enterprise/blob/1502f8b3e519d41f4a58e2acc846f315f6f5eeda/l10n_mx_edi_pos/models/pos_order.py#L150
This commit solves the above issue while checking the existence of
'l10n_mx_edi_cfdi_uuid' while creating the invoice for refund_order
sentry-4935781389
Forward-Port-Of: odoo/enterprise#64038
Forward-Port-Of: odoo/enterprise#5987319 changes
Resolved issues and error corrections
This fix resolves an issue where the Credit Notes button in helpdesk tickets was showing an empty list when both the helpdesk_account and helpdesk_sale_timesheet modules were installed together. The problem was caused by conflicting action names between the two modules, which has now been corrected by renaming the actions in helpdesk_account to prevent the conflict.
Original PR description
Steps to Reproduce: ----------- Install the helpdesk_account and helpdesk_sale_timesheet module. Go to the ticket form view. Perform a refund or reverse action. Click on the 'Credit Notes' stat button. Observe that the list view of credit notes is empty. Cause: ---------- When the helpdesk_sale_timesheet module is installed, the action_view_invoices method gets overridden. Fix: --------- We have renamed the actions in the helpdesk_account module to avoid conflicts. task-3972344
Fixed an issue where custom tax group labels (Preceding Subtotal values) were not displaying correctly on printed AvaTax invoices. When using AvaTax for automatic tax calculation, invoices now properly show the configured tax group names instead of generic "Untaxed Amount" labels, ensuring consistent invoice formatting across different tax configurations.
Original PR description
…invoices Steps to Reproduce on Runbot: 1. Set up AvaTax in Accounting settings 2. Make sure that the “Use AvaTax API” field is checked for the fiscal position named “Automatic Tax Mapping (AvaTax)”…
…invoices Steps to Reproduce on Runbot: 1. Set up AvaTax in Accounting settings 2. Make sure that the “Use AvaTax API” field is checked for the fiscal position named “Automatic Tax Mapping (AvaTax)” 3. Go to “Tax Groups” and for the record called “Tax 15%”, add “Test” to the field called “Preceding Subtotal” 4. Go to the Product Category called “All” and choose any selection for the field called “AvaTax Category” 5. Make an invoice and add the fiscal position named “Automatic Tax Mapping (AvaTax)” 6. Save then print the invoice. Notice on the printed invoice that above the box called “Total”, the box called “Untaxed Amount” shows up with no tax box. 7. Uncheck the “Use AvaTax API” field for the fiscal position named “Automatic Tax Mapping (AvaTax)” (This step is basically the inverse of step 2) 8. Print the invoice again and notice this time that the box will instead be called “Test” (which we set in step 3) and that a box showing the tax amount will show up. This commit fixes the issue so that the value in "Preceding subtotal" is shown for printed Avatax invoices too. opw-4027280
This fix resolves an issue where new helpdesk tickets displayed "name - #False" in the title bar instead of just "name" when the ticket reference number hadn't been assigned yet. After saving, the ticket reference will display correctly. This improves the user experience by removing confusing placeholder text from the interface.
Original PR description
How to reproduce (on 17.0 onwards): - Helpdesk -> new ticket form - set the name of the ticket (do not save the record) - then, set a partner to a existing partner - The display_name on the top displays 'name - #False' Expeceted behavior: - instead of displaying 'name - #False', it should display 'name' if the ticket_ref is not defined yet. After this commit, the display_name only displays the ticket_ref (#ID) if it exists. Test have been added for this purpose. Task: 3893076
This update fixes three issues in the Barcode App that affect warehouse operations: (1) When scanning lots across multiple pickings in a batch, the system now correctly stays focused on the current picking until it's completed, preventing lots from being assigned to the wrong picking; (2) The quantity increment buttons now show accurate remaining quantities even when non-reserved lots are scanned; (3) Line sorting is improved to prevent duplicate entries when lines are split. These fixes ensure accurate inventory tracking and a smoother warehouse workflow.
Original PR description
**[FIX] stock_barcode_picking_batch: scan lots with multiple pickings** > How to reproduce: > - Create a product tracked by lots and set a barcode for this product; > - Create a receipt for this…
**[FIX] stock_barcode_picking_batch: scan lots with multiple pickings** > How to reproduce: > - Create a product tracked by lots and set a barcode for this product; > - Create a receipt for this product, with at least 2 quantities and confirm it; > - Create a second similar receipt (you can duplicate the first one) and confirm it; > - Add these two receipt in a new batch and confirm the batch; > - Go in the Barcode App and open the batch, you should have two lines, one for each picking; > - Scan the product -> the first line should be selected; > - Scan a lot -> the lot is set on the first line and its qty is incremented; > - Scan another lot -> the lot is set on the second line and its qty is incremented. That's the issue. > > Expected behavior: When another lot is scanned after the first one, since we are picking quantity for the first picking, the line for the second picking shouldn't be selected until the first one is processed. To fix that, the search for a line following the scan will avoid to take a tracked line if its `picking_id` is not the same than the selected line and if the selected line is not completed. **[FIX] stock_barcode: increment right qty** > When a product tracked by lots is reserved and multiple lots are reserved, in the Barcode App, each line has a "+ qty" button where the quantity is the remaining quantity. That said, this remaining quantity was always computed regarding the difference between the move line's done and reserved quantity which means if the user scans a not reserved lot, those buttons aren't reliable anymore. > > How to reproduce: > - Create a product tracked by lots and set a barcode; > - Update the quantity on hand for this product like following: > - 3x lot1 > - 3x lot2 > - 3x lot3 > - Create a delivery for 6x this product and confirm it; > - Open the delivery in the Barcode App, unfold the line for the tracked product, you should have: > - 0/3 lot1, [+3] > - 0/3 lot2, [+3] > - Scan lot1 one time and lot3 three times, you now have: > - 3 lot3, [+1] > - 1/3 lot1, [+2] > - 0/3 lot2, [+3] > -> Since the total demand is 6 and 4 quantities have been processed, no button should display a quantity greater than 2 since it's the remaining quantity. > > To fix that, the quantity used by the increment button is also computed regarding the parent line's quantity. task-3688770 Community PR: odoo/odoo#173521 Forward-Port-Of: odoo/enterprise#64042 Forward-Port-Of: odoo/enterprise#54589
This update hides Kenya-specific eTIMS (electronic Tax Invoice Management System) fields and buttons from companies that don't operate in Kenya. This reduces clutter and confusion for international users by only showing relevant features when Kenya is set as the company's fiscal country. The change applies across invoicing, products, stock management, and configuration screens.
Original PR description
Where possible, we make the eTIMS-specific fields and buttons invisible unless the company has Kenya as fiscal country. Exceptions to this are: - the buttons on partner and user form views. We don't have a way of showing them only if the currently selected company is Kenyan. However, they are already visible only in debug mode, so this isn't too much of a problem. - the 'Custom Imports' menuitem - we don't have a way of making it conditionally visible.
This update improves the user experience by hiding the Field Service section in project forms when it contains no relevant settings. The section now only appears in debug mode when using the basic Field Service module, but displays normally when the Field Service Reports module is installed with additional settings available.
Original PR description
When `industry_fsm` is installed, the form of `project.project` contains a section `Field Service` with only one setting (`is_fsm`). This option is only visible in only visible in debug mode, so the whole section should be displayed only under this conditon. => The group `base.group_no_one` has been added to the section. When `industry_fsm_report` is installed, another setting appears under that section (`worksheet_template_id`), so the section should be displayed. => The group that is added in `industry_fsm` is removed then. task-3916982
This fix improves the user experience when connecting bank accounts by updating consent expiration dates immediately after successful synchronization, rather than making users wait up to 24 hours for the next automatic refresh. This ensures users see their updated consent status right away, making the system feel more responsive and reliable.
Original PR description
The aim of this commit is reverting a part of this commit [1]. We have to do that because by removing the call to consent expiring date after the sucess, users don't receive the new consent date directly. Users have to wait until the next call to the refresh token and this call is made every 24h so users have the feeling that the consent wasn't updated. In one case, we don't have the consent expiring date provided by the TPP directly. For that case, we keep the call after the renew token. [1]: https://github.com/odoo/enterprise/commit/25ec0ba479372126f84fd1ece6f34aea7b1eb829 Forward-Port-Of: odoo/enterprise#65408
A recent change to how French tax reports calculate values inadvertently broke the ability to audit tax line details. This fix restores the audit functionality by adjusting how the system identifies and displays the underlying journal entries for tax calculations, ensuring proper financial record-keeping and compliance.
Original PR description
This [commit](https://github.com/odoo/odoo/commit/12477a5401c4d0eaf39c87c17afc7f82d9018986) changed the way the French tax report computes its value to make sure they are rounded to the unit. It also unintentionally broke the auditing of the tax lines since tax tags are no longer used. The fix consists in adjusting the `expression_label` in the action in order to target the expression that uses the `tax_tags` engine, allowing to display the expected journal items. opw-3999520
This update adds missing safety protections to the French tax reporting module to prevent test databases from accidentally sending real data to external systems. This ensures that when support teams create copies of production databases for investigation purposes, those copies cannot inadvertently impact customers or the live production environment.
Original PR description
This commit adds the missing neutralization necessary for the l10n_fr_reports module introduced in 06f32096749a8df29b248f29698226cf996e9106 The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. opw-3928199
This fix resolves an issue in the consolidated trial balance report where users couldn't properly expand or collapse consolidation groups. The problem was caused by incorrect data being passed when building the report hierarchy, which has now been corrected to ensure the report displays and functions as intended.
Original PR description
…roup when opening the consolidated trial balance report, the folding/unfolding or consolidation groups were not working correctly. This was because the parent_line_id wasn't correctly passed in _get_generic_line_id opw-ticket: 4046553
This update fixes compatibility issues across multiple localization modules (Argentina, Chile, Mexico, Netherlands, Philippines, and Thailand) by updating code to work with newer versions of external libraries. The changes address deprecated methods and removed features in libraries like urllib3, zeep, cryptography, xlsxwriter, and openpyxl, ensuring the system continues to function properly with current software versions.
Original PR description
backport of #66166 Conflict notes: - ccfdc06546828868bfcfbe64f6f9c68914d96220 was dropped since the module does not exist in 17.0 (created in 17.3) - 2d58ab9042d823743bf9b0534d4572b88a30dc58 import adapted - 1728d1e448f90d3e32fc135de2370e054d0216f5 was dropped since the module does not exist in 17.0 (created in 17.2)
This fix corrects how package weight limits are handled when calculating shipping rates through Sendcloud. Previously, weight measurements were inconsistent—stored in kilograms but sent to Sendcloud as grams—causing shipping rates to be calculated incorrectly and appear unusually high. The fix ensures all weight values are properly converted to grams before being sent to Sendcloud, resulting in accurate shipping rate quotes.
Original PR description
Steps to reproduce: - Create a shipping method with sendcloud as provider. - In the field 'Default package type' create a package type and set 'Max Weight'(e.g 1kg). - Create a sales order, Add…
Steps to reproduce: - Create a shipping method with sendcloud as provider. - In the field 'Default package type' create a package type and set 'Max Weight'(e.g 1kg). - Create a sales order, Add shipping, and select sendcloud. - Add 'Total order weight'(e.g 0.5kg) - Click 'Get rate' Returned rate for shipping is unusually big ammout. Before this commit: For sendcloud shipping if sendcloud_default_package_type_id is set, max_weight is stored in kilograms. When checking if the package needs to be splitted, the target_weight is not being converted whereas the total_weight is.(check link at the bottom for details) Also in shipping rate request for sendcloud `max_weight` was sent in kilograms with `unit` being 'gram'. After this commit: `max_weight` is converted into grams before adding to the shipping rate request. split shipping code: https://github.com/odoo/enterprise/blob/d3b39fe78bc0ae366d32e80e325e89d2a4bb353c/delivery_sendcloud/models/sendcloud_service.py#L160-L162 opw-4035569
Fixed an issue where manually modified tax closing entries were being erased when posted. The system now preserves user changes to closing entries and properly handles dependent company closings within tax units. This ensures that accountants' manual adjustments to tax closing documents are retained during the posting process.
Original PR description
Before this commit, when posting a manually modified closing entry, the entire move would be refreshed, and all user-modified information would be erased. This occurred because, when accessing the action_periodic_vat_entries, the current tax closing move was overwritten. This commit changes this behavior by adding a flag to the method, indicating whether it is called from the _close_tax_period function. If so, it only updates moves that are different from the tax closing of the current company. Additionally, when selecting only one company within a tax unit, it sometimes happened that, when closing the main company, the dependent closings to post (depending_closings_to_post) were empty because the moves were not generated yet for the other companies. Task: 3987807
Fixed an issue where follow-up reports and printed PDFs were missing overdue invoices from branch companies. The system now correctly includes invoices from both the parent company and all its branches when generating follow-up reports, ensuring complete visibility of all outstanding invoices across your organization.
Original PR description
To reproduce: Create a branch for your company On this branch, create an overdue invoice for a partner. Change company for the parent company. Go to Follow-up Reports Go on this partner. You see the invoice appearing in the list Click on Follow-up and print => The pdf does not contain the invoice from the branch The issue is that we check on company and not on the company and branches. opw-3988003
A test for knowledge base access controls was using the wrong user type for validation. The test now correctly uses an internal employee user instead of a portal user, ensuring that access control rules are properly tested for the intended user category. This fix ensures the security testing is accurate.
Original PR description
This commit changes the user for the test `:TestWKnowledgeSecurity.test_models_as_user` which should test ACLs for internal users. Initially it used `portal_user`, which is not internal but portal. It is now replaced by `employee`. task-4059967 Forward-Port-Of: odoo/enterprise#66869
This fix corrects a calculation error that occurred when processing down payment invoices in Mexico's CFDI system. When a 90% down payment was applied to an invoice, the system incorrectly calculated negative base amounts on invoice lines, causing CFDI validation to fail. The fix ensures that discount amounts from down payments are properly distributed across invoice lines with accurate calculations.
Original PR description
**Steps to reproduce:** - Install Accounting, Sales, l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create a SO: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) *…
**Steps to reproduce:**
- Install Accounting, Sales, l10n_mx_edi
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Create a SO:
* Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA)
* Order Lines:
Product | Quantity | Unit Price | Taxes
---------------|----------------|----------------|----------
Product A | 1.00 | 1000.00 | 16%
Product B | 1.00 | 1500.00 | 16%
Product C | 1.00 | 3000.00 | 16%
- Confirm the SO
- Create a 90% down payment
- Confirm down payment and generate CFDI via "Send & Print" button
- Create a regular invoice for the remaining amount
- Confirm the invoice and generate CFDI
**Issue:**
The verification of the CDFI fails because there is one line with a negative base amount.
**Cause:**
The down payment line has a negative amount.
This negative amount is dispatched between the other lines and the "base" and "importe" values of these other lines are recomputed depending on the amount that is deducted from it.
However, the computation is based on a ratio computed from the price subtotal of the negative line, but the ratio is then applied to the remaining "base" amount of the negative line, which decreases for each deducted line.
This generates incorrect values in "transferred_values_list" field for the the second line and the following ones on which some amount is dispatched.
The issue only happens on the last line on which some amount has been dispatched because it receives the remaining amount that is too high due to the values deducted by the other lines being lower than what it should has been.
**Solution:**
The ratio should be computed from the remaining "base" amount of the negative line.
opw-4033979This fix resolves an issue where confirmation messages were not appearing when employees validated their timesheets in the pivot and kanban views. The problem was caused by mismatched parameters in the validation action, and this update ensures users receive proper feedback when submitting timesheets for approval.
Original PR description
### **Steps to reproduce:** - install Timesheets module. - Go to To Validate. - Click on All Timesheets. ### **Issue:** - The notification message is not displaying when clicking on validate in pivot and kanban views ### **Solution:** - The problem seems to be from a mismatch in parameters when triggering the validation action. PR-https://github.com/odoo/enterprise/pull/44455 task-3925639
Fixed incorrect calculation formulas in Austrian financial reports that were broken during a previous code refactoring. The formulas now correctly match the verified calculations from the previous stable version, ensuring accurate tax reporting for Austrian accounting customers who work with tax lawyers and auditors.
Original PR description
After finally checking with a full-fledged accounting customer which is verified by tax lawyers and auditors these changes are needed to show the exact same result as left behind battle tested in `15.0` - `PCVIII` is a sum of `PCVIII3` + `PCVIII4` and those can be part of `PCVIII1` or `PCVIII2` This needs also be reflected in `ABII4` if the balance needs to be mirrored. Actually it should be similar presented in `ABII4`, but was not yet done. This might need some account tags to be adapted in Odoo Community `l10n_at` CoA, but let's start from here as it is secured and tested information. Info: @wt-io-it
This fix resolves a problem in the consolidated trial balance report where users couldn't properly expand or collapse consolidation groups. The issue was caused by incorrect data being passed when organizing the report hierarchy, which has now been corrected to ensure the report displays and functions as intended.
Original PR description
when opening the consolidated trial balance report, the folding/unfolding or consolidation groups were not working correctly. This was because the parent_line_id wasn't correctly passed in _get_generic_line_id opw-ticket: 4046553