Wednesday, July 10, 2024
51 changes
Enhancements to existing features
The WhatsApp module’s security test was updated after an old signup/reset password token field was removed from the database. This keeps automated checks aligned with the current system behavior without changing customer-facing functionality.
Original PR description
Change a test that used the token to prove an operation was not done as an admin. Replaced with the only field that still exist in this context
This update renames an internal search permission parameter to make its purpose clearer for developers maintaining Odoo. It affects manufacturing lifecycle, quality, and barcode inventory areas, with no expected change to day-to-day user workflows.
This update modernizes internal data access used across accounting, reporting, payments, knowledge, and quality features after a core platform change. It should preserve existing business workflows while improving maintainability and reducing reliance on outdated internal code.
Original PR description
odoo/odoo#172378
The subscription demo data has been updated to provide clearer and more useful sample scenarios, including related stock examples and test data. This helps teams better understand and validate subscription workflows using more realistic starting data.
The Belgian payroll accounting test module’s kanban views were updated to use newer, cleaner interface building blocks. This makes the test screens easier to maintain and keeps them aligned with current Odoo standards, with minimal direct business impact.
Original PR description
In this commit we have simplified the kanban arch for the test_l10n_be_hr_payroll_account module. The goal is to simplify them, make them easier to read and use bootstrap utility classnames. - Previously, we used kanban-box, but now we are using kanban-card instead. - Deprecated oe_kanban_global_click and oe_kanban_global_click_edit. - More use of <field/> tags - Removed the oe_kanban_colorpicker class and replaced it with the kanban_color_picker widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - kanban_image from rendering context, is deprecated so we use <field name=... widget=image/> instead - kanban_color, kanban_getcolor and kanban_getcolorname are deprecated use new attribute highlight_color=color_field_name on root node - oe_kanban_colorpicker is deprecated, use kanban_color_picker widget instead Task-3992107
Account reports now use a cleaner way to identify and categorize report lines, such as grouped rows, totals, and load-more sections. This reduces fragile internal handling and helps keep financial report behavior consistent as reports become more complex.
Original PR description
Improves slightly the markup of account report lines ids such that it can contain a dictionary, therefore enabling a key-value pair. Previously, it was made using strings, which was quite a hacky way of doing. This markup is used for example either to group lines, indicate a line is a total line, or for 'load more' lines. We standardize this by putting json into the markups in case of dictionary. task-3791247
This update removes obsolete internal code from Belgian and Swedish point-of-sale localization features. It helps keep the system easier to maintain while preserving existing fiscal compliance behavior for affected localizations.
Original PR description
remove dead code and modify some from the previous implementations in BE, SE and IN. Related: https://github.com/odoo/odoo/pull/167012
The payroll and contract salary kanban card layouts were simplified to use newer standard interface components. This makes the views easier to maintain and helps keep the employee contract and payroll screens consistent with current Odoo interface practices.
Original PR description
In this commit we have simplified the kanban arch for the hr_payroll module. The goal is to simplify them, make them easier to read, and use bootstrap utility classnames. - Previously, we used `kanban-box`, but now we are using `kanban-card` instead. - Deprecated `oe_kanban_global_click` and `oe_kanban_global_click_edit`. - More use of `<field/>` tags - Removed the `oe_kanban_colorpicker` class and replaced it with the `kanban_color_picker` widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - `kanban_image` from rendering context, is deprecated so we use `<field name=... widget=image/>` instead Task-3992107
The Data Cleaning manual merge view has been renamed from the less clear “merge action manager” label. It is now available without enabling debug mode, making it easier for regular users to access data merge tools.
Original PR description
With this commit, manual merge view's name will replace "merge action manager" and will be accesible without debug mode. task-3861100
Resolved issues and error corrections
The Bangladesh payroll configuration now uses the correct name for a yearly minimum tax parameter instead of incorrectly calling it a maximum tax. This helps keep payroll tax rules clear and reduces the chance of confusion when maintaining salary calculations.
Original PR description
The rule parameter l10n_bd_yearly_maximum_tax should really be called l10n_bd_yearly_minimum_tax.
Code cleanup and technical improvements
Event communications for Social and WhatsApp now identify templates directly rather than relying on stored notification categories. This keeps scheduling behavior consistent while reducing unnecessary stored data and supports clearer template indicators in the interface.
Original PR description
Adapt enterprise code to the removal of stored notification types and the addition of a custom reference field task-3256524
Miscellaneous changes
Steps to reproduce: ------------------- - Install 'Documents' and 'Accounting' modules - Go to document settings > Activate Accounting + go to "Journal" smart link then create a synchronized with Vendor Bills journal - Go to accounting setting > Activate "Document Digitization" and select "Digitize automatically" for bills - Send a PDF to the Vendor bill mail alias - Open the created bill Issue: ------ Error in the chatter. Cause: ------ We try to set on the document an att
Original PR description
Steps to reproduce: ------------------- - Install 'Documents' and 'Accounting' modules - Go to document settings > Activate Accounting + go to "Journal" smart link then create a synchronized with Vendor Bills journal - Go to accounting setting > Activate "Document Digitization" and select "Digitize automatically" for bills - Send a PDF to the Vendor bill mail alias - Open the created bill Issue: ------ Error in the chatter. Cause: ------ We try to set on the document an attachment already linked to it, and because it goes through the versioning code, it will first link the new attachment to the record (who was already the case), and then link the old attachment (who is the same attachment as the new) to the document. Solution: --------- If trying to set the same attachment already linked to the document, we skip the versioning code. opw-4034699 Forward-Port-Of: odoo/enterprise#66361
Knowledge article filtering now correctly includes items whose internal permission is either set to 'none' or left blank. This helps ensure users see the expected articles and avoids missing content due to inconsistent permission handling.
Original PR description
The operator "=?" does not handle null values correctly and will be fixed in the future. However, the intention of the filtered domain is to return articles that have their permission set to 'none' or not set.
This update corrects how several business apps use shared Odoo utilities, preventing breakages caused by outdated internal import paths. There is no intended change to day-to-day workflows, but it improves reliability across accounting, payroll, localization, manufacturing, subscriptions, social, and worksheet features.
This update corrects a spreadsheet edition test so it matches the expected behavior for comment threads. It reduces false test failures, helping keep development and release checks more reliable without changing user-facing functionality.
Original PR description
The test `Selecting the cell with a unsolved thread does not open the thread popover` was sometimes failing. After investigation, it seems like the test is plain wrong. The thread popover should open for unsolded threads, it's for resolved threads that it should not open. Running the test in debug make it clear that the threads popoved is opened. I'm not sure how the test was somehow passing before. Task: [4042515](https://www.odoo.com/web#id=4042515&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Steps to reproduce ================== - Install website_studio - Open any app - Open studio - Click on the website tab - Create a new listing type and confirm - Click on the three dots - View in website => TypeError: Cannot read properties of undefined (reading 'action') Cause of the issue ================== Before https://github.com/odoo/enterprise/pull/49809/commits/7980155915f25128e7cb8d5a0af91ffe45bb44c7 ```xml <t t-set="onItemClicked" t-value="page.page_type === 'lis
Original PR description
Steps to reproduce ================== - Install website_studio - Open any app - Open studio - Click on the website tab - Create a new listing type and confirm - Click on the three dots - View in…
Steps to reproduce ================== - Install website_studio - Open any app - Open studio - Click on the website tab - Create a new listing type and confirm - Click on the three dots - View in website => TypeError: Cannot read properties of undefined (reading 'action') Cause of the issue ================== Before https://github.com/odoo/enterprise/pull/49809/commits/7980155915f25128e7cb8d5a0af91ffe45bb44c7 ```xml <t t-set="onItemClicked" t-value="page.page_type === 'listing' ? this.openPageUrl.bind(this, page) : this.onConfigurePage.bind(this, page)" /> <t t-set="openPageUrl" t-value="page.page_type === 'listing' ? onItemClicked : null" /> <DropdownItem t-if="openPageUrl" onSelected="openPageUrl" href="'#'">View in website</DropdownItem> ``` in the new version, `t-if="openPageUrl"` was always true because `openPageUrl` refers to the function and not the template variable. The function was also not bound to `this`. Solution ======== - The "View in Website" button should only be displayed for pages of listing type. - We add the this to the function call opw-3987521 Forward-Port-Of: odoo/enterprise#65988 Forward-Port-Of: odoo/enterprise#64691
PR does 2 things: - First round of .po file cleaning for es_xx.po files. Since v17 started using es_419 instead of the es_xx.po files, these languages are no longer accessible on Transifex for the translators to change. These files were mostly out of date/incorrect anyways though, so we delete them. The one exception to this is the es_CL.po because Chile has some specific words that differ from the rest of LATAM. This cleanup will occur in a followup PR to give translators time to double chec
Original PR description
PR does 2 things: - First round of .po file cleaning for es_xx.po files. Since v17 started using es_419 instead of the es_xx.po files, these languages are no longer accessible on Transifex for the…
PR does 2 things: - First round of .po file cleaning for es_xx.po files. Since v17 started using es_419 instead of the es_xx.po files, these languages are no longer accessible on Transifex for the translators to change. These files were mostly out of date/incorrect anyways though, so we delete them. The one exception to this is the es_CL.po because Chile has some specific words that differ from the rest of LATAM. This cleanup will occur in a followup PR to give translators time to double check if any of the translations in from these es_CL files should remain. - Cleanup the en_AU/en_GB.po files. There were some non-sense "translations" in them and most of them didn't add much value. Some en_AU files had specific legitimate "translations" were left (e.g. tax "GST", check = cheque), so they were only modified to remove any erroneous translations task: 3593077 COM PR: https://github.com/odoo/odoo/pull/172429 Forward-Port-Of: odoo/enterprise#66179 Forward-Port-Of: odoo/enterprise#65875
Added XML export options of the czech tax report. Most of the work in here was copied from the previous xml export implemented in this commit: https://github.com/odoo-dev/enterprise/commit/32c9a215a74123a2bf7f984421c729c89318e300 task-3127683 Forward-Port-Of: odoo/enterprise#66384 Forward-Port-Of: odoo/enterprise#61200
Original PR description
Added XML export options of the czech tax report. Most of the work in here was copied from the previous xml export implemented in this commit: https://github.com/odoo-dev/enterprise/commit/32c9a215a74123a2bf7f984421c729c89318e300 task-3127683 Forward-Port-Of: odoo/enterprise#66384 Forward-Port-Of: odoo/enterprise#61200
This commit addresses an issue where searching for a product by name in the database led to the recreation of product records. The problem arose during the addition of products to indexedRecords, resulting in duplicates. Community PR: https://github.com/odoo/odoo/pull/171264 opw-4004765 Forward-Port-Of: odoo/enterprise#66269 Forward-Port-Of: odoo/enterprise#65952
Original PR description
This commit addresses an issue where searching for a product by name in the database led to the recreation of product records. The problem arose during the addition of products to indexedRecords, resulting in duplicates. Community PR: https://github.com/odoo/odoo/pull/171264 opw-4004765 Forward-Port-Of: odoo/enterprise#66269 Forward-Port-Of: odoo/enterprise#65952
Forward-Port-Of: odoo/enterprise#66315
Original PR description
Forward-Port-Of: odoo/enterprise#66315
Before this commit: If an IoT is set on a company (other than the default one), when printing a report set to an IoT device. It would always show the "error to print" pop-up. This happened as the notification that the printing operation was successful was always send to the channel of the first company. After this commit: We force to use the company set on the device of the identifier (which is the iot box company). This heuristic is not perfect as different IoT might have devices wit
Original PR description
Before this commit: If an IoT is set on a company (other than the default one), when printing a report set to an IoT device. It would always show the "error to print" pop-up. This happened as the notification that the printing operation was successful was always send to the channel of the first company. After this commit: We force to use the company set on the device of the identifier (which is the iot box company). This heuristic is not perfect as different IoT might have devices with the same identifier, in this case, it would accidentally send to the wrong IoT channel. To solve this other issue, another PR in the IoT will force to send the IoT mac address in order to make sure to use the right IoT. As the code of the IoT might be outdated, we define it with a default value. opw-3965623 Forward-Port-Of: odoo/enterprise#66183 Forward-Port-Of: odoo/enterprise#65996
*l10n_account_customer_statements,l10n_my_reports,l10n_us_reports Currently some reports add buttons on their lines to perform some action on them. However, when prefix groups are used, the buttons are also shown on these lines, but refer to nothing and will thus either cause an error when clicked or lead to a new record. This commit fixes that by providing a generic hook in the `line_name` template to inject buttons. This generic hook checks whether the line is a prefix group line and doe
Original PR description
*l10n_account_customer_statements,l10n_my_reports,l10n_us_reports Currently some reports add buttons on their lines to perform some action on them. However, when prefix groups are used, the buttons are also shown on these lines, but refer to nothing and will thus either cause an error when clicked or lead to a new record. This commit fixes that by providing a generic hook in the `line_name` template to inject buttons. This generic hook checks whether the line is a prefix group line and doesn't render the buttons if it is. All other reports were adapted to use this hook now. task-3932945 Forward-Port-Of: odoo/enterprise#65270
This commit moves the generic `_with_locked_records` from `l10n_mx_edi.document` in `l10n_mx_edi` -> `res.company` in `account` This allows multiple EDIs to use the same generic method for locking their record before using them in requests. This prevents 2 (or more) users to send the same invoice at the same time. Affected EDIs: l10n_mx_edi, l10n_ro_edi task-id: 3595436 related community PR: https://github.com/odoo/odoo/pull/144061 Forward-Port-Of: odoo/enterprise#65602
Original PR description
This commit moves the generic `_with_locked_records` from `l10n_mx_edi.document` in `l10n_mx_edi` -> `res.company` in `account` This allows multiple EDIs to use the same generic method for locking their record before using them in requests. This prevents 2 (or more) users to send the same invoice at the same time. Affected EDIs: l10n_mx_edi, l10n_ro_edi task-id: 3595436 related community PR: https://github.com/odoo/odoo/pull/144061 Forward-Port-Of: odoo/enterprise#65602
before this commit: Insurance amount was sent in rating request but not in shipping request. Resulting in no insurance amount being printed on label. After this commit: If the insurance amount is sent, it is added to the shipping request and gets printed on label. opw-3845693 Forward-Port-Of: odoo/enterprise#66036
Original PR description
before this commit: Insurance amount was sent in rating request but not in shipping request. Resulting in no insurance amount being printed on label. After this commit: If the insurance amount is sent, it is added to the shipping request and gets printed on label. opw-3845693 Forward-Port-Of: odoo/enterprise#66036
Before this commit, avatax used the longitude and latitude in priority even if the partner has an address. The problem with this is that when you print the AvaTax report, the fields DestStreet, DestCity, and DestPostalCode are not populated because AvaTax was not sent any of that information. The customer needs those fields to be populated or else they may be charged more money. So now it will be the opposite, we will use the address in priority but if the customer has a delivery address wit
Original PR description
Before this commit, avatax used the longitude and latitude in priority even if the partner has an address. The problem with this is that when you print the AvaTax report, the fields DestStreet, DestCity, and DestPostalCode are not populated because AvaTax was not sent any of that information. The customer needs those fields to be populated or else they may be charged more money. So now it will be the opposite, we will use the address in priority but if the customer has a delivery address with no address information we will use the latitude and longitude of the delivery address partner. Task: 4011481 Forward-Port-Of: odoo/enterprise#66193 Forward-Port-Of: odoo/enterprise#65726