Friday, November 22, 2024
33 changes · 17.0
Enhancements to existing features
This update provides Romania with the option to generate a 4 or 5-column trial balance report, aligning with their local accounting standards. The underlying trial balance implementation has been improved for easier customization and future updates. This ensures accurate reporting for Romanian businesses using Odoo Enterprise.
Original PR description
Romania does not use the 3-column trial balance report, instead they use a 4-column and 5-column variant. This commit adds the 4/5-column report as variants to the standard trial balance. The standard trial balance implementation has been changed to be easier to override and add column groups. task: 3810685
This update adds a new XML export button to the German Intrastat report. This allows businesses to easily generate the required XML files for submitting their Intrastat reports to German authorities, streamlining the reporting process and ensuring compliance. The change is part of ongoing improvements to our German localization features.
Original PR description
This commit add the export to xml button on the intrastat report for Germany. More information can be found here: - https://erhebungsportal.estatistik.de/Erhebungsportal/informationen/hilfe-zur-meldungsabgabe-3749 task-4194404 Forward-Port-Of: odoo/enterprise#71785
This update introduces a new system parameter in the accounting settings, allowing users to specify a custom VAT number instead of the default accounting firm's VAT for CodaBox connections. This flexibility addresses situations where accounting firms require a different VAT to be used as their contract number, improving the connection's accuracy and usability.
Original PR description
Currently, the accounting firm's VAT is used for the CodaBox connection but sometimes, accounting firms need to use a different VAT as their contract number. This adds a system parameter that if filled, is used instead of the firm's VAT. task-4335294
This update ensures that the names of invoice reports generated by the l10n_mx_edi module now align with the corresponding XML invoice data. This improves data consistency and simplifies reporting processes for Mexican businesses using Odoo Enterprise. It addresses a user request for a more straightforward reporting experience.
Original PR description
Users require the name of the invoice report to be the same as the xml. task-4284482
Resolved issues and error corrections
The website editor now keeps the toolbar hidden at the right moment when opening edit mode in mobile preview. This prevents a brief toolbar flash, making the editing experience smoother and less distracting for website users.
Original PR description
Steps to reproduce: - Go to a Website page. - Enable the "Mobile" preview. - Click on the "Edit" button to enter in edit mode. - Bug: When entering edit mode, the toolbar briefly appears and then disappears on the page. To fix this, we move the line that adds a "d-none" class to this toolbar earlier in the "start" of "snippetMenu". opw-4321865 opw-4232082
Miscellaneous changes
Bank statement lines created from the form view won't have an `internal_index` value set yet. Running balance computation should set a value also on manually deleted lines from the form view as the balance is a computed non-stored field. @Tecnativa TT50906 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182497
Original PR description
Bank statement lines created from the form view won't have an `internal_index` value set yet. Running balance computation should set a value also on manually deleted lines from the form view as the balance is a computed non-stored field. @Tecnativa TT50906 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182497
Delivery slip reports now wrap extra information into cleaner rows instead of squeezing many fields onto one line. This makes printed and PDF delivery documents easier to read, especially in languages with longer words such as German.
Original PR description
Before this PR, If the deliveryslip report had many fields, say more than 5, they will be all placed on the same line, and it will be very hard to read them since they will be squashed. This is problem is more relevant when the language used for the report is a language where the words are usually long, like the german language. Now, we force at most 4 fields per line, which makes the report layout cleaner in most cases. Before <img width="613" alt="image" src="https://github.com/user-attachments/assets/49d88491-96d1-4ce3-9e06-73be713956cf"> After <img width="615" alt="image" src="https://github.com/user-attachments/assets/d20337d6-dcc1-46f0-8386-18f67091538c"> opw-4227666 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where dragging a property field into an empty or unnamed group could crash the page. Users can now reorganize CRM properties more reliably, especially when working with grouped layouts.
Original PR description
Steps to reproduce ================== - Install crm - Add a single property - Drag and drop it to the second group => TypeError: Cannot read properties of undefined (reading 'elements') Cause of the…
Steps to reproduce ================== - Install crm - Add a single property - Drag and drop it to the second group => TypeError: Cannot read properties of undefined (reading 'elements') Cause of the issue ================== A properties field is composed of a list of property stored in a JSON object. A property can either be a separator, or any other type, char, bool, ... The properties field has a columns props. If we either have no separator, or we have only one and it is at the first position, we enter the split mode. This means that properties are displayed across the available columns. If we move a property in a group, it means we wan't that property to stay in that group. When we're in split mode, we need to add the least amount of new separators so that we get the expected layout. In some cases, it wasn't possible to get the actual group where we dropped a property. This can happen for example when the target was inside an empty group with a default invisible separator (it has no name). In some cases also, the behavior wasn't simply what was expected. opw-3961445
The update ensures a required purchasing component is available before a point of sale sales test runs. This helps prevent false test failures and keeps validation of sales workflows more reliable without changing user-facing behavior.
Original PR description
This commit makes sure that the purchase module is installed before running the test. opw-4092298
The GST state validation warning in the Indian localization now avoids repeating words. This makes the message clearer for users and reduces confusion during company or partner setup.
Original PR description
Before this commit: duplicate words appeared in the GST state validation warning. After this commit: the duplicate words have been removed from the GST state validation warning.
Company forms no longer show repeated labels for tax and registry fields when both Australian and New Zealand localizations are installed. This reduces confusion for users managing company details across these localizations.
Original PR description
Problem: When both l10n_au and l10_nz are installed, the company form displays multiple labels for affected fields, vat and company_registry. Solution: The company form should only display a label per field to avoid confusions. Each view per localization will make the affected field on the parent view invisible and then add in the same affected fields but with a different label. Steps to Reproduce on Runbot: 1. Install l10_au and l10_nz 2. Observe the forms for all companies 3. See that there's duplicate labels for fields, vat and company_registry opw-4250742 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The UK accounting setup now uses the correct default accounts for deferred expenses and deferred revenue. This helps businesses classify prepayments and accruals in the right balance sheet categories from the start.
Original PR description
* Deferred expense: 110300 Prepayments (current assets) * Deferred revenue: 210900 Accruals (current liabilities) task-4338265 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents Accounting screens from crashing when a normally hidden field is made visible through Studio. The field now uses a format better suited to its data, improving stability without changing day-to-day accounting workflows.
Original PR description
Currently, if the `quick_encoding_vals` field becomes visible in a view (e.g., by toggling "Show invisible elements" in Studio), the system crashes. This happens because the field is currently a Binary field that cannot be represented as a string. ### Fix The `quick_encoding_vals` field is an **unstored computed** field that outputs a dictionary. To resolve the issue, we can safely convert it into a JSON field. Note: Fix confirmed by WAN on the ticket. opw-4241572
This update removes unused display logic from the Peru website sales address form. It reduces unnecessary code and helps keep the checkout page behavior easier to maintain without changing the customer-facing process.
Original PR description
The `t-attf-style` was useless since the view reactivity is handled from the JS side with `_on_changes`. Moreover `d-none` is a css class and not a css style. Should've been `display: None` in the fist place.
This update resolves a confusion reported by some clients regarding shift copying after using the 'copy previous week' feature. Previously, if a project linked to a shift had zero allocated hours, the shift wouldn't copy. Now, the system allows the shift to be copied even with zero allocated hours to eliminate this confusion.
Original PR description
Some clients were confused about not knowing why their shifts were not copied after setting a project to them (using the copy previous week feature). The reason was that the project linked to their shifts had allocated hours equal to 0. After this commit, if 0 hours are allocated to the project, we allow to copy the shift anyway to avoid confusion (as some clients are clearly not using this field). task-4074736 version-17.0
This update addresses small technical issues within the FedEx delivery integration module. Specifically, it improves security by replacing a potentially unsafe coding practice and enhances translation support by adding a base translation file. These changes ensure smoother and more reliable operation of the FedEx delivery process.
Original PR description
- Add .pot base translation file. - Replace potentially unsafe `const_eval()` with a `json.loads()`. - Use the built-in methods for setting filename for received files.
This update resolves an issue where the Gantt chart was displaying outdated attendance records due to a miscalculation of date ranges. The fix ensures that records with missing end dates are excluded from the chart's view, preventing inaccurate data and improving chart performance. This update addresses a technical error that could impact the accuracy of attendance reporting.
Original PR description
Steps to reproduce ================== - Install hr_attendance_gantt,web_studio - Go to Attendences - Open studio - Enable "Display total row" in the sidebar - Exit studio - Create a new entry with no end date - Switch to the week view - Go to the previous week => `Cannot read properties of undefined (reading 'pills')` Cause of the issue ================== When records don't have a dateStop value, it is set as now(). The domain included record that start before now and have no stop (so converted to now). If the current window is between the 01 and 07 Nov, and today is 14 Nov, a record starting the 09 Nov that has no end date will be included. When finding the closest date, it will be out of bound (day 8 when we only have 7). Solution ======== Those records shouldn't be included at all as the are outside the current viewable range. opw-4160977
A recent update to the Swiss payroll localization module introduced a change that impacted a key test. This fix adjusts a test to accurately reflect the new module and its functionality, ensuring continued reliability of the Swiss payroll calculations. The change is a minor technical adjustment to improve test coverage.
Original PR description
[link to broken tests](https://runbot.odoo.com/web#id=68972&menu_id=424&cids=1&action=573&model=runbot.build.error&view_type=form) since [this pr](https://github.com/odoo/enterprise/pull/62136), a lot of things changed in swiss payroll localization. One of the changes was introduction of new module, l10n_ch_hr_payroll_elm. This affected one of the assertQueryCount tests checking compute_sheet function, which is also overwriten in said module. Therefore, we need to increase the query count accordingly. Flamegraph of function _get_base_local_dict before above mentioned pr:  Flamegraph of same function after the pr: 
This update resolves an issue where commission calculations were failing when some invoices had incomplete start and end dates for subscriptions. The fix ensures that the system only considers valid dates for maximum and minimum calculations, preventing errors and ensuring accurate commission generation.
Original PR description
Following 81dce8461c7, when only some of the invoice lines have subscription start/end date, the commission generation crash when computing the maximum end date or minimal start start: ``` TypeError: '>' not supported between instances of 'bool' and 'datetime.date' ``` This commit ensure we only try to max/min non-falsy values. Forward-Port-Of: odoo/enterprise#74112
This update fixes an issue where Spanish translations for the l10n_co_reports module were accidentally deleted during a cleanup process. The translations have been restored, synced, and corrected, including a previously inaccurate sentence. This ensures accurate reporting in Spanish.
Original PR description
During the es_XX.po cleaning, the po file for l10n_co_reports was incorrectly not converted to es_419.po and only deleted. We now restore it + correctly rename it to es_419.po As part of this cleaning, the pot file has been re-exported and the po re-synced with it. Missing translations were also added it. A sentence that was obviously incorrect in the original Spanish was also translated to a correct sentence. opw-4336377 PR that deleted the original es_CO.po file: https://github.com/odoo/enterprise/pull/66317
This update resolves a technical issue within Odoo's Studio interface that prevented users from correctly configuring Sales Team settings. Specifically, the Studio was unable to recognize a key filter used in the Sales Team's configuration, leading to an error. This fix ensures Sales Team settings can be accurately adjusted through the Studio.
Original PR description
Steps to reproduce ================== - Install crm,web_studio - Enable leads - Go to CRM > Configuration > Sales Team - Open the first record - Uncheck Pipeline and Leads - Go to CRM > Sales > Teams - Open studio => Undefined graph model for Sales Team: Pre-Sales Cause of the issue ================== The window action uses the following domain `[["use_opportunities", "=", true]]` It is not used from within studio. opw-4285413
This update addresses a visual glitch in the timesheet grid view where columns would flicker during scrolling. The fix adjusts the first column's width to a fixed percentage, ensuring a smoother and more stable display of data. This improves the user experience when viewing large amounts of timesheet information.
Original PR description
Steps to reproduce: ------------------------------ - Install the timesheet module. - Open the module - Open all timesheets in grid view - Scroll the page - There is a flicker when scrolling Issue: -------------- When scrolling in grid view, there is a flicker in columns. Cause: ----------- The grid-template-columns property the first column is set to auto, meaning its width is determined by its content. However, as the content dynamically changes, such as during scrolling, the column width adjusts causing flickering.This occurs because the content size affects the column width. Solution : ----------------- The grid-template-columns property sets the width of the first column in the grid layout to 30% of the screen task-3743360
### Steps to reproduce: - Install "l10n_sa" and the Arabic language - Create a product and translate its name to Arabic - Create an invoice and print it - In the invoice lines under the description column only one translation displays and not both as it should. ### Cause: The code was changed to only display the current language in this [commit](https://github.com/odoo/odoo/commit/67b041521d05cbcf5adaf04998278c10fa046790). The goal of this commit was to prevent the duplication of the pro
Original PR description
### Steps to reproduce: - Install "l10n_sa" and the Arabic language - Create a product and translate its name to Arabic - Create an invoice and print it - In the invoice lines under the description…
### Steps to reproduce: - Install "l10n_sa" and the Arabic language - Create a product and translate its name to Arabic - Create an invoice and print it - In the invoice lines under the description column only one translation displays and not both as it should. ### Cause: The code was changed to only display the current language in this [commit](https://github.com/odoo/odoo/commit/67b041521d05cbcf5adaf04998278c10fa046790). The goal of this commit was to prevent the duplication of the product name because it is already contained in line.name. ### Solution: The way line.name is computed is by taking the sales description (or purchase one) and concatenating it with the product name. It can also be changed manually in the invoice form view under "label". So to display the product name in both languages and this label without any duplicate this commit adds conditions: - the label is always displayed - the Arabic name is displayed if the label does not contains it - the English name is displayed if the label does not contains it and if it is different from the Arabic one (ie if it is translated) opw-4187577 Forward-Port-Of: odoo/odoo#186449
When trying to add a DNI number from the user portal, the following error appears: The CUIT number [] does not seem to be valid. Note: the expected format is AR200-5536168-2 or 20055361682 How to reproduce the issue: - Install the Argentinian localization - Create a contact with an email, Identification Number on DNI - Grant them portal access - In users, change the password of the new contact - Log in to the user portal with the new contact credentials - In edit details, enter a DNI nu
Original PR description
When trying to add a DNI number from the user portal, the following error appears: The CUIT number [] does not seem to be valid. Note: the expected format is AR200-5536168-2 or 20055361682 How to reproduce the issue: - Install the Argentinian localization - Create a contact with an email, Identification Number on DNI - Grant them portal access - In users, change the password of the new contact - Log in to the user portal with the new contact credentials - In edit details, enter a DNI number and confirm The solution is a backport of this commit: https://github.com/odoo/odoo/commit/caf6bbc0ed875f9fff0440331acb10506d87605e#diff-abaa067ec8ef765ce398468a0dd52d47ea3585a90fa61e5276daa1e603b3b232R67 opw-4267173 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 Forward-Port-Of: odoo/odoo#185948
Issue: When printing the PDF of a Purchase Order, if the company has multiple address, those appear on the same line. Steps to reproduce: - Create a Mexican Company with 2 address lines - Create a Purchase Order - Print the PDF of the Purchase Order Cause: The separator between the 2 address lines in the address format is set as a blank space. Solution: Replace the blank space separator with a new line. Ticket: 4221771 --- I confirm I have signed the CLA and read
Original PR description
Issue: When printing the PDF of a Purchase Order, if the company has multiple address, those appear on the same line. Steps to reproduce: - Create a Mexican Company with 2 address lines - Create a Purchase Order - Print the PDF of the Purchase Order Cause: The separator between the 2 address lines in the address format is set as a blank space. Solution: Replace the blank space separator with a new line. Ticket: 4221771 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186926
Versions -------- - 16.0+ Steps (16.0+) ------------- 1. Create a no-variant attribute with multiple values; 2. Create a product and assign it those attributes; 3. Add an extra product media from the sales tab; 4. Go to the website and add an extra image through the web editor; 5. Go back and check the extra product media field. The only image displayed is the one you uploaded in step 3. Issue ----- Both images should be shown as this product only has no-variant attributes so th
Original PR description
Versions -------- - 16.0+ Steps (16.0+) ------------- 1. Create a no-variant attribute with multiple values; 2. Create a product and assign it those attributes; 3. Add an extra product media from the sales tab; 4. Go to the website and add an extra image through the web editor; 5. Go back and check the extra product media field. The only image displayed is the one you uploaded in step 3. Issue ----- Both images should be shown as this product only has no-variant attributes so they don't create product variants. Cause ----- In Step 4, the uploaded image is saved to the product variant based on the evaluation of the `has_configurable_attributes` field on the product template and the presence of the variant. Solution -------- Check if the attributes are all `no_variant`. In that case, no product variant is created, so the images should be saved on the product template. opw-4174331 Forward-Port-Of: odoo/odoo#187544
The previous code lead to cache-miss Courtesy of Dawn Hwang Forward-Port-Of: odoo/odoo#187772
Original PR description
The previous code lead to cache-miss Courtesy of Dawn Hwang Forward-Port-Of: odoo/odoo#187772
This fix is a continuation of this [commit]. Issue: ====== Inserting new image and image replacements don't get saved when switching tabs. Steps to reproduce the issue: ============================= - Create a mass mailing - choose welcome message template - add subject, mailing list and save - Add image using /image and switch directly to another tab like `a/b testing` - Go back to mail body => changes aren't saved. - Same if you replace an existing image with another one Ori
Original PR description
This fix is a continuation of this [commit]. Issue: ====== Inserting new image and image replacements don't get saved when switching tabs. Steps to reproduce the issue: =============================…
This fix is a continuation of this [commit]. Issue: ====== Inserting new image and image replacements don't get saved when switching tabs. Steps to reproduce the issue: ============================= - Create a mass mailing - choose welcome message template - add subject, mailing list and save - Add image using /image and switch directly to another tab like `a/b testing` - Go back to mail body => changes aren't saved. - Same if you replace an existing image with another one Origin of the issue: ==================== - For Newly inserted images we need to refocus in the editor like we did in the old commit. - Now for both of them after the refocus fix we still have an issue because the `saveModifiedImagesPromise` will take so much time so that after it gets resolved the component is already destroyed and we will not save the changes. Solution: ========= We force the commitChanges coming from mass_mailing as urgent so it will save the value before resolving any promise to make sure we don't loose the content. opw-3947516 [commit]: https://github.com/odoo/odoo/commit/146b0b9ff4b4c2cbabd5d71f869f31f4bbb649d2 Forward-Port-Of: odoo/odoo#182615
Since [1], the _is_indexable_url() method was introduced to determine whether a website should be indexed. However, if a domain name contains uppercase letters, the method incorrectly returns a falsy value. This happens because browsers automatically convert URLs to lowercase, causing a mismatch. Steps to reproduce the issue: - Navigate to Website > Configuration > Website. - Set a domain name with uppercase letters (e.g., http://TEST.localhost:8069). - Go to settings and modify the robo
Original PR description
Since [1], the _is_indexable_url() method was introduced to determine whether a website should be indexed. However, if a domain name contains uppercase letters, the method incorrectly returns a falsy value. This happens because browsers automatically convert URLs to lowercase, causing a mismatch. Steps to reproduce the issue: - Navigate to Website > Configuration > Website. - Set a domain name with uppercase letters (e.g., http://TEST.localhost:8069). - Go to settings and modify the robots.txt file. - Visit http://TEST.localhost:8069/robots.txt and notice that the changes are not reflected. This commit resolves the issue by handling uppercase letters in domain names correctly. [1]: https://github.com/odoo/odoo/commit/49c226a243864a935b7f8e13c79247a1d9405afa opw-4306840 Forward-Port-Of: odoo/odoo#187690
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188077
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188077
When a SO is partially invoiced, and we change the 'Invoicing Switch Threshold' such that the partial invoices are before the new threshold, the SO will not take invoices into account for computation of amount to invoice / invoiced. Steps to reproduce (needs account_accountant installed): - Create a SO with a line having prod invoiced on delivery and qty 3 - Set delivered quantity to 1 - Click Create Invoice > create the draft invoice, set a date (date1) in the past - set a date2 Settin
Original PR description
When a SO is partially invoiced, and we change the 'Invoicing Switch Threshold' such that the partial invoices are before the new threshold, the SO will not take invoices into account for computation of amount to invoice / invoiced. Steps to reproduce (needs account_accountant installed): - Create a SO with a line having prod invoiced on delivery and qty 3 - Set delivered quantity to 1 - Click Create Invoice > create the draft invoice, set a date (date1) in the past - set a date2 Settings > Accounting > Invoicing Switch Threshold later than date1 - Back to the SO, set delivered quantity to 2 - Click Create Invoice > create a new invoice and confirm it Issue: Sale order amount invoiced will take into account only the latest invoice, while it should account also for the legacy invoices opw-4295531 Forward-Port-Of: odoo/odoo#187211
Steps to reproduce: 1. Go to Accounting > Invoices and print any invoice. 2. Go to Settings > Configure your document layout. 3. Set the layout to "Boxed" (default is "Light"). 4. Add a Company Tagline (any value), save, then delete it completely. 5. Go back to Accounting > Invoices and print any invoice. You can notice that the grey line and the text on the top right corner is more down compare to the first printed report. When the Company Tagline `report_header` is cleared, it lea
Original PR description
Steps to reproduce: 1. Go to Accounting > Invoices and print any invoice. 2. Go to Settings > Configure your document layout. 3. Set the layout to "Boxed" (default is "Light"). 4. Add a Company…
Steps to reproduce: 1. Go to Accounting > Invoices and print any invoice. 2. Go to Settings > Configure your document layout. 3. Set the layout to "Boxed" (default is "Light"). 4. Add a Company Tagline (any value), save, then delete it completely. 5. Go back to Accounting > Invoices and print any invoice. You can notice that the grey line and the text on the top right corner is more down compare to the first printed report. When the Company Tagline `report_header` is cleared, it leaves an extra newline in the report because the HTML editor sets it to `<p><br></p>` instead of `false`. This causes the printed invoice layout to shift. As a solution I added a method that checks if `report_header` is empty or not and then display it only when it’s not empty (`<p><br></p>`). Alternative solutions considered: 1. Clean the `report_header` field before saving it to the database OR use an on-change function to remove empty values. 2. Implement a custom widget or JS hook for better control. The chosen solution is the simplest, requiring minimal code changes to address the issue effectively. opw-4247281 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186023
Issue ===== When a GS1 barcode is scanned, if it starts with a FNC1, it can't be parsed. How to reproduce ================ - In Inventory Settings, select "Default GS1 Nomenclature" as the used nomenclature; - Create a product with a valid EAN13 as barcode (eg. 1234567891231); - Open the Barcode app, then the Inventory Adjustments; - Scan a GS1 barcode for the created product who start with the FNC1 (eg. "\x1D0101234567891231") -> The product's barcode is not decoded. Solution
Original PR description
Issue ===== When a GS1 barcode is scanned, if it starts with a FNC1, it can't be parsed. How to reproduce ================ - In Inventory Settings, select "Default GS1 Nomenclature" as the used nomenclature; - Create a product with a valid EAN13 as barcode (eg. 1234567891231); - Open the Barcode app, then the Inventory Adjustments; - Scan a GS1 barcode for the created product who start with the FNC1 (eg. "\x1D0101234567891231") -> The product's barcode is not decoded. Solution ======== To fix this issue, before to be parsed, the given barcode will be cleaned and if it starts with a FNC1, it will be removed from the string. opw-4118637 Forward-Port-Of: odoo/odoo#187875