Friday, March 1, 2024
77 changes
21 changes
Resolved issues and error corrections
This update resolves an issue where SelectionFields within draggable kanban views couldn't be edited. The fix prevents a technical restriction that blocked the opening of the SelectionField's edit options. This ensures users can now correctly modify SelectionFields within the kanban interface, improving usability.
Original PR description
Before this commit, if a SelectionField was used in a kanban view alongside the HandleField (enabling re-sequencing, i.e. drag&drop), the "select" element couldn't be edited. This is because the d&d feature calls preventDefault on almost all "pointerdown" events occuring in the card, and the "pointerdown" event is the one that opens the select. There's no usecase in 17.0, but there's one in master, in the product document kanban view. We fix this in 17.0 which is the version that introduced the kanban version of the SelectionField. 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#155827
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 simplifies the process of generating UBL invoices by removing a redundant check for the 'Bronnoysund' field. Previously, a constraint ensured this field was populated, but now that 'peppol_endpoint' and 'peppol_eas' fields are used, this check is no longer needed. This streamlines the system and improves efficiency.
Original PR description
In saas-16.2, the `peppol_endpoint` and `peppol_eas` fields were added on the partner. These fields are used to fill the `<cbc:EndpointID` node. Before that, we had to map every localization specific field to this node. For instance, with the norvegian "Bronnoysund" field (see: [1]). To ensure the node was filled, a constraint was checking the existence of this field. Now that we have the `peppol_endpoint` and `peppol_eas`, we no longer have to require the bronnoysund to be filled. [1] https://github.com/odoo/odoo/blob/saas-16.1/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_bis3.py#L119 opw-3763725 Forward-Port-Of: odoo/odoo#155604
This update resolves an issue where the Contact widget on Odoo.com would crash when a partner's display name was blank. Approximately 3,000 partners had a null display name, causing this error. This fix ensures the widget functions correctly even with missing display name data.
Original PR description
In case where display_name is null, the widget contact crash - AttributeError: 'bool' object has no attribute 'split' On odoo.com we have around 3K of partners that have name with null value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155735
This update fixes an issue where employees with flexible hours and removed calendars displayed 0 remaining holiday leave on their dashboards. The change prioritizes the employee's contract calendar to ensure accurate leave balances are shown, improving the employee experience and reporting accuracy.
Original PR description
Steps to reproduce the issue: - have an employee with an allocation with an end date - remove the employee's calendar - go on his dashboard - his remaining leaves amount is 0 This commit implements a new method on the resource mixin to fetch a calendar for the record even though it might not have one. The default behaviour is to fall back on the company's calendar to ensure a value. This is overrided in the `hr_contract` module so that the calendar of the contract is prioritized. task-3609738 Forward-Port-Of: odoo/odoo#155753 Forward-Port-Of: odoo/odoo#144418
This update fixes a visual issue where the 'Apply' button in the daterange picker appeared flattened and misaligned. The change centers the button vertically and adds a 'close' button, mirroring the behavior of pressing ESC or clicking outside the picker, for a more polished user experience.
Original PR description
Current behaviour - when we access the daterange picker, it was observed that the `apply` button appeared flatter and was not vertically centered. Expected behaviour - add h-100 on buttons container to ensure they are vertically centered and no longer appear flatter - add cancel button in which action is similar to pressing ESC or clicking outside the popover Task-3624556 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#148812
This update streamlines how the Odoo website identifies event booths. Previously, the system repeatedly checked for booth existence, which was inefficient. Now, the website automatically discovers booths through crawling, ensuring accurate event listings without unnecessary manual checks.
Original PR description
If booth exists for this event, bot will discover it via crawling. Don't need to ask to crawler to check for each event if a booth exists. 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#156022
This update fixes a layout issue in the Point of Sale interface that occurred after printing receipts. Previously, the receipt's placement caused scrolling, but this change uses a 'fixed' positioning to prevent overflow and maintain a clean, non-scrollable POS experience for users.
Original PR description
Before this commit, the POS receipt was added to the bottom of the page after printing. In some browsers, this caused overflow and made the POS interface scrollable. With this commit, we fix this issue by changing the position of the receipt container to 'fixed'. This prevents the receipt from affecting the layout of the page after printing, thus avoiding the overflow issue and keeping the POS interface non-scrollable. opw-3775808 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156025
This update resolves an issue where selling consumable products through Point of Sale (POS) automatically generated an unnecessary expense entry in the accounting system. The fix ensures that consumable products are no longer tracked for Cost of Goods Sold (COGS), streamlining the accounting process and improving accuracy. This change was made to address a reported bug and improve the overall POS experience.
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 Forward-Port-Of: odoo/odoo#153657
This update resolves a problem where adding new tabs within a 'Tabs' block in website pages would create a disorganized and confusing layout. The fix restricts tab selectors to only the parent tab, ensuring a cleaner and more predictable clone experience. This improves the overall usability of our website templates.
Original PR description
Commit [1] refactored the tabs snippets options, in doing so, it introduced a selector which could also target a tabs snippet from within its own tab. This leads to very weird behaviour on clone.…
Commit [1] refactored the tabs snippets options, in doing so, it introduced a selector which could also target a tabs snippet from within its own tab. This leads to very weird behaviour on clone. Commit [2] introduced a new MultipleItems abstract option, and with it, added a selector which could cause the same issue as above. This commit fixes this by properly restricting the selectors to the direct children. Steps to reproduce: - Create a new web page - Add a "Tabs" block - Put some text in each tab in other to identify which text belongs to which tab - In the first tab, add a new "Tabs" block, so that you will have tabs and sub-tabs - Put some text in sub tabs in order to identify which text belongs to which sub tab - try to add a new tab in your main tab block => look at the beautiful mess it creates. [1]: https://github.com/odoo/odoo/commit/7572cc150d5469af92138533a024cffbd57d878e [2]: https://github.com/odoo/odoo/commit/ebfa28638b47a7be45b96d561bdf144c3487f366 opw-3730155 Forward-Port-Of: odoo/odoo#154695
This update fixes a technical issue related to how tax closing accounts are configured for Odoo's international localizations (l10n_xx). Previously, the port from version 16.2 didn't correctly implement the new requirement to define these accounts on the tax group level. This ensures accurate tax reporting across various countries.
Original PR description
Commit 14abe7acb11 (PR #123816) introduced default tax closing accounts for localizations that were so far missing them. However, the mechanism for specifying the default tax closing accounts changed in 16.2: they must now be specified on the tax groups. This was not correctly done in the fw-port, so we fix this in this commit. taskid: 3524378 Forward-Port-Of: odoo/odoo#155911 Forward-Port-Of: odoo/odoo#155074
This update ensures our cyclic inventory tests accurately reflect how Odoo handles annual inventory days, specifically considering leap years. Previously, the tests didn't account for the safeguards that automatically select the latest possible month day. This fix improves the reliability of our inventory testing process.
Original PR description
When a company's annual inventory day is selected which is higher than the number of days in that month, there are already safeguards in the feature to ensure the latest day possible for that month is selected. Unfortunately the related test forgot to take this into account for leap years, so this commit modifies it to test for this expected safeguard. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155841
This update addresses a minor issue in the automated testing of Odoo's email functionality. A temporary problem with how test steps were being handled was causing intermittent failures. The team has applied a standard fix to ensure the tests run reliably, though the original issue wasn't consistently reproducible.
Original PR description
Not a guaranteed fix (not reproducible 1500 attempts), but applying standard fix for `step` failing to use the new step helper. runbot-54560 Forward-Port-Of: odoo/odoo#155925
This update fixes an issue where the default selected value for form selection fields was not being saved after page updates. The change restores this functionality, ensuring users consistently see their preferred selections when editing website forms. This improves the user experience and data consistency.
Original PR description
Since the PR [1] changed the rendering engine of qweb, the default "selected" value set on selects field on the form snippet were lost once the page is saved. This commit builds upon the changes made in [this commit] by reinstating the default "selected" value. Steps to replicate: - Go to Website -> Edit. - Drop a Form snippet onto the page. - Click on the 'Company' field. - In Field > Type, opt for "Selection". - Choose option 3 from the options list to establish it as the default. - Save the modifications. Issue: The expected default value for the selection field is not retained after saving. [1]: https://github.com/odoo/odoo/pull/130467 [this commit]: https://github.com/odoo/odoo/commit/b42e9cc686e7d3ccf82cd091a5dc24028fff8a2b task-3767819 Forward-Port-Of: odoo/odoo#155838
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
This update fixes issues with how product categories are displayed in the Point of Sale system. Previously, long category names caused overlapping and incorrect ordering, especially when categories had multiple parent levels. This change ensures a cleaner and more organized category display for users.
Original PR description
Before this commit, there were issues with the display and ordering of categories. Long category names would overflow their containers and overlap with other categories. Additionally, the order of parent categories was incorrect when a selected category had many parents. This was due to the `getAllChildren` function not returning all children correctly, which in turn affected the display of the parent sequence. opw-3776740 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a recurring issue where tour scheduling tests were failing intermittently due to timing differences in the Odoo system. The fix adds a verification step to ensure the activity type input is fully loaded before proceeding, improving test reliability and preventing scheduling errors. This ensures tours are scheduled correctly.
Original PR description
Since PR #154105, `mail_activity_schedule_from_chatter` test was failing on some runbot builds. The problem is, the `timeout` to make sure the activity type input is ready (has its data) to click again, is not enough for all builds. Instead of using timeout (which is not same for different builds), we can add an extra step to check if the activity id input has its data after clicking on dropdown, to proceed to the next steps. fixes runbot-57738 Forward-Port-Of: odoo/odoo#156030
This update fixes a minor typo in the Belgian accounting module. The incorrect reference to the Office National de Sécurité Sociale (ONNS) has been corrected to the correct ONSS designation. This ensures accurate reporting for Belgian businesses using the Odoo accounting system.
Original PR description
Office National de Sécurité Sociale (ONNS) should be (ONSS). Forward-Port-Of: odoo/odoo#155828
A bug was causing an error when adding timesheet entries for certain users. This update corrects a technical issue related to how the employee selection field in the Timesheets module handles user permissions, ensuring correct functionality for all employees. This fix improves the user experience for all users.
Original PR description
Steps to reproduce ================== - Install Timesheets - Login as Admin - Edit the access rights of Mark Demo: * Timesheets: "User: all timesheets" * Employees: "None" - Logout and login as Demo…
Steps to reproduce ================== - Install Timesheets - Login as Admin - Edit the access rights of Mark Demo: * Timesheets: "User: all timesheets" * Employees: "None" - Logout and login as Demo - Go to a project task - Switch to the Timesheets notebook - Add a new line - Click on the employee field > Search More => An error occurred Cause of the issue ================== The hr.employee.public model is an SQL view of the hr.employee table with differents permissions. Since the user doesn't have the hr.group_hr_user group, the model hr.employee.public should be used and not hr.employee. Since [0], the model is switched depending on whether the user has the appropriate group. The EmployeeFieldRelationMixin is used and defines a getter for the relation. That relation was not propagated to the Many2OneField. Solution ======== Pass the relation to the many2OneProps. --- [0]: https://github.com/odoo/odoo/pull/136786 opw-3765393 Forward-Port-Of: odoo/odoo#155743
4 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
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 removes an incorrectly added country_code field from the Mexico EDI module that was accidentally included during a merge conflict resolution. The field should not have been present and its removal ensures the module functions as intended without unnecessary data duplication.
Original PR description
Erroneously added (https://github.com/odoo/enterprise/commit/0695afece962ad1c5d3dafc930b00c0e16d30b25) coutry_code field when reselving merge conflict. Forward-Port-Of: odoo/enterprise#57774
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