Daily updates from Odoo
Navigate
Branch
Tuesday, November 14, 2023
58 changes
39 changes
Security fixes and vulnerability patches
This change prevents users with only interviewer rights from seeing or opening referred applicants in the Recruitment app unless they are assigned as the applicant interviewer or job position interviewer. Users can still view their referrals in the Referrals app, while direct URL access in Recruitment is now blocked when unauthorized.
Original PR description
Steps to reproduce: - Have a user that have the interviewer rights but not higher ones - Set the user as the referrer of an applicant but not as the interviewer and not as the job position…
Steps to reproduce: - Have a user that have the interviewer rights but not higher ones - Set the user as the referrer of an applicant but not as the interviewer and not as the job position interviewer - As this user go to the recruitment app - You can see the applicant and you can open it Expected behavior: in that situation the user should not be able to see the applicant or access it in any way in the recruitment app. Explanation: The user was able to see the applicant because the my referral view is based on the hr.applicant model and thus the user has access to the record in both apps. But the problem should be fixed in the recruitment app because the user should still be able to see the applicant in the referral app. after this fix: You'll not be able to see the applicant in the recruitment app if you are not the interviewer of the applicant or the interviewer of the job position if you only have the interviewer rights. You'll also get an access error if you try to access the applicant directly by URL. task-3457405
Enhancements to existing features
Document actions for importing bank statements can now optionally specify the bank journal to use, which helps route CSV imports to the right account. CODA files keep their existing automatic behavior, while CSV files use the selected journal or default to the first available journal if none is selected.
Original PR description
For now we didn't chose the bank journal because we assume that only coda file where push like this, and in the coda file we can find in which journal to send it. But Coda is limited to BE and lot of user import CSV file for bank. Add the selection of the journal (not mandatory) for Document action, and inject CSV in the journal selected. If no journal selected inject the CSV in the first one of the list. If it's a coda file, keep as now and don't take care of the journal selected. task-3288472
The Helpdesk action menu now labels ticket sharing as “Share Ticket” instead of the generic “Share.” This makes the action clearer for users and helps distinguish ticket sharing from similar actions on other records.
Original PR description
Before this PR when we share task or ticket then in action menu only share was shown In this PR to make it user friendly we have made share task for task in action menu and for ticket we have made share ticket task-3328065
Features or functions removed from Odoo
This update removes older compatibility paths and deprecated testing helpers across multiple Odoo Enterprise modules. It helps keep the codebase aligned with current platform requirements and reduces maintenance risk without introducing expected user-facing changes.
Original PR description
### [REM] *: change deprecated `odoo.tests.common.Form` import In the community PR, we have now properly deprecated `odoo.tests.common.Form` to remove the backwards compatibility one day. Then fix all of those imports. ### [REM] web_studio: use no-deprecated method for testing `write_company_and_print_report` was deprecated and now removed, use another method of `res.company` for `test_07_forbidden_record`. ### [REM] sale_ebay: remove unnecessary Python version check Since https://github.com/odoo/odoo/pull/136904, we only accept Python version greater than or equal to 3.10. Remove unnecessary Python version check. https://github.com/odoo/odoo/pull/140861 https://github.com/odoo/upgrade/pull/5359
Code cleanup and technical improvements
Static interface templates were moved into their own dedicated area instead of being bundled with asset loading logic. This is an internal cleanup that makes the codebase easier to maintain without changing day-to-day user workflows.
Original PR description
This PR moves the `templates` XML document containing all static templates out of the `@web/core/assets.js` file to move it to its own file. This has been done in order to separate concerns: loading assets (`assets.js`) and registering/accessing static templates (`templates.js`). Community: https://github.com/odoo/odoo/pull/141629
Miscellaneous changes
Task: 3575942 Forward-Port-Of: odoo/enterprise#49868
Original PR description
Task: 3575942 Forward-Port-Of: odoo/enterprise#49868
- steps: open fsm app -> select a task -> add products -> select service product -> add some qty -> try to remove qty -> inconsistent behavior and error message. - Issue: The qty of these products should not be decreasable - Cause: Service product with the *qty_delivered_method* set as 'manual' are considered as directly delivered so their quantities shouldn't be decreasable once you added quantity. This logic is applied in the __inverse_fsm_quantity_ method in industry_fsm_sale module - Fix
Original PR description
- steps: open fsm app -> select a task -> add products -> select service product -> add some qty -> try to remove qty -> inconsistent behavior and error message. - Issue: The qty of these products…
- steps: open fsm app -> select a task -> add products -> select service product -> add some qty -> try to remove qty -> inconsistent behavior and error message. - Issue: The qty of these products should not be decreasable - Cause: Service product with the *qty_delivered_method* set as 'manual' are considered as directly delivered so their quantities shouldn't be decreasable once you added quantity. This logic is applied in the __inverse_fsm_quantity_ method in industry_fsm_sale module - Fix: adding a min_quantity key in the catalog _sale_product_catalog_update_sale_order_line_info_ method return dictionary, the value is setted as the sol.qty_delivered. Once this value has been fetched, the kanban_record will include it in the productCatalogData.minimumQuantityOnProduct I'm open to discussion to implement this in the sale_stock module but i don't think the quantity delivered are updated as soon as the quantity is added to the sale order anywhere else than in the industry_fsm_stock module. Also 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. Task-3553140 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#48940
**Steps:** - Install Timesheets - In Kanban View > create a new project and task with a future date - Start the timer and stop - A new entry with today's date won't be made. **Issue:** - If we have a kanban card with an older date and we start and stop the timer, a new kanban entry will be made with today's date. But if the kanban card has a future date, it will not create a new entry rather it will add the time in the same one. **Cause:** - Due to the condition given in the ac
Original PR description
**Steps:** - Install Timesheets - In Kanban View > create a new project and task with a future date - Start the timer and stop - A new entry with today's date won't be made. **Issue:** - If we have a kanban card with an older date and we start and stop the timer, a new kanban entry will be made with today's date. But if the kanban card has a future date, it will not create a new entry rather it will add the time in the same one. **Cause:** - Due to the condition given in the action_timer_start function, it will make a new entry only when the date is older. **Fix:** - Giving the proper condition in action_timer_start so that a new entry is created even when we have a future date. **Task**: 3429428 Forward-Port-Of: odoo/enterprise#50628 Forward-Port-Of: odoo/enterprise#44682
When having a sub company selected, the accounts from the parent company.ies are not accessible in the reconciliation widget. Steps: - Have a company with one branch (X and X.1) - Create a bank statement line in X.1 - In the manual operations tab of reco widget, try to select another account -> no accounts available opw-3518443 Forward-Port-Of: odoo/enterprise#48368
Original PR description
When having a sub company selected, the accounts from the parent company.ies are not accessible in the reconciliation widget. Steps: - Have a company with one branch (X and X.1) - Create a bank statement line in X.1 - In the manual operations tab of reco widget, try to select another account -> no accounts available opw-3518443 Forward-Port-Of: odoo/enterprise#48368
After merging the new Belgian accounting reports in 17.0, it seems the translations were not having the right annotions (due to a renaming during the review process) and were thus not applied. Original commit: https://github.com/odoo/enterprise/commit/c76133635bc1542765937116f02bbbd390599106 This commit fixes that such that the Belgian reports are properly translated again in NL, FR and DE. no-task-id Forward-Port-Of: odoo/enterprise#50547
Original PR description
After merging the new Belgian accounting reports in 17.0, it seems the translations were not having the right annotions (due to a renaming during the review process) and were thus not applied. Original commit: https://github.com/odoo/enterprise/commit/c76133635bc1542765937116f02bbbd390599106 This commit fixes that such that the Belgian reports are properly translated again in NL, FR and DE. no-task-id Forward-Port-Of: odoo/enterprise#50547
**Before this PR**: - Changing the visibility of a Workspace article did not save the content, resulting in content loss. - In several functions `isDirty` function returns a pending promise, hence the `if conditions` are always calculated to be true. **Reason**: - The issue was caused by the behavior of the `resetEditor` function. From `_onChangeVisibility`, `resetEditor` function triggers after calling `load` function, which resulted in the unintentional removal of the artic
Original PR description
**Before this PR**: - Changing the visibility of a Workspace article did not save the content, resulting in content loss. - In several functions `isDirty` function returns a pending promise, hence the `if conditions` are always calculated to be true. **Reason**: - The issue was caused by the behavior of the `resetEditor` function. From `_onChangeVisibility`, `resetEditor` function triggers after calling `load` function, which resulted in the unintentional removal of the article content. - `isDirty` has been changed from getter method to async function from PR https://github.com/odoo/odoo/commit/8723f020c3587a900c811b8cc23f53fe34b98df3 **After this PR**: Now article content is saved when visibility changes. **Task**-3491577 Forward-Port-Of: odoo/enterprise#48457
Steps: In planning, create a shift with date: 31/1/2020 and recurrence each month for 5 months. Expected: For all shifts, the date should be the last day of the month. Issue: From February on, each shift's date is the 29th. Cause: We calculate the next date by adding the recurrence delta to the previous one. In this case: `31/1/2020 + 1 month = 29/2/2020; 29/2/2020 + 1 month = 29/3/2020; etc.` Fix: Calculate the nth next date by adding the recurrence delta, multiplied by n, to
Original PR description
Steps: In planning, create a shift with date: 31/1/2020 and recurrence each month for 5 months. Expected: For all shifts, the date should be the last day of the month. Issue: From February on, each shift's date is the 29th. Cause: We calculate the next date by adding the recurrence delta to the previous one. In this case: `31/1/2020 + 1 month = 29/2/2020; 29/2/2020 + 1 month = 29/3/2020; etc.` Fix: Calculate the nth next date by adding the recurrence delta, multiplied by n, to the first date. In this case: `31/1/2020 + 1 month = 29/2/2020; 31/1/2020 + 2 month = 31/3/2020; etc.` task-3449851 Forward-Port-Of: odoo/enterprise#50503 Forward-Port-Of: odoo/enterprise#44965
`_compute_open_hours`() is not defined the same way as the SQL one. `_compute_open_hours` uses `close_date` and SQL view uses `assign_date`. https://www.odoo.com/documentation/16.0/applications/services/helpdesk/overview/reports.html uses difference between create date and close date so we'll use that one. _steps to reproduce:_ - create a helpdesk ticket and close it - compare helpdesk.ticket and helpdesk.ticket.report.analysis _before this commit:_ hours open are different on the tw
Original PR description
`_compute_open_hours`() is not defined the same way as the SQL one. `_compute_open_hours` uses `close_date` and SQL view uses `assign_date`. https://www.odoo.com/documentation/16.0/applications/services/helpdesk/overview/reports.html uses difference between create date and close date so we'll use that one. _steps to reproduce:_ - create a helpdesk ticket and close it - compare helpdesk.ticket and helpdesk.ticket.report.analysis _before this commit:_ hours open are different on the two models _after this commit:_ hours open are the same on the two models opw-3562355 Forward-Port-Of: odoo/enterprise#49956
Since commit https://github.com/odoo/odoo/commit/7dda6bb92715ea25b2818a62fec5e646f3678b81, The method action_set_quantities_to_reservation doesn't exist anymore. `action_assign` will do quantity setting anyway Forward-Port-Of: odoo/enterprise#50386
Original PR description
Since commit https://github.com/odoo/odoo/commit/7dda6bb92715ea25b2818a62fec5e646f3678b81, The method action_set_quantities_to_reservation doesn't exist anymore. `action_assign` will do quantity setting anyway Forward-Port-Of: odoo/enterprise#50386
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
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 commit adds an autosave feature when the window detects a `focusout` event. This enables Knowledge to save more often in order to fix one of its biggest issue: the surprise loss of data. When we detect a `focusout` we call the method isDirty to check if the body has indeed been modified. If that's the case then we launch the save mechanism to commit the changes done to the Database. task-3531468 Forward-Port-Of: odoo/enterprise#49127
Original PR description
This commit adds an autosave feature when the window detects a `focusout` event. This enables Knowledge to save more often in order to fix one of its biggest issue: the surprise loss of data. When we detect a `focusout` we call the method isDirty to check if the body has indeed been modified. If that's the case then we launch the save mechanism to commit the changes done to the Database. task-3531468 Forward-Port-Of: odoo/enterprise#49127
[FIX] sale_subscription : Paused subscription is not visible in contact's page Steps to reproduce: 1- Install Subscriptions and Contacts modules 2- Pause a subscription that is 'In progress' 3- Go to the customer's page and click on the subscription smart button Current behavior before PR: The paused subscription is not shown in the list of subscriptions under a contact Desired behavior after PR is merged: The subscription list for each contact will now show the paused subscript
Original PR description
[FIX] sale_subscription : Paused subscription is not visible in contact's page Steps to reproduce: 1- Install Subscriptions and Contacts modules 2- Pause a subscription that is 'In progress' 3- Go to the customer's page and click on the subscription smart button Current behavior before PR: The paused subscription is not shown in the list of subscriptions under a contact Desired behavior after PR is merged: The subscription list for each contact will now show the paused subscription too opw-3571647 Forward-Port-Of: odoo/enterprise#50514 Forward-Port-Of: odoo/enterprise#49732
When a move line is for a tracked product, if its `qty_done` is equal or greater than its `product_uom_qty`, the line will not be selected when the product will be scanned. It's annoying when this line has no lot yet. How to reproduce: - Create a product with a BoM kit and at least one tracked component (both product should have a barcode of course); - In the Barcode App, create a new receipt; - Scan the product kit and validate -> Before the validation, the kit is decomposed and a line
Original PR description
When a move line is for a tracked product, if its `qty_done` is equal or greater than its `product_uom_qty`, the line will not be selected when the product will be scanned. It's annoying when this line has no lot yet. How to reproduce: - Create a product with a BoM kit and at least one tracked component (both product should have a barcode of course); - In the Barcode App, create a new receipt; - Scan the product kit and validate -> Before the validation, the kit is decomposed and a line for each component should be created; - Scan the tracked component -> Instead of selecting the existing line, a new one is created. That means the user is not able to set the lot for this line without select it manually. To fix that, the line will be selected even if it has enough `qty_done` only if the product is tracked and there is no lot/serial number. Forward-Port-Of: odoo/enterprise#49608 Forward-Port-Of: odoo/enterprise#49163
…ctor` Adapt spreadsheet side panel following https://github.com/odoo/odoo/pull/140622 A user will again be able to delete the field of a filter field matching. Forward-Port-Of: odoo/enterprise#50337 Forward-Port-Of: odoo/enterprise#50113
Original PR description
…ctor` Adapt spreadsheet side panel following https://github.com/odoo/odoo/pull/140622 A user will again be able to delete the field of a filter field matching. Forward-Port-Of: odoo/enterprise#50337 Forward-Port-Of: odoo/enterprise#50113
Enterprise adaption for adding dtpmo to subcontracting lead days. Task-3081481 Forward-Port-Of: odoo/enterprise#48516
Original PR description
Enterprise adaption for adding dtpmo to subcontracting lead days. Task-3081481 Forward-Port-Of: odoo/enterprise#48516
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
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
The bank reconciliation kanban view is currently not updated after changes to transactions in the list view. This can lead to wrong (outdated) information to be shown on the right side in the bank reconciliation kanban view. This further allows creating wrong reconcilation journal entries with the "Validate" button (I.e. after a change to the "amount" of a transaction in the list view is not reflected on the right side of the bank reconciliation kanban view). The test tour was extended to tes
Original PR description
The bank reconciliation kanban view is currently not updated after changes to transactions in the list view. This can lead to wrong (outdated) information to be shown on the right side in the bank…
The bank reconciliation kanban view is currently not updated after changes to transactions in the list view. This can lead to wrong (outdated) information to be shown on the right side in the bank reconciliation kanban view. This further allows creating wrong reconcilation journal entries with the "Validate" button (I.e. after a change to the "amount" of a transaction in the list view is not reflected on the right side of the bank reconciliation kanban view). The test tour was extended to test for this case. To reproduce: 1. Go to bank reconciliation (in kanban view) 2. Select some transaction kanban card that is not yet reconciled 3. Switch to the tree view 4. Modify the "amount" field of the transaction that was selected in step 2. This corresponds to a change in the database. 5. Switch back to kanban view 6. The right part of the UI (under the "Validate" button) is not updated: I.e. the top line (liquidity line) has a wrong debit / credit. 7. Validate 8. The journal entry created due the validation in step 7 uses the non-updated / wrong values and is thus wrong. task-3504471 PR on 16.0: https://github.com/odoo/enterprise/pull/47930 (very different code) Forward-Port-Of: odoo/enterprise#48175
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
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
This commit aims to standardize, in tests, the "partner_ids" field for creating calendar events: it must be a list of Command sets of "res.partner" objects. Task-id: 3450045 Forward-Port-Of: odoo/enterprise#50080 Forward-Port-Of: odoo/enterprise#49411
Original PR description
This commit aims to standardize, in tests, the "partner_ids" field for creating calendar events: it must be a list of Command sets of "res.partner" objects. Task-id: 3450045 Forward-Port-Of: odoo/enterprise#50080 Forward-Port-Of: odoo/enterprise#49411
Currently, an error occurs as below when cron 'EDI : Perform web services operations' runs. Error: ``` TypeError: 'str' object is not callable File "odoo/tools/safe_eval.py", line 365, in safe_eval return unsafe_eval(c, globals_dict, locals_dict) File "ir.actions.server(615,)", line 1, in <module> File "addons/account_edi/models/account_edi_document.py", line 256, in _cron_process_documents_web_services nb_remaining_jobs = edi_documents._process_documents_web_services(j
Original PR description
Currently, an error occurs as below when cron 'EDI : Perform web services operations' runs. Error: ``` TypeError: 'str' object is not callable File "odoo/tools/safe_eval.py", line 365, in safe_eval…
Currently, an error occurs as below when cron
'EDI : Perform web services operations' runs.
Error:
```
TypeError: 'str' object is not callable
File "odoo/tools/safe_eval.py", line 365, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "ir.actions.server(615,)", line 1, in <module>
File "addons/account_edi/models/account_edi_document.py", line 256, in _cron_process_documents_web_services
nb_remaining_jobs = edi_documents._process_documents_web_services(job_count=job_count)
File "addons/account_edi/models/account_edi_document.py", line 243, in _process_documents_web_services
self._process_job(job)
File "addons/account_edi/models/account_edi_document.py", line 202, in _process_job
edi_result = method_to_call(moves)
File "home/odoo/src/enterprise/saas-16.4/l10n_ec_edi/models/account_edi_format.py", line 220, in _cancel_invoice_edi
return self._l10n_ec_cancel_move_edi(invoices)
File "home/odoo/src/enterprise/saas-16.4/l10n_ec_edi/models/account_edi_format.py", line 202, in _l10n_ec_cancel_move_edi
_("You cannot cancel a document that is still authorized (%s, %s), check the SRI portal",
ValueError: <class 'TypeError'>: "'str' object is not callable" while evaluating
'model._cron_process_documents_web_services(job_count=20)'
File "odoo/addons/base/models/ir_cron.py", line 373, in _callback
self.env['ir.actions.server'].browse(server_action_id).run()
File "home/odoo/src/custom/trial/saas_trial/models/sentry.py", line 33, in run
res = super().run()
File "odoo/addons/base/models/ir_actions.py", line 688, in run
res = runner(run_self, eval_context=eval_context)
File "odoo/addons/base/models/ir_actions.py", line 558, in _run_action_code_multi
safe_eval(self.code.strip(), eval_context, mode="exec", nocopy=True, filename=str(self)) # nocopy allows to return 'action'
File "odoo/tools/safe_eval.py", line 379, in safe_eval
raise ValueError('%s: "%s" while evaluating\n%r' % (ustr(type(e)), ustr(e), expr))
```
This is because with the recently reflected https://github.com/odoo/enterprise/pull/49350 added [1],
which uses `_` as a variable,; in Odoo, `_`(_()) is used in translation, and it is a class, so we can't use
`_` as a variable.Also, this is causing the "local variable `_` referenced before assignment" error from [2]
because the '_l10n_ec_cancel_move_edi' method tries to access `_` before [1] when the above cron
runs or when a user requests a cancellation EDI.
This commit fixes the above issue by changing the variable name.
[1]-https://github.com/odoo/enterprise/blob/b1abcb7a5b075ccbb1409a5fb19c6b142bc6cf77/l10n_ec_edi/models/account_edi_format.py#L197 [2]-https://github.com/odoo/enterprise/blob/b1abcb7a5b075ccbb1409a5fb19c6b142bc6cf77/l10n_ec_edi/models/account_edi_format.py#L190
sentry-4608132760
Forward-Port-Of: odoo/enterprise#50353Since the field is removed in the parent view, the xpath has to be adapted. see https://github.com/odoo/odoo/pull/141390 Forward-Port-Of: odoo/enterprise#50346
Original PR description
Since the field is removed in the parent view, the xpath has to be adapted. see https://github.com/odoo/odoo/pull/141390 Forward-Port-Of: odoo/enterprise#50346
In this commit we add the tax letters corresponding to each orderline in the receipt. https://github.com/odoo/odoo/pull/140974 Forward-Port-Of: odoo/enterprise#50134
Original PR description
In this commit we add the tax letters corresponding to each orderline in the receipt. https://github.com/odoo/odoo/pull/140974 Forward-Port-Of: odoo/enterprise#50134
[FIX] account_reports : general ledger localization Issue: ====== In some countries (like Italy), with the corresponding l10n module installed, opening the General Ledger and selecting the "Customer Invoices" or "Vendor Bills" journal in the filter crashes, telling the `report_id` of the computed options is inconsistent with the report using them. Steps to reproduce the issue: ============================= - Install accounting and l10n_it_reports - Go to accounting / reporting / gene
Original PR description
[FIX] account_reports : general ledger localization Issue: ====== In some countries (like Italy), with the corresponding l10n module installed, opening the General Ledger and selecting the "Customer…
[FIX] account_reports : general ledger localization Issue: ====== In some countries (like Italy), with the corresponding l10n module installed, opening the General Ledger and selecting the "Customer Invoices" or "Vendor Bills" journal in the filter crashes, telling the `report_id` of the computed options is inconsistent with the report using them. Steps to reproduce the issue: ============================= - Install accounting and l10n_it_reports - Go to accounting / reporting / general ledger - Choose customer invoices in journals Origin of the issue: ==================== When selecting only sales or purchase journals (not both together), the General Ledger displays additional lines corresponding to the data of the Generic Tax Report matching the chosen options. The way it was done in 16.4, however, let the tax report choose the first variant available for the current company, so if the l10n module contained a tax report, the wrong report was chosen and set in `report_id`, and we were calling the Generic Tax Report with an options dict whose `report_id` key corresponded to a localized variant instead of the root report. Solution: ========= Previous versions used to directly force the `report_id` key, but this does not work anymore because of the introduction of the composite reports (aka sections), and the way they changed the options generation. The key to force is now `selected_variant_id`, to make sure the root report is the one that gets selected. opw-3580078 Forward-Port-Of: odoo/enterprise#50399
* = test_mail_enterprise Since commit [1], the model `mail.channel` was renamed to `discuss.channel`. In our Mobile App (Android, iOS) we have a specific logic to handle opening a DM with the correct action related to this model. Due to this renaming, we were not able to open the action of the direct message on Android and iOS apps. Also, as we can't push change on `iOS`, we are not able to adapt the logic in the Mobile App (due to Apple Store Policies). This commit forces to send the old
Original PR description
* = test_mail_enterprise Since commit [1], the model `mail.channel` was renamed to `discuss.channel`. In our Mobile App (Android, iOS) we have a specific logic to handle opening a DM with the correct action related to this model. Due to this renaming, we were not able to open the action of the direct message on Android and iOS apps. Also, as we can't push change on `iOS`, we are not able to adapt the logic in the Mobile App (due to Apple Store Policies). This commit forces to send the old model to apply the correct logic on the Mobile App (Android, iOS). Steps to reproduce: * Send a DM to the Mobile App's user * The user clicks on the notification * The Mobile App opens but not in the correct view => BUG [1]: https://github.com/odoo/odoo/commit/90cb44e1e1b6bad9c12f3bd14d1c9e340461e19e Forward-Port-Of: odoo/enterprise#50520
When having the hierarchy options enabled on the general ledger, some column with a "string" figure type had the value zero in the cell which was not the intended behaviour. To correct that we have added a check to change the default value in case the figure type is a string. task: 3438422 Forward-Port-Of: odoo/enterprise#50021
Original PR description
When having the hierarchy options enabled on the general ledger, some column with a "string" figure type had the value zero in the cell which was not the intended behaviour. To correct that we have added a check to change the default value in case the figure type is a string. task: 3438422 Forward-Port-Of: odoo/enterprise#50021
This commit addresses a bug in the financial reports module where the General Ledger link, previously unfolding the relevant account details, stopped functioning as expected. turns out it was because of a change in `_get_generic_line_id` method that was not taken into account. task-3575474 Forward-Port-Of: odoo/enterprise#50022
Original PR description
This commit addresses a bug in the financial reports module where the General Ledger link, previously unfolding the relevant account details, stopped functioning as expected. turns out it was because of a change in `_get_generic_line_id` method that was not taken into account. task-3575474 Forward-Port-Of: odoo/enterprise#50022
This PR will fix three different issues with the tasks gantt view's group expand method. The first issue is that it did not include closed task for the past period, so no empty line was displayed for the user. The second issue is that it did not include closed task for the current period, so no empty line was displayed for the user. The third issue is that it included private tasks, which should not be the case. To fix this, the _group_expand_user_ids method was changed to include closed task
Original PR description
This PR will fix three different issues with the tasks gantt view's group expand method. The first issue is that it did not include closed task for the past period, so no empty line was displayed for the user. The second issue is that it did not include closed task for the current period, so no empty line was displayed for the user. The third issue is that it included private tasks, which should not be the case. To fix this, the _group_expand_user_ids method was changed to include closed tasks in the domain calculation for the previous/current period, and to exclude private tasks. Tests were also added. task-3389422 Forward-Port-Of: odoo/enterprise#50459 Forward-Port-Of: odoo/enterprise#43438
Added test cases for WhatsApp templates covering the following scenarios: - Template synchronization from a WhatsApp account. - Single template synchronization from Template. - Template submit to WhatsApp account - Template status update webhook. - Template quality update webhook. - Template category update webhook. Task - 3536176 Forward-Port-Of: odoo/enterprise#50458 Forward-Port-Of: odoo/enterprise#49815
Original PR description
Added test cases for WhatsApp templates covering the following scenarios: - Template synchronization from a WhatsApp account. - Single template synchronization from Template. - Template submit to WhatsApp account - Template status update webhook. - Template quality update webhook. - Template category update webhook. Task - 3536176 Forward-Port-Of: odoo/enterprise#50458 Forward-Port-Of: odoo/enterprise#49815
Add the `static props` variable on AccountReportButtonsBar (to remove owl warning). Forward-Port-Of: odoo/enterprise#50358
Original PR description
Add the `static props` variable on AccountReportButtonsBar (to remove owl warning). Forward-Port-Of: odoo/enterprise#50358
Fixes a typo in the key used to show analytic plans in the PDF export filters. Forward-Port-Of: odoo/enterprise#50303 Forward-Port-Of: odoo/enterprise#48232
Original PR description
Fixes a typo in the key used to show analytic plans in the PDF export filters. Forward-Port-Of: odoo/enterprise#50303 Forward-Port-Of: odoo/enterprise#48232
'closing_entry' option key was introduced in l10n_be in order to bypass the display of some options on the pdf stored in attachment of the tax closing entry. It is not needed anymore in account_reports in 17.0, because of the split between pdf and UI templates: the pdf templates' extra_options template only displays information when its options are explicitly set to a value. For example if only posted entries are displayed in the report; it's not written on the pdf ; only the fact of showing dra
Original PR description
'closing_entry' option key was introduced in l10n_be in order to bypass the display of some options on the pdf stored in attachment of the tax closing entry. It is not needed anymore in account_reports in 17.0, because of the split between pdf and UI templates: the pdf templates' extra_options template only displays information when its options are explicitly set to a value. For example if only posted entries are displayed in the report; it's not written on the pdf ; only the fact of showing draft entries is mentioned when printing. Therefore, the pdf attached to the tax closing moves never shows any of these filters anyway. Forward-Port-Of: odoo/enterprise#50292
See COM PR for details of the bug. This commit adds a test to ensure this issue hopefully never returns COM PR: odoo/odoo#141210 Forward-Port-Of: odoo/enterprise#50274
Original PR description
See COM PR for details of the bug. This commit adds a test to ensure this issue hopefully never returns COM PR: odoo/odoo#141210 Forward-Port-Of: odoo/enterprise#50274
In order for this module to work, two system parameters must be set up: - "website_generator.token", a token which is used to identify the user(s) and give the appropriate access to the WSS - "website_scraper_endpoint", the public url of the WSS This PR is the merge of https://github.com/odoo/enterprise/pull/43608 (already reviewed a lot) and https://github.com/odoo/enterprise/pull/43306 ----------------- The goal of this module is to 'import' external websites directly in Odoo. Spe
Original PR description
In order for this module to work, two system parameters must be set up: - "website_generator.token", a token which is used to identify the user(s) and give the appropriate access to the WSS -…
In order for this module to work, two system parameters must be set up:
- "website_generator.token", a token which is used to identify the user(s) and give the appropriate access to the WSS
- "website_scraper_endpoint", the public url of the WSS
This PR is the merge of https://github.com/odoo/enterprise/pull/43608 (already reviewed a lot) and https://github.com/odoo/enterprise/pull/43306
-----------------
The goal of this module is to 'import' external websites directly in
Odoo.
Specifically, it will load data into the appropriate models:
- Menu
- Pages
- Footers
- Images
- Attachments
- Social media links
- Theme custos
- ..
Indeed, some users have already built their own websites outside of Odoo
and have the desire to move it into Odoo.
Unfortunately it takes a lot of effort to migrate.
This module is here to help in thar regard.
Their mission is, given a reference website, to reproduce it in Odoo.
In the first implementation, it will be only possible to scrape a
website through a special /trial page on Odoo.com.
The module will work out of the box only in this configuration.
It will be reployed in a V1 as a beta:
- Can only scrape 10 pages
- Only able to scrape from /trial
- There will be a disclaimer about the fact that it's a beta
- If need more than 10 pages, we will advertise to contact us to be able
to do it
- Write on website 1, keep only one website in the DB (multi website is
complexe)
- User will land on a request waiting page, calling IAP every 10 sec to
know if the results are ready (and get it)
- A CRON will be started and run every 15 min in case the user leave the
page. The CRON will be disabled once the request is fully processed.
- A mail will be sent once the website is ready
- A systray icon will be shown to go back to the pending screen. That
icon is gone once you have visited the pending screen and that the
request is ready.
In such a case, the screen will either reload to the website in case
of scraping success, or will shown an error message.
Known issues that will be fixed in a later commit:
- data-snippet attribute management
- Missing snippet versioning (vcss vjs)
In a V2:
- We will scrape products with `website_generator_sale`
- Will probably use data module instead of recreating everything
- Will be able to scrape a website from an existing database through
the website configurator screen
Terminology:
- Website Scraper (WS):
This is where the magic happens. It parses the target website,
extracts all the information it needs and generates an output file.
This output file contains all the information required for building
the website in odoo (HTML, images, theme, etc).
- Website Scraper Server (WSS):
It's the server which runs the website scraper. It records the
requests and is responsible for load balancing.
- Website Generator (WG):
This PR: it takes the output file from the WS and build the website
This module is allow to send and receive requests to/from the WSS.
Flow of Operations:
1. WG sends a request to WSS
2. WSS accepts (or denies) the request
3. WSS executes WS on the targeted website
4. Once it's done, the request is marked as ready on WSS
5. WG requests WSS for the output file
6. WSS streams the file back to WG if ready, or denies if not allowed or
return "not ready yet" status
7. WG builds the website once it receives the file
8. WG let WSS know that everything went fine
Errors:
- (Step 2) WSS checks for:
- A valid token
- A number of pages
- A valid URL
- That the URL is not blacklisted website
- A valid DBUUID
- (Step 6) WSS checks for:
- A valid output_uuid and DBUUID
(that the DB receiving the request is the one that made it)
- That the request is done (not 'error' or 'processing')
- That the result is still accessible (not deleted due to cleanup)
Notes:
- WG never saves the output as an attachment, it is only stored in RAM
- WG should be robust, if info is missing it will try to do without it.
If essential info is missing, it will simply not create the website.
Related PR:
- (WSS) https://github.com/odoo/iap-apps/pull/609
- (WS) https://github.com/odoo/website-scraper
- Internal custo: https://github.com/odoo/internal/pull/2463
Co-authored-by: Christopher du Toit <chto@odoo.com>
Co-authored-by: Damien Decleire <deda@odoo.com>
Co-authored-by: Guillaume-gdi <gdi@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Forward-Port-Of: odoo/enterprise#50161Removes useless CSS rules. Enterprise part of odoo/odoo#140255 Forward-Port-Of: odoo/enterprise#49808
Original PR description
Removes useless CSS rules. Enterprise part of odoo/odoo#140255 Forward-Port-Of: odoo/enterprise#49808
19 changes
Enhancements to existing features
Knowledge now automatically saves your work when you click away from the document or switch windows. This improvement prevents the frustrating loss of unsaved changes by detecting when you've left the document and saving any modifications you've made.
Original PR description
This commit adds an autosave feature when the window detects a `focusout` event. This enables Knowledge to save more often in order to fix one of its biggest issue: the surprise loss of data. When we detect a `focusout` we call the method isDirty to check if the body has indeed been modified. If that's the case then we launch the save mechanism to commit the changes done to the Database. task-3531468
Resolved issues and error corrections
This fix resolves an issue where article content was being lost when users changed the visibility settings of a Workspace article. The problem was caused by the editor being reset after loading, which unintentionally removed the content. The fix ensures that content is properly saved before any visibility changes are applied.
Original PR description
**Before this PR**: - Changing the visibility of a Workspace article did not save the content, resulting in content loss. - In several functions `isDirty` function returns a pending promise, hence the `if conditions` are always calculated to be true. **Reason**: - The issue was caused by the behavior of the `resetEditor` function. From `_onChangeVisibility`, `resetEditor` function triggers after calling `load` function, which resulted in the unintentional removal of the article content. - `isDirty` has been changed from getter method to async function from PR https://github.com/odoo/odoo/commit/8723f020c3587a900c811b8cc23f53fe34b98df3 **After this PR**: Now article content is saved when visibility changes. **Task**-3491577
This fix prevents users from accidentally reducing quantities of service products that have already been marked as delivered in Field Service Management tasks. When a service product is added to a task, its quantity is now locked at the delivered amount, preventing inconsistent behavior and error messages when users try to decrease it.
Original PR description
- steps: open fsm app -> select a task -> add products -> select service product -> add some qty -> try to remove qty -> inconsistent behavior and error message. - Issue: The qty of these products…
- steps: open fsm app -> select a task -> add products -> select service product -> add some qty -> try to remove qty -> inconsistent behavior and error message. - Issue: The qty of these products should not be decreasable - Cause: Service product with the *qty_delivered_method* set as 'manual' are considered as directly delivered so their quantities shouldn't be decreasable once you added quantity. This logic is applied in the __inverse_fsm_quantity_ method in industry_fsm_sale module - Fix: adding a min_quantity key in the catalog _sale_product_catalog_update_sale_order_line_info_ method return dictionary, the value is setted as the sol.qty_delivered. Once this value has been fetched, the kanban_record will include it in the productCatalogData.minimumQuantityOnProduct I'm open to discussion to implement this in the sale_stock module but i don't think the quantity delivered are updated as soon as the quantity is added to the sale order anywhere else than in the industry_fsm_stock module. Also 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. Task-3553140 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves issues with spreadsheet version history when spreadsheets are created from templates. Previously, users would encounter errors when trying to view version history, and the system would lose track of revision information due to mismatches between template data and regular spreadsheet data. The fix ensures that spreadsheet data is properly converted and synchronized when created from templates, and that revision history is correctly maintained and cleaned up.
Original PR description
Task: 3575942
This fix restores proper translations for Belgian accounting reports in Dutch, French, and German languages. The translations were not being applied correctly due to annotation issues that occurred during the review process. This ensures users in Belgium can now see the accounting reports in their preferred language.
Original PR description
After merging the new Belgian accounting reports in 17.0, it seems the translations were not having the right annotions (due to a renaming during the review process) and were thus not applied. Original commit: https://github.com/odoo/enterprise/commit/c76133635bc1542765937116f02bbbd390599106 This commit fixes that such that the Belgian reports are properly translated again in NL, FR and DE. no-task-id
Fixed a crash that occurred when Italian users filtered the General Ledger report by Customer Invoices or Vendor Bills. The issue was caused by incorrect report configuration when localized tax reports were installed. The fix ensures the correct base report is selected, allowing users to filter by journal type without errors.
Original PR description
[FIX] account_reports : general ledger localization Issue: ====== In some countries (like Italy), with the corresponding l10n module installed, opening the General Ledger and selecting the "Customer…
[FIX] account_reports : general ledger localization Issue: ====== In some countries (like Italy), with the corresponding l10n module installed, opening the General Ledger and selecting the "Customer Invoices" or "Vendor Bills" journal in the filter crashes, telling the `report_id` of the computed options is inconsistent with the report using them. Steps to reproduce the issue: ============================= - Install accounting and l10n_it_reports - Go to accounting / reporting / general ledger - Choose customer invoices in journals Origin of the issue: ==================== When selecting only sales or purchase journals (not both together), the General Ledger displays additional lines corresponding to the data of the Generic Tax Report matching the chosen options. The way it was done in 16.4, however, let the tax report choose the first variant available for the current company, so if the l10n module contained a tax report, the wrong report was chosen and set in `report_id`, and we were calling the Generic Tax Report with an options dict whose `report_id` key corresponded to a localized variant instead of the root report. Solution: ========= Previous versions used to directly force the `report_id` key, but this does not work anymore because of the introduction of the composite reports (aka sections), and the way they changed the options generation. The key to force is now `selected_variant_id`, to make sure the root report is the one that gets selected. opw-3580078 Forward-Port-Of: odoo/enterprise#50399
This fix resolves a critical error that occurs when the EDI document processing system runs automatically. The issue was caused by using an underscore (_) as a variable name, which conflicts with Odoo's translation system. This fix renames the variable to prevent the system from crashing when processing electronic invoices for Ecuador.
Original PR description
Currently, an error occurs as below when cron 'EDI : Perform web services operations' runs. Error: ``` TypeError: 'str' object is not callable File "odoo/tools/safe_eval.py", line 365, in safe_eval…
Currently, an error occurs as below when cron
'EDI : Perform web services operations' runs.
Error:
```
TypeError: 'str' object is not callable
File "odoo/tools/safe_eval.py", line 365, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "ir.actions.server(615,)", line 1, in <module>
File "addons/account_edi/models/account_edi_document.py", line 256, in _cron_process_documents_web_services
nb_remaining_jobs = edi_documents._process_documents_web_services(job_count=job_count)
File "addons/account_edi/models/account_edi_document.py", line 243, in _process_documents_web_services
self._process_job(job)
File "addons/account_edi/models/account_edi_document.py", line 202, in _process_job
edi_result = method_to_call(moves)
File "home/odoo/src/enterprise/saas-16.4/l10n_ec_edi/models/account_edi_format.py", line 220, in _cancel_invoice_edi
return self._l10n_ec_cancel_move_edi(invoices)
File "home/odoo/src/enterprise/saas-16.4/l10n_ec_edi/models/account_edi_format.py", line 202, in _l10n_ec_cancel_move_edi
_("You cannot cancel a document that is still authorized (%s, %s), check the SRI portal",
ValueError: <class 'TypeError'>: "'str' object is not callable" while evaluating
'model._cron_process_documents_web_services(job_count=20)'
File "odoo/addons/base/models/ir_cron.py", line 373, in _callback
self.env['ir.actions.server'].browse(server_action_id).run()
File "home/odoo/src/custom/trial/saas_trial/models/sentry.py", line 33, in run
res = super().run()
File "odoo/addons/base/models/ir_actions.py", line 688, in run
res = runner(run_self, eval_context=eval_context)
File "odoo/addons/base/models/ir_actions.py", line 558, in _run_action_code_multi
safe_eval(self.code.strip(), eval_context, mode="exec", nocopy=True, filename=str(self)) # nocopy allows to return 'action'
File "odoo/tools/safe_eval.py", line 379, in safe_eval
raise ValueError('%s: "%s" while evaluating\n%r' % (ustr(type(e)), ustr(e), expr))
```
This is because with the recently reflected https://github.com/odoo/enterprise/pull/49350 added [1],
which uses `_` as a variable,; in Odoo, `_`(_()) is used in translation, and it is a class, so we can't use
`_` as a variable.Also, this is causing the "local variable `_` referenced before assignment" error from [2]
because the '_l10n_ec_cancel_move_edi' method tries to access `_` before [1] when the above cron
runs or when a user requests a cancellation EDI.
This commit fixes the above issue by changing the variable name.
[1]-https://github.com/odoo/enterprise/blob/b1abcb7a5b075ccbb1409a5fb19c6b142bc6cf77/l10n_ec_edi/models/account_edi_format.py#L197 [2]-https://github.com/odoo/enterprise/blob/b1abcb7a5b075ccbb1409a5fb19c6b142bc6cf77/l10n_ec_edi/models/account_edi_format.py#L190
sentry-4608132760
Forward-Port-Of: odoo/enterprise#50353This update fixes an issue where incoming invoices for Chilean operations were not applying the correct default tax. The system now properly adds the default purchase tax when processing incoming emails with invoices, and prioritizes it in the tax sequence to ensure it's applied first.
Original PR description
Since changes have been made in default tax settings, incoming emails with invoices for l10n-cl are not configuring the tax correctly. This ensures that the default tax is being added correctly. This PR is a revision of #49332 wich did not work since method `_get_withholding_taxes()` returns a set, and the default_purchase_tax cannot be added that way. Besides, as the default tax is the main one, we put it first in the sequence of taxes. Forward-Port-Of: odoo/enterprise#49651
This fix resolves an issue where subsidiary companies could not access parent company accounts when performing bank reconciliation. Users working with subsidiary branches can now properly select accounts from the parent company in the reconciliation widget, enabling complete financial operations across the company structure.
Original PR description
When having a sub company selected, the accounts from the parent company.ies are not accessible in the reconciliation widget. Steps: - Have a company with one branch (X and X.1) - Create a bank statement line in X.1 - In the manual operations tab of reco widget, try to select another account -> no accounts available opw-3518443 Forward-Port-Of: odoo/enterprise#48368
This update fixes a bug in the Planning module where recurring shifts created on the last day of a month were incorrectly scheduled for earlier dates in subsequent months. For example, a shift starting on January 31st would appear on February 29th instead of the last day of February. The fix ensures all recurring shift occurrences maintain their original day-of-month position, improving scheduling accuracy and reliability.
Original PR description
Steps: In planning, create a shift with date: 31/1/2020 and recurrence each month for 5 months. Expected: For all shifts, the date should be the last day of the month. Issue: From February on, each shift's date is the 29th. Cause: We calculate the next date by adding the recurrence delta to the previous one. In this case: `31/1/2020 + 1 month = 29/2/2020; 29/2/2020 + 1 month = 29/3/2020; etc.` Fix: Calculate the nth next date by adding the recurrence delta, multiplied by n, to the first date. In this case: `31/1/2020 + 1 month = 29/2/2020; 31/1/2020 + 2 month = 31/3/2020; etc.` task-3449851 Forward-Port-Of: odoo/enterprise#50503 Forward-Port-Of: odoo/enterprise#44965
This fix resolves a discrepancy in how helpdesk ticket open hours were being calculated across different reports. The system was using different date references (assignment date vs. close date) in different places, causing the same ticket to show different hours open depending on which report you viewed. This update ensures consistent calculations across all helpdesk reports by using the creation date to close date method, which aligns with Odoo's official documentation.
Original PR description
`_compute_open_hours`() is not defined the same way as the SQL one. `_compute_open_hours` uses `close_date` and SQL view uses `assign_date`. https://www.odoo.com/documentation/16.0/applications/services/helpdesk/overview/reports.html uses difference between create date and close date so we'll use that one. _steps to reproduce:_ - create a helpdesk ticket and close it - compare helpdesk.ticket and helpdesk.ticket.report.analysis _before this commit:_ hours open are different on the two models _after this commit:_ hours open are the same on the two models opw-3562355 Forward-Port-Of: odoo/enterprise#49956
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 fix ensures that paused subscriptions are now displayed when viewing a customer's subscription list. Previously, paused subscriptions were hidden from the customer's page, making it difficult to track all subscription statuses. Now customers and support teams can see the complete subscription history including paused ones.
Original PR description
[FIX] sale_subscription : Paused subscription is not visible in contact's page Steps to reproduce: 1- Install Subscriptions and Contacts modules 2- Pause a subscription that is 'In progress' 3- Go to the customer's page and click on the subscription smart button Current behavior before PR: The paused subscription is not shown in the list of subscriptions under a contact Desired behavior after PR is merged: The subscription list for each contact will now show the paused subscription too opw-3571647 Forward-Port-Of: odoo/enterprise#50514 Forward-Port-Of: odoo/enterprise#49732
Fixed a critical issue where the bank reconciliation widget wasn't updating when transaction amounts were modified in the list view, which could result in incorrect journal entries being created. The system now properly refreshes the reconciliation display to reflect all changes made to transactions, ensuring accurate financial records.
Original PR description
The bank reconciliation kanban view is currently not updated after changes to transactions in the list view. This can lead to wrong (outdated) information to be shown on the right side in the bank…
The bank reconciliation kanban view is currently not updated after changes to transactions in the list view. This can lead to wrong (outdated) information to be shown on the right side in the bank reconciliation kanban view. This further allows creating wrong reconcilation journal entries with the "Validate" button (I.e. after a change to the "amount" of a transaction in the list view is not reflected on the right side of the bank reconciliation kanban view). The test tour was extended to test for this case. To reproduce: 1. Go to bank reconciliation (in kanban view) 2. Select some transaction kanban card that is not yet reconciled 3. Switch to the tree view 4. Modify the "amount" field of the transaction that was selected in step 2. This corresponds to a change in the database. 5. Switch back to kanban view 6. The right part of the UI (under the "Validate" button) is not updated: I.e. the top line (liquidity line) has a wrong debit / credit. 7. Validate 8. The journal entry created due the validation in step 7 uses the non-updated / wrong values and is thus wrong. task-3504471 PR on 16.0: https://github.com/odoo/enterprise/pull/47930 (very different code) Forward-Port-Of: odoo/enterprise#48175
Fixed an issue in the Barcode app where scanning a tracked product component would create a duplicate line instead of selecting the existing one when no lot number was assigned yet. This fix allows users to properly assign lot numbers to tracked components without manual intervention, improving the efficiency of barcode-based receiving workflows.
Original PR description
When a move line is for a tracked product, if its `qty_done` is equal or greater than its `product_uom_qty`, the line will not be selected when the product will be scanned. It's annoying when this line has no lot yet. How to reproduce: - Create a product with a BoM kit and at least one tracked component (both product should have a barcode of course); - In the Barcode App, create a new receipt; - Scan the product kit and validate -> Before the validation, the kit is decomposed and a line for each component should be created; - Scan the tracked component -> Instead of selecting the existing line, a new one is created. That means the user is not able to set the lot for this line without select it manually. To fix that, the line will be selected even if it has enough `qty_done` only if the product is tracked and there is no lot/serial number. Forward-Port-Of: odoo/enterprise#49608 Forward-Port-Of: odoo/enterprise#49163
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
This fix resolves an issue where direct messages couldn't be opened properly on Android and iOS mobile apps after a recent system update. The fix ensures that mobile apps receive the correct information to display direct messages in the proper view when users click on notifications.
Original PR description
* = test_mail_enterprise Since commit [1], the model `mail.channel` was renamed to `discuss.channel`. In our Mobile App (Android, iOS) we have a specific logic to handle opening a DM with the correct action related to this model. Due to this renaming, we were not able to open the action of the direct message on Android and iOS apps. Also, as we can't push change on `iOS`, we are not able to adapt the logic in the Mobile App (due to Apple Store Policies). This commit forces to send the old model to apply the correct logic on the Mobile App (Android, iOS). Steps to reproduce: * Send a DM to the Mobile App's user * The user clicks on the notification * The Mobile App opens but not in the correct view => BUG [1]: https://github.com/odoo/odoo/commit/90cb44e1e1b6bad9c12f3bd14d1c9e340461e19e Forward-Port-Of: odoo/enterprise#50520
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