Monday, November 25, 2024
26 changes · 17.0
Enhancements to existing features
This update corrects a terminology inconsistency in the US payroll module. The term 'Taxable Salary' has been replaced with 'Gross Pay' for salary rules and categories, aligning with US tax regulations and reporting standards. This ensures accurate payroll calculations and reporting for US-based employees.
Original PR description
The previously named 'Taxable Salary' for the salary rule 'GROSS' and the category 'GROSS' should be renamed in the US to 'Gross Pay'. Task: 4329661
Resolved issues and error corrections
The web app installation prompt no longer suppresses the browser's default event handling when it is not needed. This keeps the same user-facing installation prompt behavior while avoiding unnecessary console messages, helping keep diagnostics cleaner.
Original PR description
It is not necessary useful to prevent the event in our case, so we can just stop doing it while maintaining the same functionality. Preventing the event writes a log in the console, and we prefer to avoid having a log if we can keep the service without it.
Miscellaneous changes
For an expense report paid by an employee, the bank account should be set on the employee form and be used to create the Journal Entry and in Register Payment Wizard. enterprise: https://github.com/odoo/enterprise/pull/71080 task-4206895 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181870
Original PR description
For an expense report paid by an employee, the bank account should be set on the employee form and be used to create the Journal Entry and in Register Payment Wizard. enterprise: https://github.com/odoo/enterprise/pull/71080 task-4206895 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181870
List views now do less repeated work when checking which row is being edited. This should make editing in lists feel smoother, especially on longer records or embedded lists in areas like accounting and projects.
Original PR description
This commit reduces the number of read to a getter `editedRecord` which loops on all the record of the list to find the current one in edition.
Accounting setup now correctly loads demo data for company branches when chart templates are installed. This prevents branch demo environments from breaking and adds test coverage to help avoid regressions.
Original PR description
The chart template loading process involves loading demo data for branches [^1], but at the moment this is not tested and broken. This commit fixes the flow and adds a test. [^1]: https://github.com/odoo/odoo/blob/b79bcb0574354a17a2aa64e2fe8d05da95535257/addons/account/models/chart_template.py#L232 Enterprise PR: https://github.com/odoo/enterprise/pull/74409 task-none
The Czech and Slovak localization views now show the company registry field based on the company’s own country, rather than fiscal country settings. This prevents the field from appearing more than once and keeps partner forms clearer for users managing companies in these countries.
Original PR description
Using fiscal_country_codes in the invisible condition can result in the field being displayed multiple times, as multiple countries may meet the condition. Instead, we are using country_code, as it is more logical for the field to be visible only if the company is located in that specific country. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents errors when Starshipit reports an order as not manifested even though it already is. The system now checks whether the manifest PDF is available before using it, avoiding failed shipping manifest actions for affected deliveries.
Original PR description
Before this commit: Manifesting order in starshipit sometimes fails to return manifest 'pdf'. In order details we get `order_manifested = False` when it is already manifested. So we send a new request to manifest, in which 'pdf' is not returned if order is already manifested. After this commit: Added an additional check for 'pdf' to avoid traceback when order is already manifested. opw-4119236
This update corrects a test issue in the HR Payroll Expense module, ensuring that an employee's bank account is established before approval of the payroll expense sheet. This prevents errors and ensures accurate processing of payroll transactions. The fix improves the reliability of the HR payroll system.
Original PR description
related: https://github.com/odoo/odoo/pull/181870 task-4206895 Forward-Port-Of: odoo/enterprise#71080
This update fixes a problem that prevented users from completely uninstalling the Helpdesk module when other Helpdesk-related modules were also removed. The change ensures a smooth uninstall process by forcing a necessary data refresh, preventing a key error related to field configurations.
Original PR description
Issue ----- With helpdesk_fsm installed, uninstall helpdesk_fsm or any module that will trigger its uninstallation (e.g. helpdesk): Error: ``` in fields.py: fields = records.pool.field_computed[self]…
Issue ----- With helpdesk_fsm installed, uninstall helpdesk_fsm or any module that will trigger its uninstallation (e.g. helpdesk): Error: ``` in fields.py: fields = records.pool.field_computed[self] KeyError: 'helpdesk.team.fsm_project_id' ``` Cause ----- Issue since 1da1467115726263e5cdc50354b4413f8bb7ca7d and the addition of `use_fsm` as a dependency of `_compute_fsm_project_id` When we uninstall any helpdesk module, we set to False the associated fields of all helpdesk teams (mapped in `_get_field_modules`) for all uninstalled modules. https://github.com/odoo/enterprise/blob/9fba5f841c3c0710eb0cce00263bf914dac03dc6/helpdesk/models/ir_module.py#L13-L16 The change of `use_fsm` means `fsm_project_id` is marked as a field to be recomputed. This happens at some point during a `flush_all`, but after the field has been deleted in DB and a new registry has been loaded without that field. Change ----- Force a recomputation by flushing the records. opw-4338172 opw-4339801 Forward-Port-Of: odoo/enterprise#74255
This update resolves an error in the Hong Kong payroll module that prevented calculations for internet allowances for new employees who hadn't started working. The fix ensures accurate allowance calculations by handling cases where work days are zero, preventing the system from crashing.
Original PR description
Steps to reproduce: - Install both hr_contract_salary and l10n_hk_Hr_payroll - Try to review a contract in recruitment Current behaviour: - Exception raised Expected behaviour: - No exception raised Explanation: - Internet allowance is based on employee actual work days. However, for candidate who hasn't join the company, they won't have any work days. Therefore the salary internet rules prorata_rate will be divided by zero, and raised exceptions. X-original-commit: f9e7d39
This update optimizes the performance of Odoo's list views by streamlining how the system identifies the currently edited record. By reducing unnecessary database queries, this change results in faster loading times for list views, enhancing the user experience.
Original PR description
This commit reduces the number of read to a getter `editedRecord` which loops on all the record of the list to find the current one in edition.
This update resolves an issue where document filtering was overly restrictive, limiting the actions available on visible records. By disabling domain selection, the system now correctly applies actions to records that are currently displayed, ensuring users can perform the intended operations. This improves the overall usability of the document management feature.
Original PR description
We disable the domain selection because most of the actions are only applied on visible records. Task-3754115
This update corrects an issue where the date wasn't displayed on Chilean Point of Sale (POS) receipts when a VAT number wasn't entered. The localization logic was incorrectly removing the date based on country and VAT status, leading to inconsistent display. This fix ensures the date is always shown on receipts for Chilean POS transactions, regardless of VAT presence.
Original PR description
### Steps to reproduce: - Install "l10n_cl_edi_pos" - Create a new company with the Chilian localization - Do not add a VAT number - Go to POS, create an order and validate - The date is not displayed on the ticket ### Cause: The localization is moving the date from the bottom of the receipt to the header but the conditions are not the same: - If the country of the company is Chile then date is removed from the bottom - If the company has a Chilian VAT the date is shown in the header So there is a case where none of the conditions are True and the date does not show. ### Solution: Add a condition on the VAT to delete the date from the bottom. opw-4330252
This update eliminates the creation of a duplicate demo account (123456) within Odoo branches. Branches primarily use their parent company's accounting data, so this change streamlines account management and avoids unnecessary duplication. It ensures branches accurately reflect their parent company's chart of accounts.
Original PR description
Branches can access their parent companies' accounts, and generally will just use their parent companies' CoA. Therefore, it makes no sense to create an account `123456 Account Payslip Houserental` in a branch if it already exists in the parent company. Community PR: https://github.com/odoo/odoo/pull/188247 task-none
This update resolves a crash within the Web Studio module that occurred when reloading the interface. The fix ensures that critical data passed through URLs is correctly loaded, preventing the application from failing. This improves the overall stability and reliability of Web Studio for users.
Original PR description
…o studio Have a flow where active_ids is in the url and is used by the action itself (with a dynamic context key for example). Enter studio and reload. Before this commit, this flow crashed, because active_ids was not present. After this commit it doesn"t crash. opw-4296198 Forward-Port-Of: odoo/enterprise#74291
This update fixes a bug that caused a traceback error when merging two Helpdesk tickets with specific SLA configurations. The change ensures the correct method is called during the merge process, preventing the error and ensuring smooth ticket merging functionality. This improves the stability and reliability of the Helpdesk module.
Original PR description
### Steps to reproduce: - Install Data Cleaning and Helpdesk modules - Create 2 Helpdesk tickets with conditions: - at least 1 helpdesk ticket has an SLA policy and is in a stage excluded by the SLA policy - at least 1 helpdesk ticket doesn't have an SLA deadline and has an SLA policy and is also in a stage excluded by the SLA policy - Merge those 2 tickets - Notice a traceback pops-up ### Current behavior before PR: In this commit https://github.com/odoo/enterprise/pull/69352/commits/97e83104dad816a7a65345dea74a66e5dbea94cb a new merge method was introduced but in the new file we created we are importing datetime from datetime and then using datetime.datetime and since we are already importing the sepcific class we don't need to call it like module.class.method ### Desired behavior after PR is merged: We are calling the method directly from the class without using the module before the call so it is only datetime.max opw-4330793
This update fixes an issue within Odoo's Web Studio module related to how address formatting is handled. The change ensures that address replacements work correctly when a specific setting is used, improving the consistency of address displays. This resolves a technical limitation impacting the user experience within Web Studio.
Original PR description
The FormatAddressMixin implements a feature that will replace some parts of a view with some other when having no_address_format in the context. commit 28d8ee5ea27106bf21e5a25c3fce48d39ffed4fd partially solved the problem, but not for all the spots where we need to do a `get_view` without being parasited with the foreign tree parts. opw-4335439
This update ensures that transaction currencies are correctly set, even when a company doesn't use multiple currencies. Previously, a missing currency setting would cause issues. Now, the system automatically uses the company's default currency, improving data accuracy and reliability.
Original PR description
In case we are not in a multi currency environment the currency of the journal is falsy, so if there is not a currency set, we take the one from the company task: 4293986
In this commit https://github.com/odoo/odoo/pull/155339/commits/ca2d54a81ebb2611c14b0fc06784bd5d285856e3, in the task form, we changed the sol field to make it editable even when the user has no sale access. Trying to edit this field in such conditions produces an Access Error, so we revert this commit. task-4207245 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182158
Original PR description
In this commit https://github.com/odoo/odoo/pull/155339/commits/ca2d54a81ebb2611c14b0fc06784bd5d285856e3, in the task form, we changed the sol field to make it editable even when the user has no sale access. Trying to edit this field in such conditions produces an Access Error, so we revert this commit. task-4207245 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182158
Before this commit: Some logger.error(...) were ambigious and would just catch the exception to log it's error name without much details. Therefore it was wasting time trying to figure the cause of the error as we lack the traceback details After this commit: Most of them were switch to logger.exception which does add the Exception information to the logging messages automatically. Which include the error message alongside the full traceback. Log messages were also rewrote to be more
Original PR description
Before this commit: Some logger.error(...) were ambigious and would just catch the exception to log it's error name without much details. Therefore it was wasting time trying to figure the cause of the error as we lack the traceback details After this commit: Most of them were switch to logger.exception which does add the Exception information to the logging messages automatically. Which include the error message alongside the full traceback. Log messages were also rewrote to be more comprehensive than the: "An error encountered" Example of logs that would be improved: ``` 2024-11-19 07:19:50,611 1138 ERROR ? odoo.addons.hw_drivers.tools.helpers: Unable to load file: PrinterInterface_L.py 2024-11-19 07:19:50,612 1138 ERROR ? odoo.addons.hw_drivers.tools.helpers: An error encountered : (1280, 'Success') ``` Forward-Port-Of: odoo/odoo#186162
Before this commit, a KeyError would occur if 'entryPointType' was missing in the entryPoints dictionary. opw-4009884 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188002
Original PR description
Before this commit, a KeyError would occur if 'entryPointType' was missing in the entryPoints dictionary. opw-4009884 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188002
**Current behavior:** With a product that is invoiced based on ordered qty, has avg costing, and real time valuation: it is possible to invoice and received quantity in such an order that, when there is a landed cost associated with an invoice instance of the product, the standard price of the product may be updated with an incorrect value. **Expected behavior:** Product cost follows 'average' selection logically. **Steps to reproduce:** *Enable anglo-saxon accounting* 1. Create
Original PR description
**Current behavior:** With a product that is invoiced based on ordered qty, has avg costing, and real time valuation: it is possible to invoice and received quantity in such an order that, when there…
**Current behavior:** With a product that is invoiced based on ordered qty, has avg costing, and real time valuation: it is possible to invoice and received quantity in such an order that, when there is a landed cost associated with an invoice instance of the product, the standard price of the product may be updated with an incorrect value. **Expected behavior:** Product cost follows 'average' selection logically. **Steps to reproduce:** *Enable anglo-saxon accounting* 1. Create a product with: * real time property valuation * average cost method * on ordered quantities control policy 2. Create a purchase order for the product, for 100 000 units of the product at 1.35 each -> confirm the order 3. Create an invoice for 23 000 units, receive 23 000 units and backorder the rest 4. Create a landed cost on the invoice for 23 000 in the company currency units 5. Post the invoice 6. Create a second invoice for 27 000 units and post it 7. Receive 27 000 more units from the receipt 8. See that the product standard price is not the expected value of 1.81 **Cause of the issue:** The landed cost on the invoice is not taken into account. Since the price unit for the moves informing the new price value are obtained with `_get_price_unit()`, we end up only taking into account the sum value of the invoice lines linked to the move. So the landed cost does not get included in the subsequent price unit calculation here: https://github.com/odoo/odoo/blob/22e7bfb591c43e849c554eb4c128279d76ad31f9/addons/stock_account/models/stock_move.py#L328 **Fix:** Extract a method which returns invoice lines to the `_get_price_unit()` method of purchase_stock so that we may return line records that represent landed costs that will otherwise be omitted. opw-4048396 Forward-Port-Of: odoo/odoo#185889
Install mass-mailing and crm. Change the email address of Brandon to a@example.com;b@example.com. In the list view of crm, add the select all leads and change their customer to Brandon (the customer column is not displayed by default, just make it visible). Create a new mass-mailing with the recipient list as "Lead/Opportunity". Start the campaign. Brandon receives as many emails as there are leads but he shall only receive one. The system has a known limitation when it comes to filtering dup
Original PR description
Install mass-mailing and crm. Change the email address of Brandon to a@example.com;b@example.com. In the list view of crm, add the select all leads and change their customer to Brandon (the customer…
Install mass-mailing and crm. Change the email address of Brandon to a@example.com;b@example.com. In the list view of crm, add the select all leads and change their customer to Brandon (the customer column is not displayed by default, just make it visible). Create a new mass-mailing with the recipient list as "Lead/Opportunity". Start the campaign. Brandon receives as many emails as there are leads but he shall only receive one. The system has a known limitation when it comes to filtering duplicates: it skips all records that have multiple recipients. In this case Brandon has two: [a@example.com](mailto:a@example.com) and [b@example.com](mailto:b@example.com). The de-duplication mechanism was skipped for every lead he was the customer of and each time a new email was sent, spamming him. In this work we make it possible to also process records with multiple recipients. It is a best-effort and will still let some duplicates through. Nonetheless it solves the current problem with minimal changes. Note: any([]) and any(['']) are both False while all([]) is True, hence we now check for empty list / empty email first otherwise an empty list would be considered to be opt-out instead of empty. Task-3927361 Forward-Port-Of: odoo/odoo#186149
Issue: ====== `enter` command doesnt work properly for `pre` element inside list element. Steps to reproduce the issue: ============================= - Add a list - Add a code block with `/code` - Add sone text - Put the cursor at the end of the text - click `enter` - It adds a `br` element and puts the selection at the start. Origin of the issue: ==================== The `oEnter` function of the `pre` element is triggered which adds a `p` element just after the `pre` element in
Original PR description
Issue: ====== `enter` command doesnt work properly for `pre` element inside list element. Steps to reproduce the issue: ============================= - Add a list - Add a code block with `/code` - Add sone text - Put the cursor at the end of the text - click `enter` - It adds a `br` element and puts the selection at the start. Origin of the issue: ==================== The `oEnter` function of the `pre` element is triggered which adds a `p` element just after the `pre` element inside the same `li` element. Now in sanitiwe we unwrap the p elements inside `li` which leaves us with only a `br` after the `pre`. Since we put the selection at the start of the newly added then removed `p` element, the final selection will not behave correctly. Solution: ========= We single out the case when the parent element of the `pre` is a `li` and treat it as a break inside a `li`. task-4187676 Forward-Port-Of: odoo/odoo#180268
This PR fixes readability issues within the forecast details table. Prior to this PR, the table was using arbitrary color that were out of our color maps, meaning that they were not dark mode proof by default. As no variation was defined for these color in dark mode, some readability issues would occur in some cases (e.g link color over that background in dark mode). To handle this issue, we go back to basics and use Bootstrap default table utility classes, easing the maintenance and pr
Original PR description
This PR fixes readability issues within the forecast details table. Prior to this PR, the table was using arbitrary color that were out of our color maps, meaning that they were not dark mode proof by default. As no variation was defined for these color in dark mode, some readability issues would occur in some cases (e.g link color over that background in dark mode). To handle this issue, we go back to basics and use Bootstrap default table utility classes, easing the maintenance and preventing. readability issues. | 16.0 | This PR | |--------|--------| | <img width="459" alt="image" src="https://github.com/user-attachments/assets/571d9dea-2f42-479d-9fb1-85c9e1afbc76"> | <img width="451" alt="image" src="https://github.com/user-attachments/assets/121ec777-5a24-48da-912e-41f51e662e7a"> | task-4344045 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187719
This commit will correct the fact that the siret and APE number must be displayed also when the country code is from the DOM-TOM task:4290323 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185862
Original PR description
This commit will correct the fact that the siret and APE number must be displayed also when the country code is from the DOM-TOM task:4290323 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185862