Friday, March 1, 2024
37 changes
13 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 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 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 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 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
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
The iOS app check-in feature was broken due to issues with location access. This update resolves the problem by skipping the location request process specifically for iOS users, ensuring the check-in functionality works correctly. This improves the user experience for iOS users.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Use iOS app; 2. click on red dot on top; 3. click check in. Issue ----- Nothing happens. Cause ----- The iOS app cannot request the user's location. Commit 1acd0b6c5d7ce292f670882f6ff48a2ff9db05f0 attempted to fix this by first checking whether `navigator.geolocation` exists, but the cause is likely with its `getCurrentPosition` method instead of its existence. Solution -------- Instead of checking for `navigator.geolocation`, use `isIosApp` to skip the geolocation part when using the iOS app. opw-3734385 Forward-Port-Of: odoo/odoo#155588
This update fixes a problem where the Mexican localization module prevented users from creating new accounts in the chart of accounts. The issue stemmed from a mismatch in how Odoo handles method calls through RPC, specifically regarding the required arguments for the 'create' method. This fix ensures proper account creation functionality is restored.
Original PR description
Currently, if you install the Mexican localization, you are no longer able to create a new account in the chart of accounts. ### Steps to reproduce * install `l10n_mx` * attempt to create a new…
Currently, if you install the Mexican localization, you are no longer able to create a new account in the chart of accounts. ### Steps to reproduce * install `l10n_mx` * attempt to create a new account in the chart of accounts You should be met with a traceback: `TypeError: AccountAccount.create() missing 1 required positional argument: 'vals_list'` ### Cause The `@api.model` and `@api.model_create_multi` decorators in indicate that a method is intended to operate at the model level rather than on specific record instances. Without these decorators, the system defaults to treating methods as if they are meant to be executed on the record level. This distinction significantly impacts how methods are invoked through RPC. In RPC scenarios, Odoo's default expectation for record-level methods is that the RPC call will include the IDs of the records to which the method applies, alongside any actual method arguments necessary for the operation. Here, `create()` is called through RPC, as a model-level method (i.e, without record IDs). This makes sense because `create()` is always a model-level method. However, in our case, create is a record-level method, so the system expects the RPC call to contain record IDs. This mismatch produces a traceback. Issue introduced by 858bf9efdd9fcc29a73336863a51227c15cc19f0 opw-3772520 opw-3772469 opw-3772287 opw-3771854 opw-3771361 Forward-Port-Of: odoo/odoo#155848
This update corrects a bug where restricted users weren't consistently displaying branding on website pages due to a caching issue. The fix ensures that branding is correctly applied to all user types, regardless of their access level, improving the user experience. This resolves a discrepancy in how cached QWeb templates handled branding.
Original PR description
When QWeb templates became cached and compiled in [1], the list of default cache key elements did not contain `inherit_branding_auto` (but it included the old `inherit_branding`). Because of this the cache was shared between restricted editors and public users, which could lead to problems such as missing the branding on edited fields. Steps to reproduce: - Use a single browser instance and do not log any user out. - Start with `website_sale`. - Make "demo" user a restricted editor and a sales administrator. - Connect on 127.0.0.1 as "demo" and go to a product website page. - Go to 127.0.0.2 as a visitor and go to the same product page. => The product name field of the visitor page was branded. If you swap the last two steps, the "demo" user's page lacks the branding. [1]: https://github.com/odoo/odoo/commit/7ede9bcb2de9d52994b3a6fcb84edc3f81d60284 task-3482439 Forward-Port-Of: odoo/odoo#155264
This change reverts a recent update that restricted how taxes were managed in transactions, which was causing users to duplicate and modify taxes unnecessarily. By removing these restrictions, users can now easily adjust tax settings, and logging has been optimized to reduce unnecessary notifications.
Original PR description
Problem --------- Due to commit 8d77045b46a1b4a9d7fffd1111e53749d51d81e2, restrictions were added to taxes that were used in transactions. However, this behavior worsens user experience; users that…
Problem --------- Due to commit 8d77045b46a1b4a9d7fffd1111e53749d51d81e2, restrictions were added to taxes that were used in transactions. However, this behavior worsens user experience; users that would like to modify a tax would have to duplicate it, update the duplicated version and modify the tax usage where necessary. For such reason, this process is being reverted (we keep the tracking of the modification). The tracking of repartition lines now also includes the sequence of the lines since it is not restricted anymore. Furthermore, `_message_log_repartition_lines` has been updated to log messages when new repartition lines are added or repartition lines are removed. It also has been update to track changes of lines by comparing their position in the tax (rel. sequence) and not their IDs. Doing so allows to remove unnecessary logging when, for example, users remove a repartition line and immediately add a new one similar to the one deleted. It also allows to not log reordering event of two similar lines. original-commit: 8d77045b46a1b4a9d7fffd1111e53749d51d81e2 task-3450002 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155055
2 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.
10 changes
Resolved issues and error corrections
This fix resolves an issue where job applicants were unable to upload documents in the recruitment module. The problem was caused by an incorrect model configuration that prevented uploaded documents from being properly stored and displayed. With this fix, applicants can now successfully upload and manage their documents.
Original PR description
**Description of the issue/feature this PR addresses:** In the kanban view of all applicants within the recruitment module, an issue arises when applicants attempt to upload documents, this functionality is currently malfunctioning. --- **Current behavior before PR:** Document uploads by applicants are failing. --- **Desired behavior after PR is merged:** Applicants should be able to successfully upload documents. ___ **Fix:** The PR addresses the problem by modifying the default_res_model in the context. This adjustment is crucial as the current setting results in an incorrect model name, preventing the display of uploaded documents in this model. task-3579833 Forward-Port-Of: odoo/enterprise#57717 Forward-Port-Of: odoo/enterprise#52029
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
A recent update to journal options in account reports inadvertently caused journal groups to be incorrectly selected as individual journals. This fix ensures that only actual journals are selected, not journal groups, restoring the correct behavior for financial reporting.
Original PR description
In #25518, the journal options were reworked to better use journal groups and multi-company reports. However, this caused a regression where _get_options_journals would select journal groups as journals This change uses the 'model' key in the journal options to only select the 'account.journal' ids --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#56730
This fix resolves an issue where purchase orders and delivery quantities were being doubled when adding storable products to subscription upsells. The problem occurred because stock rules were being triggered twice—once from the parent subscription and once from the upsell. The fix ensures stock rules are only triggered from the upsell, preventing duplicate orders and quantities.
Original PR description
Steps to reproduce: - Create a storable product invoice on delivered qty MTO enabled - Create a subscription for a service product and invoice it - Create an upsell and add on it the storable product Bug: PO line and delivery quantities are doubled Fix: only trigger stock rules on the upsell not from the parent SO opw-3696134 Forward-Port-Of: odoo/enterprise#57590
This fix improves how non-UK companies using UK tax positions submit VAT reports to HMRC. The system now automatically handles foreign VAT numbers correctly and removes the need for users to manually strip the 'GB' or 'XI' prefix from VAT numbers before submission, making the process simpler and less error-prone.
Original PR description
This commit ensures that non-UK companies using a UK fiscal position are correctly handled, using the foreign VAT when connecting and sending reports to the HMRC. Additionally, the need to input the VAT without the 'GB' prefix has been eliminated by automatically stripping the prefix before sending. task-3765235 Forward-Port-Of: odoo/enterprise#57570
This update synchronizes the intrastat code lists with 2024 regulatory standards by adding new codes and removing outdated ones. The changes include setting effective dates for new codes and expiry dates for removed codes to ensure accurate international trade reporting and compliance with current regulations.
Original PR description
The annual changes to the intrastat code lists have occured. In order to synchronise with these new standards, we have to add the new codes, and remove the old ones. This commit adds the new codes in into the relevant csv. We also add expiry dates for the removed codes, and start dates for the new codes. In forward ports, these should be added directly on the account.intrastat.code.csv (since the modules account_intrastat and account_intrastat_expiry were merged after v15.0) One of the codes (50072060) has a supplementary unit, so we add that to the relevant dictionary, though in the forward ports this will be added directly in the data. task-id: 3747808 Forward-Port-Of: odoo/enterprise#57633 Forward-Port-Of: odoo/enterprise#57124
This update fixes a technical issue where video calls could experience problems if a channel was removed while the call was still loading. The fix prevents these timing conflicts, ensuring calls remain stable and don't encounter unexpected errors when channels are closed during the loading process.
Original PR description
Before this commit, there could be race conditions in which a channel could be removed while the call was still loading, this commit prevents this issue. task-3660964
This fix prevents the Point of Sale system from incorrectly creating expense entries when selling consumable products. Previously, when a consumable product was sold in a POS session without an invoice and the session was closed, an unwanted expense entry would be added to the accounting records. This fix ensures consumable products are properly excluded from cost of goods sold (COGS) calculations.
Original PR description
Steps to reproduce: - Open POS session - Sell a consumable product in POS (no invoice) - Close session Bug: an expense entry is added to the Account move opw-3705156
This update fixes an issue where product attributes with multiple selection options were not appearing in the product configurator popup when using Point of Sale on mobile devices. Customers can now properly select from all available product options when adding items to their order on mobile, improving the checkout experience.
Original PR description
Current behavior: When adding a product with a multi selection attribute, the attribute is not displayed in the product configurator popup. This only happens when opening it on a mobile device. Steps to reproduce: - Add a product with a multi selection attribute - Open PoS - Add the product to the order - The attribute is not shown on the product configurator popup opw-3711164 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where dropdown menus (like user menu and language selection) were not visible when clicking on them in website headers with the "Fixed" scroll effect. The fix ensures dropdowns appear properly by adjusting how the header behaves during scrolling and automatically scrolling to the top when users interact with dropdowns.
Original PR description
Since the commit [1], a new element called "o_header_hide_on_scroll" was introduced in some header templates. This element has the feature of gradually decreasing its height as you start scrolling…
Since the commit [1], a new element called "o_header_hide_on_scroll" was introduced in some header templates. This element has the feature of gradually decreasing its height as you start scrolling the page until it completely disappears. To reduce the height of this element without leaving its contents fully visible (because they maintain their height), we added an "overflow: hidden" property on it. However, this "overflow: hidden" introduced a bug fixed by this commit. Due to this, the dropdowns within the "o_header_hide_on_scroll" element, like "user menu" dropdown or "language selection" dropdown, became invisible. Steps to reproduce the bug: - Go to Website edit mode. - Click on the header. - Choose the "Menu - Sales 2" template from the options. - Select the "Fixed" Scroll Effect from the options. - Click on the "User Menu" dropdown in the header. - Bug: The dropdown menu does not appear. The same issue occurs if you type something in the search bar; the dropdown with the results does not appear either. To fix this, we don't apply "overflow: hidden" on the "o_header_hide_on_scroll" element when the page hasn't been scrolled yet. And if the page has been scrolled just a bit and the user clicks on a dropdown or the search bar, we scroll the page to the top first, and then display the dropdown menu. This commit also add a test tour to prevent the bug from reappearing. [1]: https://github.com/odoo/odoo/commit/143d475c3ab8d755906807bda8edb655c6dd22eb opw-3698887
This fix resolves an issue where QR codes were not appearing on automatically printed receipts at the point of sale. The problem occurred because the QR code image was being fetched after the receipt was already sent to the printer. The fix ensures the QR code image loads completely before printing, so customers receive complete receipts with the QR code included.
Original PR description
Prior to this commit, enabling auto receipt printing resulted in the QR code not being printed on the receipt. This was due to the QR image being fetched post printing. This commit addresses the issue by first loading the QR code image, then sending it to the printer, ensuring its presence on the printed receipt. opw-3763169 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr