Monday, March 18, 2024
17 changes · 17.0
Resolved issues and error corrections
Users reading Knowledge articles are now redirected back to the article they were viewing after signing in, instead of being sent to the backend or dashboard. This prevents users from losing track of the content they were reading and improves the overall experience when accessing Knowledge articles that require authentication.
Original PR description
When a user reads an article from the frontend view of Knowledge and clicks on the "Sign in" button to sign in: internal users will be redirected to the Odoo backend while portal users will be redirected to the `/my` page. The current redirection process is confusing because users may lose track of the article they were reading. If people re-open Knowledge after being redirected, they may no find the article they were reading as it could be hidden in the sidebar. When people click on the "Sign in" button from Knowledge, we assume that they probably wanted to edit the article, change the permissions, add new members, access their own workspace, etc. So, we will now redirect the user to the article they were reading after they sign in. With that change, portal users can still access the '/my' page from Knowledge by clicking on the home icon of the sidebar and internal users can view all apps of the backend by clicking on the home button of the Odoo navbar. task-3776350
Fixed a formatting issue in US check printing where complete address information would overlap with the check memo when using the TOP print format. The address font size has been reduced to prevent this overlap and ensure checks print correctly with full address details.
Original PR description
## Issue: - If a Contact record has a complete Address record (Street 1, Street 2, City, State, Zip, and Country) and the Check Print Format is set to TOP then the Address and the check memo overlap (see screenshot). ## Steps To Reproduce: - Create a contact with a long name and long address. - Be in a company set up under l10n_us. - Set your check printing to be Print Check (Top) - US. - Issue a Vendor Payment to the contact - Add a memo and print check. - The address overlaps the reference ## Solution: - Adjust the font size of the address to make it slightly smaller, thereby avoiding overlap. opw-3735486
This fix resolves an issue where manually adjusted discounts on sales orders were being overwritten by pricelist discounts during confirmation. The problem occurred because a recent change to handle subscription states was triggering an unintended recalculation of discount fields. The fix ensures discount protection is applied before subscription state modifications are made.
Original PR description
Versions -------- - saas-16.4+ Steps ----- 1. Create a pricelist wich shows discounts; 2. create a SO using this pricelist; 3. add a non-subscription-based product; 4. modify its discount; 5. confirm the SO. Issue ----- The manually modified discount gets overwritten by the pricelist one. Cause ----- Commit 71f15a9af4063bfb960b4706c3f237e69dd28e16 started protecting the discount field in `action_confirm` to protect it from recomputation when a start date would be added. This was adequate for earlier versions, but commit 4ac62c700826ce1b38307641f91b7c9ce4f91d54 added a line setting `subscription_state` to `False` for any SO that isn't an upsell or subscription. As this field is also a dependent of `_compute_subscription`, a recompute is triggered. Solution -------- Move the `with self.env.protecting` clause up, before the for-loop which modifies `subscription_state`. opw-3646915 Forward-Port-Of: odoo/enterprise#58437
This update improves the performance of the Brazilian EDI module by fixing how certain features are calculated and displayed. The changes separate visibility logic from email field processing and remove unnecessary system triggers, resulting in faster and more efficient document handling without affecting user-facing functionality.
Original PR description
- Whether the option is visible or not shouldn't depend on the `mail_extra_fields` compute. Use a separate compute to avoid useless processing. - Wrong moves used in the warning computation. - Remove useless trigger in `api.depends` to avoid unecessary computations.
This fix corrects how the "CFDI to Public" status is calculated when a point-of-sale order is converted to an invoice in Mexico. Previously, the system incorrectly marked invoices as public (using a generic RFC) even when a customer provided their actual tax ID. Now the system properly recalculates this field based on the customer's actual information, ensuring invoices are submitted to Mexican tax authorities with the correct customer details.
Original PR description
How to reproduce: - in point of sale, enable "Generate a code on ticket" - create a pos_order, save the ticket - using the code on the ticket, request an invoice through the portal and fill the information as if you were a mexican company => An invoice is generated and sent successfully to the SAT, but "CFDI to Public" is True on the invoice. Hence, the receptor's RFC will be "XAXX..." instead of the RFC filled in the portal. Reason: The pos_order has "CFDI to Public" to True, and this value is copied on the invoice. Fix: Recompute the value for the "CFDI to Public" field on the pos_order when the partner_id is filled. It should only be True when the Receptor's RFC is "XAXX...". Note that the new compute for "CFDI to Public" on the pos_order now resembles the one on the account_move. opw-3767576
This update corrects the positioning of the message that appears when marking timesheets as billable or non-billable in project tasks. The message was appearing in the wrong location due to an imprecise technical selector, which has now been fixed to display correctly.
Original PR description
Versions: --------- - 17.0 Issue: ------ Message for flag timesheet from project as billable/non-billable is misplaced. Cause: ------ Xpath given for Message placed in sale_timsheet is not very specific. Solution: --------- Give accurate xpath for message div. task-3630449
This update corrects the display order of company identification numbers in Czech Republic reports to match local standards. The Company ID (IČO) now appears before the VAT ID (DIČ), and the label has been clarified to "Company ID" for better clarity. This is a minor formatting adjustment to report templates with no impact on system functionality.
Original PR description
In Czech republic, the standard is to first render Company ID (IČO), and then to render VAT ID (DIČ). What I did in this commit is: - changing the position to before (not after), so company ID renders before VAT ID - I changed a label from ID to Company ID (so it is obvious in what ID it is) - This should not cause any harm, as we are just doing tiny changes in a view, not changing any logic. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects the display order of company identification fields on Czech invoices to comply with local standards. The Company ID (IČO) now appears before the VAT ID (DIČ), and the label has been clarified to "Company ID" for better clarity. This is a minor formatting adjustment to the invoice report template with no impact on business logic or data.
Original PR description
In Czech republic, the standard is to first render Company ID (IČO), and then to render VAT ID (DIČ). What I did in this commit is: changing the position to before (not after), so company ID renders before VAT ID I changed a label from ID to Company ID (so it is obvious in what ID it is) This should not cause any harm, as we are just doing tiny changes in a view, not changing any logic. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix removes the automatic activation of the US tipping feature for all new Point of Sale systems. Previously, new customers outside the US were getting the tipping option enabled by default, which was not appropriate for their business needs. Now, the tipping feature will only be enabled when explicitly configured for the customer's country.
Original PR description
In SaaS, the DB is pre-prepared with the generic chart of accounts before the new user finishes the form. Since the default country of the generic chart of accounts is the US, then `set_tip_after_payment` option in the pre-created pos.config is set to True. Now, when the form is submitted, the country is identified but the said option remains to be True. This is a problem because not all customers are creating an odoo instance for a US company. So customers from other countries will have the option activated by default which is not a good default for them. We introduced this behavior in aa1c5b53bf131c6df96ad621e00bd2ee3d44c6c0 and in this commit we won't set the option by default anymore.
This fix resolves an error that occurred when users tried to preview email marketing templates on mobile devices while in debug mode. The preview feature was not functioning properly due to a recent code change, preventing users from seeing how their emails would appear on mobile devices before sending.
Original PR description
Current behavior: --- When trying to preview a mailing template with the debug mode enabled, there is an error: Invalid props for component Steps to reproduce: --- 1. Enable debug mode with assets 2. Go to Email Marketing 3. Create a new Mailing 4. Select a template 5. In the Editor, click on the mobile icon 6. ... 'preview' is not a function Cause of the issue: --- Caused by https://github.com/odoo/odoo/commit/13b3f8af4b55d32912b698ae1672be9e144cb775 opw-3702901 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that when creating projects, the system now correctly uses the analytic plan selected in the Project settings rather than ignoring that choice. Previously, projects would always use a default plan even after administrators changed the setting to a different plan option like Departments instead of Projects.
Original PR description
Currently, the `plan_id` used to create analytic accounts is not the one set in the settings. Steps to reproduce: ------------------- * Go to the **Settings** * Enable developper mode * Select **User…
Currently, the `plan_id` used to create analytic accounts is not the one set in the settings. Steps to reproduce: ------------------- * Go to the **Settings** * Enable developper mode * Select **User & Companies** > **Groups** * Select `Technical/Analytic Accounting` * Add user * Go to the **Project** app * Select **Configuration** > **Settings** * Under **Time Management**, enable Timesheets * Under **Analytics** > **Analytic Plan**, select Projects * Create a new project * Go into the settings of the project * Under the **Settings** tab, select the internal link for the **Analytic Account** > **Observation**: The Plan is set to Projects * Go to **Conffiguration** > **Settings** * Under **Analytics** > **Analytic Plan**, change Projects to Departments * Create a new project * Go into the settings of the project * Under the **Settings** tab, select the internal link for the **Analytic Account** > **Observation**: The Plan is still set to Projects Why the fix: ------------ When creating, an analytic account, the plan is computed with `_get_all_plans()`. https://github.com/odoo/odoo/blob/e365e22485dc45f1cbe87ae93395b022a4724a3c/addons/project/models/project_project.py#L894-L903 Inside `__get_all_plans()` the plan is computed as follows: https://github.com/odoo/odoo/blob/e365e22485dc45f1cbe87ae93395b022a4724a3c/addons/analytic/models/analytic_plan.py#L106-L107 However, the setting that the user changes in the frontend corresponds to `analytic.analytic_plan_projects`. https://github.com/odoo/odoo/blob/e365e22485dc45f1cbe87ae93395b022a4724a3c/addons/project/models/res_config_settings.py#L18-L22 This seeting is not company-related. It can be used on projects even if they have a `company_id` set to false. We fallback on `_get_all_plans()` if the user did not specifically choose a plan in the settings. opw-3751661
This update fixes a test that was failing intermittently due to timing issues. The test now properly waits for WebSocket connections to be fully established before checking results, ensuring more reliable testing and fewer false failures in our quality assurance process.
Original PR description
Before this commit, the `test_websocket_instances_weak_set` was sometimes failing. Indeed, this test doesn't wait for the connection to be fully established before making its assertions. This commit fixes this issue. fixes runbot-55037,55035 Forward-Port-Of: odoo/odoo#157433
This fix restores the ability to select "Dropship" as a delivery option when creating purchase orders and RFQs. The dropship feature was previously unavailable in the delivery dropdown due to a system update that wasn't reflected in the selection filters. This fix ensures users can properly configure dropship deliveries and specify which customer should receive the shipment.
Original PR description
**Current behavior:** When making a new RFQ, dropship is not an available selection for the 'Deliver To' option. **Expected behavior:** As on previous versions, you should 'dropship' should be selectable here which reveals a sub-selection to select the customer who should receive the shipment. **Steps to reproduce:** 1. Enable `Dropshipping` in Purchase settings as well as `Storage Locations` in Inventory settings 2. Create a new RFQ, observe that in the 'Deliver To' dropdown there is no way to select a dropship option **Cause of the issue:** Dropshipping was made into a discrete `stock.picking.type`.code and the domain that constrains the selection menu options was not updated to accomodate this change. **Fix:** Update the domain to show picking types that have the dropship code. opw-3764617 Forward-Port-Of: odoo/odoo#155529
Fixed an issue in the website editor where updating a button's label would cause any custom styling (font size, color, etc.) to be lost. The problem occurred because the system was incorrectly identifying text elements when updating labels. This fix ensures that custom styles are preserved when users edit button labels from the sidebar.
Original PR description
Issue: ====== When you update the link button label from the sidebar it loses its style. Steps to reproduce the issue: ============================= - Got to website editor - Insert a text block - Added a button in the text block and any label - Click on the button to edit it from the sidebar - Change font size or font color or any style you want - Update the label - The style is lost Origin of the issue: ==================== When updating the label, we search for the first child that has that text, but when we have `ZWS start` it will be considered as the first child and then we update the inner text of the `a` element so we loose the span of the text which has the custom styles. Solution: ========= We search for the first child which is not `ZWS` task-3721686 Forward-Port-Of: odoo/odoo#155038
Fixed a bug in the Newsletter Block snippet where users could encounter an error when configuring the "Thanks" message option with certain "On Success" settings. The fix hides the "Display Thanks Button" option when it's not applicable, preventing configuration errors and improving the user experience.
Original PR description
When configuring a Newsletter Block snippet to display a subscription form, the option to decide whether a message must be displayed is only available when "On Success" is set to "Show Message" through the button beside that option. Unfortunately, the general option for the "Thanks" message is not disabled for other "On Success" values, for which no outcome can display a message. Trying to combine these triggered an error. This commit fixes this problem by hiding the "Display Thanks Button" option when the "Form Subscription" template is selected. Steps to produce: - Install `website_mass_mailing`. - Drop a "Newsletter Block" snippet. - Change template to "Form Subscription". - Click on "Subscribe" button. - Change "On Success" to "Nothing". - Click on "Display Thanks Button". => An error was displayed. task-3748574 Forward-Port-Of: odoo/odoo#157517
This update fixes the display order of company identification numbers on Czech invoices to match local standards. Company ID (IČO) now appears before VAT ID (DIČ), and the label has been clarified from "ID" to "Company ID" for better clarity. This ensures invoices comply with Czech business practices.
Original PR description
In Czech republic, the standard is to first render Company ID (IČO), and then to render VAT ID (DIČ). - Changing the position to before (not after), so company ID renders before VAT ID. - Changed label from "ID" to "Company ID" (so it is obvious in what ID it is). Original fixes by @cunivca: odoo/odoo#149339, odoo/odoo#149340, merged into one. Related: https://github.com/odoo/odoo/commit/d0704a19de31e0251d343081ae6b3da9991a248e
This fix ensures that payment term notes appear in the customer portal preview, matching what customers see in the printed sales order. Previously, only the payment term name was shown in the preview while the full note was visible in the printed report, creating a confusing inconsistency.
Original PR description
Description: There is a discrepancy between the printed sale order report and the customer preview when it comes to displaying the Payment Terms. On the SO report, Odoo prints the 'note' field, whereas on the preview, Odoo only displays the 'name' field. Desired behavior after PR is merged: Customer preview now matches the printed report by displaying the payment_term.note field as well opw-3790997 Forward-Port-Of: odoo/odoo#157475