Thursday, August 15, 2024
6 changes · 17.0
Enhancements to existing features
This update allows URL fields to be treated like links in the interface, including when they are styled as buttons in areas such as status bars. It gives implementers more flexibility to create clearer, action-oriented screens without changing the underlying behavior.
Original PR description
Therefore there's nothing especially wrong in styling it like a button e.g. in the statusbar.
Resolved issues and error corrections
The Bangladesh localization package now includes required accounting tag setup in the standard installation data instead of demo-only data. This ensures businesses can install and use the package correctly even when demo data is disabled.
Original PR description
[FIX] l10n_bd: fix loading account template The issue is that I put the account tags templates in the manifest to load into demo section which cause issues when user try to load the package without demo data as It will not going to load Solution: moving the account tags template/states to the data section task-id#3974212 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Steps to reproduce: - Planning > Configuration > Shift Templates > Create - Configure the Shift so that it ends 1 minute into the next day. ==> "(2 days span)" is not displayed in the shift template name. What happens: The rounding precision on the number of days computation only goes up to a 16th of a day, any less was rounded down and show up as 1 day (i.e 1-14 minutes assuming 40h work weeks, ...). This 16th rounding was removed entirely. Rounding precision has to be at least 3 decim
Original PR description
Steps to reproduce: - Planning > Configuration > Shift Templates > Create - Configure the Shift so that it ends 1 minute into the next day. ==> "(2 days span)" is not displayed in the shift template name. What happens: The rounding precision on the number of days computation only goes up to a 16th of a day, any less was rounded down and show up as 1 day (i.e 1-14 minutes assuming 40h work weeks, ...). This 16th rounding was removed entirely. Rounding precision has to be at least 3 decimals for this problem to stop occuring. 8:02 still rounded to 1 day on the previous fix https://github.com/odoo/odoo/commit/a9be2e45d8db5011cfcbef8f5d81ce4127d5d151. opw-3911429 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173645
Fixed an issue where clearing an end date and choosing a new one would incorrectly change the start date instead. This helps users maintain accurate date ranges and reduces data entry mistakes.
Original PR description
before this commit: When the user removes the end date and then selects a new date, that date is update the start date. after this commit: When the user removes the end date and then selects a new date, that date should update the end date. Task-3899581
This update fixes warning messages in Kenya's electronic invoicing system to only appear when a company has an active OSCU (Online Sales Control Unit). Previously, warnings about quantity mismatches on invoices and bills of materials would display regardless of whether the company was using Kenya's EDI system, causing unnecessary alerts for non-Kenyan users. The change also removes unused code to keep the system clean.
Original PR description
Two warnings need to be conditionally hidden if the company does not have an OSCU active: - the warning on invoices that the delivered quantities do not match invoiced quantities; and - the warning on BoMs. In addition, we take the opportunity to remove the method `env['product.product']._compute_l10n_ke_validation_message` which is dead code.
Description of the issue/feature this PR addresses: Passing a context as a dict rather than a key-value pair will drop the current context and only keep the explicitly passed dict. In some modules methods like `name_get` have been overridden to have a conditional behavior based on context. This, however, will never work if `_compute_translated_display_name` drops all the context before it gets to said method. This fix simply makes all the upstream context pass through. Current behavi
Original PR description
Description of the issue/feature this PR addresses: Passing a context as a dict rather than a key-value pair will drop the current context and only keep the explicitly passed dict. In some modules methods like `name_get` have been overridden to have a conditional behavior based on context. This, however, will never work if `_compute_translated_display_name` drops all the context before it gets to said method. This fix simply makes all the upstream context pass through. Current behavior before PR: Calls to methods that have `_compute_translated_display_name` somewhere in the call stack will not see the context that they have been originally given. Desired behavior after PR is merged: All methods will see the context that they have been given at the call --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170050