Daily updates from Odoo
Wednesday, August 22, 2018
10 changes · master
Resolved issues and error corrections
Scheduling now correctly handles requests for zero planned hours or days by moving to the next valid working time instead of returning a non-working time. This removes the need for workaround values and makes planning more accurate around evenings, holidays, and other non-working periods.
Original PR description
The methods plan_hours (resp plan_days) does nothing if the 'hours' parameter (resp 'days') is equals to 0. This commit tends to add the 0 case in the logic. Example : A workorder works each days between 8am and 4pm. If we call plan_hours(0) at 9pm, we want to get 8am the next day. Currently, it send back 9pm. Before this commit, a hack existed consisting to send a very small value to plan_hours. The holidays and non-working time were taken into account and the values was rounded to 0. After this commit. We can send explicitely 0 and the non-working hours will be skipped. 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 change restores an automated test that helps ensure manufacturing orders correctly handle produced quantities across reserved materials. It reduces the risk of regressions in production workflows after earlier code changes.
Original PR description
Restore and adapt test added from rev[1] and lost during the forward port because the code was changed at [2]. Note that the original bug is fixed because we now have a produce line by move line, so we can set the quantity done correctly acrosse the reservation. [1] f0028bc837bc93e355d5bda7be1223142b485718 [2] 2678eba0be0593e9d5857025200d6b7b264162ce 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 prevents text areas from being manually resized vertically in Chrome when Odoo already calculates their height automatically. It keeps form fields looking consistent across browsers and avoids layout issues for users.
Original PR description
Since we correctly compute the height of the field, we don't want to let the user resize it vertically. This was already working on Firefox because it doesn't require the field to be in the DOM to read the resize attribute, but Chrome does require the field to already be in DOM. Task: 1869469 PR: # 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 change aims to reduce random failures in automated validation by making query count checks more stable. It helps keep the development pipeline more reliable, with no expected direct impact on everyday users.
Original PR description
Try to get rid of random red runbot: query count v1 Note: will investigate on why emp count is less than admin count for test_adv_activity
This fixes the placement of arrow controls in the delivery method view so they no longer appear awkwardly on the right side of the text. The change improves the visual clarity of the delivery configuration screen for users.
Original PR description
Arrow ui of delivery method: https://drive.google.com/file/d/1CXBYBTkRTtPBNs4BzwxpifjjhqnsYsGy/view?usp=drivesdk Before this commit, arrow is visible in right side of text 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 fixes an error that could appear when users opened employee badge information. Badge statistics are now calculated correctly, improving reliability for teams using gamification badges.
Original PR description
Description of the issue/feature this PR addresses: Since 960360afe478a8f7b9c456721b5591154952a37d, when computing badge stats, a datetime was compared to a string leading to a traceback. e.g. when clicking in employess > badges. Also, due to a typo, the compute method was assigning the stats result to the wrong attributes. e.g. 'stats_my_this_month' instead of 'stat_my_this_month'. With this commit, the above mentioned issues are fixed and a test is covering these issues to avoid regression. Current behavior before PR: Traceback when clicking employees > badges Desired behavior after PR is merged: No traceback -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents timesheet test runs from starting background services that could interfere with automated checks. It helps keep test results stable and avoids unrelated pop-ups or service activity affecting the Timesheet app tests.
Original PR description
Related to following community PR: https://github.com/odoo/odoo/pull/26519
We do not want to deploy services in tests environments, because it
may influence the execution of the tests. For instance, if we receive
a new direct message in Odoo, we do not want to have a chat window
appear in those environments.
Timesheet UI is a service provider. So for any test on timesheet UI,
we should disable its logic as a Service Provider.A flaky automated test in the barcode inventory area has been temporarily skipped because it can fail before a screen finishes loading. This reduces false alarms in testing while the responsible team prepares a proper fix later.
Original PR description
This test opens a form view and waits for a label that contains "Product". In some rare non deterministic cases that ,the test fails before the view is fully loaded. This test will be fixed/refactored later by the conerned team.
This fix updates the Mexican electronic invoicing external trade module to use the current unit-of-measure model and removes demo data that relied on incorrect company assumptions. It helps ensure Mexican localization modules can be installed reliably during automated checks and customer setup.
Original PR description
A new test in community account addon has been added to test all l10n_* modules installation along with their chart of account. Because the l10n_* were not tested on the runbot, a few glitches were discovered. product.uom was still used in l10n_mx_edi_external. With this commit, the new uom.uom model is used. l10n_mx_reports was creating demo data based on main_company and res_partner_1 with the assumption that it was a mexican company and partner. With this commit, those demo data are removed.
Code cleanup and technical improvements
This change aligns sales-related modules with the updated sales order confirmation process. It also removes an obsolete dependency now included directly in Sales, simplifying maintenance without changing day-to-day user workflows.
Original PR description
https://www.odoo.com/web?debug#id=39340&action=333&active_id=965&model=project.task&view_type=form&menu_id=4720