Tuesday, November 28, 2023
17 changes · 17.0
Enhancements to existing features
This update expands internal code checking rules so they cover all point of sale modules, helping developers catch issues more consistently. It also adds a helper script to list point of sale modules, making future maintenance easier without changing the user experience.
Original PR description
In this commit we update the lists of modules from `_eslintignore` and `jsonconfig.json` such that they now contain all pos modules. In addition, we also create script in the `tools` directory of pos that returns a list of all the pos modules. This list is often very useful. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix prevents an error when users disable a discussion subscription. The system now keeps the needed display name available, so the action completes smoothly even after the related discussion record is removed.
Original PR description
Before this PR: When a user removes Discussion subtype, the thread is automatically deleted and also its relational field. Subsequently, a getter method responsible for retrieving the name to generate the title fetches it from the 'partner' _field, which is now undefined, leading to a traceback. Desired behaviour after this PR: Saving the 'name' in the state will enable the getter to retrieve the name even after the record is deleted. task-3590756
Miscellaneous changes
Previously, if there were multiple loyalty programs with different sets of rules, all of them would appear on the receipt, regardless of their applicability to the order. This caused confusion as it included programs that were not actually applied to the customer's order. This commit addresses the issue by altering the receipt logic. Now, a loyalty program will only be shown on the receipt if it has either awarded points or had points redeemed in the specific order. This ensures that only rel
Original PR description
Previously, if there were multiple loyalty programs with different sets of rules, all of them would appear on the receipt, regardless of their applicability to the order. This caused confusion as it included programs that were not actually applied to the customer's order. This commit addresses the issue by altering the receipt logic. Now, a loyalty program will only be shown on the receipt if it has either awarded points or had points redeemed in the specific order. This ensures that only relevant loyalty programs are displayed, enhancing clarity and accuracy in customer receipts. opw-3608570 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143301
This fixes a problem where links created in the website editor could be redirected incorrectly because the system did not properly recognize secure web addresses. Users can now add links starting with http:// or https:// and have them open as intended.
Original PR description
Description of the issue/feature this PR addresses: Fixes href variable used to construct the link. Resolves #104597 Current behavior before PR: href variable was looking to see if the link started with http:// or https://:// before redirecting to http:// Desired behavior after PR is merged: href variable will correctly verify if the link begins with http:// or https:// and redirect the request accordingly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Spanish localization now marks the DUA negative adjustment tax line so it is excluded from Libros exports. This prevents an incorrect -100% line from appearing in tax reporting exports and helps keep Spanish tax submissions accurate.
Original PR description
add l10n_es_type 'ignore' on Subtract Base (DUA) -100% tax so that it can be ignored when creating Libros export enterprise-PR: https://github.com/odoo/enterprise/pull/51366 task-id: 3604971
This update fixes the Twitter social media posting interface by hiding character limit messages after a post is sent and adding proper spacing between icons and text in the posts section. These improvements make the interface cleaner and more polished for users managing their social media accounts.
Original PR description
**Before this PR:** -Message character limits are visible after posting a message on Twitter. -There is no space between globe icon and text in the posts by accounts section. **After this PR:** -Message character limits will be hidden after posting a message on Twitter. -Space will be added between text and globe icon in the posts by accounts section. **Task**-3459739
This update fixes a timing issue in the website rental testing process where rental start and end dates could differ when tests run near midnight. The fix ensures both dates are set to the same day, allowing the test to run reliably at any time. This resolves a recurring build failure that was affecting the rental sales feature.
Original PR description
Before this commit, default dates were used for renting. Launching this test just before midnight, start date and end dates are different, although the remaining of the test relies on the fact that hours are defined for the same day. This commit makes sure the renting start date is the same as the end date. Fixes build error 28629
Steps to reproduce: - Enable the merge on account.account in data cleaning APP (in debug) - Create an invoice with a receivable account = A - Define a lock date after the invoice date - Go to chart of accounts - Select your receivable = A et receivable = B - Action = Merge accounts where B is the MASTER Issue: Upon revisiting the customer invoice: Notice that the journal items have been updated. Solution: We simply prevent ~~the use of a nuclear weapon~~ the merge of `account.ac
Original PR description
Steps to reproduce: - Enable the merge on account.account in data cleaning APP (in debug) - Create an invoice with a receivable account = A - Define a lock date after the invoice date - Go to chart of accounts - Select your receivable = A et receivable = B - Action = Merge accounts where B is the MASTER Issue: Upon revisiting the customer invoice: Notice that the journal items have been updated. Solution: We simply prevent ~~the use of a nuclear weapon~~ the merge of `account.account` as there other possibilities less dangerous such as multi-edit + archiving We also prevent the merge of `res.partner` if this one is used in hashed entries oe:https://github.com/odoo/enterprise/pull/47053 opw-3389157 Forward-Port-Of: odoo/odoo#138313 Forward-Port-Of: odoo/odoo#134634
**Description of the issue/feature this PR addresses:** Several fixes and updates for the not yet complete Austrian Localization, started to prepare in Valencia on the OCA Code Sprint. Same version as https://github.com/odoo/odoo/pull/134958 but upgraded on 16.0 Enterprise PR: https://github.com/odoo/enterprise/pull/47198 Info: @wt-io-it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#141961 Forward-Port-Of:
Original PR description
**Description of the issue/feature this PR addresses:** Several fixes and updates for the not yet complete Austrian Localization, started to prepare in Valencia on the OCA Code Sprint. Same version as https://github.com/odoo/odoo/pull/134958 but upgraded on 16.0 Enterprise PR: https://github.com/odoo/enterprise/pull/47198 Info: @wt-io-it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#141961 Forward-Port-Of: odoo/odoo#134959
When opening the calendar view in, for example, the timesheets app, the first day of the week used for the number calculation is provided by the localization service, which in turn requests it from the database. Because the first day of the week is stored as a number between 1 and 7 in the `res.lang` model and a value between 0 and 6 is expected by the `DateEnv`, offset errors can occur. The error is fixed in various components (for example, the `CalendarDatePicker` and `CalendarCommonRendere
Original PR description
When opening the calendar view in, for example, the timesheets app, the first day of the week used for the number calculation is provided by the localization service, which in turn requests it from the database. Because the first day of the week is stored as a number between 1 and 7 in the `res.lang` model and a value between 0 and 6 is expected by the `DateEnv`, offset errors can occur. The error is fixed in various components (for example, the `CalendarDatePicker` and `CalendarCommonRenderer`) but not in others (`CalendarYearRenderer`). Instead of patching each component separately, a better solution is to require the `CalendarModel` to expose a 0 to 6 `firstDayOfWeek` value as part of its public interface. opw-3389617 Forward-Port-Of: odoo/odoo#128369
Task: 3551443 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#140270 Forward-Port-Of: odoo/odoo#138544
Original PR description
Task: 3551443 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#140270 Forward-Port-Of: odoo/odoo#138544
### Steps to reproduce * install the German localization * create and print an invoice You should see that the 'total' block and payment reference are not correctly aligned opw-3524254 Before:  After:  Forward-Port-Of: odoo/odoo#141945
Original PR description
### Steps to reproduce * install the German localization * create and print an invoice You should see that the 'total' block and payment reference are not correctly aligned opw-3524254 Before:  After:  Forward-Port-Of: odoo/odoo#141945
Prior to this commit, a problem was introduced in the POS HR module where loading paid orders would incorrectly display the current cashier as the cashier for all orders. This issue happened after changes made in commit https://github.com/odoo/odoo/commit/990b10aece1439779b185d6a49ed26d9586c6c01. opw-3556225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142737
Original PR description
Prior to this commit, a problem was introduced in the POS HR module where loading paid orders would incorrectly display the current cashier as the cashier for all orders. This issue happened after changes made in commit https://github.com/odoo/odoo/commit/990b10aece1439779b185d6a49ed26d9586c6c01. opw-3556225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#142737
Backport of https://github.com/odoo/odoo/pull/140446/commits/80293ba701164315e137a541f543e0aaf837ae83 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143503
Original PR description
Backport of https://github.com/odoo/odoo/pull/140446/commits/80293ba701164315e137a541f543e0aaf837ae83 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143503
A custom script is modifying the output of load_information_from_description_file to disable the auto-install of modules during local testing. It was naively adapted for v16.0 by replacing the corresponding methods. Since a lru cache was added (nice optimization in most cases) this is an issue because running lint test afterward will get the cached value with an incorrect autoinstall value. It makes sense to avoid reading the file on the filesystem each time, but making a deepcopy looks like an
Original PR description
A custom script is modifying the output of load_information_from_description_file to disable the auto-install of modules during local testing. It was naively adapted for v16.0 by replacing the corresponding methods. Since a lru cache was added (nice optimization in most cases) this is an issue because running lint test afterward will get the cached value with an incorrect autoinstall value. It makes sense to avoid reading the file on the filesystem each time, but making a deepcopy looks like an acceptable safeguard to avoid hard to debug behaviors. Forward-Port-Of: odoo/odoo#143522
Before: No lituanian translation was created for this version about the number of remaining products in stock on website ecommerce page. Step to reproduce: - Create a db with the website_sale_stock module - Configure a product in sales tab: active Show available qty with only if below 1000 - Add lituanian language - Go on the product page on the website and change the lanuage in lituanian Now: Translation added opw-3560842 Forward-Port-Of: odoo/odoo#142772 Forward-Port-Of: odoo/odo
Original PR description
Before: No lituanian translation was created for this version about the number of remaining products in stock on website ecommerce page. Step to reproduce: - Create a db with the website_sale_stock module - Configure a product in sales tab: active Show available qty with only if below 1000 - Add lituanian language - Go on the product page on the website and change the lanuage in lituanian Now: Translation added opw-3560842 Forward-Port-Of: odoo/odoo#142772 Forward-Port-Of: odoo/odoo#140523
The "Scan your badge" login option was not working properly when trying to log in to the POS shop. The barcode scanner styles were missing which caused the issue. opw-3509075 Forward-Port-Of: odoo/enterprise#48169
Original PR description
The "Scan your badge" login option was not working properly when trying to log in to the POS shop. The barcode scanner styles were missing which caused the issue. opw-3509075 Forward-Port-Of: odoo/enterprise#48169