Tuesday, November 14, 2023
26 changes · 17.0
Enhancements to existing features
Sales order product quantities now automatically return to the delivered or minimum allowed amount if a user enters a lower value. This helps prevent inconsistent order quantities and keeps sales and delivery records aligned with less manual correction.
Original PR description
Added a small improvement, if the product is already at the delivered/minimum quantity, inputing a quantity below the delivered/minimum one will reload the record to set the quantity to the delivered/minimum. Enterprise PR: https://github.com/odoo/enterprise/pull/48940 Task-3553140 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
A small issue in the Purchase Stock guided tour setup was fixed by removing an unnecessary call that could cause the tour to fail. This helps keep the purchase workflow guidance reliable for users without changing day-to-day functionality.
Original PR description
Before this commit, the builder called `this._super` which is not defined anymore by `patch` and thus caused an error. The call to `this._super` was useless as it does not use the returned steps so this commit simply removes the line. Fixes #141112
Miscellaneous changes
Steps to reproduce: - Install DHL delivery and enable batch transfers - Create 2 SO with adding shipping - Select the 2 delivery orders and add them to the same batch - Put the batch in a pack - Only movelines of the first delivery are put in the pack Bug: when delivery is Installed a Delivery Package Type has to be chosen this will in turn put the active picking mls in pack the case of batch picking was disregarded https://github.com/odoo/odoo/pull/55096/files#r469780148 Fix: impl
Original PR description
Steps to reproduce: - Install DHL delivery and enable batch transfers - Create 2 SO with adding shipping - Select the 2 delivery orders and add them to the same batch - Put the batch in a pack - Only movelines of the first delivery are put in the pack Bug: when delivery is Installed a Delivery Package Type has to be chosen this will in turn put the active picking mls in pack the case of batch picking was disregarded https://github.com/odoo/odoo/pull/55096/files#r469780148 Fix: implementing a method to get the movelines to pack will allow to simply make an override in stock_picking_batch instead of creating a new module this has also the added benefit of unifying the behavior across the different methods opw-3357423 Forward-Port-Of: odoo/odoo#141369 Forward-Port-Of: odoo/odoo#139013
This update fixes a random failure in activity menu tests that happened when tests ran around midnight. It makes the checks wait properly for screen updates, improving confidence in test results without changing user-facing behavior.
Original PR description
Each failing of the test "activity menu widget: activity menu with 2 models" was close to midnight. And that was actually the cause of the error. Actually, when executing that test very close to midnight, the test activities are set up for a day and the check happens the day after (actually a few second after). As we check in this test "overdue", "planned" and "today" activities, the tested value are not inline anymore with the test setup when switching from a day to the next (passing midnight). For example, "today" activities become "overdue" activities. To avoid that we patch the date to be far from midnight. [IMP] test_mail: use "await contains" instead of "assert" on dom We replace the immediate dom checks with the more rebust and standard construct "await contains". Task-3592798
This update fixes a problem in the spreadsheet app related to evaluating spreadsheet content. It helps ensure spreadsheet calculations or formulas behave more reliably for users.
Original PR description
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 removes references to the IAP sandbox platform from the Peruvian EDI module, as this platform will no longer be supported. The change simplifies the code without affecting functionality, since test mode already operates without requiring credits.
Original PR description
The support for IAP sandbox platform will soon be dropped, so all references to it need to be removed. This reference wasn't necessary in the first place since, in test mode, the service doesn't require credits to run. Forward-Port-Of: odoo/enterprise#50387
This update removes unnecessary test server configuration from the digital signature service (itsme). A recent system update made the manual endpoint switching no longer needed, simplifying the setup process and reducing maintenance overhead.
Original PR description
Since commit odoo/odoo@550595d, it's no longer necessary to change the endpoint to the IAP services test server. Forward-Port-Of: odoo/enterprise#50402
This update resolves an issue where the Recruitment Analysis menu appeared twice in the system. The fix ensures that the recruitment reporting menu properly overrides the original menu, eliminating the duplicate entry and providing a cleaner navigation experience for HR teams.
Original PR description
Before this commit, two menuitems were created for Recruitment Analysis. This commit redirects the menuitem from hr_recruitment_reports to override the menuitem from hr_recruitment. follow-up of odoo/enterprise#46083 Forward-Port-Of: odoo/enterprise#49114 Forward-Port-Of: odoo/enterprise#49099
The daily target input fields in the Helpdesk 'My Performance' section now display correctly in dark mode. Previously, these fields showed an unwanted visual effect when focused. This fix improves the overall appearance and consistency of the interface for all users.
Original PR description
Before this commit, in helpdesk homepage, the daily target inputs in the 'My Performance' area were reasonably functional in focused state, but in dark mode, they exhibited an undesirable box-shadow/inset effect. This commit addresses the issue by applying a 'form-control' class to the inputs and removing any superfluous classes, thereby enhancing the visual consistency and aesthetic. <table> <tr> <td>Before</td> <td> After</td> <tr> <td> <img alt="before" src="https://github.com/odoo/enterprise/assets/80678921/fef930e2-06d3-4932-ac91-726f6fddd132"> </td> <td><img alt="after" src="https://github.com/odoo/enterprise/assets/80678921/16321474-0070-4987-9e35-c4b963f8dc6f"> </td> </table> task-3593349 Forward-Port-Of: odoo/enterprise#50536
Description of the issue/feature this PR addresses: Following #133759 - The code will fail if the purchase_order has NO date. This is because max( po.date_order.date_order and po.date_order.date(), fields.Date.today() ) will try to compare False with a date, resulting in: TypeError: '>' not supported between instances of 'datetime.date' and 'bool' Current behavior before PR: TypeError is raised Desired behavior after PR is merged: No error is raised --
Original PR description
Description of the issue/feature this PR addresses: Following #133759 - The code will fail if the purchase_order has NO date. This is because max( po.date_order.date_order and po.date_order.date(), fields.Date.today() ) will try to compare False with a date, resulting in: TypeError: '>' not supported between instances of 'datetime.date' and 'bool' Current behavior before PR: TypeError is raised Desired behavior after PR is merged: No error is raised --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#139672
Before this commit, recurrences were being cut off after being fetched when their length exceeded the range of the current calendar view. This was because we were fetching the new events within the `get_events_delta` function, but skipping their fetch at the `_get_occurrence_details` function for occurrences outside the current calendar view range, leaving them not created when they should have been. Additionally, the last day within the weekly view was not being fetched because the API request
Original PR description
Before this commit, recurrences were being cut off after being fetched when their length exceeded the range of the current calendar view. This was because we were fetching the new events within the…
Before this commit, recurrences were being cut off after being fetched when their length exceeded the range of the current calendar view. This was because we were fetching the new events within the `get_events_delta` function, but skipping their fetch at the `_get_occurrence_details` function for occurrences outside the current calendar view range, leaving them not created when they should have been. Additionally, the last day within the weekly view was not being fetched because the API request ignored the "23:59" hour/minute information and fetched events up to the "00:00" hour/minute of the respective day. After this commit, they are now entirely created during their search in the `_get_events_delta` function call. This solves the problem of leaving occurrences uncreated and maintains the improvement of not fetching all recurrences every time as in the previous code after the performance task. In addition, to correct the substitution of the hour/minute "00:00", a day is now being added to the end date to fix the interval obtained. Benchmark test with 300 recurrences of 500 events each (150.000 events): - Before the performance task: 01:02:09 (hour/min/sec) - After this PR: 00:09:51 (hour/min/sec) Issue from task-id: 3525764 Forward-Port-Of: odoo/odoo#140233
Payment acquirers don't have an `active` field, which makes users confused when they try to delete an acquirer, and the error message suggests archiving it instead. opw-3579946 Forward-Port-Of: odoo/odoo#141893 Forward-Port-Of: odoo/odoo#140691
Original PR description
Payment acquirers don't have an `active` field, which makes users confused when they try to delete an acquirer, and the error message suggests archiving it instead. opw-3579946 Forward-Port-Of: odoo/odoo#141893 Forward-Port-Of: odoo/odoo#140691
- adapt test to ensure consistent (scroll) state at each step The issue is hard to reproduce, so the complete resolution of the issue is not guaranteed, but the current change should do the job, and if it doesn't, it will help to pinpoint the issue. Estimated issue: the thread doesn't load more messages when scrolling to bottom because the scroll to bottom is overriden by the auto-scroll top when clicking on pin. Adding extra wait point should solve the issue. runbot-24512 Forward-Po
Original PR description
- adapt test to ensure consistent (scroll) state at each step The issue is hard to reproduce, so the complete resolution of the issue is not guaranteed, but the current change should do the job, and if it doesn't, it will help to pinpoint the issue. Estimated issue: the thread doesn't load more messages when scrolling to bottom because the scroll to bottom is overriden by the auto-scroll top when clicking on pin. Adding extra wait point should solve the issue. runbot-24512 Forward-Port-Of: odoo/odoo#141892 Forward-Port-Of: odoo/odoo#141798
This commit add and test the support for string format with %d. this is because python will fail if a string is passed to a %d, and therefore we can consider it safe. Forward-Port-Of: odoo/odoo#141836
Original PR description
This commit add and test the support for string format with %d. this is because python will fail if a string is passed to a %d, and therefore we can consider it safe. Forward-Port-Of: odoo/odoo#141836
Since commit 550595d, it's no longer necessary to change the endpoint to the IAP services test server. Forward-Port-Of: odoo/odoo#141504
Original PR description
Since commit 550595d, it's no longer necessary to change the endpoint to the IAP services test server. Forward-Port-Of: odoo/odoo#141504
The following commit updated the test to use freezegun. One of the event start date was not properly set before the freezegun date. As a result a notification mail was sent. https://github.com/odoo/odoo/commit/080688868e6acf31d3bd624798559852272bcc1a --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#141844
Original PR description
The following commit updated the test to use freezegun. One of the event start date was not properly set before the freezegun date. As a result a notification mail was sent. https://github.com/odoo/odoo/commit/080688868e6acf31d3bd624798559852272bcc1a --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#141844
For existing users who had previously disabled the "Lots & Serial Numbers" settings, by applying this fix: https://github.com/odoo/odoo/pull/138907/commits/376ee1289eba840f1d8b2b6149d933bdedd47518 They will get the user error each time they try to access the settings. Therefore, we prefer to prevent this and trigger the error only when necessary. opw-3452946 Forward-Port-Of: odoo/odoo#140912 Forward-Port-Of: odoo/odoo#140653
Original PR description
For existing users who had previously disabled the "Lots & Serial Numbers" settings, by applying this fix: https://github.com/odoo/odoo/pull/138907/commits/376ee1289eba840f1d8b2b6149d933bdedd47518 They will get the user error each time they try to access the settings. Therefore, we prefer to prevent this and trigger the error only when necessary. opw-3452946 Forward-Port-Of: odoo/odoo#140912 Forward-Port-Of: odoo/odoo#140653
**Steps to reproduce the bug:** - Create a tracked product with BoM “P1”: - component: add any storable product e.g “C1” - byproduct: add any storable product e.g “B1” - Update the stock of C1 - Update the stock of “P1” with two SN - use the 2 SN of P1 as component in any MO and mark the MO as done - Create a new MO to produce 2 units of P1 - Confirm the MO - Click on “Mass produce” - Generate two new SN * First error : The byproduct quantity is not set - Try to Mark as d
Original PR description
**Steps to reproduce the bug:** - Create a tracked product with BoM “P1”: - component: add any storable product e.g “C1” - byproduct: add any storable product e.g “B1” - Update the stock of C1 -…
**Steps to reproduce the bug:**
- Create a tracked product with BoM “P1”:
- component: add any storable product e.g “C1”
- byproduct: add any storable product e.g “B1”
- Update the stock of C1
- Update the stock of “P1” with two SN
- use the 2 SN of P1 as component in any MO and mark the MO as done
- Create a new MO to produce 2 units of P1
- Confirm the MO
- Click on “Mass produce”
- Generate two new SN
* First error : The byproduct quantity is not set
- Try to Mark as done the new MO
**Problem:**
A user error is raised: 'This serial number for product P1 has already been produced'
When splitting the MO into two, a “stock.move.line” are created with a qty_done = 1, leading to an error when verifying if the serial_number of the move_finished has already been produced.
When clicking the "mark as done" button on the MO, the function "_check_sn_uniqueness" is triggered and since the finished product is tracked and there is a serial number set in the MO, the function "_is_finished_sn_already_produced" is called:
https://github.com/odoo/odoo/blob/c84d80cc71ca0e7120dd293bfc56f9027bfdf9fc/addons/mrp/models/mrp_production.py#L2158-L2162
Within this function, we verify if the move lines of the finished move have a lot and qty_done set. If this condition is met and we do not need to exclude this move, an error is triggered.
https://github.com/odoo/odoo/blob/77ca3a830d0f61ee8a5ba31b3b79e80e85c08e79/addons/mrp/models/mrp_production.py#L2063
https://github.com/odoo/odoo/blob/77ca3a830d0f61ee8a5ba31b3b79e80e85c08e79/addons/mrp/models/mrp_production.py#L2086
**Solution:**
Set "qty_done" to 1 only within the move lines of the components.
Opw-3566259
Forward-Port-Of: odoo/odoo#140949
Forward-Port-Of: odoo/odoo#140537Steps to reproduce the bug: - Create a kit product - Create a storable product without BoM “P1” - Create a MO to produce one unit of “P1” - Add the kit product as component - confirm the MO **Problem:** The Manufacturing Order is cancelled. This is because the MO contains a kit product, and we need to generate moves based on its Bill of Materials. However, at the same time, we cancel and remove the move associated with the original product, which is no longer relevant. But We remove
Original PR description
Steps to reproduce the bug: - Create a kit product - Create a storable product without BoM “P1” - Create a MO to produce one unit of “P1” - Add the kit product as component - confirm the MO **Problem:** The Manufacturing Order is cancelled. This is because the MO contains a kit product, and we need to generate moves based on its Bill of Materials. However, at the same time, we cancel and remove the move associated with the original product, which is no longer relevant. But We remove it before creating the moves generated from the phantom product. Consequently, since we cancel the move, the 'compute_state' of the MO is triggered, and as there is only one 'move_finished' status in 'cancel,' the status of the MO is set to 'cancel: https://github.com/odoo/odoo/blob/5c238bbb18c682ff2d25f740aad604feb7bb5bbc/addons/mrp/models/mrp_production.py#L462-L463 Opw-3548464 Forward-Port-Of: odoo/odoo#139644 Forward-Port-Of: odoo/odoo#139560
In some undeterministic circumstances the tests in `test_wysiwyg_collaboration.js` tried to load an image with a wrong url (`/web/image?model=res.users&field=avatar_128&id=undefined`). It is `undefined` because in the testing context, `this.getSession().uid` is `undefined`. It is not necessary to load these images in these tests so this commit prevents the loading of these images. runbot-24600 task-3566600 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.
Original PR description
In some undeterministic circumstances the tests in `test_wysiwyg_collaboration.js` tried to load an image with a wrong url (`/web/image?model=res.users&field=avatar_128&id=undefined`). It is `undefined` because in the testing context, `this.getSession().uid` is `undefined`. It is not necessary to load these images in these tests so this commit prevents the loading of these images. runbot-24600 task-3566600 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#139480
Steps to reproduce: - Install Accounting - Create a Company located in Italy (e.g. Company A) - Create another company located in Italy (e.g. Company B) - Switch to Company A and set its fiscal localization to Italy in Accounting settings - Switch to Company B and set its fiscal localization to Italy in Accounting settings - Try to install "Italy - E-invoicing (Withholding)" module (10n_it_edi_withholding") => An User Error is raised: "Incompatible companies on records: - 'account.tax
Original PR description
Steps to reproduce: - Install Accounting - Create a Company located in Italy (e.g. Company A) - Create another company located in Italy (e.g. Company B) - Switch to Company A and set its fiscal…
Steps to reproduce: - Install Accounting - Create a Company located in Italy (e.g. Company A) - Create another company located in Italy (e.g. Company B) - Switch to Company A and set its fiscal localization to Italy in Accounting settings - Switch to Company B and set its fiscal localization to Italy in Accounting settings - Try to install "Italy - E-invoicing (Withholding)" module (10n_it_edi_withholding") => An User Error is raised: "Incompatible companies on records: - 'account.tax.repartition.line,688' belongs to company 'Company B' and 'Account' (account_id: '160900 Receivables for withholdings incurred') belongs to another company. - 'account.tax.repartition.line,690' belongs to company 'Company B' and 'Account' (account_id: '160900 Receivables for withholdings incurred') belongs to another company. - 'account.tax.repartition.line,692' belongs to company 'Company B' and 'Account' (account_id: '260200 Payables for withholding taxes to be paid') belongs to another company. - 'account.tax.repartition.line,694' belongs to company 'Company B' and 'Account' (account_id: '260200 Payables for withholding taxes to be paid') belongs to another company. - 'account.tax.repartition.line,696' belongs to company 'Company B' and 'Account' (account_id: '160900 Receivables for withholdings incurred') belongs to another company." Cause: When installing "10n_it_edi_withholding" module, some tax data are updated for each Italian company. These data are "generic" (not linked to any company) data, but some treatment is performed on them for the first Italian company, linking them to the account ids of that company. The following companies are then updated with data linked to the first company. opw-3538921 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#141520
The demo data of point_of_sale module was failing to load when pos_iot module was installed due to proxy_ip validation error. In fact, the iot module overrides this field by creating a relationship to iot_ip. When the demo data is created in the pos, the iot does not yet exist, so proxy_ip is empty, so it trigger the validation error. Error validation is triggered only when proxy_ip is empty and printer_type is set to "iot". In the point_of_sale data demos, we set printer_type to false, which
Original PR description
The demo data of point_of_sale module was failing to load when pos_iot module was installed due to proxy_ip validation error. In fact, the iot module overrides this field by creating a relationship to iot_ip. When the demo data is created in the pos, the iot does not yet exist, so proxy_ip is empty, so it trigger the validation error. Error validation is triggered only when proxy_ip is empty and printer_type is set to "iot". In the point_of_sale data demos, we set printer_type to false, which fixes the problem. Forward-Port-Of: odoo/odoo#140341
On live youtube videos, url are in reality like this: `https://www.youtube.com/live/<video_id>` which was not properly caught by the regex in its compute Reported during OXP Forward-Port-Of: odoo/odoo#141630
Original PR description
On live youtube videos, url are in reality like this: `https://www.youtube.com/live/<video_id>` which was not properly caught by the regex in its compute Reported during OXP Forward-Port-Of: odoo/odoo#141630
[FIX] fleet : Vehicle is mandatory and readonly while creating contract Current behavior before PR: You can't create a new contract in fleet module as the vehicle input is mandatory and readonly Desired behavior after PR is merged: the vehicle is now mandatory but not readonly where you can input a value opw-3564526 Forward-Port-Of: odoo/odoo#140147
Original PR description
[FIX] fleet : Vehicle is mandatory and readonly while creating contract Current behavior before PR: You can't create a new contract in fleet module as the vehicle input is mandatory and readonly Desired behavior after PR is merged: the vehicle is now mandatory but not readonly where you can input a value opw-3564526 Forward-Port-Of: odoo/odoo#140147
The support for IAP sandbox platform will soon be dropped, so all references to it need to be removed. This reference wasn't necessary in the first place since, in test mode, the service doesn't require credits to run. Forward-Port-Of: odoo/odoo#141489
Original PR description
The support for IAP sandbox platform will soon be dropped, so all references to it need to be removed. This reference wasn't necessary in the first place since, in test mode, the service doesn't require credits to run. Forward-Port-Of: odoo/odoo#141489
The cog menu in the control panel (displayed next to breadcrumbs) has a shortcut, so it is available in the command palette. However, as is has no text content and no title/tooltip, the command palette displays "No description provided". This commit adds a tooltip on the icon, which is thus also displayed in the command palette. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the C
Original PR description
The cog menu in the control panel (displayed next to breadcrumbs) has a shortcut, so it is available in the command palette. However, as is has no text content and no title/tooltip, the command palette displays "No description provided". This commit adds a tooltip on the icon, which is thus also displayed in the command palette. 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#141786