Friday, March 1, 2024
77 changes
22 changes
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
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 update clarifies how the `force_price_include=False` context key affects tax calculations within the Odoo accounting module. Previously, it was interpreted inconsistently, leading to potential errors in price calculations. This change ensures accurate tax handling, resolving a client issue related to price unit calculations.
Original PR description
Before this commit, using context key `force_price_include=False` had different interpretations in different methods In `compute_all` its semantic was forcing the "price_include" of taxes to be False In `_compute_amount` it was ignored (as only value "True" was overriding anything) To add to this incoherence, compute_all does use `force_price_include=False` when calling `_compute_amount`. This commits brings semantical coherence to the `account_tax` methods by keeping both interpretations of the context key the same: an override of price_include, whether its value True or False. This fixes a ticket in which the client uses that override to inverse the computation of `price_unit` from a tax-excluded counterpart. owp-3770871 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155769
A warning was appearing during internal transfers when tracked products had existing serial numbers. This update prevents the warning from triggering, ensuring smoother internal transfers and avoiding potential disruptions to inventory management. The fix addresses a technical issue related to serial number verification.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- Tracked by “SN”
- Update the qty to 1 in “WH/stock” with “SN1”
- Create an internal transfer:
- Location: wh/Stock
- Dest location: wh2/stock
- Mark as todo
- Try to select SN1 in the `stock.move`
Problem:
A warning is triggered:
`Existing Serial numbers. Please correct the serial numbers encoded: (001) exists in location WH/Stock`
We do a search to find all the quants in every location to verify if the same serial number is not being used, but we do not exclude the source location.
opw-3734300
Forward-Port-Of: odoo/odoo#155651
Forward-Port-Of: odoo/odoo#154626This update fixes a potential issue where channel subscriptions weren't reliably updating, leading to test failures. The change simplifies the subscription process using 'onAdd/onDelete' events, ensuring accurate channel tracking. This improves the overall stability and performance of the messaging system.
Original PR description
Before this PR, the `bus subscription is refreshed when channel is left` test was sometimes failing. This actually reveals a real issue: if a channel is joined a leave very quickly, the bus subscription is not updated. This occurs because we rely on the last subscription made and the one that should be made to detect if channels differ. Since the `updateBusSubscription` method is debounced, we can miss information. This PR replaces the complicated `updateBusSubscription` method by a `onAdd/onDelete`. This is much more reliable and more efficient since there is no need to walk through every channel to detect changes. This PR also remove a test that was redundant that the failing one. fixes runbot-55292,57645,56232 Forward-Port-Of: odoo/odoo#155720
This update resolves an issue where clicking on a color code in the colorpicker would reset the text field instead of updating the color. The fix ensures that color selections from the colorpicker now correctly update the note's color, improving usability.
Original PR description
Issue: ===== Clicking on hex color or rbga in colorpicker will reselect the inital selected text and not the value if hex or rgba. Steps to reproduce the issue: ============================= - Create…
Issue: ===== Clicking on hex color or rbga in colorpicker will reselect the inital selected text and not the value if hex or rgba. Steps to reproduce the issue: ============================= - Create a note , type anything and apply custom color - When clicking on the hex color code , the cursor is alwyas set back to the text. Origin of the issue: ==================== The behavior was introduced by https://github.com/odoo/odoo/commit/033b49e1a810c3decd8988698620616bd927f6c3 In the click listener, we always reset the comuted selection wich reselects the original text. When clicking on empty space on the dropdown menu, it happens too but it doesn't matter since the menu closes anyway, but clicking on text input fields that you want to update will be a problem since the menu doesn't close but the text get reselected. Solution: ========= To overcome the problem of resetting when clicking on the dropdown, we first check if the click is on the colorpicker or not, if Yes do nothing and skip this. task-3648629 Forward-Port-Of: odoo/odoo#149480
This update fixes an issue where the live chat element was sometimes hidden behind other content on certain websites. The change ensures the live chat consistently appears on top, improving the user experience and preventing interruptions. This was achieved by setting a high z-index value.
Original PR description
The live chat should always be on top of other elements: some sites that embeds it use z-index for various purpose. Currently, the live chat does not uses z-index, thus is it can be hidden by other elements. This PR sets the z-index to the largest value of a signed integer on a 32 bit system which is the theorical maximum value for this property. opw-3732033 e.g. on squarespace (before)  (after)  Forward-Port-Of: odoo/odoo#155903
This update clarifies the analytic widget by replacing a confusing floppy disk button with a 'New model' link. This change simplifies the process of creating analytic distribution templates, reducing user confusion and improving the overall user experience. The update also automatically populates relevant fields for easier setup.
Original PR description
On the analytic widget, when putting an Analytic Account, a floppy disk appear on top of the wizard. This button is used to create a new analytic distribution template. It is confusing for users that thinks that the purpose of the button is to save the analytic distribution. This PR will replace the button to be a link called "New model". Also, this pr will fill some field (partner_id, account_prefix and product_id) if there are populated. task: 3736786 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155611 Forward-Port-Of: odoo/odoo#153588
This update fixes an issue where the Kanban view incorrectly displayed overdue statuses for activities, even when no overdue activities existed. The fix ensures the Kanban column header accurately reflects the status of activities, improving the user experience and data consistency. This resolves a visual inconsistency impacting lead management.
Original PR description
How to reproduce: - Install CRM with demo data - Configure one activity type to keep done activities - Go to CRM and chose a kanban column with a green status (only planned activities for that state)…
How to reproduce: - Install CRM with demo data - Configure one activity type to keep done activities - Go to CRM and chose a kanban column with a green status (only planned activities for that state) - On a lead of that column, add an activity of the type chosen above with a deadline in the past - When going back to the kanban view, that column has the overdue status (red) - Mark that activity as done - Reload the kanban view The kanban column has still the status overdue (red) while there are no more overdue activity in that state. With this fix, after reloading the kanban view, the header displays the correct status summary. In the example above, the kanban column header is green. Technical note: archived activities were returned when grouping by activity_state because that part was done in SQL and not taking into account the recently added active field. While adding it in the "_read_group_groupby" method, we also add it in "_search_activity_state" to avoid the same problem when searching on activity_state. Note that we don't add flush in those methods using raw SQL so flush is needed in the added test. Task-3732333 Forward-Port-Of: odoo/odoo#153274
This update simplifies the process for international partners by removing unnecessary state validation within the l10n_in_edi module. Now, state requirements are only enforced for e-invoicing specifically for partners in India. This streamlines operations and reduces complexity for our overseas clients.
Original PR description
This commits removes the state validation for `l10n_in_edi` for overseas partner and now state will be only required for e-invoicing for partner having country `India` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154118
3 changes
Resolved issues and error corrections
The Sendcloud product selection screen has been fixed after a recent change caused it to stop working correctly. This helps users choose the right delivery product again when preparing Sendcloud shipments, reducing disruption in shipping workflows.
Original PR description
The product selection widget view has been broken by recent changes. This update aims to rectify that and bring it back to goodness.
This fix restores correct budget-related totals when users group budget data in the interface. It ensures fields such as theoretical amounts remain available for grouped reporting, preventing missing or incorrect business figures in budget analysis.
Original PR description
Since https://github.com/odoo/odoo/pull/127353, we do a dryrun to see if a field is aggregable (_descrition_aggregator()). We use `_read_group_select` to do so, and it doesn't work the field doesn't have an aggregator for the webclient, and then it is not ask when we groupby. Because of this every direct override of _read_group for these fields won't be use by the webclient anymore. Fix them by overriding `_read_group_select` (and `_read_group_postprocess_aggregate` for some cases). https://github.com/odoo/odoo/pull/155585
This fixes a small issue that caused unnecessary warning messages in server logs when field service worksheet templates were looked up. The change helps keep logs cleaner and avoids misleading operational noise without changing user-facing behavior.
Original PR description
Before this commit, a warning is logged in the server logs because `=` operator is used with an array as right leaf in a domain used in a search in `_compute_worksheet_template_id` defined in `project.project` model. The operator used should be `in` instead of `=`, that's why we got that warning. This commit fixes the issue by changing the operator used inside that domain to use `in` instead of `=`. runbot-58374 X-original-commit: 2b12d5e8