Daily updates from Odoo
Monday, April 15, 2024
23 changes
1 change
Resolved issues and error corrections
The timesheet leaderboard now shows the correct prompt when a user has not yet appeared in the rankings. This avoids showing billing-rate guidance when the leaderboard ranking feature is enabled, reducing confusion for users tracking their timesheet progress.
Original PR description
If the current user isn't in the leaderboard, a message gets displayed on the indicator: "Record timesheets to earn your rank!" or "Record timesheets to determine your billing rate!", depending on if the leaderboard feature is on or not. The condition for this was wrong, and as such, the second message would get displayed whether the feature was on or not. This PR fixes the condition.
22 changes
Resolved issues and error corrections
This update corrects how NHIF (National Health Insurance Fund) and AHL (Affordable Housing Levy) deductions are calculated for Kenyan employees. Previously, these deductions were incorrectly based on gross salary; they are now properly calculated based on basic salary, ensuring employees are charged the correct amounts.
Original PR description
The NHIF and AHL computation were not correct because they were based on the gross salary instead of the basic salary. task-3827167
This fix ensures that approval notifications are properly sent when records don't match certain approval rules with domain filters. Previously, notifications for alternative approval rules were incorrectly suppressed. Now users will receive the correct notifications when records need approval under different rule conditions.
Original PR description
Have some rules: 1. with domain, exclusive, order: 1 2. no domain, exclusive, order: 1 3: no domain, exclusive, order: 2 Have a record that doesn't satisfy rule#1's domain. Before this commit, no notification is sent when validating rules, but it should send one for rule#3 After this commit, a notification is sent for rule#3 opw-3815732
Fixed an issue in the Budget Analysis report where percentage totals were being calculated incorrectly as a sum instead of an average. This ensures that when viewing budget achievement percentages across multiple budget lines, the total percentage now accurately reflects the average achievement rather than an inflated sum, providing more meaningful financial reporting.
Original PR description
**Current behavior:** On the pivot view for the budget analysis view, the percentage column total is the sum of each row's percentage. **Expected behavior:** This value is the mean of all percentages. **Steps to reproduce:** 1. In the Accounting app, create a budget that has a non-zero Achievement value in at least 2 rows 2. Go to *Reporting* -> *Budgets Analysis* and expand the y-axis to show the lines created, observe that the Achievement total is displaying the sum of all percentages **Cause of the issue:** The percentage field is being aggregated by summation in the read_group() method of the `crossovered.budget.lines` model. **Fix:** Calculate the mean instead of the sum. opw-3761952 Forward-Port-Of: odoo/enterprise#59103
This fix resolves a crash that occurred when opening a kanban view with specific configurations: grouped by a date field with monthly granularity and containing a progress bar. The issue was caused by incorrect parsing of the field name. Users can now view these kanban layouts without encountering errors, improving the stability of the web studio editor.
Original PR description
…ressbar Have a kanban view that: - is grouped by a granular date field "date:month" - has a progressbar - won't display any records (the domain yields no record) Before this commit, there was a crash, because the field name was wrongly parsed. After this commit, there is no crash when we open that kanban view, even in the ml editor opw-3853604
This fix removes the Codes filter from intrastat reports when it's not applicable to the company's localization. Previously, the filter appeared for all users but only worked properly in certain regions, causing confusion with non-functional filter options. Now the filter only displays when it's actually supported by the company's localization settings.
Original PR description
With FR localization installed and FR company setup Create an invoice to an EU partner Check the intrastat report Issue: "Codes" filter is visible but it is only supported in some localizations. Currently: - Selecting 'Goods' will toggle on/off all lines as all taxes are grouped under that section - 'Triangular' and 'Services' are no use This occurs because we always show the 'Codes' filter while we should display it only when relevant opw-3777753
This fix resolves a bug where editing task dates in bulk would display incorrect dates for some records. The issue occurred when mass-editing multiple project tasks' start and end dates in list view. The fix ensures dates are properly handled whether editing single or multiple tasks at once.
Original PR description
Steps to reproduce: ----------------- - install project module - create new project - click on project,and click on see examples button - click on use this for my project - create tasks and click on list view - unhide the start date and end date - give start date and end date for more than 1 records Issue: - Bug when mass editing the task's date_deadline (always showing the wrong date for one of the records) Cause: - this is because the for single record it is not accepting work intervals Solution: - by giving condition using len then issue will be solved task-3561946 Forward-Port-Of: odoo/enterprise#53164
This fix ensures that when exporting spreadsheets to Excel format, the system waits for all data sources to fully load before starting the export. Previously, some data was being missed because the export was starting before lazy-loaded data had finished loading, resulting in incomplete spreadsheets.
Original PR description
Following #38133, we were no longer waiting for the datasources to be properly loaded before calling `model.exportXLSX` which means that only the asynchronous data already loaded were properly loaded as we lazy load them. Task: 3839559 Forward-Port-Of: odoo/enterprise#60483 Forward-Port-Of: odoo/enterprise#59772
This fix resolves an issue where the tag count in the search panel wasn't updating when users added or removed tags from documents using the inspector or drag-and-drop functionality. The system now properly refreshes the tag counts to reflect these changes, ensuring users see accurate information when organizing documents by tags.
Original PR description
Purpose ======= Fix the tags count which isn't updated in the search panel when adding or removing the tag from a document using the inspector. Specifications ============== When removing or adding a tag to a document using the inspector, the record tag was updated but the search panel wasn't notified of the tag update. Notifying the search model after the tag update to modify the tag count. Task-3837247 Forward-Port-Of: odoo/enterprise#60541 Forward-Port-Of: odoo/enterprise#59764
This update resolves a technical issue that was preventing the import of ZG canton tax rates in the Swiss payroll module. The system was crashing when processing certain tax data due to a buffer size limitation. The fix ensures that payroll administrators can successfully import and process Swiss canton tax information without interruptions.
Original PR description
Purpose ======= Since a recent update, the number of caracters for rule parameter Canton (ZG) - Church _tax (N) - Tax Scale (B) - Children (0) is exceeding the default buffer size, leading to a traceback on file import.
The German tax report has been updated to comply with 2024 requirements. Additionally, the report version year has been made dynamic to automatically adjust in future years, preventing the need for manual updates annually.
Original PR description
Adapted the tax report to 2024. There does not seem to be any other changes to do. To avoid this kind of issue, let's make the version's year dynamic opw-3859628 Forward-Port-Of: odoo/enterprise#60634 Forward-Port-Of: odoo/enterprise#60507
This fix resolves an issue where users couldn't schedule activities for documents from the activity view. When clicking "schedule activity" and selecting a document, nothing would happen. The fix restores the proper functionality so users can now successfully schedule activities for documents through the activity view interface.
Original PR description
Steps to reproduce =================== 1. Go to activity view. 2. Click on schedule activity. 3. Select any document to schedule an activity. Nothing happens Technical ========== The commit https://github.com/odoo/enterprise/commit/e35017719d0996279f362423a7b4b1c6e30b9766 prevents the default behavior of the list view, but it's required for list view pop-up when prompted to schedule an activity from activity view. Note : - The schedule activity dialog box renders the list view of the related module. In our case, it renders the base list view from the documents and loads its JS. - We cannot change this in stable so we fixed the issue in JS. After this PR ================ The activity view opens up to schedule an activity for the document. Task-3718760 Forward-Port-Of: odoo/enterprise#56359
This update fixes an issue in the email handling system where an incorrect library reference was causing errors. The system now correctly uses the proper email processing library, ensuring that emails are handled reliably without interruption.
Original PR description
Replacing 'clean.defs' with 'defs' found in 'lxml.html.defs' module. This was causing a problem which is clean.defs attribute is not found.
This update corrects Turkish language translations throughout the Odoo system. Previously, some interface text was displayed in English instead of Turkish. This change ensures that Turkish-speaking users see the system interface in their native language, improving the user experience for this market.
Original PR description
Description of the issue/feature this PR addresses: Fix some i18n statements Current behavior before PR: statements are given in english Desired behavior after PR is merged: do not cure the fact that the expressions are Turkish --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where recruitment interviewers were not receiving notifications when added as followers in job application chats. Since sensitive salary information is now handled separately, interviewers can safely receive chat notifications and be notified when mentioned or when messages are posted to applications they're following.
Original PR description
### Steps to reproduce: - Change the recruitment access rights of Marc Demo to "Interviewer". - Go to Recruitment > Applications > All Applications. - Create a new application and add Marc Demo as…
### Steps to reproduce: - Change the recruitment access rights of Marc Demo to "Interviewer". - Go to Recruitment > Applications > All Applications. - Create a new application and add Marc Demo as follower of the chatter. - Write and send a message on the chatter. #### > Marc Demo will not be notified ### Expected behavior: As discussed the PO of the recruitment module (gmf), since users with "interviewer" access rights have access to the chatter and since the sensible informations are now shared via the salary offer model instead of relying on the chatter of the application model, the followers of the chatter with "interviewer" access rights should be notified if pinged on a log note or if a general message is sent. ### Cause of the issue: Since sensitive informations used to pass through the chatter, users with "interviewer" access rights did not have access to it, and were removed on purpose from the recipients of the notifications: https://github.com/odoo/odoo/blob/cd6ed7f9fd2e0654cfb0672d7a9536dca21035cf/addons/hr_recruitment/models/hr_applicant.py#L376-L379 to avoid any leak of sensible information. #### Note: This access right did not exist before saas-16.4 opw-3783965 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160130
This update corrects a tax classification error in the Italian localization module. The 0% Services (0% S) tax was incorrectly assigned tax code "+02" when it should be "+03". This fix ensures proper tax reporting compliance for Italian businesses using the 0% services tax rate.
Original PR description
In IT localization open tax "0% S (Services)" Issue: invoice repartition line tax tag is "+02", it should be "+03" opw-3860109
This fix improves how Odoo handles manufacturing workflows by allowing companies to use multiple pickup locations and types after production. Previously, the system was too restrictive and always used a default pickup type, ignoring custom manufacturing rules. Now it intelligently detects the correct pickup location and type based on your warehouse configuration, making the manufacturing process more flexible for complex operations.
Original PR description
There is 2 issues with it: - People that want to use multiple picking type or multiple store after manufacturing locations. It's not possible since the equals is strict on the warehouse store after…
There is 2 issues with it: - People that want to use multiple picking type or multiple store after manufacturing locations. It's not possible since the equals is strict on the warehouse store after manufacturing picking type. - The procurement group always use the default manufacture picking type and ignore the picking type on the manufacture rule that will be use. This commit checks if the location is a child of the post production in order to create the procurement group. It would be an issue for people having multiple step in post prod. But it could be fix by using a subset of the warehouse post production location. Check if we have a manufacture rule with the same warehouse in the current route. It's not perfect but it could give a more accurate result than today. 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#159647 Forward-Port-Of: odoo/odoo#159418
Users can now search for reconciliation models by name in the Accounting Configuration section. Previously, the search feature didn't suggest any fields to search on, making it difficult to find specific reconciliation models. This fix adds the name field as a searchable option, improving the user experience when managing reconciliation models.
Original PR description
Issue ----- Reconciliation models are not searchable by specific fields (e.g. name). Steps ----- - Open Accounting -> Configuration -> Reconciliation Models. - Try typing something into search. - No field are suggested to search on. Cause ----- No search fields are defined for `account.reconcile.model`, only filters. opw-3847744 Forward-Port-Of: odoo/odoo#161040
Fixed a bug that caused errors when employees tried to add skills from their profile. The system was incorrectly identifying which employee was adding the skill, leading to missing records or access errors. Now the skill addition feature works correctly when accessed from "My Profile."
Original PR description
Description of the issue/feature this PR addresses: Default employee ID send in request context, when adding a skill from My profile, is not the good one. That can lead to error (missing record, not access) Steps: - Login as "Mitchel Admin" - Install hr_skills_survey - Delete all employee except "Mitchel Admin" - Open "My profile" - Open "Resume" - Add a skill Actual result: - Error due to missing employee - default_employee_id is using the current record ID so a user ID - default_employee_id is not the correct ID - Can lead to record not existing error or access error Expected result: - No error - default_employee_id is the correct employee of the user - Default employee in dialog is "Mitchel Admin" or Empty but not another employee opw-3852542
This fix resolves an error that occurred when posting vendor bills containing landed costs along with section and note lines. The system now properly skips display-only lines during the reconciliation process, allowing bills with mixed line types to be posted successfully.
Original PR description
Steps to reproduce: - Create a vendor bill with landed costs - Add section and note lines - Try posting the bill (ERROR) Bug: display lines should be skipped opw-3715660 Forward-Port-Of: odoo/odoo#161692 Forward-Port-Of: odoo/odoo#161269
This fix ensures that emails sent to invalid or non-existent email addresses are properly bounced back, even when sent alongside catch-all email addresses. Previously, these invalid emails were not being rejected as they should have been, which could cause delivery issues and confusion about whether messages were actually received.
Original PR description
Description of the issue/feature this PR addresses: - Send an email to catchall@exemple.com, random@exemple.com (Note : random@exemple.com is an email witch does not exist) --> Issue the email is not bounced @tde-banana-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161691 Forward-Port-Of: odoo/odoo#140113
This update corrects how addresses are formatted for customers in Luxembourg. The zip code will now appear before the city name, which aligns with the official postal standards used by Bpost and the Post of Luxembourg. This ensures that printed sales orders and other documents display customer addresses correctly.
Original PR description
### Steps to reproduce: Create and print an SO for a customer based in Luxembourg ### Expected behavior: According to Bpost and to the Post of Luxembourg, the zip code should be displayed before the city name in the address format in Luxembourg. ### Current behavior: The zip code is displayed after the city name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Ticket [link](https://www.odoo.com/web#model=project.task&id=3791142) on Odoo opw-3791142 Forward-Port-Of: odoo/odoo#159240
This fix resolves a critical issue where certain partner form views were trying to access a VAT container element before it was created, causing system failures during upgrades. By adjusting the view priority order, the VAT container is now properly initialized before other views attempt to use it. This fix unblocks approximately 60 pending system upgrades.
Original PR description
`base_vat.view_partner_base_vat_form` creates a new div `vat_vies_container` referenced by other views such as `l10n_mx_edi_stock.mx_partner_operator_form` All these extension views have the same priority and in this case the later is trying to access the div before it is even created. We fix this issue by changing the priority of the view that creates the div from 16 to 15. This is currently blocking around 60~ upgrades Forward-Port-Of: odoo/odoo#160329