Wednesday, April 24, 2024
34 changes
2 changes
Resolved issues and error corrections
Stock operation types must now have default source and destination locations set when configured. This prevents inventory moves from being created without a valid destination, reducing errors in warehouse processing after recent routing changes.
Original PR description
Since the pull&push refactor, the `location_dest_id` of a stock.move is now computed, based on its picking or picking type. It raises an issue, as a picking type can be created without a `default_location_dest_id`. This implies that a move can be created without any destination (no picking yet and picking type has no default dest), which makes no sense. Since we're in stable version, we can only enforce it on the client-side, a real requirement will be set in master. As we enforce the `default_location_dest_id`, we also enforce it for `default_location_src_id` for consistency's sake, even though it is far less critical. Doing so also means providing a compute that will give a default source/destination location regardless of the picking.type's `code`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves Odoo's internal HOOT testing framework and adjusts related tests in Mail, Live Chat, and Web. It helps developers catch problems more reliably without changing normal business workflows for end users.
Original PR description
## Pull Request HOOT (PRHOOT) - part 15 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 15 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 Enterprise: https://github.com/odoo/enterprise/pull/59971 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
4 changes
Resolved issues and error corrections
This fix adjusts accounting report tests so they can correctly generate report templates that include images or other assets. It helps prevent test deadlocks and improves the reliability of automated checks without changing business functionality.
Original PR description
When a template is rendered wkhtmltopdf kicks-in in a subprocess and makes HTTP GET requests for all the assets / images found inside the document. For those HTTP requests to succeed (1) the web server must up and running, (2) the cursor must be the same for serving the HTTP request and for running the test. (1) is achieved by running the test post-install as the web server is started after at-install tests and before post-install ones. (2) is achieved by being in "test mode", a mode where all new registries (no what the current thread) will reuse a same cursor (typically the one used by the test). The registry is automatically in test-mode when using the HttpCase test class. When the TransactionCase class is in-used, entering/leaving the test mode must be done manually. --- Related to community PR: https://github.com/odoo/odoo/pull/161438 The introduction of a new lock on inside the threaded-server to solve a long-running odoo-sh bug made those tests deadlock.
19 changes
Resolved issues and error corrections
This update adds support for the asbestos/work accident contribution (amiante) to the Belgian payroll DmfA reporting system. Belgian employers are now required to report this special contribution to social security authorities, and this fix ensures the payroll system correctly calculates and includes this contribution in the DmfA declarations.
Original PR description
https://www.socialsecurity.be/employer/instructions/dmfa/fr/latest/instructions/special_contributions/other_specialcontributions/asbestosfunds.html
This fixes broken color highlighting in the Manufacturing Master Production Schedule after a Bootstrap upgrade. Users should again see the intended subtle background colors that help distinguish planning lines and statuses.
Original PR description
With the upgrade to bootstrap 5.3 in odoo/odoo#158560, using `alert-` alone does not work anymore. It was already the wrong use of `alert-` since it is not supposed to be used to change background colors. This PR replaces `alert-*` with `bg-*-subtle` to repair the broken behavior.
The paper-related setting for self-order preparation displays was moved out of the general preparation display area and into the correct self-order module. This prevents the setting from appearing or being used where it does not apply, reducing configuration confusion and avoiding incorrect behavior.
Original PR description
pos*: pos_preparation_display, pos_self_order_preparation_display A previous commit (odoo/enterprise#59959) has introduced a field `has_paper` in the pos_config. This field is introduced in the module pos_self_order and should only be used in this context. The problem here is that it was used in the pos_preparation_display module which is not correct. This commit fixes this by moving the changes brought by the first commit in the correct module 'pos_self_order_preparation_display'.
This fix improves how Odoo handles inherited view conditions that combine rules with “and” or “or”. It helps prevent false errors or unintended changes when customizing views in affected business apps.
Original PR description
The inheritance for python expression can use 'and' and 'or' separator. The expression will automatically wrapped by parenthesis to avoid any alteration of the previous expression. task-3433721 liked merged pr: #104741 https://github.com/odoo/odoo/pull/161129
This update aligns the Belgian employment bonus calculations with the new 2024 government system that took effect April 1st. The changes ensure employees receive the correct bonus amounts under the updated rules, which include revised thresholds and calculation methods as mandated by Belgian social security authorities.
Original PR description
Sources: https://www.socialsecurity.be/employer/instructions/dmfa/fr/latest/intermediates#bonus-a-l-emploi-plafonds-apres-l-augmentation-du-rmmmg-et-la-scission-du-calcul-29-03-2024 https://www.ucm.be/actualites/le-bonus-lemploi-renforce-au-1er-avril-2024#:~:text=Qu'est-ce%20que%20le,salaire%20net%20effectif%20est%20augment%C3%A9
This fix corrects the module assignment for maintenance worksheets, which was preventing proper cleanup when uninstalling the maintenance module. Previously, database entries would remain after uninstalling because the system couldn't identify all related records to remove. This ensures a clean uninstall process.
Original PR description
Since the wrong module set on the maintenance worksheets, this would lead to issues when trying to uninstall the maintenance module, as it wouldn't find every models to uninstall. This ended up leaving some entries in the database after the module was removed. runbot-57422
Fixed an issue where the timer was incorrectly appearing in the All Timesheets kanban view. The timer should only be visible in the My Timesheets view. This fix uses a context flag to properly hide the timer header in the shared kanban view while keeping it available where it's needed.
Original PR description
Steps to Reproduce: - Install Timesheets app - Navigate to All timesheets from the header menu - Click on kanban view Issue: - Timer is present in the All timesheets Kanban view Causes: - Timer is present in the All timesheet kanban view because this view is inherited in my time sheets. Solution: - Using the context that is only used in MyTimeSheet Action window to hide the timer header (my_timesheet_display_timer) task-3741260 Forward-Port-Of: odoo/enterprise#56581
This fix resolves an issue where Sendcloud shipping with pick-up locations was failing due to incomplete delivery addresses. The house number was not being included when creating customer addresses, causing Sendcloud to reject the shipment. The update now ensures the complete address, including house number, is properly captured and sent to Sendcloud.
Original PR description
Steps to reproduce: 1. Configure Sendcloud shipping with pick-up location 2. Go to website, use the shipping method and select a pick-up location 3. Go to the backend, confirm the sale order and validate the delivery 4. Get Error from Sendcloud that the `house_number` is required If we check the delivery address, we see that the house number is not taken into account when creating a new partner, and the address is incomplete. This commit adds the house number to the `street` field of the address to have a complete address. opw-3864382
This update fixes a performance issue in the Appointment module's test suite where an extra database query was causing test failures in no-demo mode. The fix ensures the automated testing process runs smoothly without unnecessary database calls that could impact system performance.
Original PR description
A single additional query makes runbot break. runbot-62073 Forward-Port-Of: odoo/enterprise#61347
This update fixes visual issues with form inputs across the website and web modules to make them clearer and more consistent. Disabled input fields are now more visually distinct, dropdown carets are more visible on dark backgrounds, and checkboxes/radio buttons maintain readability with custom theme colors. These changes improve the user experience when interacting with forms and product configurations.
Original PR description
### Adjust disabled input colors (*1) 1. Maintain border consistency of frontend inputs : Prior to this PR, `form-select` borders overlapped the background color, which is not the case with…
### Adjust disabled input colors (*1) 1. Maintain border consistency of frontend inputs : Prior to this PR, `form-select` borders overlapped the background color, which is not the case with `form-control`. This is because `form-control` uses the `background-clip` property. As we're using a semi-transparent border on frontend inputs, this creates a color issue: when a `form-select` input is disabled, the border color is darker than that of the `form-control`. This PR adapts the `background-clip` on `form-select` input to maintain color consistency between inputs. 2. Make disabled inputs more recognizable : Prior to this PR, disabled inputs were not sufficiently distinct from regular inputs, especially `website_sale` inputs which had a gray background. **Steps to reproduce:** - Make sure your instance has`website_sale_renting` installed. - Go to the Shop page. - Look for a product with a rental period (eg. Printer). - Click on Add to cart, this will disable the rental period input. - -> The gray search bar and the disabled input have almost the same style This PR adapts the style of disabled inputs in the frontend to make them more recognizable. --- ### Adjust dropdown caret color (*2) Prior to this PR, dropdown inputs had a color issue in frontend: the caret color of `form-select` was dark regardless of the input's background and didn't provide enough contrast when we defined a dark background on the page. **Steps to reproduce:** - Go to the Contact page. - Click on Edit. - Click on Theme tab. - Replace the fourth color with a dark one (ex. black). - Click on the form in the page. - Add a field. - Select the new field and choose the "Selection" type. - Click on Save. - -> The dropdown caret is not enough visible. --- ### Adjust `form-check-input` colors (*3) This PR adjusts the caret color to make sure that this will be always visible. Prior to this PR, checkboxes, radios and switch inputs had a color issue in frontend: as the inner element (eg. check mark) was always white if the user changed the primary color to a bright one, the inputs were no longer readable. **Steps to reproduce:** - Go to the Contact page. - Click on Edit. - Click on Theme tab. - Replace the primary color with a bright one (ex. light gray). - Click on the form in the page. - Add a field. - Select the new field and choose the "Radio Buttons" or " Checkbox" type. - Click on Save. - Check the checkbox or the radio button. - -> The check mark or the dot is not visible enough. This PR adjusts the colors to ensure that these inputs will always be visible. --- ### Adjust `form-range` track color (*4) Prior to this PR, the `form-range` track color used the light color. This created a color inconsistency with the rest of the UI when we changed the third color. **Steps to reproduce:** - Go to the Shop page. - Click on Edit. - Click on the page and make sure "Price Filter" is active in the Web Editor. - Go to Theme tab. - Change color-3 (light) to another one (eg. red). This PR adjusts the color to maintain consistency with the rest of UI elements --- ### Adjust custom dropdown caret (*5) Prior to this PR, the custom dropdown caret in the `website_sale` sidebar didn't handle the "multiple" attribute, unlike the default dropdown. If we decided to add a "multiple" attribute to this element, the caret remained displayed, which created a design issue. This PR adapts the caret of this dropdown so that it works correctly when this attribute is defined. --- task-3702675 --- | (*1) | Before | After | | -- | - | - | | Portal |  |  | | Website (light bg) |  |  | | Website (dark bg) |  |  | | (*2) | Before | After | | -- | - | - | | Adjust dropdown caret color |  |  | | (*3) | Before | After | | -- | - | - | | Adjust `form-check-input` colors |  |  | | (*4) | Before | After | | -- | - | - | | Adjust `form-range` track color |  |  | | (*5) | Before | After | | -- | - | - | | Adjust custom dropdown caret |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where saving document layouts with tabs in the footer or HTML fields would fail when switching between different browsers. The problem occurred because tab formatting wasn't being properly recognized during the save process, causing errors. The fix ensures that formatting changes are detected correctly from the start, preventing save failures when users work with the same document across multiple browsers.
Original PR description
Issue: ====== If you have some tabs in a html_field, opening with a different browser may cause an issue when saving the document layout. Steps to reproduce the issue: ============================= -…
Issue: ====== If you have some tabs in a html_field, opening with a different browser may cause an issue when saving the document layout. Steps to reproduce the issue: ============================= - Open with firefox - Go to settings , document layout - Added some `tab` in the footer or any html field - save - Open with chrome - Go to settings , document layout - click save without doing anything - error Origin of the issue: ==================== When calling sanitize in the constructor, the tabs size doesn't change because we didn't add the class `odoo-editor-editable` which doesn't make the `editable` dirty since no changes has been made. When calling save, `cleanForSave` will be called with a clone of the `editable` so in sanitize it won't matter since the element is not connected to the dom so again no changes and the edtior still no dirty, after that , `onWillUpdateProps` of `Wysiwyg` will be called and we will set the value of the editor by the new value which will call `resetContent` of `odooEditor` and it will sanitize the editable but this time it has the class `odoo-editor-editable` so the finally the sizes of the tabs will be changed and the editable will become dirty. Now `onWillUnmount` in `html_field` will be called and since the field is dirty it will commit changes as a normal save , but a traceback will occur since the component is already destroyed. Solution: ========= Add the class `odoo-edtior-editable` before the call to sanitize to mark the field as dirty from the start and will be updated with the new sizes of tabs on the first commit and not in the commit of `onWillUnmount`. opw-3742423
This fix corrects how project status displays sales order items by filtering out section headers and notes that don't represent actual products or services. Previously, these non-billable line items were incorrectly appearing in the project overview, cluttering the profitability and time investment analysis. The fix ensures only relevant sales items are shown to help managers better understand project performance.
Original PR description
## Reported issue ### Steps to reproduce: Be sure that 'industry_fsm' is installed. - Go to Project > Projects and swap to the list view - Create and save a new project with a customer - Access the…
## Reported issue ### Steps to reproduce: Be sure that 'industry_fsm' is installed. - Go to Project > Projects and swap to the list view - Create and save a new project with a customer - Access the related SO via the smart button - Add a service product, a storable product a section and a note - Go back and access the project status with the smart button #### > The SOL generated for the section and the note appear as SO items ### Expected behavior: The purpose of the project status tab is to have an overview at the project to help in the analyse its profitability, the time investment,... as such, these SOL should not be considered as SO items. In addition, these lines lose their entire purpose in the list view used in this overview (they can not be moved and display irrelevant infos). ### Cause of the issue: These lines were not filtered out by the current query. ## Second Issue: ### Steps to reproduce: Install only the "project" and "sale_management" module and reproduce the same flow as above. #### > Only the service product is displayed as a SO items. ### Cause of the issue: Since the onchange method: https://github.com/odoo/odoo/blob/f72968561acec164697a7a9ee0965ec304854dd5/addons/sale_project/models/sale_order.py#L124-L128 is triggered before an analytic account is linked to the project, the sale order created in our flow will not be linked to an `analytic_account_id`. In particular, as this value is null in the DB and is not computed it can not be relied on here: https://github.com/odoo/odoo/blob/7f5f2963966f5a3bcfeb4bede0f9d956fff6e831/addons/sale_project/models/project.py#L341 to define the SQL query fetching our SOL. ##### Note: If the `industry_fsm` module is installed, the second issue do not happen because an analytic account is linked to the project before the trigger of the onchange method. In particular, since the behavior of this flow is different with additional modules installed we added both a test "at install" and a test "post install". opw-3794386 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue in Odoo's template engine (QWeb) that was incorrectly closing XML elements with namespaces like <g:link>. The system was treating namespaced elements the same as standard HTML void elements, preventing proper nesting of content. This fix ensures that namespaced elements are handled correctly, allowing developers to use XML namespaces in templates as intended.
Original PR description
Until now, it is impossible to do <g:title>xxx</title> because qweb will autoclose the <g:link> because it checks if link is a void element instead to check g:link. Now we check the el_tag instead of unqualified_tag. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where empty receipts were being printed twice when customers add tips after payment in restaurant POS settings. The problem occurred because the tip receipt template was missing the total amount display, and the system wasn't properly handling cases without a physical printer. This improvement ensures receipts only print when they contain actual data.
Original PR description
### Steps to reproduce:
- Install **POS** app.
- Go to **POS** settings and enable:
- Is a Bar/Restaurant
- Tips > Add tip after payment
- Open a POS session -if first time, add a floor and a table-
- Add a product
- Click on **payment**
- Choose a payment method
- Click on **Close Tab**
- The print popup is shown twice in a row with an empty receipt.
### Investigation:
Investigation:
- Inside the `TipReceipt` template, the `total` is not shown as the class lacks a getter for it https://github.com/odoo/odoo/blob/1d49034782e3ff0e4384bad4e927a895e2a97839/addons/pos_restaurant/static/src/app/tip_receipt/tip_receipt.xml#L13-L16
- Also when there is no printer, we won't fallback to the web printer as it's annoying to the cashier.
opw-3836549This fix resolves an issue where cost of goods sold (COGS) entries were not being created when processing partial downpayments on sales orders with real-time inventory valuation. The system now correctly recognizes when to generate COGS entries even when credit notes with negative quantities are involved, ensuring accurate financial reporting for inventory costs.
Original PR description
Usecase to reproduce: - Product wiht a real time valuation - Product with invoice on delivered quantity - Create a SO for 5 units and 1000$ each - Do a full downpayment of 100% of quotation - Deliver 3 out of 5 units and create a backorder - Create an invoice - Validate the invoice Expected behavior: The cogs entries are there Current behavior: No cogs It only happens with partial downpayment. When the downpayment amount equals the quotation amount. An invoice is created instead of a credit note and the process works correctly. It happens because it creates a credit note with a negative quantity to invoice so the system doesn't understand it has to create the cogs at that point. 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#161098
When downloading multiple invoices as a ZIP file, the Factur-X XML files were being overwritten because they all had the same generic filename. This fix ensures each invoice's XML file has a unique name so all files are properly included in the download. Users can now successfully download complete invoice packages with all corresponding XML documents.
Original PR description
Context: in 17.0 we enabled mass download for invoices. We expect this download to create a zip with all PDF invoices and their related xml files. Steps to reproduce: 1. Install l10n_fr 2. Create two invoices to french partners 3. Send & Print the two invoices and select 'Factur-x" and "Download" 4. A .zip file is generated with two PDF but only **one** XML file "factur-x.xml" Cause: The name of the XML file for the factur-x XML file is not specific to related invoice, it gets overriden each time it is generated. See: https://github.com/odoo/odoo/pull/137382 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 fixes a bug where single-value graphs were not displaying correctly in cumulated graph views. The issue was caused by a technical ordering problem that resulted in invalid calculations. Users will now see all their graph data properly displayed in cumulated views.
Original PR description
Single value graph were not shown in cumulated graph. This is due to unshift happening before the accumulator, leading to `undefined + X = NaN` for the value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162247
This fix resolves an issue where event privacy settings marked as 'Available' in Odoo were not being properly synchronized to Google Calendar. Users will now see their privacy preferences correctly reflected across both Odoo and Google Calendar, ensuring consistent calendar management across platforms.
Original PR description
### Version - 16.0 ### Steps to reproduce - Create a event from odoo calendar with privacy 'Available' - Open google calendar and open that event ### Issue - When the user sets privacy as 'Available' in Odoo, it is not properly synchronized in Google Calendar. ### Solution - Syncing privacy value changes between odoo and Google Calendar will be correct after this commit by passing the `transparency` value. task-3667696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157545
This fix resolves an issue where UBL invoice exports were incorrectly generating validation errors when processing invoices for customers with separate invoicing addresses. The fix adjusts how the system validates customer information during the export process, ensuring that properly configured customers no longer trigger false error messages.
Original PR description
Problem --------- Because of this PR: 155896, the customer default value for the UBL export values has been modified from commercial partner to partner. However, in 16.0+, some constraints have been added to verify that some fields were properly set up before generating the XML. Those restrictions clash with the said changes. Indeed: 1 - Create NO company 2 - Set up UBL on invoice journal 3 - Create a new NO customer and set up UBL in the same way 4 - Create an invoicing address for that customer 5 - Create an invoice for with the customer set as the invoice address set up in step 3. 6 - Send & Print with UBL selected >> An error is added to the export errors while it should not. Solution --------- Use the commercial partner when checking constrains of all fields other than addresses. OPW-3848367 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162366 Forward-Port-Of: odoo/odoo#160523
Fixed a test failure in the survey module related to duplicate session codes. When creating multiple surveys at once, each survey requires a unique session code. This fix ensures the test properly handles the uniqueness requirement, preventing test failures that could mask real issues.
Original PR description
Surveys cannot be created in batch without `session_code` because it must be unique across surveys. Technically, using a 5-digit codes makes it unlikely that a collision occurs with records created without explicit session_code (see Survey._get_default_session_code's iterative process). See runbot 55709 See also related runbot 25041 Task-3829536 Forward-Port-Of: odoo/odoo#159882
This update resolves a visual display problem in the Activity view where the activity counter badge was overlapping with the activity deadline information. The fix improves the layout by adjusting the styling of activity cells, making it easier for users to see both the activity count and deadline clearly when multiple activities are scheduled for the same day.
Original PR description
**Steps to reproduce:** - Go to activity view. (Ensure that it has at least 10-12 activity types) - Schedule multiple activities for the same day. - Activity count badge overlaps activity deadline! **Before this PR:** Activity count badge overlaps the activity deadline in an activity cell. **After this PR:** The issue has been resolved by tweaking the CSS of Activity Cell. Task-[3818264](https://www.odoo.com/web#id=3818264&menu_id=4722&cids=2&action=333&active_id=10888&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#162573 Forward-Port-Of: odoo/odoo#158512
This fix corrects an issue where expenses created via email alias would be assigned to the wrong employee when a user has multiple employee profiles. Previously, the system would select the first employee record instead of the correct one based on the user's default company setting. Now expenses are properly assigned to the right employee, preventing errors and ensuring accurate expense tracking.
Original PR description
[FIX] hr_expense: select the right employee for an expense created with alias Current behavior: When trying to create an expense using alias, if there's several `hr.employee` linked to a user, it select the first one instead of this with the right company Steps to reproduce the error : - Create different employee's profiles for a same user - Put the default one on the user's profile (don't put the first that you created because it will select the first for the expense) - Try to send an email to the expense's alias and check at the logs After this commit: The right employee (this one in the default company) will be selected and no error will be triggered opw-3754015 Forward-Port-Of: odoo/odoo#161853