Daily updates from Odoo
Tuesday, January 21, 2025
18 changes · master
Enhancements to existing features
Changes made through the Edit Payslip Lines wizard are now recorded in the payslip chatter. This improves transparency and makes it easier for payroll teams to review who changed payroll line values and what was updated.
Original PR description
When you change the values of lines in the 'Edit Payslip Lines' wizard, the changes are not logged in the chatter. Now, the changes made when editing payslip lines will be logged. task-4353585
Resolved issues and error corrections
The Appointments website block now keeps any custom destination set for its “See all” link after the page is saved. This prevents visitors from being sent back to the default appointments page when the website editor intended the link to point elsewhere.
Original PR description
Steps to reproduce: - Install the appointments module. - Go to the homepage. - Enter edit mode. - Drag and drop a "Appointments" block onto the page. - Click on the "See all" link. - Edit the link (e.g., change "/appointment" to "/contactus"). - Save the page. - Click on the "See all" link. - Bug: You are redirected to the "/appointment" page instead of the "/contactus" page as expected. The bug occurs since commit [1], where the "See all" link was added to "Dynamic" snippets. Each time a "Dynamic" snippet is rendered during a page load, the href of the "See all" link is reset to the main module page. While this behavior is useful when the snippet is first rendered after being dropped onto the page, it is problematic afterward. Once the user has edited the link with a different href, it should not be reset on every page load. [1]: bbcff74 opw-4418048
This fix prevents Odoo Studio from triggering background updates when a user edits a view for a model where they do not have permission to create records. This avoids unnecessary warning messages and makes Studio behave more smoothly for users with restricted access.
Original PR description
This commit adapts studio for commit odoo/odoo@74c5cd56a0539edab6a61efa517ca6a08c08d915 which prevents doing an onchange if the user doesn't have create access on the model. Before the present commit, there were warnings in some cases because we tried just that: opening studio to edit a form view without a record, on a model on which there was no create access rights. After the present commit, we prevent such cases using the view's activeActions. runbot-error-112212
Miscellaneous changes
This commit fixes the second query count in `test_visible_menu_ids` where it is sometimes 1 if `account_reports` is not installed (the xmlid is never cached since it does not exist yet) Runbot Error 109492 Forward-Port-Of: odoo/enterprise#77405
Original PR description
This commit fixes the second query count in `test_visible_menu_ids` where it is sometimes 1 if `account_reports` is not installed (the xmlid is never cached since it does not exist yet) Runbot Error 109492 Forward-Port-Of: odoo/enterprise#77405
This PR fixes two accessibility issues related to the gantt view connectors. Prior to this commit, the connectors were using the raw value when hovering the pill. This is mostly fine is light mode, but for some specific color, this was sometimes not enough to ensure a good visual separation between the connectors and the pill. To handle this issue, we add a pseudo element underneath the border, to make it stand out and prevent all the potential contrast issues. There was also a `z-index` is
Original PR description
This PR fixes two accessibility issues related to the gantt view connectors. Prior to this commit, the connectors were using the raw value when hovering the pill. This is mostly fine is light mode,…
This PR fixes two accessibility issues related to the gantt view connectors. Prior to this commit, the connectors were using the raw value when hovering the pill. This is mostly fine is light mode, but for some specific color, this was sometimes not enough to ensure a good visual separation between the connectors and the pill. To handle this issue, we add a pseudo element underneath the border, to make it stand out and prevent all the potential contrast issues. There was also a `z-index` issues with the connectors, the one at the bottom being hidden by the pill below. To fix the issue, we handle the `z-index` at the pill wrapper level to ensure it gets the right elevation. | 17.0 | This PR | |--------|--------| | <img width="366" alt="image" src="https://github.com/user-attachments/assets/f14d3c98-c2d5-4215-90ec-3cbe97b3ea56"> |  | task-3865935 Forward-Port-Of: odoo/enterprise#77420 Forward-Port-Of: odoo/enterprise#74859
**Issue:** In 17.0 and saas-17.2, The Cost of Scrap section does not appear in the the Cost Analysis Report despite having scrapped some components during manufacturing. **Steps to reproduce:** 1. Create a product with a BoM 2. Manufacture the product 3. Scrap some components during manufacturing 4. print the Cost Analysis Report 5. Notice the cost of scrap section does not appear in the report. **Solution:** - I added `raw_material_production_id` t
Original PR description
**Issue:**
In 17.0 and saas-17.2, The Cost of Scrap section does not appear
in the the Cost Analysis Report despite having scrapped some components
during manufacturing.
**Steps to reproduce:**
1. Create a product with a BoM
2. Manufacture the product
3. Scrap some components during manufacturing
4. print the Cost Analysis Report
5. Notice the cost of scrap section does not appear in the report.
**Solution:**
- I added `raw_material_production_id` to the search criteria to ensure scrap stock moves linked to raw materials are also included.
- I replaced `product_qty` with the `quantity` field for handling scrap quantities.
opw-4183097
Forward-Port-Of: odoo/enterprise#77451
Forward-Port-Of: odoo/enterprise#75221This commit makes sure that, in tax report, when tax_period is used to determine the report date, and when the tax_period periodicity matches one of the 3 standard filters (month, quarter, or year), that the correponding standard filter is selected with the right date set on it. Before this commit, the default date filter of the tax report would make use of the tax_period to set its date. The date was set properly, but the tax_period date filter would be hidden in case the periodicity matches
Original PR description
This commit makes sure that, in tax report, when tax_period is used to determine the report date, and when the tax_period periodicity matches one of the 3 standard filters (month, quarter, or year), that the correponding standard filter is selected with the right date set on it. Before this commit, the default date filter of the tax report would make use of the tax_period to set its date. The date was set properly, but the tax_period date filter would be hidden in case the periodicity matches monthly, quarterly, or annually. When its hidden, the date filter dropdown menu would show 3 standard filters with none of them selected, which was confusing. task-4373943 Forward-Port-Of: odoo/enterprise#75366
steps to reproduce: -Go to an indian company -Open the payroll application. -try to create salary register -the end date is current date issue: The end date should be set to the last day of the current month. solution: changed the code for '_get_default_date_to' to set default date to the last day of the current month task-4432414 Forward-Port-Of: odoo/enterprise#76246
Original PR description
steps to reproduce: -Go to an indian company -Open the payroll application. -try to create salary register -the end date is current date issue: The end date should be set to the last day of the current month. solution: changed the code for '_get_default_date_to' to set default date to the last day of the current month task-4432414 Forward-Port-Of: odoo/enterprise#76246
Before this Commit: -------------------------------------- - If only one failure location was available during quality checks (with control per quantity), it was not automatically selected by default. - This lack of default selection caused confusion, and as a result, products were mistakenly sent to the normal stock location instead of the failure location. After this Commit: -------------------------------------- - When only one failure location is available, it is now automatically pr
Original PR description
Before this Commit: -------------------------------------- - If only one failure location was available during quality checks (with control per quantity), it was not automatically selected by default. - This lack of default selection caused confusion, and as a result, products were mistakenly sent to the normal stock location instead of the failure location. After this Commit: -------------------------------------- - When only one failure location is available, it is now automatically pre-selected by default to enhance the user experience. - This change simplifies the user onboarding process by reducing the risk of products being sent to the normal stock location instead of the failure location. Task-id: 4348525 Forward-Port-Of: odoo/enterprise#74665
Issue Before This Commit: -------------------------------- The delivery label generated by the Shiprocket delivery method displayed an incorrect total when a discount or free delivery was applied, which caused confusion for users. Steps to Produce: -------------------------------- 1. Apply a discount or free delivery for a Shiprocket shipment. 2. Validate the delivery. 3. The total on the delivery label will show an incorrect value, not accounting for the discount or free delivery. W
Original PR description
Issue Before This Commit: -------------------------------- The delivery label generated by the Shiprocket delivery method displayed an incorrect total when a discount or free delivery was applied, which caused confusion for users. Steps to Produce: -------------------------------- 1. Apply a discount or free delivery for a Shiprocket shipment. 2. Validate the delivery. 3. The total on the delivery label will show an incorrect value, not accounting for the discount or free delivery. With This Commit: -------------------------------- The issue is fixed by ensuring the correct data is sent to the API, which now reflects the accurate total value on the delivery label, even when a discount or free delivery is applied. Task-id: 4395054 Forward-Port-Of: odoo/enterprise#75660
Forward-Port-Of: odoo/enterprise#77393
Original PR description
Forward-Port-Of: odoo/enterprise#77393
Task-4110505 https://github.com/odoo/odoo/pull/192953 Forward-Port-Of: odoo/enterprise#77184
Original PR description
Task-4110505 https://github.com/odoo/odoo/pull/192953 Forward-Port-Of: odoo/enterprise#77184
In list view and reports, the accounting entries were displayed in different manners. Sometimes in a stupid way (name of the move repeated twice). This commit aims to give a single and unified way to display them. ticket-4440711 Forward-Port-Of: odoo/enterprise#77362 Forward-Port-Of: odoo/enterprise#76522
Original PR description
In list view and reports, the accounting entries were displayed in different manners. Sometimes in a stupid way (name of the move repeated twice). This commit aims to give a single and unified way to display them. ticket-4440711 Forward-Port-Of: odoo/enterprise#77362 Forward-Port-Of: odoo/enterprise#76522
Steps: - Install the hr_holiday module - Configure Time Off Type with validation set to `Approved by Time Off Officer` or `Both` - Create a Time Off request without setting a Time Off Officer. --- Description of the issue/feature this PR addresses: When the validation type is set to `hr` or `both` and no Time Off Officer is configured, an activity is incorrectly generated upon creating a Time Off request. --- Fix: This PR requires adding responsible_ids in the test cases. The ch
Original PR description
Steps: - Install the hr_holiday module - Configure Time Off Type with validation set to `Approved by Time Off Officer` or `Both` - Create a Time Off request without setting a Time Off Officer. --- Description of the issue/feature this PR addresses: When the validation type is set to `hr` or `both` and no Time Off Officer is configured, an activity is incorrectly generated upon creating a Time Off request. --- Fix: This PR requires adding responsible_ids in the test cases. The changes made in this task remove activities when responsible_ids is not set, causing the test cases to fail. Adding responsible_ids will ensure the tests pass successfully. task-4351688 Forward-Port-Of: odoo/enterprise#77385 Forward-Port-Of: odoo/enterprise#75828
This commit's purpose is to make the profitability test works without demo data. The issue is that without some specific groups, the 'workorder_ids' field is not visible inside the views, making the creation of record impossible. Adding these groups in the config of the test fixes the issue version 18.0-master Forward-Port-Of: odoo/enterprise#77350
Original PR description
This commit's purpose is to make the profitability test works without demo data. The issue is that without some specific groups, the 'workorder_ids' field is not visible inside the views, making the creation of record impossible. Adding these groups in the config of the test fixes the issue version 18.0-master Forward-Port-Of: odoo/enterprise#77350
In this commit, we add 2 additionnal check steps to ensure the tour take the good way. runbot-error-id~109456 Forward-Port-Of: odoo/enterprise#77417
Original PR description
In this commit, we add 2 additionnal check steps to ensure the tour take the good way. runbot-error-id~109456 Forward-Port-Of: odoo/enterprise#77417
This reverts commit 6d00d4da05af71f17139cdb5a3a25ae9e0c10afb That commit was causing an exception in the code handling the response from the API call to the Ecuadorian Tax Agency (SRI), causing a transaction rollback and the loss of the information sent to the SRI as well as the SRI's response. Users with affected invoices need to take care to not reset the invoices to draft. After this fix is merged, the API handling code will be able to recover the invoice status from the SRI, so no data
Original PR description
This reverts commit 6d00d4da05af71f17139cdb5a3a25ae9e0c10afb That commit was causing an exception in the code handling the response from the API call to the Ecuadorian Tax Agency (SRI), causing a transaction rollback and the loss of the information sent to the SRI as well as the SRI's response. Users with affected invoices need to take care to not reset the invoices to draft. After this fix is merged, the API handling code will be able to recover the invoice status from the SRI, so no data-fix should in principle be needed. task-none Forward-Port-Of: odoo/enterprise#77461
Before this commit, if the user alters the grid view to have this kind of ranges: ```xml <range name="month" string="Month" span="month" step="month"/> ``` the `step="month"` will not be used to load the data for the grid view and will continue to load data per day (when this range is the current one in the grid view). This commit makes sure the step is correctly used to fetch the data for each columns displayed in the grid view (in this case only one column for the whole month should b
Original PR description
Before this commit, if the user alters the grid view to have this kind of ranges: ```xml <range name="month" string="Month" span="month" step="month"/> ``` the `step="month"` will not be used to load the data for the grid view and will continue to load data per day (when this range is the current one in the grid view). This commit makes sure the step is correctly used to fetch the data for each columns displayed in the grid view (in this case only one column for the whole month should be displayed). Forward-Port-Of: odoo/enterprise#75056