Friday, April 26, 2024
41 changes
1 change
Resolved issues and error corrections
Fixed an issue where email marketing messages could fail to send when a template contained social media icons or buttons without a web link. This helps users send standard marketing templates reliably without hidden errors blocking delivery.
Original PR description
Currently, an exception is generated when the user sends a template to a mailing that contains icons like Facebook, LinkedIn, etc. Steps to produce an exception: 1. Create a database without demo…
Currently, an exception is generated when the user sends a template to a mailing that contains icons like Facebook, LinkedIn, etc. Steps to produce an exception: 1. Create a database without demo data > install 'Email Marketing'. 2. Go to Email Marketing > Create New > Select the `Welcome Message` template. 3. Click 'Send' >> An error will occur in the log, and there is nothing to send. Error: `AttributeError: 'NoneType' object has no attribute 'startswith'` This is because at [1], we don't have `href` in 'link_node', so we receive `False` in 'original_url', and as a result, it generates an error while accessing 'original_url.startswith'. With the recently refactored code with commit https://github.com/odoo/odoo/commit/6349051e5e4442cfabc899520c5708081dc0be31, line [1] was added. Before this change, Line [2] was filtering out elements from `html` that did not have 'href'. This commit will fix the above issue by not processing to find the absolute URL if we do not have `original_url`. [1]- https://github.com/odoo/odoo/blob/b6629bbdb53d9a4bacee2032190e30a848bb6d6d/addons/link_tracker/tools/html.py#L25 [2]- https://github.com/odoo/odoo/blob/c9644a086b294e69b69e52e8ccfd5292bde815da/addons/link_tracker/models/mail_render_mixin.py#L39 sentry-5140192785
24 changes
Resolved issues and error corrections
This update brings the Colombian electronic invoice system into compliance with the new Anexo 1.9 specification, which requires converting invoice amounts to Colombian Pesos (COP). The changes also fix a bug where credit note concepts were being set after posting instead of before, and add test coverage for vendor documents to ensure quality.
Original PR description
### [FIX] l10n_co_edi: add a test for the vendor document Previously there was no test for the vendor document. This commit adds a (simple) test.c In the next commit of the same PR the code for the…
### [FIX] l10n_co_edi: add a test for the vendor document Previously there was no test for the vendor document. This commit adds a (simple) test.c In the next commit of the same PR the code for the vendor document had to be adapted while keeping the result the same. This test helps in making sure nothing went wrong. The reason was that the electronic invoice and vendor document share some common code / logic but the shared parts had to be changed for an update to the electronic invoice spec (Anexo 1.9). (See the next commit for details) ### [FIX] l10n_co_edi: update for anexo 1.9 The spec for electronic invoices in Colombia was updated and is now known as Anexo 1.9. This commit updates the electronic invoice to meet the new spec A bit part of the new spec is the conversion of many fields from document to company currency / COP. There is also a vendor document. But it follows a different spec. Thus some shared logic / section with the electronic invoice was updated so that the vendor document remains unchanged. The following sections were removed since they are obsolete and also (basically) dead code: * OVT section: dead code * FE1 section: content is dead code Previously when creating a credit note from an invoice with the reversal wizard (account.move.reversal) there was the following bug. The Credit Note Concept (l10n_co_edi_description_code_credit on account.move) was set after posting. This was corrected in this commit (since a validation on post was added to check that the concept is there). ### task task-3639271 ### related PRs forward-port of https://github.com/odoo/enterprise/pull/54086 (15.0) https://github.com/odoo/enterprise/pull/55268 (16.0) https://github.com/odoo/enterprise/pull/55274 (saas-16.3)
This update improves how Odoo handles invoice cancellations with Mexico's SAT (tax authority). Previously, invoices would be marked as cancelled even if the SAT rejected the cancellation request. Now the system properly tracks cancellation requests separately and automatically handles cases where the SAT cancels documents directly, ensuring the invoice status accurately reflects the SAT's approval or rejection of cancellation requests.
Original PR description
Case 1: The user can cancel the document directly from the SAT. In that case, in odoo, the user needs to "Request Cancel" first even if the SAT state becomes 'cancelled'. To improve that, this case is now managed by adding a new cancel document automatically on the invoice. Case 2: The user can request a cancellation from the SAT. Currently, the invoice is marked as "cancel" even if the SAT rejects the cancellation. In order to manage that, let's introduce a new document: 'invoice_cancel_requested'.
Fixed an issue where completing a field service task incorrectly updated the delivery quantity for products using milestone-based invoicing. Now, delivery quantities for milestone-based products are only updated when milestones are actually reached, not when tasks are marked as done.
Original PR description
To Reproduce: ============= - create a service Product with **invoicing policy** based on milestones and **create on Order** a task in fsm - create Sale order with this product and confirm it - a task is created, mark the task as done (with the button 'Mark as Done') -> the delivered quantity of the sale order line is updated to 1 Problem: ======== - marking the task as done should not update the delivered quantity of the sale order line of product based on milestones Solution: ========= add condition to check if the product invoicing policy is based on milestones before updating the delivered quantity of the sale order line as it will be done when the milestones are reached opw-3850167
This update fixes technical issues in the appointment scheduling system's gantt view that were preventing it from displaying correctly when multiple resources from different companies are involved. The fix updates outdated code references and improves how the system handles resource assignments and access permissions, making the gantt view more reliable for scheduling appointments.
Original PR description
In [1] we added a domain on appointment actions to prevent a traceback when users visit the gantt appointment views when resources from different companies appear at the same time. However appointment_resource_id was deprecated in favor of appointment_resource_ids in stable since then. `appointment_resource_ids` should now be used in the domain. [1] ab7addece528d887f062e70732f96fde2ed76dca task-3893256
This update fixes a usability issue in the Documents app where the inspector panel was not scrollable on smaller screens, making it difficult or impossible to use. The fix allows vertical scrolling when needed while preventing unwanted horizontal scrolling, ensuring the inspector remains accessible on all device sizes.
Original PR description
Purpose ======= Prevent the horizontal scrolling of the inspector but allow the vertical scrolling for small screen sizes. Specifications ============== Reverting the addition of the "overflow-hidden" class on the documents inspector as it is preventing its horizontal but also its vertical scrolling. On lower screen sizes, a vertical scrolling is needed or else the inspector becomes pratically unusable. related PR: odoo/enterprise#59652 Task-3884149 Forward-Port-Of: odoo/enterprise#61399 Forward-Port-Of: odoo/enterprise#61220
This fix resolves an issue where recurring subscription invoices were not generating pickings (shipments) when the subscription product used a bill of materials with kit type. The fix ensures that pickings are now correctly created for each subscription invoice, allowing orders with kit-based products to be properly fulfilled on an ongoing basis.
Original PR description
**Version:** - saas-16.3 **Step to reproduce:** - Create a subscription product with the type set to 'product' - Create a BOM for that product with the BOM type set to 'kit' - In the component, add any product with the type 'product' - Create a sale order with the products that are created and generate an invoice - Upon creating the next invoice for the subscription product, the picking was not being generated. **Issue:** Currently, if the product type is set to 'product' and recurring_invoice is true, and the product has a bill of materials (BOM) with the type 'kit' the picking was not created after the first invoice. **Solution:** If the product has a subscription, the quantity for BOM kits will not be updated. task-3681597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#56121
Fixed an issue where Peruvian invoices were always displaying "RUC" as the customer identification type, regardless of the actual identification type selected (such as DNI). The invoice PDF now correctly shows the identification type that was chosen for each customer.
Original PR description
Problem: For a peruvian company, there is many choices of identification type and when creating an invoice, the identification type is always "RUC" whatever the identification type really is Steps to reproduce: - Install the "contacts" and the "accounting" apps - Add a peruvian company from the settings and set the "fiscal localization" as "Peru" for this company - Create a new contact from Peru and set the "Identification Number" as DNI and fill in the number - Create an invoice for this customer and preview the invoice - You will see written on top right "RUC:" instead of "DNI:" Cause: The identification type shown on the invoice is the default one for the country and then is not updated depending on the selection Solution: Replace the field to the selected one for Peru opw-3846814 Forward-Port-Of: odoo/enterprise#61123
This fix resolves a layout issue in the EU OSS tax report where using multiple column groups caused misalignment between data rows and column headers. The report was displaying too many cells per country line, breaking the visual structure. The fix corrects how column groups are processed to ensure proper alignment with headers.
Original PR description
Before, using a column group on the OSS report broke the layout, as each country line displayed more cells than it should, and they hence mismatched the column headers. This was due to bad management of the column groups: when there was more than one column group, the tax_sums variable contained more than one value, and we were then looping on each column for each tax sum to generate the columns of the country line, which was wrong, since options['columns'] already contained the columns of each column group.
This update corrects how the Gantt view handles grouping when using date and datetime fields. Previously, the system would encounter errors when trying to group by date fields with time granularity options (like grouping by year). The fix ensures these field types are properly recognized and processed without errors.
Original PR description
Issue:
------
The commit[^1] filters groupby in the gantt view according to whether it is a propertie or not.
However, fields of type `date` and `datetime` use `:` to refer to the granularity (example `check_in:year`).
To avoid const { type } = metaData.fields[fieldName:granularity]; to trigger an error, it is therefore necessary
to adapt the diff of commit[^1].
opw-3893042
[^1]: https://github.com/odoo/enterprise/commit/6ee5fe8220d692173187402a7361f77883dca921This fix corrects a module installation issue in the Dutch tax reporting system (ICP part). A previous update accidentally referenced the wrong module name, preventing the feature from working properly. This change ensures the correct module is installed so Dutch companies can properly handle their tax reporting requirements.
Original PR description
The commit https://github.com/odoo/enterprise/commit/cf61f05e78e40f03f4d1d4ba2692b8b5426759cc forgot to change the name of the module that needs to be installed to make the feature work correctly for the ICP part. Forward-Port-Of: odoo/enterprise#61470
Fixed an issue where comments entered during Belgian tax closing were not appearing in the generated VAT XML export files. Users can now see their comments properly reflected in the XML output, improving record-keeping and compliance documentation for Belgian tax reporting.
Original PR description
When generating VAT XML by posting a tax closing entry, the `<ns2:Comment>` tag in the ML is empty despite specifying a comment during the closing process. ### Steps to reproduce 1. Install `l10n_be_reports_post_wizard`. 2. Switch to a Belgian company. 3. Open the tax report. 4. Create a tax closing. 5. Post the tax closing, ensuring a comment is defined in the appearing wizard. 6. Review the generated XML file. Expected behavior: The `<ns2:Comment>` tag in the XML should display the comment entered during the tax closing. Actual behavior: The `<ns2:Comment>` tag is found to be empty. opw-3859928 Forward-Port-Of: odoo/enterprise#60917
Odoo has updated its Colombian electronic invoicing system to comply with the new Anexo 1.9 specification. This fix updates the base Colombian localization module with necessary changes to support the new electronic invoice format requirements, ensuring your invoices remain compliant with Colombian tax regulations.
Original PR description
The spec for electronic invoices in Colombia was updated and is now known as Anexo 1.9. This was done in the related enterprise PR (module l10n_co_edi). This commit introduces some changes in the base module that are needed for the Anexo 1.9 update. task-3639271 ### related PRs FW-port of https://github.com/odoo/odoo/pull/148953 (15.0) https://github.com/odoo/odoo/pull/151407 (16.0) https://github.com/odoo/odoo/pull/151418 (saas-16.3)
Fixed a display issue where miscellaneous operations amounts were shown in the wrong currency on the bank journal dashboard. When a bank journal uses a different currency than the company's main currency, the miscellaneous operations amount will no longer be displayed to avoid showing incorrect converted amounts. Users will still see the "Misc. Operations" label so they know there are unlinked journal entries.
Original PR description
Steps: ------ 1. Have accounting installed. 2. Have a bank journal with a currency different from company's currency, use a bank account with no currency set for this bank journal. 3. Make a misc operation in the bank account used by the journal. 4. On the dashboard, the "Misc. Operations" amount will not be converted to the journal's currency, even though the currency's symbol is correct, the amount is in the company's currency. Fix --- Do not show the total amount of misc operations if the bank journal and bank journal's bank account currencies are not matching. The user still knows there are journal entries not linked to a bank transaction thanks to the "misc operations" text, but we avoid doing a currency conversion that may not make sense. **opw-3767010**
Fixed a crash that occurred when processing payments with currency exchange differences if the exchange difference journal wasn't configured. Now users receive a clear error message instructing them to set up the required journal, preventing system failures and improving the payment experience.
Original PR description
The issue: when you make a payment and there is an exchange difference, since the post exchange difference is not set, it will throw a traceback To reproduce: - Enable 2 currencies - Have the exchange difference journal set to NULL (empty) - Create an invoice with a different currency than the one set for the company - then register a payment. The fix: Throw a user error indicating to set the post exchange difference journal opw-3783917 opw-3768202
Odoo has been updated to support Indonesia's new VAT tax ID regulation, which now requires 16 digits instead of 15 by adding a leading zero. The system automatically removes the leading zero to validate tax IDs correctly under the new regulation, ensuring Indonesian businesses can continue using the tax validation feature without manual adjustments.
Original PR description
The issue: Currently, in Indonesia, the regulation for tax ID is 15 digits. But a new regulation is coming where Tax ID is now 16 digits by adding 0 in front The fix: Remove the first zero and leave the rest for the _run_vat_test function Related PR: odoo/odoo#146111 opw-3782636
This update fixes several data consistency issues with how binary and image files are stored and retrieved in the system. The changes ensure that when users upload or modify binary files (like images), the system correctly stores and displays the actual file content rather than incorrect cached versions. This is particularly important for features like web-based file saving and image resizing.
Original PR description
#### [FIX] core: add invalidation of Environment's _cache_key. Changing the environment in method create() to force bin_size=False looks harmless, but it actually breaks many tests, in particular in…
#### [FIX] core: add invalidation of Environment's _cache_key. Changing the environment in method create() to force bin_size=False looks harmless, but it actually breaks many tests, in particular in module account. The reason is that company_dependent fields are read at the wrong place in the cache. And this is because `env._cache_key` can be polluted with old data. Make sure that `_cache_key` is cleared when resetting all the lazy properties on the environment. Only the change in res_user.py makes it work, but let's not tempt the devil. Side note: I hate caches. #### [FIX] test_new_api: test's change that already works Add some test cases, and also remove useless flush/invalidate. #### [FIX] core: fix create/write on binary fields When invoking create() or write() with a binary field, the cache of the field was incorrect if bin_size=True was in context. Force context with bin_size=False when putting a binary value in cache. It is particularly important to have coherent values in the cache for `web_save`. Also, because an environment with bin_size=False won't return the same context cache key as one with bin_size=None, it leads to have a cache inconstistency when we write with bin_size=False. Change Environment method cache_key() to return the same cache key when bin_size is absent, bin_size=None or bin_size=False. Tests on binary fields have been updated to not rely on flush and invalidate. We also created specific tests for the binary write() path. #### [FIX] core: cache inconsistency when assigning related resized image field After writing or creating on a related Image field, its cache contains the full-size image instead of the resized one (according to its attributes max_width and max_height). Fix it by re-setting the the resized image on the cache at the end of the inverse method. #### [FIX] core: flush non-attachment binary field when necessary Non-attachment binary field needs to be flushed before reading their size, since the latter relies on the database's binary size function. #### [FIX] core: fix no-attachment binary for web_save When bin_size=True is in the context, the computed no-attachment binary was incorrectly saved to the database. The row is updated with the size of the binary instead of the value itself (check compute_value() + cache.set). Fix this problem by avoiding setting the cache of the bin_size value as dirty. Moreover, the binary size is computed with `pg_size_pretty` for the no-attachment binary fields. Also, in compute_value() we called b64decode on the value that was previously encoded in base64 by _compute_datas(). But in our case, we never use _compute_datas() because it is not stored as an attachment. Then b64decode() doesn't make sense in this case. These 2 bugs are now covered by testing web_save(), where cache consistency is required. It was first reported for this method. First proposal: https://github.com/odoo/odoo/pull/156673
When requesting time off for multiple employees, the system was incorrectly filtering available time off types based on the current user's allocations instead of the selected employees' allocations. This fix ensures that time off types are properly filtered based on the actual employees selected in the request, preventing unavailable time off types from appearing in the search results.
Original PR description
Currently, when requesting time off for multiple employees, the search for the leave type correspond to the search of the current user. Steps to reproduce: ------------------- * Go to the **Time…
Currently, when requesting time off for multiple employees, the search for the leave type correspond to the search of the current user. Steps to reproduce: ------------------- * Go to the **Time Off** app * Select **Configuration** > **Time Off Type** * Create a new time off type * Approval: By Employee's Approver and Time Off Oficcer * Requires allocation: Yes * Employee Requests: Extra Days Requests Allowed * Approval: Approved by Time Off Officer * Notified Time off officer: Mitchell Admin * Select **Management** > **Allocations** * Create a new allocation * Employees: Mitchell Admin * Time off time: The one created previously * Validate the allocation * Select **Management** > **Time Off** * create a new time off * Employees: Any Employee A & Employee B * Time off type: > Observation: The new time off time is present in the name search while both employees don't have any allocation for it. Why the fix: ------------ The name search searches for time off type with ``` ['|', ['requires_allocation', '=', 'no'], '&', ['has_valid_allocation', '=', True], '&', ['max_leaves', '>', '0'], '|', ['allows_negative', '=', True], '&', ['virtual_remaining_leaves', '>', 0], ['allows_negative', '=', False]] ``` By configuration, the time off has `requires_allocation = yes` therefore it shouldn't appear here and it does not -> ok `has_valid_allocation` has a search method `_search_valid` https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/hr_holidays/models/hr_leave_type.py#L109-L138 `max_leaves` has a search method `_search_max_leaves` https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/hr_holidays/models/hr_leave_type.py#L165-L192 Both use the function `_get_contextual_employee` to make their search. https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/hr_holidays/models/hr_employee.py#L386-L388 When there are more than one employee selected on the hr leave form, the context contains `employee_id: False`. Thus here we are making the search using the current user, which is Mitchell Admin. The search shouldn't be made using the current user in this case since he doesn't correspond to any of the employees we added of the form. opw-3816442
This fix resolves an issue where analytic plan applicability rules were not being applied when the company field was left empty. Now, applicability rules without a specific company assignment will correctly apply to all companies in the system, with a lower priority than company-specific rules. This ensures more flexible and consistent analytic planning across multi-company environments.
Original PR description
If you create an applicability and remove the company field, they are never used. An applicability like this should be valid for all companies. We put a 0.5 value for the company field so an applicability so it has a lesser priority than other fields. Same idea as the distribution models. opw-3847415 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves access control for email templates by allowing users to manage templates they are assigned to. Previously, users could not update, read, or delete templates even when assigned as responsible parties. This change aligns permissions with the new user assignment feature, making template management more intuitive and efficient.
Original PR description
Since the introduction of `user_id` field, it makes sense to allow those users to update/read/delete templates they have been assigned to. task-3748816 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the French Point of Sale certification module by adding detailed logging of hash string data. This makes it easier for support teams to investigate and troubleshoot issues when they occur. Additionally, a fix prevents accidental duplication of POS orders when managed from the backend system.
Original PR description
This commit add the logging of hash string data. By printing the string to hash, it becomes easier to investigate issues. opw-3839287 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where subscription products with kit-type bills of materials (BOMs) were not generating pickings after the first invoice. When a subscription product is invoiced repeatedly, the system now correctly creates the necessary pickings for fulfillment, ensuring smooth order processing for recurring subscriptions.
Original PR description
**Version:** - saas-16.3 **Step to reproduce:** - Create a subscription product with the type set to 'product' - Create a BOM for that product with the BOM type set to 'kit' - In the component, add any product with the type 'product' - Create a sale order with the products that are created and generate an invoice - Upon creating the next invoice for the subscription product, the picking was not being generated. **Issue:** Currently, if the product type is set to 'product' and recurring_invoice is true, and the product has a bill of materials (BOM) with the type 'kit' the picking was not created after the first invoice. **Solution:** If the product has a subscription, the quantity for BOM kits will not be updated. task-3681597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153173
This fix corrects how the spreadsheet accounting function interprets date periods. Previously, when users entered a month/year (like "02/2024") in a cell and used it in a balance formula, the system would only look at the first day of that month instead of the entire month. Now it correctly processes the full month period, ensuring users see the right financial data when drilling down into account records.
Original PR description
Steps to reproduce:
- in A1, type '02/2024'
- in A2, type '=ODOO.BALANCE("100", A1)'
- right click on A2
- click the menu item "See record" => you end up with wrong records in the list view
The value of A1 is detected as a number (first of february 2024) When that number is given as the argument of ODOO.BALANCE, the number falls back as being interpreted as a single day, instead of a month period.
opw-3872445
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix resolves a crash that occurred when users tried to apply the Syscohada accounting template to their company. The Chart of Accounts (COA) is now properly visible in the system settings, preventing errors. Users can only apply the Syscohada template to companies that already have the required COA configured.
Original PR description
The COA should be visible, so existing db won't crash. Indeed, it is used in the Selection field of the config settings. As the field does not exist, the users get an error. We instead don't let a user apply the Syscohada template to a company that does not already have the COA. opw-3893013 opw-3891587 opw-3891028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where products would disappear from a product block after adding and then removing a product tag filter. Previously, the system couldn't distinguish between "no tags selected" and "empty tag list," causing it to apply an incorrect filter. Now the system properly resets to show the default product set when all tags are removed.
Original PR description
Steps to reproduce: ------------------- - create a product tag (eCommerce / Product Tags); - go to a product page and open editor; - edit the page adding a "Products" block; - add the created product…
Steps to reproduce: ------------------- - create a product tag (eCommerce / Product Tags); - go to a product page and open editor; - edit the page adding a "Products" block; - add the created product tag; - remove it and save; Issue: ------ No products are displayed, whereas without tags, a default product set should be displayed. Cause: ------ At first, when we don't have a tag, the domain determined for the search is `[]`, which returns a list of products. When we add the tag, a domain will be built with the products linked to this tag: `['all_product_tag_ids, 'in', []]` (in the case of the use case above, there will be none). The attribute `data-product-tag-ids="[]"` is added to the dynamic snippet section. Then, when we remove it, we will get the same domain: because the string `"[]"` is valid for the condition that checks whether `productTagIds` exists. As a result, it will no longer be possible to obtain the default set for this block. Solution: --------- Try to reduce the domain to a list in all cases and compare its length. If it is empty, the domain must be an empty domain. opw-3859482 Forward-Port-Of: odoo/odoo#161818