Friday, March 1, 2024
120 changes
15 changes
Enhancements to existing features
This update enhances the speed and accuracy of product and partner searches within Point of Sale. The new search algorithm, based on the Smith-Waterman algorithm, reduces irrelevant results and prioritizes exact matches, leading to a better user experience. Additionally, search results are now displayed in the order of the search query, increasing relevance.
Original PR description
Before this commit, the fuzzyLookup function from the web was used, which had some issues when users searched for exact terms to find products or partners with a limited number of characters. It often showed irrelevant items, which was confusing for the users. With this commit, a new fuzzy lookup based on the Smith-Waterman algorithm for local sequence alignment is implemented. Also it improves the search accuracy by giving a bonus when the exact term is found in a text. Additionally, the product search results are now displayed based on the search order, instead of being sorted by the product name. This change makes the search results more relevant to the user's search query. opw-3766742 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update fixes a previous issue where Point of Sale performance was impacted by large product catalogs. A new setting, 'point_of_sale.limited_product_count', allows administrators to control the number of products initially loaded, optimizing performance for businesses with extensive product lists. This ensures a smoother and faster Point of Sale experience.
Original PR description
This commit re-enables the limited product loading feature that was inadvertently removed in a recent refactor. This feature is essential for databases with a large product catalog. The feature can now be configured using the "point_of_sale.limited_product_count" system parameter. This parameter determines the number of products initially loaded in the Point of Sale. opw-3758356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
10 changes
New functionality added to Odoo
Adds support for Canadian CPA 005 electronic payment files so businesses can submit batch vendor payments to participating banks. The feature includes configurable bank file numbering, payment validations, and guidance to reduce rejected files and manual troubleshooting.
Original PR description
This update fixes a previous issue where products within a POS category's child categories weren't visible. Now, all products associated with a category and its children are correctly displayed, improving the user experience for product browsing in the Point of Sale system. This ensures accurate product listings and simplifies the sales process.
Original PR description
Before this commit, if a POS category had children, we didn't show the products in the child categories. This commit fixes this issue by ensuring that products in child categories are also displayed. opw-3754832 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug where QRIS code generation for countries other than Indonesia didn't display error messages. Now, the system will correctly generate an error if a bank account from a different country is used, ensuring accurate QR code generation and compliance.
Original PR description
At the moment, QRIS is not returning an error message when you try to generate a QR code with a country that is not Indonesia. It will instead skip all checks and return no errors. This fix will ensure that we arise an error if we try to generate the QR code with a bank account from another country. Task id # 3758668 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a potential issue where manually editing follower lists could cause errors when assigning users to records after merging. The change ensures that follower lists are always up-to-date, preventing duplicate entries and improving the reliability of follower management. This primarily impacts users managing leads and contacts.
Original PR description
`_message_auto_subscribe` relies on `_get_subscription_data` to know who is subscribed to what. This method uses a raw SQL query but doesn't flush the relevant records beforehand. This is not an issue in most normal cases, but if followers are edited manually, for example in order to merge existing models, it may cause issues when then assigning someone to the model will attempt adding them to the list of followers, when they already were on it. task-3713472 original issue in opw-3634410 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155043 Forward-Port-Of: odoo/odoo#152041
This update resolves an issue where users were unable to save custom background colors for product ribbons on the website. The fix adds an 'important' tag to the ribbon color setting, ensuring changes are applied as intended. This improves the user experience by allowing for personalized product displays.
Original PR description
Before this commit, the `bg-primary` class was overwriting the `bg_color` set by the user after saving changes as it has the `!important` tag. Steps to reproduce the issue: 1. Go to Shop page on website 2. Enable edit mode 3. Pick a product and create a new Badge (ribbon) 4. Change the background color and save changes -> color reverts to `bg-primary` This commit fixes this behavior by adding the `!important` tag to the `bg_color` so that it properly overwrites the `bg-primary` color. opw-3734598 Forward-Port-Of: odoo/odoo#155040
This update resolves an issue where the PoS user's partner information wasn't consistently loaded, potentially causing problems with cash transactions. By always loading the PoS user partner, this fix guarantees accurate cash handling and improves the overall Point of Sale experience. This change is a critical fix for reliable operations.
Original PR description
Prior to this commit, in cases with a large number of customers in the database, we loaded a limited number of customers. This could potentially exclude the PoS user partner, causing issues during cash in/out operations. This commit ensures the PoS user partner is always loaded to prevent such issues. opw-3767023 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where cash in/out operations failed when multiple employees were logged into a session. The recent refactoring of a key data field caused this conflict. This change ensures reliable cash management functionality regardless of the number of employees using the system.
Original PR description
Before this commit, if multiple employees were enabled in a session, performing cash in/out operations would cause an error. This was due to a recent refactor where the 'work_contact_id' was changed to an object. opw-3764015 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a minor issue where loyalty points were being displayed with slight rounding errors due to how the system calculates points. The change ensures that loyalty points are shown accurately, providing a better customer experience. This improves the reliability of the loyalty program's point calculations.
Original PR description
Steps ----- 1. Create a loyalty card program awarding 1 point per $ spent; 2. make sure "Show points Unit" is enabled; 3. give yourself a loyalty card with 267.39 points on it; 4. create a product with a price of $0.89; 5. go to website and add it to your shopping car; 6. go to checkout. Issue ----- > You have 268.28000000000003 Loyalty point(s) Cause ----- The number comes from the `_get_real_points_for_coupon` method, which uses `float_round` by way of `res.currency`. The `float_round` function isn't suited for raw number display, as it can make tiny rounding errors due to floating point arithmetic. Solution -------- Add a `_format_points` method to `loyalty.card` which will return a string using the same format the `points_display` field uses. opw-3705546 Forward-Port-Of: odoo/odoo#155466 Forward-Port-Of: odoo/odoo#153541
This update fixes an issue where pricelists created in new databases caused problems with multi-company sales reporting. The change now ensures pricelists are tied to the current company, simplifying setup and preventing errors, especially for businesses using a single company.
Original PR description
Since 83c52575d0ce3d7deb1737c622c6ce366db8c31b, there is no default pricelist in new database, and a magic pricelist is created for each company when the pricelist setting is enabled. But, since this…
Since 83c52575d0ce3d7deb1737c622c6ce366db8c31b, there is no default pricelist in new database, and a magic pricelist is created for each company when the pricelist setting is enabled. But, since this automatically created pricelist is restricted to a specific company, you couldn't use it as 'Base' for rules of other pricelists, which are, by default, shared between companies, unless you set a specific company on them. This commit changes that default behavior, to restrict pricelists to the current company (unless the field is manually emptied), to avoid those multi-company issues, particularly in single-company databases where multi-company issues are not expected. Also, while testing this task, we discovered that a user could change the company of a pricelist, even if it conflicted with existing rules. To avoid this situation, we now trigger the multi-company check on the pricelist rules when the pricelist company is updated. task-3610823 See odoo/enterprise#55857 Forward-Port-Of: odoo/odoo#147014
This update corrects a bug that limited the number of documents available for scheduling activities after multiple scheduling attempts. The fix ensures that all documents are accessible during the scheduling process, preventing the restriction of available records. This improves the user experience when managing activities.
Original PR description
**Steps to reproduce:** - Go to activity view. - Schedule an activity for one document. (Say 8 docs are available) - Schedule an activity for the second time. (Again 8 docs are available) - Try to…
**Steps to reproduce:** - Go to activity view. - Schedule an activity for one document. (Say 8 docs are available) - Schedule an activity for the second time. (Again 8 docs are available) - Try to schedule an activity for the 3rd time. (Only 2 docs are available) **Issue:** Since 7682286, the existing props of activity model are being passed as params while scheduling an activity. Currently, `["activity_ids", "!=", false]` is being pushed to the domain of activity model in order to display only those records on which activities have been set. As a result, after you schedule activities more than once, `["activity_ids", "!=", false]` domain gets applied and the list of documents available for scheduling activity is restricted to only those specific records from the third time onwards. **Fix:** This PR passes the 'searchParams' of activity model as params to the 'load' method while scheduling activity, instead of existing props, to ensure that the existing params are applied, as well as all documents are accessible while scheduling activity in `searchCreateDialog` (i.e. ["activity_ids", "!=", false] condition is not added to its domain). Task: [3721750](https://www.odoo.com/web#id=3721750&menu_id=4722&cids=2&action=333&active_id=10888&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#155700 Forward-Port-Of: odoo/odoo#153606
This update resolves an issue where the 'l10n_ar_withholding' module couldn't be installed correctly when multiple Argentine companies were set up in Odoo. The fix ensures that tax data is properly calculated and linked to each company individually, preventing compatibility errors.
Original PR description
Steps to reproduce: - Install Accounting and l10n_ar - Create 2 companies located in Argentina (e.g. Company A & Company B) - Switch to Company A - Go to Accounting settings - Set Fiscal Localization…
Steps to reproduce: - Install Accounting and l10n_ar - Create 2 companies located in Argentina (e.g. Company A & Company B) - Switch to Company A - Go to Accounting settings - Set Fiscal Localization to Argentina (e.g. Argentina - Argentine Generic Chart of Accounts for Excempt individuals) - Switch to Company B - Go to Accounting settings - Set Fiscal Localization to the same Fiscal Localization than Company A (i.e. Argentina - Argentine Generic Chart of Accounts for Excempt individuals) - Try to install "l10n_ar_withholding" module Issue: A User Error is raised: "Incompatible companies on records: - 'account.tax.repartition.line,1230' belongs to company 'Company A' and 'Account' (account_id: '1.1.4.03.020 SUSS Withholding incurred') belongs to another company. - 'account.tax.repartition.line,1232' belongs to company 'Company A' and 'Account' (account_id: '1.1.4.03.020 SUSS Withholding incurred') belongs to another company. - 'account.tax.repartition.line,1234' belongs to company 'Company A' and 'Account' (account_id: '1.1.4.05.030 Withholdings of Profits incurred') belongs to another company. - 'account.tax.repartition.line,1236' belongs to company 'Company A' and 'Account' (account_id: '1.1.4.05.030 Withholdings of Profits incurred') belongs to another company." Cause: When installing "l10n_ar_withholding" module, each Argentine company is updated with some tax data. These data are "generic" (not linked to any company) and used for each company, but some treatment is performed on them by the first Argentine company, linking them to the account ids of that company. The following companies are then updated with data linked to the first company. Solution: Compute the data for each company. opw-3709819 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154219
This update fixes an issue where the website's header search field couldn't be accessed using the keyboard. The change ensures all users, including those using assistive technologies, can easily find and use the search function, improving website usability and accessibility. This resolves a previous accessibility concern.
Original PR description
This commit resolves the accessibility issue where the search field located within the header was not navigable (see [1]) via keyboard tabbing, rendering it inaccessible to users relying on keyboard navigation. This fix ensures that users can seamlessly navigate to the search field in the header using the keyboard, thereby enhancing the overall accessibility and usability of the website. [1]: https://github.com/odoo/odoo/commit/ac5866a059c345480e246b558eeae1e94aead822 task-3607481 Forward-Port-Of: odoo/odoo#153197
This update corrects a bug where changing the end date of a shift template would reset the start date. The issue stemmed from how Odoo calculates date values, and this fix ensures that date fields retain their original values when templates are used. This improves data consistency and prevents unexpected behavior when creating shifts.
Original PR description
To reproduce: ============ - on Planning create new shift - select a template - change the end date -> the end date is reset to the template value Problem: ======== - `end_datetime` and…
To reproduce: ============ - on Planning create new shift - select a template - change the end date -> the end date is reset to the template value Problem: ======== - `end_datetime` and `start_datetime` have the same compute method - `template_id` depends on `start_datetime` and `end_datetime` - so changing `end_datetime` triggers the compute method of `template_id` that will read `start_datetime` - reading `start_datetime` triggers the compute method of `end_datetime`, that will check if `template_id` is set and if so, will take its values ------- why the compute method of `end_datetime` is triggered ? : ------- - `start_datetime` is not protected from recomputing, at this line : https://github.com/odoo/odoo/blob/83aa46a4ab88c0226b1aa1dc36671d3208a0835a/odoo/models.py#L6746 we only protect the fields sent by frontend (only `end_datetime`) - frontend doesn't send `start_datetime` as it was not changed Solution ======== as ORM fix can't be made in stable, we send `start_datetime` in the `onchange` query even if it's unchanged to make sure both fields are protected opw-3693206 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155705 Forward-Port-Of: odoo/odoo#154190
This update resolves an issue where the COA SAT(XML) export generated warnings on newly created databases. The fix corrects incorrect account tags, particularly for 102 accounts, ensuring the report functions correctly out-of-the-box. It also includes a default tag calculation for new accounts.
Original PR description
Steps to reproduce: 1. Install l10n_mx 2. Go to Accounting > Reporting > Trial balance. 3. Click the COA SAT(XML) export button. 4. Warnings are raised. Problem: the report should work out-of-the-box on new databases. Cause: 1. Some tags are missing on auto-generated accounts. 2. Some data were not correct and had the wrong tag. 102 accounts in particular should be debit and not credit. This PR migrate the incorrect data and add a default naive computation of the tag on newly created accounts. opw-3283746 Enterprise: https://github.com/odoo/enterprise/pull/57531 Forward-Port-Of: odoo/odoo#155677 Forward-Port-Of: odoo/odoo#119485
This implements Canadian Payment Association Standard 005 (CPA005) Electronic Fund Transfer (EFT) files. They allow users to easily submit batch vendor payments to their bank. This feature is similar…
This implements Canadian Payment Association Standard 005 (CPA005) Electronic Fund Transfer (EFT) files. They allow users to easily submit batch vendor payments to their bank. This feature is similar to l10n_us_payment_nacha, which implements a similar file format for the US.
CPA005 files consist of logical records with a fixed length [1]. A logical record corresponds to a line in the file and has a type, denoted by a letter. For our purposes we only support 3 types: header ("A"), deposit data ("C") and footer ("Z").
The header record contains metadata about the batch payment, which includes the currency. CPA005 allows one file to have either CAD or USD payments, but not both. Of interest here is the the File Creation Number (FCN). This is the 4 digit identifier of the file. We made defining this field as flexible as possible because different banks have different requirements. We know of at least the following requirements made by different banks:
- FCN must be different from the previous 9 FCNs submitted [4],
- FCN must be TEST for test files [4],
- Subsequent FCNs should increment by 1 [5][6],
Because of these differences the FCN is overridable on the batch payment (for e.g. specifying TEST). When not overridden, numbers are generated based on a sequence linked to the journal so the step can be adjusted to match what the bank requests.
To adhere to industry standards we deviate from the official specification in two ways. First of all, we don't encode the files in EBCDIC [2], instead we use the standard UTF-8 encoding. Secondly, we only add one payment per "C" record. The format allows for up to 6 payments in the same "C" record [3], but this seems uncommon nowadays.
From our experience with NACHA we know that banks don't always provide good errors to customers. To minimize trial and error we provide as much help as we can to users with tooltips and validations.
Contrary to NACHA, no good validators exist. This implementation has been tested in two ways. The output was compared to the output of known good software, and generated files were tested in production with a real bank (CIBC).
[1] https://www.payments.ca/sites/default/files/standard005eng.pdf
[2] p6 in [1]
[3] p13 in [1]
[4] p6 in https://www.rbcroyalbank.com/ach/file-451770.pdf
[5] https://help.treasurysoftware.com/hc/en-us/articles/360046359093-TD-Toronto-Dominion-80-byte-and-1464-byte-EFT-file-formats
[6] p129 in https://www.atb.com/siteassets/pdf/resources/support/atb-business/atb-business-eft-user-guide-0422.pdf
task-3639094Miscellaneous changes
**Steps to reproduce:** 1- Install Helpdesk, Website module 2- Login using portal user 3- Navigate to tickest and search by assignees **Current behavior before PR:** When searching by assignees using a portal user you will not get any results. This is happening because the portal user seems to not have the access to search in 'res.users' so when the orm parse the user_id assigned to the ticket to a name it will not be able to parse it for the portal user. **Desired behavior after PR
Original PR description
**Steps to reproduce:** 1- Install Helpdesk, Website module 2- Login using portal user 3- Navigate to tickest and search by assignees **Current behavior before PR:** When searching by assignees using a portal user you will not get any results. This is happening because the portal user seems to not have the access to search in 'res.users' so when the orm parse the user_id assigned to the ticket to a name it will not be able to parse it for the portal user. **Desired behavior after PR is merged:** We search first for the users that are matching the search key in 'res.users' using 'sudo()' then get their ids and search in 'helpdesk.ticket' using those ids opw-3719387 Forward-Port-Of: odoo/enterprise#56716
Based on last runbot counters Forward-Port-Of: odoo/enterprise#57731
Original PR description
Based on last runbot counters Forward-Port-Of: odoo/enterprise#57731
the headers of the xlsx report were not translated this commit fixes that by adding the missing translations into the controller task-3718923 Forward-Port-Of: odoo/enterprise#55761
Original PR description
the headers of the xlsx report were not translated this commit fixes that by adding the missing translations into the controller task-3718923 Forward-Port-Of: odoo/enterprise#55761
steps to reproduce: 1. Go to approvals with no rights 2. create a new approval request 3. add an approver -> the approver cannot be selected because the line is readonly expected behavior: the approver can be selected Explaination of the issue: The field can_edit_user_id is set to False when no user is selected because when you add a line no user is selected by default. behavior after the fix: the approver can be selected task-3602617 Forward-Port-Of: odoo/enterprise#54822
Original PR description
steps to reproduce: 1. Go to approvals with no rights 2. create a new approval request 3. add an approver -> the approver cannot be selected because the line is readonly expected behavior: the approver can be selected Explaination of the issue: The field can_edit_user_id is set to False when no user is selected because when you add a line no user is selected by default. behavior after the fix: the approver can be selected task-3602617 Forward-Port-Of: odoo/enterprise#54822
### Cause When validating an address, we take for granted that Avatax returns latitude and longitude, while it's optional. We started using Avatax's returned geocoordinates in `saas-16.2`, https://github.com/odoo/enterprise/commit/282b878d8c441aaf546e6ce5d5c7dbe9f831d5b2 ### Steps to reproduce * install `account_avatax` * in the settings, enable and setup Avatax. Make sure to enable Address Validation. * create a partner with the following address: - Street 1: 999 Canada Pl - Cit
Original PR description
### Cause When validating an address, we take for granted that Avatax returns latitude and longitude, while it's optional. We started using Avatax's returned geocoordinates in `saas-16.2`, https://github.com/odoo/enterprise/commit/282b878d8c441aaf546e6ce5d5c7dbe9f831d5b2 ### Steps to reproduce * install `account_avatax` * in the settings, enable and setup Avatax. Make sure to enable Address Validation. * create a partner with the following address: - Street 1: 999 Canada Pl - City: Vancouver - State: British Columbia (CA) - Zip: V6C 3B5 - Country: Canada * click the 'Validate' button, next to the country You should be met with a traceback: `KeyError: 'latitude'` Ticket link: https://www.odoo.com/web#model=project.task&id=3752775 opw-3752775 Forward-Port-Of: odoo/enterprise#57612
Bug === Currently, we can not login to Instagram, because a permission is missing. This commit adds the missing permission, and we upgrade from 10.0 to 17.0. Task-3761561 Forward-Port-Of: odoo/enterprise#57693 Forward-Port-Of: odoo/enterprise#57218
Original PR description
Bug === Currently, we can not login to Instagram, because a permission is missing. This commit adds the missing permission, and we upgrade from 10.0 to 17.0. Task-3761561 Forward-Port-Of: odoo/enterprise#57693 Forward-Port-Of: odoo/enterprise#57218
This commit(https://github.com/odoo/enterprise/commit/217594fe8ba00329b3eb5c68e3eca3b556127cde) removed a filter on products that are services and that shouldn't be in the intrastat report (for now). This commit adds again this filter. opw-3763306 opw-3764904 opw-3730803 Forward-Port-Of: odoo/enterprise#57701 Forward-Port-Of: odoo/enterprise#57607
Original PR description
This commit(https://github.com/odoo/enterprise/commit/217594fe8ba00329b3eb5c68e3eca3b556127cde) removed a filter on products that are services and that shouldn't be in the intrastat report (for now). This commit adds again this filter. opw-3763306 opw-3764904 opw-3730803 Forward-Port-Of: odoo/enterprise#57701 Forward-Port-Of: odoo/enterprise#57607
At the moment, when auto sending the customer statement, it will always send the values for the current month. This means that if you send it bi-weekly, the first sending will contain the values for the first two weeks of the month, while the second will contain the values for the whole month. But this does not work well when you can have custom frequency, as there will be cases, where you will want the values of the last x weeks/months, or when a two-week period is between two months.
Original PR description
At the moment, when auto sending the customer statement, it will always send the values for the current month. This means that if you send it bi-weekly, the first sending will contain the values for the first two weeks of the month, while the second will contain the values for the whole month. But this does not work well when you can have custom frequency, as there will be cases, where you will want the values of the last x weeks/months, or when a two-week period is between two months. To have a more flexible system, we will now compute the start date by taking into account the set frequency. The end date of the statement will always be the day before the sending date, while the start date will be the end date minus the frequency (so minus two weeks if set to bi-weekly). Task id # 3713352 Forward-Port-Of: odoo/enterprise#56893
- Adds an option/filter to display amount in different units, i.e, 'decimals', 'units', 'thousands', 'lakhs' and 'millions'. - Makes 'format_value' a private python method and creates a new public 'format_value' method that should be called from the client. This change was made because we can not pass records from the client to the server. For example for currency, we can pass the currency_id to the server, but then we need to fetch the currency before continuing. task-3626894 Forwar
Original PR description
- Adds an option/filter to display amount in different units, i.e, 'decimals', 'units', 'thousands', 'lakhs' and 'millions'. - Makes 'format_value' a private python method and creates a new public 'format_value' method that should be called from the client. This change was made because we can not pass records from the client to the server. For example for currency, we can pass the currency_id to the server, but then we need to fetch the currency before continuing. task-3626894 Forward-Port-Of: odoo/enterprise#56817 Forward-Port-Of: odoo/enterprise#55218