Daily updates from Odoo
Wednesday, March 20, 2024
49 changes
3 changes
Resolved issues and error corrections
This fix stops the web interface from running the same server action more than once when it appears multiple times in the navigation path. Users should see more consistent breadcrumb labels and avoid duplicate action processing when navigating back to list views.
Original PR description
Since [1], when a server action is found in the url, it will be executed to retrieve the window action when is the current action. If the server action is found in multiple places in the url, it will be executed each time it becomes the current action. For instance, /crm/12, will execute the server action crm to retrieve the window action at the first load, and the same server action will be executed again when clicking on the breadcrumb to go back to the multi-record view. Now, After the first execution of the server action, all the same server actions found in the controller stack (breadcrumb) will be replaced with the resultant window action. This is to avoid executing multiple times the same server action. Note that, this will also use the correct display name on the breadcrumb, the one of the window action. [1] https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f
New employee and internal user records will now automatically receive a name-based avatar when no image is provided. This keeps profiles visually identifiable from the start and avoids blank images in employee and user views.
Original PR description
Ensure an avatar is generated based on the employee/user name if no image is provided at the record creation (for internal users only). TaskID: 3637523 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update stabilizes automated checks around the company switching menu by ensuring delayed router actions finish before results are checked. It reduces random test failures, helping maintain confidence in releases without changing business functionality.
Original PR description
In the "router" there are some debounced methods, and they produce some undeterministic errors. To avoid these errors, we run all timers before reading value from the router. task-3705027 runbot-error-59015 runbot-error-58156 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
11 changes
Resolved issues and error corrections
This update fixes an issue where the mobile menu wasn't correctly navigating users to linked sections on pages. The fix ensures that clicking menu items in mobile view now properly jumps to the intended anchor point, improving the user experience. This resolves a bug that caused unexpected scrolling behavior.
Original PR description
This commit addresses the erratic behavior of the mobile menu, specifically when clicking on menu items linked to anchors instead of navigating to different pages. The issue occurs in mobile view and can be reproduced by following these steps: 1. Create a page longer than the height of the screen with 3 blocks. 2. Add 3 links to target different sections on the page. 3. Create 3 menu items linked to the newly created anchors (/#...). 4. Save to apply the modifications. 5. Switch to mobile view. 6. Open the hamburger menu. 7. Click on the first menu item, then the second, then the third, and again on the first one. Upon reproducing these steps, the scrolling event would pass through all the anchors, causing unexpected behavior. This commit introduces fixes to ensure proper navigation when clicking on menu items in mobile view, resolving the described issue. opw-3652930 Forward-Port-Of: odoo/odoo#150810
This update fixes a calculation error in the Profit and Loss report for UK accounting. Specifically, the type of cost of sales accounts has been changed to 'expense_direct_cost'. This ensures accurate Gross Profit calculations, aligning with UK accounting standards and improving financial reporting.
Original PR description
The cost of sales accounts need to have the type expense_direct_cost for the Gross Profit calculation in the Profit and Loss report to be correct task: 3764767 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155374
This update resolves an issue where users could interact with the 'load more' button in the Kanban view when the system was running on sample data. This change ensures that the Kanban view functions correctly, regardless of whether it's using live data or a sample dataset, improving user experience.
Original PR description
This commit fixes an issue where one could interract with the load more button of the kanban view even in sample data mode. task-3754233
This update resolves an issue where the profile button wasn't appearing correctly when users and targets were associated with multiple companies. The fix now accurately checks for employee IDs across all companies, ensuring the profile button is displayed as expected for users with complex company relationships.
Original PR description
Currently, when the user and the target both are in multiple companies, the profile button cannot be displayed correctly. Since the employee_id uses `('company_id', '=', self.env.company.id)` rather than `in`.
This commit fixes the issue by checking employee_ids directly and if it is found, the profile button will be displayed correctly.
We don't care about which employee_id is used if there are multiple, since the user are in multiple companies as well. If looking for a specific profile, the employee can be found in the HR application.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#157741This update fixes an issue where stock receipt quantity updates weren't accurately reflecting internal transfer quantities, particularly with multi-step receipts. The change ensures that quantity updates correctly update internal transfers, improving inventory accuracy. This resolves discrepancies between received quantities and internal stock levels.
Original PR description
Steps to reproduce: - Enable 2 step reciept in warehaouse settings Bug1: - Create and confirm a PO qty = 1 - Open reciept update qty to 4 and validate - The internal transfer qty is updated to 3 (the…
Steps to reproduce: - Enable 2 step reciept in warehaouse settings Bug1: - Create and confirm a PO qty = 1 - Open reciept update qty to 4 and validate - The internal transfer qty is updated to 3 (the difference) Bug2: - In inventory overview create a new reciept and mark it as todo - Update quantity and validate - Internal transfer is not updated Root cause: Initially in version 17 product_uom_qty was changed to indicate the demand before the move is done and it indicates the acutual done qty when the move is done. After https://github.com/odoo/odoo/pull/130342 product_uom_qty will always indicate the demand qty, and qty_done will always indicate actually done quantity. Fix: updating the quantity will create a new move for the difference that is used to trigger new push rule and then merged back in the original when merging product_uom_qty is not updated to keep track of the intial demand but pending linked moves should be updated to reflect the new quantity opw-3708740 Forward-Port-Of: odoo/odoo#156331
The project task progress bar was incorrectly displaying a value of '1' instead of '100' when timesheets were logged. This update corrects a calculation error that was introduced recently, ensuring the progress bar accurately reflects the percentage of time logged on tasks. This improves the visibility and accuracy of task progress for users.
Original PR description
### Steps to reproduce: - Install **Field service** app. - Go to Field Service app and create a new task, with Allocated Time of 5 hours. - In the new ticket, Log 5 hours in the **TimeSheets** tab. - Go to the tasks list. - Notice how the progress bar of the new task shows **1** _instead_ of **100** although 5 out of 5 hours have been logged. ### Investigation: - 8389722b1abdef029799c3c082a44e30dafb24b1 introduced the new **ProjectTaskProgressBarField** component. - 4a93d9aee957dd3feb3db0cb69eb3b8f0f4a4683 introduced a change to calculate the `task.progress` as a _fraction_ instead of a _percentage_ https://github.com/odoo/odoo/blob/7280dd53bc14f7c398c63a1f719987bcab7c257a/addons/hr_timesheet/models/project_task.py#L102 - But the **ProjectTaskProgressBarField** wasn't adapted to that change working with percentage values. opw-3790397
A recent bug preventing users from previewing email templates on mobile devices has been resolved. This update corrects an error within the email marketing module, ensuring that users can accurately see how their templates will appear on mobile devices when using debug mode. This improves the user experience and allows for more effective email campaigns.
Original PR description
Current behavior: --- When trying to preview a mailing template with the debug mode enabled, there is an error: Invalid props for component Steps to reproduce: --- 1. Enable debug mode with assets 2. Go to Email Marketing 3. Create a new Mailing 4. Select a template 5. In the Editor, click on the mobile icon 6. ... 'preview' is not a function Cause of the issue: --- Caused by https://github.com/odoo/odoo/commit/13b3f8af4b55d32912b698ae1672be9e144cb775 opw-3702901 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153176
This update corrects a formatting issue in the Czech localization for Odoo. It ensures that the Company ID (IČO) is displayed before the VAT ID (DIČ), aligning with Czech reporting standards. The change also clarifies the label for the Company ID to 'Company ID' for better readability.
Original PR description
In Czech republic, the standard is to first render Company ID (IČO), and then to render VAT ID (DIČ). - Changing the position to before (not after), so company ID renders before VAT ID. - Changed label from "ID" to "Company ID" (so it is obvious in what ID it is). Original fixes by @cunivca: odoo/odoo#149339, odoo/odoo#149340, merged into one. Related: https://github.com/odoo/odoo/commit/d0704a19de31e0251d343081ae6b3da9991a248e Forward-Port-Of: odoo/odoo#157993
This update corrects a visual issue where the 'billable' message within the project timesheet was incorrectly positioned. The fix involved refining the system's targeting of the message element, ensuring it appears in the correct location for users. This improves the clarity and usability of the timesheet feature.
Original PR description
Versions: --------- - 17.0 Issue: ------ Message for flag timesheet from project as billable/non-billable is misplaced. Cause: ------ Xpath given for Message placed in sale_timsheet is not very specific. Solution: --------- Give accurate xpath for message div. task-3630449 Forward-Port-Of: odoo/odoo#148880
This update resolves a sporadic failure in a key WebSocket test, ensuring more reliable test results. The fix addresses a timing issue where the test was prematurely evaluating the connection before it was fully established. This improves the overall stability of the Odoo platform.
Original PR description
Before this commit, the `test_websocket_instances_weak_set` was sometimes failing. Indeed, this test doesn't wait for the connection to be fully established before making its assertions. This commit fixes this issue. fixes runbot-55037,55035 Forward-Port-Of: odoo/odoo#157510 Forward-Port-Of: odoo/odoo#157433
This update resolves an issue where a manufacturing smart button was incorrectly displayed during resupply picking for subcontracting orders. The change ensures that this button is hidden, aligning with the intended workflow and preventing potential user confusion. This improves the user experience and data accuracy for subcontracting processes.
Original PR description
Create a [TEST] product: - Routes: - Replenish on Order (MTO) - Buy Assign to [TEST] the following Bill of Material: - BoM Type: Subcontracting - Subcontractors: [Partner] - Components: - [component 1] - [component 2] Components are set up as follows: - Routes: - Buy - Resupply Subcontractor on Order Now create a PO: - Partner: [Partner] - Product: [TEST] Confirm the PO Go to the created resupply picking Issue: there is a smart button for manufacturing The MO should not be visible and the smart button should not be there. opw-3801113
2 changes
Resolved issues and error corrections
Corrected demo planning entries so allocated hours are calculated consistently instead of appearing as zero. This helps sample data better reflect realistic schedules, contracts, and sales planning behavior for demonstrations and testing.
Original PR description
Some planning slots from demo data had allocated hours = 0. For some, it was because the resource had no contract at that period. For others, because they took place on saturdays. Finally, some had an allocated percentage of 0. They where created with allocated hours = 4, but then a `_read_group` called `_compute_allocated_hours`, and because the key `sale_planning_prevent_recompute` was in the context, it was not computed. But then `_compute_allocated_percentage` was called, which didn't make sense, and resulted in weird interactions. task-3321377
This update improves the internal test suite for Odoo's Gantt view by reducing timing-related failures and using more suitable test helpers. It helps make future changes safer and more predictable, without changing day-to-day user features.
Original PR description
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 Community: https://github.com/odoo/odoo/pull/157863 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
33 changes
Resolved issues and error corrections
Fixed an issue where reconciliation group headers were not displaying properly in the accounting module. The system now groups reconciliation records by matching number instead of account reference, resulting in clearer and more user-friendly group headers when reviewing automatic reconciliations.
Original PR description
Since `account.full.reconcile` doesn't have a `display_name`, the header of the group is not displayed nicely. By grouping per `matching_number` instead, we can have a nicer display.
This update resolves memory errors that occurred when installing the Mexican EDI module on large databases. The fix optimizes how payment method information is processed during installation by creating the necessary database column upfront and then properly setting payment method values after the module's data files are loaded, preventing the system from running out of memory.
Original PR description
The computed stored field l10n_mx_edi_payment_method_id of account_move in l10n_mx_edi can lead to MemoryErrors during module installation in some large databases. To fix that, this commit first creates the field's column in _auto_init, avoiding the recomputations that overfill the field_cache and lead to MemoryErrors. Then, since inside the field's compute method the field should be set to a specific payment_method defined in the module's data files, change the post_init_hook to set the payment_method to the correct id in the database after data files loading. I missed it in PR odoo/enterprise#30929 because this field was changed to a computed field starting v15. opw-3018535 Forward-Port-Of: odoo/enterprise#58495 Forward-Port-Of: odoo/enterprise#34974
This fix corrects how withholding amounts are calculated and rounded in Peruvian electronic invoices (EDI documents). Previously, incorrect rounding rules caused the remaining amount after withholding to be miscalculated (showing 1052.20 instead of the correct 1051.38). The fix ensures currency amounts use proper decimal precision and withholding amounts are correctly rounded according to Peruvian tax requirements.
Original PR description
Steps to reproduce: - Install Accounting and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - In Contacts, Configure a bank account (Banco de la nación - BANCPEPL) for PE Company - In…
Steps to reproduce:
- Install Accounting and l10n_pe_edi
- Switch to a Peruvian company (e.g. PE Company)
- In Contacts, Configure a bank account (Banco de la nación - BANCPEPL) for PE Company
- In Accounting settings, run the automatic currency rates service ([PE] SUNAT)
- Create a product: (e.g. Product X)
* Sales Price: 990.00
* Withhold code: Arrendamiento de bienes muebles
* Withhold Percentage: 10.00
- Create an invoice:
* Customer: [a Peruvian contact] (e.g. Comercial Constructora los Patitos S.A.)
* Operation Type: [1001] Operation Subject to Detraction
* Payment terms: End of Following Month
* Journal in: USD
* Invoice Lines:
- Product: Product X
- Account: 7012100 Merchandise - Merchandise - Local sale - Third parties
- Price: 990.00
- Taxes: 18%
- EDI Affect. Reason: Taxed- Onerous Operation
- Confirm the invoice
- Process to EDI service
Issue:
The remaining amount after deducting the withholding is not correct in the generated EDI document.
The total is 990.00 + Taxes (18%) = 1168.20
The withholding is 1168.20 * 10% = 116.82
The remaining amount should be 1168.20 - 116.82 = 1051,38
However, the remaining amount set in the EDI document is 1052,20, which is not correct.
Cause:
The rounding used to compute the withholding amounts are not correct.
The amount in the selected currency should contain 2 decimal digits (precision_rounding should be 0.01, instead of 2).
Also, the Detraction amount should be declared in PEN currency in the EDI document and should not contain the decimal part (precision_rounding should be 1, instead of 2).
opw-3747620
Forward-Port-Of: odoo/enterprise#58473This update fixes how fields are displayed in the Kanban view editor's 'Add' tab. Previously, fields that were added before the main kanban card template were not showing up in the editor sidebar, making it difficult for users to see all available fields. The fix ensures all relevant fields are now properly displayed so users can easily add them to their kanban views.
Original PR description
This commit fixes the way we filter fields to show in the kanban editor sidebar, under the 'Add' tab. Since this view don't render what's included before the <templates> node from the xmlDoc. In other types of view, we can easily toggle the 'Show invisible' elements to display items that are considered being present in the view, but not in Kanban when they add items before the kanban card template. A test has been added too. task-3647045 Forward-Port-Of: odoo/enterprise#58578 Forward-Port-Of: odoo/enterprise#57322
This update fixes a security issue where published articles from private sections were incorrectly appearing in portal users' private sections. The fix ensures that portal users can only see articles they have proper access to, preventing unauthorized visibility of private content.
Original PR description
**Current behavior before this PR:** When a user creates an article in a private section and then publishes it on the web, now if a portal user accesses that link, the article will appear in the private section of the portal as well. **Reason:** There was no specific domain to prevent the portal user from showing private articles of others. **Desired behavior after this PR:** Published web articles will not shown in the portal's private section. **Task**-3486083 Forward-Port-Of: odoo/enterprise#56231
This update fixes a problem that prevented customers from submitting support tickets through website forms in multi-company environments. The issue caused access errors when trying to create tickets, and has now been resolved to ensure ticket submissions work smoothly regardless of company configuration.
Original PR description
Steps to produce: - add new form from editor on website - add action create ticket on it - submit ticket on multi-company environment. Cause: access error while submit ticket with multi-company Solution: access ticket using sudo resolve this issue. task-3635784 Forward-Port-Of: odoo/enterprise#58882 Forward-Port-Of: odoo/enterprise#53389
Fixed a bug where changes made to automation records in Studio were not being saved when closing the editor. The issue was that Studio's internal service wasn't properly syncing unsaved changes with the main application. Now when users create or edit automation records in Studio and close the editor, their changes are properly saved.
Original PR description
In studio, click on the "Automation" menu item. Create, or edit, one base.automation record, and modify some fields. Hit the button "Close" to get out of Studio. Before this commit, the base automation record was not saved. This was because the studio's action service did not receive the clear uncommitted changes from the main one. After this commit, the record is saved when we leave studio. Note that the ViewEditor mode should not be affected as we operate under a clean owl environment in StudioView. Forward-Port-Of: odoo/enterprise#58926 Forward-Port-Of: odoo/enterprise#58862
The availability widget for rental order lines was displaying incorrect information because rental dates weren't being passed to it. This fix ensures rental dates are properly communicated to the widget, so customers and staff see accurate availability information specific to their rental periods.
Original PR description
Previously, the availability widget showed non-rental info, even for rental order lines. This was because the rental dates were never passed to the widget. This commit ensures the rental dates are passed. opw-3700809
This fix ensures that when creating new mass mailing campaigns, the system correctly uses the company's configured email domain settings instead of defaulting to the current user's email. Previously, the email address would only update if you manually changed the mail server setting. Now it properly applies the company's email configuration at the time of creation, ensuring consistent and correct sender addresses for all campaigns.
Original PR description
# Context With 17.0 the `mail.alias.domain` was introduced, allowing the configuration of the bounce, catchall and default from email addresses at the company level (`res_company`). For this purpose,…
# Context With 17.0 the `mail.alias.domain` was introduced, allowing the configuration of the bounce, catchall and default from email addresses at the company level (`res_company`). For this purpose, the `_compute_email_from` method was introduced to correctly compute the `email_from` in various email contexts. But, the `email_from` field in mass_mailing was using an obsolete combination of `default=` and a compute method. This meant that when one created a new `mailing.mailing` record, it was always defaulting to `self.env.user.email_formatted`. The compute was only triggered when the `mail_server_id` field manually updated. This is corrected with this fix and a unit test was added to test three different use cases. An invisible `create_uid` was added to the base mailing From view xml to have the compute method trigger correctly in some unit tests. ## How to reproduce bug: See related github issue https://github.com/odoo/odoo/issues/151310 ## Behavior after this fix: If `mail.alias.domain` is setup for the company and a default `ir.mail_server` is configured for Email Marketing, `_compute_email_from` will select the expected `email_from` at record creation for `mailing.mailing`. opw-3704715 Fixes #151310 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the ability to set receivable and payable accounts as default accounts on miscellaneous journals, which was broken by a previous change. This allows users managing credit card statements to set payable accounts as defaults, eliminating the need to manually select accounts for each transaction entry and improving data entry efficiency.
Original PR description
This commit cleans the domain that defines the default account that can be set on a journal. It first removes the domain that excludes the receivable and payable accounts from the default account,…
This commit cleans the domain that defines the default account that can be set on a journal. It first removes the domain that excludes the receivable and payable accounts from the default account, and we restore the default accounts that could be set on sale, purchase, bank, and cash journals. The domain was broken since this commit: https://github.com/odoo/odoo/commit/3312657294947b1cc8670a0ed3557e12ee6969c8 The following journals must have the following possible default account types: - bank: asset_cash, - cash: asset_cash, - sale: income, income_other, - purchase: expense, expense_depreciation, expense_direct_cost, - general: all account types are possible, The object of the task was mainly to allow misc journals to allow receivable or payable default account type for the following use case: Suppose a user creates a Miscellaneous Journal to manage the details of the credit card statements. Most journal entries will consist of journal items impacting the Payable Account, as this will reclassify the debt towards various vendors and address this debit to the credit card company. It would in that case be necessary that the liquidity_payable accounts can be the default account on the miscellaneous journal. Otherwise, the user will have to fill in manually the account for each line of its credit card statement, and considering there can be a lot, this could become cumbersome. task-3393017
This fix resolves an issue where unlisted Vimeo videos could not be embedded in the website editor using the /video command. The system now properly preserves the access hash parameter when generating video URLs, allowing unlisted videos to load correctly instead of showing an error message.
Original PR description
When the user inserts a video with the `/video` command and provides a link of an unlisted vimeo video, the system generates a new url based on the options selected but omits the hash parameter…
When the user inserts a video with the `/video` command and provides a link of an unlisted vimeo video, the system generates a new url based on the options selected but omits the hash parameter granting access to the given video. As a result, the video can not be loaded and the vimeo `iframe` indicates that the video does not exist. To fix the issue, we will copy the hash parameter from the original link to the newly generated url. That way, the video will be loaded properly and the user will be able to embed unlisted vimeo videos. Steps to reproduce the issue: 1. Install the website app 2. Open the website builder 3. Drag and drop a text block 4. In the text block, type the `/video` command to insert a video 5. In the modal, paste the link of an unlisted video 6. The `iframe` indicates that the video does not exist => The system should extract the hash parameter from the provided url and set it on the generated url. The video should then be loaded properly. task-3697764 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154329 Forward-Port-Of: odoo/odoo#150663
This fix restores the ability for developers to get import suggestions for the OWL library when working in the enterprise version of Odoo. A recent change had inadvertently broken this feature by causing the system to look for OWL in the wrong location. The fix uses a symbolic link approach to ensure the enterprise environment can properly access the OWL library, improving the developer experience.
Original PR description
For some reason, it was not possible to have imports suggestion to OWL in enterprise after commit 62cbb2073922db98df380eacce0b620e1dda9877. My personal opinion about it is that somehow the resolution…
For some reason, it was not possible to have imports suggestion to OWL in enterprise after commit 62cbb2073922db98df380eacce0b620e1dda9877. My personal opinion about it is that somehow the resolution of the `@web` module implied an "hard" resolution of the `@odoo/owl` module but in the community directory (../odoo/node_modules) which was stored in cache. This ought to happen before trying to get completions for anything, i.e. at TSServer loading, as a few loggers in TypeScript indicate that owl is never found. Things I discovered: - delete `odoo/nodule_modules` in enterprise: `@odoo/owl` becomes a suggestion again. - replace the copy of node_modules in enterprise by a symlink to odoo/node_modules (this commit), owl is suggested. - comment the path line of `@web/*` in enterprise/jsconfig.json, owl is suggested. I suppose there is an issue in TypeScript code, without being able to pinpoint it, even after trying to debug it. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where clicking on form field inputs would incorrectly display an empty "Column" editor in the side panel and cause errors when attempting to delete it. The problem occurred because form elements were being mistakenly recognized as columns due to a recent padding option update. This fix refines the selector to exclude form field parts from being treated as editable columns.
Original PR description
Since [1] when the "Padding (Y, X)" option was added, form elements are recognized as columns because they match the `.row > div` selector of that new option. This commit excludes those form elements from this option's selector. Steps to reproduce: - Drop a website form. - Click on field's input. => An empty "Column" editor appeared in the side panel, and an error occurred when trying to delete it. [1]: https://github.com/odoo/odoo/commit/11418cc6f0afcc8e14869f4f38ae0d6d462ac712 task-3748574
This fix corrects how the system identifies which user initiated document sending when the process runs automatically through scheduled tasks. Previously, automated sends would incorrectly show as coming from OdooBot instead of the actual user who requested the send. This ensures proper tracking and attribution of document sending actions.
Original PR description
Some methods were using the `self.env` to decide users/partners while those methods can also be called from Cron, thus the user would end up to be OdooBot instead of the partner that initiated the async sending.
This update allows search view filters to use user-provided values through the self variable, making filters more flexible and dynamic. Previously, the domain property couldn't reference user data, limiting filter customization. Now users can create more sophisticated search filters that adapt to their specific information.
Original PR description
The domain in the search view's field can contain user-provided values, which are accessible via the self variable. Description of the issue/feature this PR addresses: The current version of the domain property in the search view for a field cannot accept user-provided values as the domain value, which is unreasonable. Current behavior before PR: cannot use self variable as user-provided values Desired behavior after PR is merged: can use self variable as user-provided values --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where custom font size settings were not being applied to buttons in the website header navigation menu. When users changed the font size formatting in the header's navbar settings, some buttons were ignoring these changes. The fix ensures all buttons now properly respect the custom font size values set by users.
Original PR description
Steps to reproduce: - Enter in edit mode. - Select the 'Header' menu. - Switch the default template to 'Rounded box menu'. - Select again the 'Header' menu and on the 'Navbar' details, update the format value (i.e: 10px) and save. -> Problem: some buttons are not affected by the change of the format value. The problem is that since [1], those buttons have the `rounded-circle` class so their font size is not the custom one (but it is the value of `$font-size-base` instead). To solve the problem, the css rule has been adapted in order to force the font size of the buttons inside the header to the custom value if it exists. [1]: https://github.com/odoo/odoo/commit/e3e9c492e0d1e009a0c459a1dc591e122b4b65d3 opw-3810794
This fix corrects how down payment sales order line names are displayed when invoices are finalized. Previously, the system would show "Draft" status even after an invoice was posted (finalized). Now the system properly updates the down payment line name to reflect the actual invoice status, ensuring accurate and up-to-date information in sales orders.
Original PR description
Before this commit sol name was not reflacting invoice status when it moved to posted it only reflect draft and cancel state. This commit re-compute downpayment related sol name when invoice related to that sol get posted this way it'll update sol name to proper name instead of keeping always Draft string in it. opw-3768323 Forward-Port-Of: odoo/odoo#157824
Fixed an issue where the image cropping tool in the website editor wasn't responding to mouse clicks and keyboard input. Users can now properly close the crop tool by clicking elsewhere and save their cropped images by pressing Enter, making the image editing experience work as intended.
Original PR description
**Current behaviour before commit:** When trying to crop image in website, 'mousedown' and 'keydown' events are not getting caught. Due to this, - Crop is not getting closed when clicking on document - Cropped image is not getting saved when pressing enter **Desired behaviour after commit:** Now, events are added to the owner document of the crop widget. As result, - Crop gets closed when clicking anywhere in document - Image gets saved when pressing enter. task-3570524 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157763 Forward-Port-Of: odoo/odoo#140108
This fix resolves an issue where users with limited permissions (without full employee access) would encounter an error when creating timesheets for team members on tasks without a company assigned. The system now properly retrieves the employee's company information without attempting to access restricted employee fields, allowing the timesheet to be created successfully.
Original PR description
Before this commit, when the current user did not have `hr.group_hr_user` group and creates a timesheet for an employee in his team, he could get a traceback before one field defined only…
Before this commit, when the current user did not have `hr.group_hr_user` group and creates a timesheet for an employee in his team, he could get a traceback before one field defined only `hr.employee` model cannot be fetched in `hr.employee.public` by the ORM. The reason is because when the user creates a timesheet in a task without any company set, we will take the company of the employee set on the timesheet to set it in the new timesheet, by doing that, the ORM will prefetch the fields of `hr.employee` and returned the company from its cache. This commit makes sure we will not have any issue when we try to get the company of the employee to set in the new timesheet if one field defined in `hr.employee` is not defined in `hr.employee.public` and has to be prefetched by the ORM. Steps to reproduce (in 17+) ================== 0. install `hr_timesheet` and `pos_blackbox_be` modules. 1. create a user A with `hr_timesheet.group_hr_timesheet_approver`, without any access to Employee app 2. create a project and a task without any company set (default value) 3. log in as user A 4. go to the form view of task created in step 2 5. add a timesheet and save the form view Expected Behavior ================= The timesheet should be added in the task and the form view should be saved without any issue. Actual Behavior =============== A traceback is occured saying "The fields 'insz_or_bis_number' you try to read is not available on the public employee profile" opw-3769277 Forward-Port-Of: odoo/odoo#156506
The automatic invoice sending cron job was not properly processing invoices due to incorrect use of the job count parameter. This fix changes how invoices are retrieved to ensure all pending invoices are processed correctly, preventing timeouts and duplicate processing. The update also improves performance and adds proper lock handling to prevent concurrent execution issues.
This fix ensures that when generating electronic invoices (EDI documents), the system now correctly uses the specific invoice address assigned to a customer instead of always defaulting to the main partner address. This resolves issues where custom invoice addresses were being ignored during EDI document creation.
Original PR description
* = facturx, ubl, ubl_cii, ubl_bis3 Problem --------- Currently, the EDI use the commercial partner to craft the XML document. However, this causes issues when users add, for example, an invoice address to a partner. Indeed, the address of the main partner will be used and not the invoice address. This caused issue; see the relevant OPW-3624205. Objective --------- Make sure that the correct address is used when generating the XML. Solution --------- Make sure the commercial partner // partner value is used at the correct spot. - `partner` should be used for addresses - `commercial_partner` for everything else. OPW-3624205 task-3636315 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157856 Forward-Port-Of: odoo/odoo#155896
This fix resolves an issue where search result messages were invisible in dropdown menus when using certain theme colors. When users searched for content that returned no results, the "No results found" message was displayed in white text on a white background, making it unreadable. The fix ensures that text colors in dropdowns automatically adjust based on the background color for better visibility.
Original PR description
Steps to reproduce the bug: - Install the "Blogs" app and go to the "/blog" page. - Click on "Edit" to enter edit mode. - Go to the "Theme" tab. - Select the 4th color from the theme colors and…
Steps to reproduce the bug: - Install the "Blogs" app and go to the "/blog" page. - Click on "Edit" to enter edit mode. - Go to the "Theme" tab. - Select the 4th color from the theme colors and choose "black". - Save the page to exit edit mode. - Perform a search in the search bar input that yields no results, for example: "zzz". - Bug: The message "No results found. Please try another search." is not visible because it is displayed in white on the white background of the dropdown. A previous commit [1] had already addressed the issue for the "Search" snippet that can be dropped into a page, but this fix wasn't sufficient to solve the problem everywhere. Indeed, the text-muted in a dropdown should be adjusted in all cases and not just for snippets; it's a Bootstrap issue. The text-muted color should be adapted to the background color of the dropdown. [1]: https://github.com/odoo/odoo/commit/f9bf40cb53cf487c8736c1f565c2f0d3834acd5e task-3662985 Forward-Port-Of: odoo/odoo#157731 Forward-Port-Of: odoo/odoo#156029
This update fixes a layout issue in the Mass Mailing email editor where the snippet menu was appearing misaligned at the top of the form. The fix ensures the mail body displays properly formatted, improving the user experience when creating and editing mass mailing campaigns.
Original PR description
Before this PR: The snippet menu in the Mail Body appeared on the top of the form, causing misalignment. Technical details: - This problem was observed in the `view_mail_mass_mailing_form` form and all other views inheriting from it. - The fix involves adding the `o_mass_mailing_iframe `class using the `iframeHtmlClass` attribute on the body_arch field. After this PR: The layout is now aligned. This PR targets up to 17.0, for further versions the issue has already been resolved. task-3603623 Forward-Port-Of: odoo/odoo#157864 Forward-Port-Of: odoo/odoo#152996
This fix corrects the employee count shown on partner records to accurately reflect the number of employees associated with each partner based on selected companies. When viewing partner details, the employee count button now displays the correct number and opens a proper employee list view for easy access to employee information.
Original PR description
This will fix the number of employees in the partner view and redirect to a kanban view of the employees. The smart button on the partner view for the number of employees related to this partner now gives the correct number depending on the companies selected. If multiple employees are related, the action shows a kanban view of those employees. Task: 3693173 Forward-Port-Of: odoo/odoo#157537 Forward-Port-Of: odoo/odoo#154162
This update fixes an intermittent test failure in the stock accounting module by making the search criteria more specific. The test was sometimes failing because it wasn't properly isolating the account record it needed to verify, which has now been corrected to ensure reliable and consistent test results.
Original PR description
The account move search was not enough specific to retrieve only one account move. The following `assert` sometimes failed because of this. This commit reinforces to search to get only one account move opw: runbot error 60338 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#158050
This fix resolves an issue where the system was incorrectly checking access rules when creating new records. The system is now designed to skip access rule validation for new records, allowing automated actions (like onchange events) to work properly without being blocked by security restrictions. This ensures a smoother user experience when creating new items in the system.
Original PR description
This fixes an issue where access rules are checked on a new record: the rule domains are evaluated with method `filtered_domain()`, and one rule uses the operator `'child_of'`, which is implemented with a call to `search()`. When used with a new record, `filtered_domain()` returns an empty recordset instead of the record itself. By design, the ORM doesn't check security on new records. A base automation of type `'onchange'` will run some server action on a new record. The server action may still check access rights on the model, but should not check access rules.
This fix ensures that when creating an alternative purchase order from a request for quotation, the vendor taxes are properly calculated on all line items. Previously, taxes were not being computed when using the alternative creation feature, even though they would be calculated correctly if the purchase order was created manually. This update makes the behavior consistent across both methods.
Original PR description
Steps to reproduce: - - Create a request for quotation for a product with set vendor Taxes - Create an alternative purchase order from that RFQ with Copy Product Current Behavior: - The purchase…
Steps to reproduce: - - Create a request for quotation for a product with set vendor Taxes - Create an alternative purchase order from that RFQ with Copy Product Current Behavior: - The purchase order line of the PO associated with the created alternative does not compute the taxes. Expected behavior: - The taxes should be computed in the same way as if the PO was created manually and then linked to the alternatives. Cause of the issue: - When creating a PO manually, the taxes of each purchase order line are computed when the product is set during the call of the `onchange_product_id` onchange method: https://github.com/odoo/odoo/blob/64c13193ae0fe23eb1b426f5bbcd8531e9a40967/addons/purchase/models/purchase.py#L1221 https://github.com/odoo/odoo/blob/7ed0a773b6e0711b127f236ce665c35202d973bc/addons/purchase/models/purchase.py#L1055-L1061 By contrast, PO created from the `action_create_alternative` generate each `purchase.order.line` using `Command.create`. Therefore these lines will not trigger the onchange method and their taxes will not be computed. Fix: - To KISS, we compute the taxes of each line just after the creation of the record using the `_compute_tax_id` method. opw-3750719 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155060
This fix resolves an issue where activity feedback was appearing twice in the activity log when marking a calendar event as done. The problem occurred because the system was syncing the event description with activities, causing feedback to be logged twice. The fix ensures the activity is logged first before updating the event description, eliminating the duplication.
Original PR description
How to reproduce: - install crm - open a lead - create an activity call or meeting (and schedule it in the calendar) - mark it as done with a feedback The activity log in the chatter contains the feedback twice and shouldn't. The problem was caused by the synchronization of the event description with the related activities. When marking an activity as done, the event description is updated with the feedback which in turn update the activity note with the feedback. When logging the activity done in the chatter, the note and the feedback are logged leading to a duplicate feedback. We solve this by first logging the activity done in the chatter before updating the event description. Task-3653088 Forward-Port-Of: odoo/odoo#157930 Forward-Port-Of: odoo/odoo#147898
This update fixes an issue where barcode scanning wasn't working properly on mobile Chrome browsers. The fix adds a missing jQuery library dependency that the barcode service requires to function correctly on mobile devices.
Original PR description
The barcode service using jquery for chrome on mobile is not working properly without jquery included, we include it here task-3817495
This fix resolves an issue where TikTok icons inserted into email marketing templates were not displaying correctly when the campaign was sent. The problem occurred because the system wasn't properly converting the icon's CSS class into an image format for email delivery. Users can now successfully add and send TikTok icons in their mass mailing campaigns.
Original PR description
Since commit [1], the new tiktok icon is added to odoo but the conversion of the css class into an image is not supported. This commit ensures that the conversion is correctly handled. Steps to reproduce: - Open the mail marketing app - Create a new mass mailing - Insert an icon in the template, for instance type /image in the text and select the "Pictogram" tab - Search for tiktok icon and insert it - Send the mass mailing - The icon will not be found in the mail [1]: https://github.com/odoo/odoo/commit/515915b9 Forward-Port-Of: odoo/odoo#157937 Forward-Port-Of: odoo/odoo#157919
This fix resolves a database query error that occurred when both the HR Holidays and Auth Signup modules were installed together. The error prevented the system from correctly identifying which employees are currently on leave. The fix clarifies which data field to use in the query, ensuring the leave tracking feature works reliably regardless of which modules are enabled.
Original PR description
Issue addressed by this commit: An ambiguous column error occurs in the hr_holidays model when the auth_signup module is installed alongside it, due to both modules having a state field. This…
Issue addressed by this commit: An ambiguous column error occurs in the hr_holidays model when the auth_signup module is installed alongside it, due to both modules having a state field. This ambiguity arises within the _get_on_leave_ids method, affecting the execution of a SQL query designed to identify users on leave. How to reproduce the issue: Install both hr_holidays and auth_signup modules. Attempt to execute the _get_on_leave_ids method to identify users on leave. Behaviour before this commit: An "ambiguous column error" is raised due to the SQL query not specifying which state field to use, leading to confusion between the state fields in the hr_leave and res_users tables. Expected behaviour: The SQL query should clearly reference the state field from the hr_leave table, avoiding ambiguity and accurately identifying users on leave without errors. Solution: The SQL query within the _get_on_leave_ids method has been updated to use hr_leave.state = 'validate' for clear distinction, resolving the ambiguous column error. opw-3770758 Forward-Port-Of: odoo/odoo#156663
This fix resolves a timing issue where the push-to-talk extension feature was not being properly detected during video calls. The system was ignoring responses from the extension if they arrived before the call service fully started, causing the feature to appear unavailable. This update ensures the extension is correctly recognized regardless of timing.
Original PR description
The push-to-talk extension service sends a message to the extension when starting to check if it is enabled. If the response is received before the RTC service is started, the answer is ignored, and the service acts as if the extension were not available. This PR fixes this issue.
PayPal was rejecting the access token parameter name, causing users to see an incorrect "log in again" error message. This fix renames the parameter to properly handle transaction cancellations, ensuring users can successfully cancel PayPal payments without authentication issues.
Original PR description
PayPal refuses to take access_token name parameter and throws an error to user that they need to log again. Since the Access Token is neeeded to cancel transaction, it is renamed to return_access_token. opw-3810686 Forward-Port-Of: odoo/odoo#157974