Thursday, November 7, 2024
36 changes · master
Enhancements to existing features
An unused payment redirect value has been removed from online batch payments. This keeps the payment data model simpler and avoids storing information that is not needed for business operations.
Original PR description
The field redirect_url is unsued and it makes no sense to store it in the database anyway. This commit removes it from the model.
This update adds a check to ensure field display widgets are only used with compatible field types, helping prevent configuration errors from reaching users. It also updates the timesheet grid timer setup to use the newer widget selection approach, reducing the chance of incorrect behavior after related platform changes.
Original PR description
This commit introduces a validation that will raise an error if the widget is used in a field type that is no supported. It bases on the supported types of the widget definition. opw-[4224192](https://www.odoo.com/web#id=4224192&view_type=form&model=project.task)
This update simplifies how common system fields are handled across several Odoo Enterprise apps. It reduces duplicated technical definitions, helping keep future maintenance safer and more consistent without changing day-to-day workflows.
Original PR description
odoo/odoo#186121
Resolved issues and error corrections
This fixes an issue in Odoo Studio exports where built-in system fields could be handled incorrectly. Exports should now use the proper field names, making exported data more reliable for users.
Original PR description
Use the name instead of the field instance.
Code cleanup and technical improvements
Point of Sale utility files were reorganized into a dedicated folder to make the codebase easier to maintain. This is an internal restructuring with no expected change to day-to-day user workflows.
Original PR description
Reorganization of all utils files into a specific folder. task-id: 4290514
Miscellaneous changes
…pany currency Problem: When calculating the non_deductible_tax_value on an asset the non_deductible_tax_value of the original move lines are not converted into the asset's/company's currency. This is used when calculating the original_value of the asset and can cause incorrect calculations. Purpose of this PR: To make sure the non_deductible_tax_value is stored in the asset's currency How to reproduce: 1- install: Uruguay - Accounting 2 - change company country to Uruguay 3- setti
Original PR description
…pany currency Problem: When calculating the non_deductible_tax_value on an asset the non_deductible_tax_value of the original move lines are not converted into the asset's/company's currency. This…
…pany currency Problem: When calculating the non_deductible_tax_value on an asset the non_deductible_tax_value of the original move lines are not converted into the asset's/company's currency. This is used when calculating the original_value of the asset and can cause incorrect calculations. Purpose of this PR: To make sure the non_deductible_tax_value is stored in the asset's currency How to reproduce: 1- install: Uruguay - Accounting 2 - change company country to Uruguay 3- settings -> accounting -> taxes -> Fiscal Country: Uruguay. 4- create a new tax and make sure that the accounts on % of tax are expenses account so that the tax in non-deductible tax. 5- make sure to select the right tax group and country = Uruguay in the advanced options of tax. 6- create new product, and in accounting tap set the fixed asset account to the expenses account. and in the purchase tap make sure that the vendor taxes is set to the tax created before. 7- create a new vendor bill with the currency set to UYU. and confirm the bill. make sure that the fixed assets account is selected. 8- go to assets and create a new asset, in bills tab add the created bill. the asset will be created and the Original Value filed will contain the wrong amount. When calculating the non_deductible_tax_value for an asset, if there are original move lines in a foreign currency they won't be converted into the assets currency opw-4089386 Forward-Port-Of: odoo/enterprise#73206 Forward-Port-Of: odoo/enterprise#70268
Belgian payroll now shows the eco voucher action only for the relevant holiday termination payslip batches. When used, the wizard creates or updates the correct monthly payslip structure so eco vouchers are included accurately without disrupting payslip presentation.
Original PR description
Problem ---------- - The eco voucher button should be only displayed when a holiday termination payslip is in the batch. (N or/and N-1) - When payslips are generated with the eco-voucher wizard, all…
Problem ---------- - The eco voucher button should be only displayed when a holiday termination payslip is in the batch. (N or/and N-1) - When payslips are generated with the eco-voucher wizard, all payslips have the wrong structure : CP200HOLN. The eco voucher button should generate or regenerate a monthly payslip with the eco voucher inside. Objective ---------- - Display the button for the good structures. - Change the filtered employee in the eco-voucher wizard to match the structs - Use the good struct for payslips generated from eco-voucher wizard : CP200MONTHLY - Add new rule in the structure to display a line in the payslip if an eco-voucher is add as "other fields". (But hide it in the payslip) Solution ---------- - Condition on structure code changed from CP200HOLN and CP200HOLN1 for the visibility of the eco voucher button. - Employees filter changed for the eco-voucher action - Payslip structure changed for payslips generated from the eco-voucher wizard. - New record added in the CP200MONTHLY structure. Test ---------- Python test added to test if an eco-vouchers line is added to payslips in the batch when the user validate the payslip generation from the eco-vouchers wizard. 3 cases are covered : - generated payslips - existing payslips - edited existing payslips (edited with the edit payslip wizard in cogmenu) task-3598939
This fix improves the wording of an error shown when users scan a barcode that is not found during receipt operations. It makes the message clearer and more professional, reducing confusion for warehouse staff.
Original PR description
Barcode --> Operations --> Receipts --> NEW Scan a barcode that doesn't exist in the DB ie: "5449000000996" The current error message's spelling and grammar are off. opw-4307102
Installing the Payroll Accounting module on a new database will now also install the required Accounting app. This prevents setup gaps and ensures payroll accounting features work as expected from the start.
Original PR description
When installing hr_payroll_account on an empty DB, we expect the Accounting app to be installed. But that is not the case. hr_payroll_account should depend on the accountant app.
The commission plan form now uses the standard date range selector, making start and end date selection work better on mobile devices. This reduces friction for users managing commission plans from phones or tablets.
Original PR description
before this commit, commission plan form date field selector seems broken in mobiles devices because we did not directly used widget available. after this commit, use daterange widget.
The sale commission plan list view no longer shows the status field twice. This removes duplicate information from the screen, making the list cleaner and easier for users to read.
Original PR description
in this PR, fixed an issue where the status of the sale commission plan was being displayed twice. This fix ensures that the status information is shown only once.
The l10n_cl_edi_factoring module allows the credit and rights of a generated sales invoice to be yielded to a third party. The third-party will advance the invoice money, charging a commission or interest on the amount as compensation. This feature enhances financial flexibility and cash flow management for businesses using our Odoo instance. The module complies with requirements from the SII (Servicio de Impuestos Internos) regarding the electronic execution of the yield. It includes the gener
Original PR description
The l10n_cl_edi_factoring module allows the credit and rights of a generated sales invoice to be yielded to a third party. The third-party will advance the invoice money, charging a commission or interest on the amount as compensation. This feature enhances financial flexibility and cash flow management for businesses using our Odoo instance. The module complies with requirements from the SII (Servicio de Impuestos Internos) regarding the electronic execution of the yield. It includes the generation of the AEC (Archivo Electrónico de Cesión) file, the creation of the account move for the yield, and the reconciliation of the invoice with the yield account move. This is also compatible with l10n_cl_edi demo mode, generating and simulating the send and acceptation of the AEC to the SII. Task [link](https://www.odoo.com/odoo/project/967/tasks/3982234?cid=3) task-3982234 Forward-Port-Of: odoo/enterprise#70696
Since domain method for the Sales Order Item field is not harcoded anymore, the inheritance in this module is now considered, so it needs to be adapted to work correctly with the expected value, i.e. returning a list instead of a string. [FIX] helpdesk_sale_timesheet: unharcode domain method of SO line field Since domain method of the Sales Order Item field is set using the actual class method instead of a lambda, it is not possible to inherit that method when inheriting the model.
Original PR description
Since domain method for the Sales Order Item field is not harcoded anymore, the inheritance in this module is now considered, so it needs to be adapted to work correctly with the expected value, i.e. returning a list instead of a string. [FIX] helpdesk_sale_timesheet: unharcode domain method of SO line field Since domain method of the Sales Order Item field is set using the actual class method instead of a lambda, it is not possible to inherit that method when inheriting the model. This issue is fixed by using a lambda function to call the domain method. Forward-Port-Of: odoo/enterprise#73188 Forward-Port-Of: odoo/enterprise#72931
With an MX company setup Create a Payment Action > Send receipt by email Traceback will raise ``` KeyError: 'l10n_mx_edi_cfdi_attachment_id' ``` It occurs because the field is not defined on the payment model opw-4298457 Forward-Port-Of: odoo/enterprise#73457
Original PR description
With an MX company setup Create a Payment Action > Send receipt by email Traceback will raise ``` KeyError: 'l10n_mx_edi_cfdi_attachment_id' ``` It occurs because the field is not defined on the payment model opw-4298457 Forward-Port-Of: odoo/enterprise#73457
## Pull Request HOOT (PRHOOT) - part 26 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10
Original PR description
## Pull Request HOOT (PRHOOT) - part 26 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…
## Pull Request HOOT (PRHOOT) - part 26 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 Part 15.5: https://github.com/odoo/odoo/pull/166463 Part 16: https://github.com/odoo/odoo/pull/166311 Part 17: https://github.com/odoo/odoo/pull/168328 Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657 Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767 Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895 Part 21: https://github.com/odoo/odoo/pull/174337 Part 22: https://github.com/odoo/odoo/pull/176777 / https://github.com/odoo/enterprise/pull/68721 Part 23: https://github.com/odoo/odoo/pull/179660 / https://github.com/odoo/enterprise/pull/69728 Part 24: https://github.com/odoo/odoo/pull/181971 Part 25: https://github.com/odoo/odoo/pull/183358 Community: https://github.com/odoo/odoo/pull/186403 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#73361
The trigger in the tour that filter apps was wrongly set to "Not Installed", instead of "Installed". Indeed, that tour puts approval on ir.module's updgrade button, so on already installed apps, and check whether approval rules are triggered when clicking on the "upgrade" button. So we need to filter only installed apps in the ir.module kanban. Forward-Port-Of: odoo/enterprise#73441
Original PR description
The trigger in the tour that filter apps was wrongly set to "Not Installed", instead of "Installed". Indeed, that tour puts approval on ir.module's updgrade button, so on already installed apps, and check whether approval rules are triggered when clicking on the "upgrade" button. So we need to filter only installed apps in the ir.module kanban. Forward-Port-Of: odoo/enterprise#73441
The 'Requests to switch' filter is supposed to show slots that are unwanted and that are not in the past. Prior to this commit, some shifts that were in the future were not shown by the filter. That was because the planning.slot field end_datetime was encoded in UTC while the datetime.datetime.now() function in the filter's domain was returning the datetime in the client's timezone. Shifts in the time difference between the user's timezone and UTC would be mistakenly marked as "past shifts
Original PR description
The 'Requests to switch' filter is supposed to show slots that are unwanted and that are not in the past. Prior to this commit, some shifts that were in the future were not shown by the filter. That was because the planning.slot field end_datetime was encoded in UTC while the datetime.datetime.now() function in the filter's domain was returning the datetime in the client's timezone. Shifts in the time difference between the user's timezone and UTC would be mistakenly marked as "past shifts" while they might still be in the future. We fix this by using the 'to_utc()' function which should make the filter domain's comparisson between 2 UTC datetimes. Fix done in 17.0 task-4286161 Forward-Port-Of: odoo/enterprise#72820
Steps to reproduce: - New product > Storable; Recurring; Edit 'On Hand Quantity' to 10 - New subscription > Add your product > Confirm - Create Invoice > Confirm > Back to sub - View forecast on order line > 1 reserved; 1 forecasted for next period (This is correct, the subscription is ongoing) - Renew > Confirm > View forecast - 1 reserved for original sub (OK); 2 forecasted for next period This is wrong because renewed subscriptions should no longer have recurring invoices, meaning th
Original PR description
Steps to reproduce: - New product > Storable; Recurring; Edit 'On Hand Quantity' to 10 - New subscription > Add your product > Confirm - Create Invoice > Confirm > Back to sub - View forecast on order line > 1 reserved; 1 forecasted for next period (This is correct, the subscription is ongoing) - Renew > Confirm > View forecast - 1 reserved for original sub (OK); 2 forecasted for next period This is wrong because renewed subscriptions should no longer have recurring invoices, meaning there is no reason to forecast a stock decrease for them. i.e here it should only forecast 1 unit for the next period corresponding to our new subscription (Created by renew). Prior to 17.0 a storable product cannot also be recurring, so this issue is irrelevant there. opw-4239989 Forward-Port-Of: odoo/enterprise#73413 Forward-Port-Of: odoo/enterprise#72397
Steps --- * Create a payslip for an Employee with a contract (e.g. Anita Oliver) (*Payroll > Payslips > All Payslips > New*) * From the *Edit Payslip Lines* action, try to add a new worked day line (first list) with a non 0 amount * *Validate Edition* => Traceback Cause --- When saving new worked days lines, we try to recompute the amount of the *Basic Salary* payslip line, but if the payslip is still a **draft** it was never computed, and so the action we are calling does not exist
Original PR description
Steps --- * Create a payslip for an Employee with a contract (e.g. Anita Oliver) (*Payroll > Payslips > All Payslips > New*) * From the *Edit Payslip Lines* action, try to add a new worked day line (first list) with a non 0 amount * *Validate Edition* => Traceback Cause --- When saving new worked days lines, we try to recompute the amount of the *Basic Salary* payslip line, but if the payslip is still a **draft** it was never computed, and so the action we are calling does not exist. task-4191349 Forward-Port-Of: odoo/enterprise#72031 Forward-Port-Of: odoo/enterprise#71373
Have a node that goes: ```xml <div groups="!module.some_group" /> ``` Before this commit, this case was not handled and that not-group was just ignored. This created confusion as the node, when the user was part of the group, would be invisible, the checkbox invisible would be ticked, and uniticking it had no effect. After this commit, we handle the case, with a second selector in the studio sidebar. opw-4273853 Forward-Port-Of: odoo/enterprise#73419 Forward-Port-Of: odoo/enter
Original PR description
Have a node that goes: ```xml <div groups="!module.some_group" /> ``` Before this commit, this case was not handled and that not-group was just ignored. This created confusion as the node, when the user was part of the group, would be invisible, the checkbox invisible would be ticked, and uniticking it had no effect. After this commit, we handle the case, with a second selector in the studio sidebar. opw-4273853 Forward-Port-Of: odoo/enterprise#73419 Forward-Port-Of: odoo/enterprise#73233
Adding the journal type to the user informations of the OCR parsing request will help the algorithm as it'll know whether it's a credit card statement or a "regular" bank statement that is being parsed. Task 4285658 Forward-Port-Of: odoo/enterprise#72829
Original PR description
Adding the journal type to the user informations of the OCR parsing request will help the algorithm as it'll know whether it's a credit card statement or a "regular" bank statement that is being parsed. Task 4285658 Forward-Port-Of: odoo/enterprise#72829
In this commit, we remove useless run: "click" on steps that are just a check. Forward-Port-Of: odoo/enterprise#73393
Original PR description
In this commit, we remove useless run: "click" on steps that are just a check. Forward-Port-Of: odoo/enterprise#73393
The problem: In the accounting reports, filter options were not being translated. Steps to reproduce: Install and change to the Danish language. Navigate to Accounting > Reporting > Partner ledger (Kontoudtog) Activate the filter "Only Show Unreconciled Entries" (Vis kun ikke udlignede posteringer) Generate the PDF report. Why it was happening: The array `extra_options` was built dynamically by concatenating raw python strings to it. Those raw strings will not be translated. The f
Original PR description
The problem: In the accounting reports, filter options were not being translated. Steps to reproduce: Install and change to the Danish language. Navigate to Accounting > Reporting > Partner ledger (Kontoudtog) Activate the filter "Only Show Unreconciled Entries" (Vis kun ikke udlignede posteringer) Generate the PDF report. Why it was happening: The array `extra_options` was built dynamically by concatenating raw python strings to it. Those raw strings will not be translated. The fix: Now, we create local variables for each string, using the syntax `<t t-set="label_raw_string">Raw String</t>` which makes the string label_raw_string translatable, then we append it to `extra_options`. opw-4213562 Forward-Port-Of: odoo/enterprise#73421 Forward-Port-Of: odoo/enterprise#72870
Steps to reproduce: - go to any pivot view - Insert the pivot into a spreadsheet - hit the "Freeze & share" button - open the sharing link in an incognito window => blank page When the document is copied (using the `copy` method), the frozen data is given as a new value for `spreadsheet_data`. But revisions are still copied even though new data is provided on which the revisions should not apply. Task: 4299935 Forward-Port-Of: odoo/enterprise#73117
Original PR description
Steps to reproduce: - go to any pivot view - Insert the pivot into a spreadsheet - hit the "Freeze & share" button - open the sharing link in an incognito window => blank page When the document is copied (using the `copy` method), the frozen data is given as a new value for `spreadsheet_data`. But revisions are still copied even though new data is provided on which the revisions should not apply. Task: 4299935 Forward-Port-Of: odoo/enterprise#73117
Purpose ======= Fix the left panel which wasn't updated when dragging a folder to trash. Specification ============= When dragging a document of type 'folder' to the trash, the model is correctly being notified but the search model isn't, the folder is thus still visible in the left panel. Fixing that by also reloading the search model when archiving a document. Moving the reloading methods calls from toggleArchive to onDropDocuments as it is the only method where we don't reload t
Original PR description
Purpose ======= Fix the left panel which wasn't updated when dragging a folder to trash. Specification ============= When dragging a document of type 'folder' to the trash, the model is correctly being notified but the search model isn't, the folder is thus still visible in the left panel. Fixing that by also reloading the search model when archiving a document. Moving the reloading methods calls from toggleArchive to onDropDocuments as it is the only method where we don't reload the model and search model after archiving. Keeping the reload calls in toggleArchive caused redundant reloads of the models. Task-4260645 Forward-Port-Of: odoo/enterprise#72068
Before this PR, the oe_add class caused the input field to stretch across the entire line. After this PR, adjustments to the class ensure it only takes up the necessary space. task-4223539 Forward-Port-Of: odoo/enterprise#71333
Original PR description
Before this PR, the oe_add class caused the input field to stretch across the entire line. After this PR, adjustments to the class ensure it only takes up the necessary space. task-4223539 Forward-Port-Of: odoo/enterprise#71333
Steps: Create a product of type service that creates a task. Create a subscription with that product, and confirm. Note that if you set the task's state to done, it creates another one. Close the subscription. Issue: If you set the task's state to done, it still creates another one, whereas it would make sense that the task's recurrence ends with the "invoice recurrence". Cause: Actually, it was first designed that way, and `_set_closed_state` was overridden to unlink the recurrence. B
Original PR description
Steps: Create a product of type service that creates a task. Create a subscription with that product, and confirm. Note that if you set the task's state to done, it creates another one. Close the subscription. Issue: If you set the task's state to done, it still creates another one, whereas it would make sense that the task's recurrence ends with the "invoice recurrence". Cause: Actually, it was first designed that way, and `_set_closed_state` was overridden to unlink the recurrence. But then that method and `set_close` were rethought and the override wasn't called anymore. Solution: Just do the same thing, but in `set_close` i/o `_set_closed_state`. task-4259561 Forward-Port-Of: odoo/enterprise#72706
Forward-Port-Of: odoo/enterprise#73389
Original PR description
Forward-Port-Of: odoo/enterprise#73389
https://github.com/odoo/odoo/pull/164671 offers a way for non-template editors to use simple expressions. Thanks to this, most of the expressions used in email templates, such as the partner name in an opportunity email template, can be used by regular users without the need to be an email template editor. Thanks to this, the need to set, by default, internal users as template editors is no longer a strong necessity. This revision aims to set the "Restrict Template Rendering" setting
Original PR description
https://github.com/odoo/odoo/pull/164671 offers a way for non-template editors to use simple expressions. Thanks to this, most of the expressions used in email templates, such as the partner name in an opportunity email template, can be used by regular users without the need to be an email template editor. Thanks to this, the need to set, by default, internal users as template editors is no longer a strong necessity. This revision aims to set the "Restrict Template Rendering" setting by default. Companies needing to set everyone as an email template editor can enable this back by un-checking its related box in the general settings. task-4246174 Forward-Port-Of: odoo/enterprise#71619
To check that an amount is greater than another one, compare_amounts need to be bigger than 0 not 1 Forward-Port-Of: odoo/enterprise#73183 Forward-Port-Of: odoo/enterprise#73159
Original PR description
To check that an amount is greater than another one, compare_amounts need to be bigger than 0 not 1 Forward-Port-Of: odoo/enterprise#73183 Forward-Port-Of: odoo/enterprise#73159
**Steps to reproduce:** - Install account_3way_match - Go to "Invoicing / Vendors / Bills" - Create a bill - (Edit the view in order to display "release_to_pay" field) - (Make sure that "Force Status" (force_release_to_pay) is always checked) - Set "Should Be Paid" (release_to_pay_manual) to "Yes" => "release_to_pay" becomes "Yes" - Save the bill => "release_to_pay" stays "Yes" - Change "Should Be Paid" to "No" => "release_to_pay" becomes "No" - Save the bill => "release_to_pay" reverts
Original PR description
**Steps to reproduce:** - Install account_3way_match - Go to "Invoicing / Vendors / Bills" - Create a bill - (Edit the view in order to display "release_to_pay" field) - (Make sure that "Force Status" (force_release_to_pay) is always checked) - Set "Should Be Paid" (release_to_pay_manual) to "Yes" => "release_to_pay" becomes "Yes" - Save the bill => "release_to_pay" stays "Yes" - Change "Should Be Paid" to "No" => "release_to_pay" becomes "No" - Save the bill => "release_to_pay" reverts to "Yes" **Issue:** Upon save, "release_to_pay" reverts to "Yes", even if it has been correctly computed to "No" before saving. opw-4181752 Forward-Port-Of: odoo/enterprise#73289 Forward-Port-Of: odoo/enterprise#72190
**Steps to reproduce:** 1. send a sign request to the user. 2. attempt to sign a document without logging in. **Issue:** Session expiration pop-up appears unexpectedly. **Cause:** Due to recent improvements, the userId is not being retrieved as expected. **Fix:** Modify the condition to handle cases where userId is either null or false. task-4178827 Forward-Port-Of: odoo/enterprise#69939
Original PR description
**Steps to reproduce:** 1. send a sign request to the user. 2. attempt to sign a document without logging in. **Issue:** Session expiration pop-up appears unexpectedly. **Cause:** Due to recent improvements, the userId is not being retrieved as expected. **Fix:** Modify the condition to handle cases where userId is either null or false. task-4178827 Forward-Port-Of: odoo/enterprise#69939
Steps to reproduce: 1. select a document 2. open chatter 3. drag(preview part) and drop to the others folder 4. the mail-chatter-dropzone remains open Technical Reason: Removing the unnecessary stop propagation on the search panel's document drop event as it was preventing it from being caught by the window keeping the chatter drop zone open. After this commit: The mail-chatter-dropzone will be closed after being moved to drag documents to the folders. Task-4268738 Forward-Por
Original PR description
Steps to reproduce: 1. select a document 2. open chatter 3. drag(preview part) and drop to the others folder 4. the mail-chatter-dropzone remains open Technical Reason: Removing the unnecessary stop propagation on the search panel's document drop event as it was preventing it from being caught by the window keeping the chatter drop zone open. After this commit: The mail-chatter-dropzone will be closed after being moved to drag documents to the folders. Task-4268738 Forward-Port-Of: odoo/enterprise#73354 Forward-Port-Of: odoo/enterprise#72443
### Current behavior before PR: When creating a Helpdesk team and the Timesheets option enabled and Time Billing disabled you will not get all non-billed projects in the dropdown menu. This is happening because the domain for project_id is checking the company_id to be the same as the company_id of the team. https://github.com/odoo/enterprise/blob/18.0/helpdesk_sale_timesheet/models/helpdesk_team.py#L10 Though since this commit https://github.com/odoo-dev/odoo/commit/16a07ed1bfd33a193b363f3e87
Original PR description
### Current behavior before PR: When creating a Helpdesk team and the Timesheets option enabled and Time Billing disabled you will not get all non-billed projects in the dropdown menu. This is…
### Current behavior before PR: When creating a Helpdesk team and the Timesheets option enabled and Time Billing disabled you will not get all non-billed projects in the dropdown menu. This is happening because the domain for project_id is checking the company_id to be the same as the company_id of the team. https://github.com/odoo/enterprise/blob/18.0/helpdesk_sale_timesheet/models/helpdesk_team.py#L10 Though since this commit https://github.com/odoo-dev/odoo/commit/16a07ed1bfd33a193b363f3e87aab3f9bd6f8bd0 company_id is not required for projects. Since the domain of the project_id field was introduced here https://github.com/odoo/enterprise/pull/4956/commits/c82b1b019cebd1f78749b9563e717fae88d7fae5 and the reason why we check the company_id is not the same anymore since the commit I mentioned above we should not use the same domain. Also in this PR we are solving another issue which is where you enable both Timesheets and Time Billing options and choose a project that has both options enabled too then you disable the Time Billing option for the team the project that we chose before will be kept and have both options enabled and you can save it. ### Desired behavior after PR is merged: We are now checking for the project of the team if the company_id is False or equal to the team's company_id. Also when disbaling the Time Billing option we set the project_id to False. opw-4275647 opw-4148207 Forward-Port-Of: odoo/enterprise#72935
Currently, when the "Ask to Switch" toast is displayed, the fa-check-circle and fa-exclamation-circle are not visible because they have the same color as the background of the toast. This PR will remove their color, making them dark and visible. task-3919543 Forward-Port-Of: odoo/enterprise#71345
Original PR description
Currently, when the "Ask to Switch" toast is displayed, the fa-check-circle and fa-exclamation-circle are not visible because they have the same color as the background of the toast. This PR will remove their color, making them dark and visible. task-3919543 Forward-Port-Of: odoo/enterprise#71345
Steps to reproduce: ------------------- 1. Install Planning app 2. Have an employee A with 40h/week working schedule and an employee B with 35h/week working schedule 3. Create a shift and assign it to employee A, the default allocated hours should be 8h 4. From the Gantt view, duplicate this shift and assign it to employee B (use drag and drop) 5. Problem: The allocated hours of the duplicated shift are not recomputed, they are equal to 8h instead of 7h Fix: ------------------- When d
Original PR description
Steps to reproduce: ------------------- 1. Install Planning app 2. Have an employee A with 40h/week working schedule and an employee B with 35h/week working schedule 3. Create a shift and assign it to employee A, the default allocated hours should be 8h 4. From the Gantt view, duplicate this shift and assign it to employee B (use drag and drop) 5. Problem: The allocated hours of the duplicated shift are not recomputed, they are equal to 8h instead of 7h Fix: ------------------- When duplicating a shift and assigning it to another resource, the copy() method is called with the resource_id of the target resource (an employee in this case). But _compute_allocated_hours() is not called so we have to call it explicitly in this case. version-17.0 task-3978590 Forward-Port-Of: odoo/enterprise#69828