Wednesday, October 23, 2024
17 changes · 17.0
Enhancements to existing features
Purchasing screens and reports now consistently use “Buyer” instead of the older “Purchase Representative” wording. This reduces confusion for users when filtering, searching, or reviewing purchase orders.
Original PR description
Since [1] the `user_id` represents the buyer, the string in the field was updated but not in the filter and the search which could be confusing. [1]: https://github.com/odoo/odoo/commit/470b7562 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The lead enrichment email template now displays its Twitter section correctly. This improves the appearance and professionalism of automated emails sent to users or customers.
Original PR description
Prior to this PR, the layout of the Twitter section in the email template was distorted (see reference image: https://tinyurl.com/29meoh6o). With this PR, the layout issue will be fixed to ensure it displays correctly. Task-4210376
Miscellaneous changes
This commit adds a constraint on the availability_condition, checking that if the availability_condition is set to country, the field country_id is set. task-4160643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182509
Original PR description
This commit adds a constraint on the availability_condition, checking that if the availability_condition is set to country, the field country_id is set. task-4160643 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182509
This fixes an error that could appear when users navigated back from a linked record in the stock forecast report after opening it from a purchase order. The report now keeps the correct record type information, preventing a traceback and allowing users to continue their workflow smoothly.
Original PR description
**Current behavior:** Opening a purchase order, clicking on the forecast report for a product in an orderline, then navigating to a "Used By" link, then clicking the back button in browser will…
**Current behavior:** Opening a purchase order, clicking on the forecast report for a product in an orderline, then navigating to a "Used By" link, then clicking the back button in browser will reusult in a traceback when MRP is installed. **Expected behavior:** No traceback. **Steps to reproduce:** *install mrp,purchase* *enable reception report in settings* 1. Open a purchase order with a product that is used in another order 2. Click on the forecast report on the order line 3. Click on a linked record in the "Used by" column in the report table 4. Click the browser back button -> traceback **Cause of the issue:** When trying to rebuild context, we get the actual model name provided by this.props.action.res_model. This was invariably treated as a stringified number in a read call to `ir.model` to try to get the model name -> result of the read is nonsense and when it is later used in an RPC, it tries to read fields from a nonexistent model. **Fix:** Get rid of the String -> Number conversion, directly use the value in `res_model` as the new `this.resModel`. opw-4181590
This update fixes an issue where renaming an IoT box could accidentally change its name to a generic default. The change makes the rename process more reliable by avoiding a temporary storage location that could fail when full, helping prevent device identification problems in point of sale setups.
Original PR description
Sometimes when renaming the IoT box, it would instead rename to `localhost.localdomain`. This was due to the script writing to the `/tmp` directory, which sometimes gets full and causes the `/etc/hostname` file to become empty. The fix is simply to bypass using the `/tmp` directory at all in the script. task-4210432 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change removes use of an outdated Python component from Odoo's HTTP handling so the system remains compatible with future Python versions. It does not change business workflows or user-facing behavior.
Original PR description
As part of the removing `Dead Batteries` pep 594, the usage of the `cgi` module is deprecated and it will be removed the standard library in python 3.13. See https://peps.python.org/pep-0594/#cgi Here the cgi module was used to parse the `Content-Type` of a response and separate the mime part from the parameters. But as the mime part was only used to verify the beginning of the string this separation is not nedeed. While at it, this commit removes the unused zlib import.
The dynamic placeholder menu now closes properly when users press Escape or click the close button after choosing a related field. This prevents a stuck interface and makes editing placeholders smoother and less confusing.
Original PR description
This commit fixes an issue where the dynamic placeholder popover would not fully close upon pressing escape or clicking on the cross when a relation field was selected. This is because its previous condition for changing state instead of closing was if it had some field path selected upon closing the model field selector popover. This would not handle well the case where a relation is selected before closing. The fix is therefore to specify inside calls to the close function of the model field selector popover whether it closed because a final value was selected or not. task-4066184
Company settings now only show trusted Points of Sale that belong to the currently selected company. This prevents users from accidentally selecting a Point of Sale from another company, improving data separation in multi-company setups.
Original PR description
Steps to reproduce: ------------------- * Make sure you have atleast 2 companies created * Create atleast one PoS in each company * Go in one of the company settings and look for Trusted Point of sale > Observation: You are able to select the PoS from the other company Why the fix: ------------ Adapt the domain to filter out PoS that are not part of the current company opw-4161351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix improves how IoT devices detect whether a display is connected, while keeping compatibility with older device images. It helps avoid starting unnecessary browser sessions when no screen is plugged in, reducing wasted resources and potential confusion.
Original PR description
In this PR: [https://github.com/odoo/odoo/pull/169633](https://github.com/odoo/odoo/pull/169633) We updated the method to detect displays to use a safer and better maintained lib. For older images (<24.08), that don't have this lib, we chose to create a display anyway as a fallback in case people had one. We now use the old method as a fallback of the new one to avoid creating a display and starting a browser instance if no screen is plugged in.
This update ensures that the country setting is correctly applied within account reporting filters. Previously, a constraint was added that required the country ID to be set when using the 'country' availability condition. This change prioritizes setting the country before the availability condition, ensuring accurate reporting results.
Original PR description
In odoo/odoo#182509, a constraint on the availability_condition was added, where if availability_condition is set to country, the country_id should be set. Therefore, in tests where the availability condition is set to country, the country should be set before. task-4160643
This update fixes an issue where a distracting notification appeared when adding tags to the sign document. It also addressed a problem with the field size increasing with multiple tags, now maintaining a consistent size. This enhancement provides a cleaner and more user-friendly experience for signing documents.
Original PR description
**Version:** - 17.0 **Current Behaviour:** - Whenever tags were added to the document, the saved notification would appear, which looked odd. - Adding multiple tags caused the field size to increase, which was inappropriate. **Updated Behaviour:** - The saved notification will only appear when exiting the document. - A CSS class has been added to maintain a fixed size when adding multiple tags. task-4164151
This update fixes a confusing error message related to timesheet lock dates. Previously, the message used a fixed date format, causing confusion for users with different language settings. Now, the message dynamically adapts to the user's preferred date format, ensuring clarity and consistency.
Original PR description
Before this commit: The lock date error message was hard-coded to the MM/DD/YYYY format, regardless of the user's language, which causing inconsistency and confusion in date format. After this commit: The lock date error message now dynamically follows the date format set to the user's language, which improve consistency and reduce confusion. task-3925185 Forward-Port-Of: odoo/enterprise#70405
This update enhances the account synchronization process by allowing users to reauthorize only the specific accounts needed for their journals. Previously, the system incorrectly triggered full reauthorizations, leading to inefficiencies. This fix ensures accurate and streamlined transaction updates.
Original PR description
We solve 2 issues: The first is that we want the user to be able to only reauthorize the actual account that he needs for the journal (and not all of them). The second is that the automatic redirection to reauthorize wasn't working due to the way Odoofin sends the infos. Now, it's sent in the result. task-4216399
This update corrects typographical mistakes found in the planning module, specifically fixing errors in field labels and text strings related to task assignments. These corrections improve the accuracy and professionalism of the user interface.
Original PR description
**Before this commit:** The `date_assign` field string contained a minor typographical error in the `project.task` **Group By**. **After this commit:** The typographical error in the 'Group by' has been corrected. Additional issues related to 'assignment' in the codebase were also addressed by fixing the `date_assign` field string. community: https://github.com/odoo/odoo/pull/183760
**Steps to reproduce:** - Install l10n_sa_edi_pos - Switch to a Saudi Arabian company (e.g. SA Company) - Create a user with admin rights for Invoicing, but no right for POS and Inventory - Connect with that user - Create an invoice for an Individual contact - Click on "Send & Print" **Issue:** A traceback is raised because the system tries to access some POS orders to get the payment means code, but the user hasn't the rights for that. opw-4192948 --- I confirm I have sig
Original PR description
**Steps to reproduce:** - Install l10n_sa_edi_pos - Switch to a Saudi Arabian company (e.g. SA Company) - Create a user with admin rights for Invoicing, but no right for POS and Inventory - Connect with that user - Create an invoice for an Individual contact - Click on "Send & Print" **Issue:** A traceback is raised because the system tries to access some POS orders to get the payment means code, but the user hasn't the rights for that. opw-4192948 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184342
How to reproduce: - Create a product P, storable, uom=Units - Create Receipt for 12 units of P, Confirm - Change the operation line from 12 Units to 1 Dozen - Validate Receipt => Valuation layer for 12 Units created (OK) - Unlock Receipt - Change the operation line from 1 to 2 Dozens - Save Receipt => Valuation layer for 1 Unit created (Should be 12) OPW-4204420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#1825
Original PR description
How to reproduce: - Create a product P, storable, uom=Units - Create Receipt for 12 units of P, Confirm - Change the operation line from 12 Units to 1 Dozen - Validate Receipt => Valuation layer for 12 Units created (OK) - Unlock Receipt - Change the operation line from 1 to 2 Dozens - Save Receipt => Valuation layer for 1 Unit created (Should be 12) OPW-4204420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182502
Context: The commit https://github.com/odoo/odoo/commit/eb2dd1d67464b75c0e480ebad95bc6cdb7372685 changed the order of the `server_type` selection to account for most used and/or most "logical" default protocol for mail fetching. But one might argue we should also have changed the defaul to "imap" so that new incoming severs actually pre-select the IMAP protocol. From experience, in real life use cases, 99% of the time we want IMAP for mail fetching because: * Only unread mails are fetche
Original PR description
Context: The commit https://github.com/odoo/odoo/commit/eb2dd1d67464b75c0e480ebad95bc6cdb7372685 changed the order of the `server_type` selection to account for most used and/or most "logical"…
Context: The commit https://github.com/odoo/odoo/commit/eb2dd1d67464b75c0e480ebad95bc6cdb7372685 changed the order of the `server_type` selection to account for most used and/or most "logical" default protocol for mail fetching. But one might argue we should also have changed the defaul to "imap" so that new incoming severs actually pre-select the IMAP protocol. From experience, in real life use cases, 99% of the time we want IMAP for mail fetching because: * Only unread mails are fetched (no fetching of unnecessary emails) * Email are marked as read after processing and NOT deleted Drawbacks of POP protocol that most end users are not necessarily aware of: * After fetching emails are deleted on the fetched mail server, i.e. no hard copy of the original mail is kept which might be an issue if a bug in Odoo fetches the mail "correctly" (routing succeeded), but a downstream bug creates side effects (attachments deleted, wrong record creted) * Since POP will try to fetch ALL mails in the inbox, if the customer (un)purposely hoards Odoo unrelated emails, these will be always fetched but never routed -> time spend for nothing routing, logs are spammed and percieved delay for fetching new emails (since older ones are processed for nothing over and over again) Proposed solution: Change `default` parameter to `imap` argument. Will not change old records ad-hoc, but preset new incoming email servers. User is free to still change the server type if they feel the need to use the POP protocol. Recent support tickets with related issues: OPW-4206157 OPW-4229682 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183712