Friday, April 26, 2024
49 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
2 changes
Enhancements to existing features
Payroll users can now open an employee contract directly in the main page from a payslip instead of a smaller pop-up window. This makes it easier to review detailed contract information and prevents creating contracts on the fly from payroll screens, reducing accidental or inappropriate records.
Original PR description
This commit adds a new widget to open a many2one field in current mode from a form view instead of a modal view. This is useful when the view to load is too heavy/big and the user wants to quickly check some information. task-3818439
22 changes
New functionality added to Odoo
This update introduces financial reporting capabilities for Rwanda, including balance sheet and profit & loss statements. These new reports are now available for businesses operating in Rwanda to ensure accurate financial compliance and balanced reporting.
Original PR description
This commit adds the financial reports of Rwanda and make sure they are balanced. task: 3627705
Barcode commands and demo barcodes were updated to use shorter, easier-to-read values without special characters. This makes barcode sheets and shop floor workflows easier for staff to understand, remember, and scan consistently.
Original PR description
*: stock_barcode{_mrp,_picking_batch}, mrp_workorder
Revamp the barcodes of commands and demo data to be shorter and with no special characters. So that they are more readable and easier to remember.
COM PR: odoo/odoo#158827
Task-3774096Odoo now includes a complete localization package for Rwanda, enabling businesses operating in Rwanda to use the system with local compliance. This package includes the chart of accounts, tax configurations, tax reporting, fiscal positions, and default settings tailored to Rwandan accounting standards.
Original PR description
Add the basic package to the Rwanda localisation. -COA -Taxes -Default settings -Tax report -Fiscal position task-3584127 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
The UNSPSC (United Nations Standard Products and Services Code) list has been updated to include previously missing product codes. This ensures that the product classification system is more complete and accurate, allowing better product categorization and compliance with international standards.
Original PR description
Some codes in UNSPSC list were reported as missing, updated missing codes and added them to our list. Task Id: 3871714
The BACS payment module will now automatically install and activate for UK-based databases. This ensures that UK companies have the necessary payment processing capabilities enabled by default, eliminating the need for manual setup and reducing configuration time.
Original PR description
[IMP] account_bacs: auto install bacs for uk db auto install bacs for uk db by depending on l10n_uk module and auto_install it when it's in-place for uk Reason: It should be in-place for uk databases Task-3880681
This update improves the German accounting export functionality by adding document metadata file support for DateV integration. The enhancement enables better correspondence tracking between accounting entries and their attachments through new file and identifier mechanisms, improving compliance with German accounting standards and DateV platform requirements.
Original PR description
To make correspondences between accounting entries and attachments, we need a new file and guid for the entries. Documentation can be found at https://developer.datev.de/datev/platform/en/node/6344 task-3888995 Forward-Port-Of: odoo/enterprise#61481 Forward-Port-Of: odoo/enterprise#61378
This update improves how taxes are calculated and displayed on Mexican electronic invoices (EDI documents). The system now properly includes tax information in the base line items, ensuring more accurate and compliant tax reporting for Mexican businesses using Odoo.
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