Tuesday, September 17, 2024
74 changes · master
Enhancements to existing features
The eLearning course dashboard layouts were simplified to use newer, standard Odoo interface patterns. This should make the screens easier to maintain and keep the user experience consistent, without introducing major functional changes.
Original PR description
In this commit we have simplified the kanban arch for the website_slides module dashboard. the goal is to simplify them, make them easier to read and use bootstrap utility classnames. - Previously, we used kanban-box, but now we are using kanban-card instead. - Deprecated oe_kanban_global_click and oe_kanban_global_click_edit. - More use of `<field/>` tags - Removed the oe_kanban_colorpicker class and replaced it with the kanban_color_picker widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - kanban_image from rendering context, is deprecated so we use `<field name=... widget=image/>` instead - kanban_color, kanban_getcolor and kanban_getcolorname are deprecated use new attribute highlight_color=color_field_name on root node Task-3992107 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The maintenance dashboard cards were cleaned up to use newer interface building blocks and clearer structure. This makes the dashboard easier to maintain while preserving the same day-to-day user experience.
Original PR description
In this commit we have simplified the kanban arch for the maintenance module dashboard. the goal is to simplify them, make them easier to read and use bootstrap utility classnames. - Previously, we used kanban-box, but now we are using kanban-card instead. - Deprecated oe_kanban_global_click and oe_kanban_global_click_edit. - More use of <field/> tags - Removed the oe_kanban_colorpicker class and replaced it with the kanban_color_picker widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - kanban_image from rendering context, is deprecated so we use <field name="..." widget="image"/> instead - kanban_color, kanban_getcolor and kanban_getcolorname are deprecated use new attribute highlight_color="color_field_name" on root node Task-3992107 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website-related kanban views have been simplified and updated to use newer standard building blocks. This makes these screens easier to maintain and keeps the user interface more consistent across website, sales, events, forum, eLearning, live chat, and SMS-related areas.
Original PR description
*website_blog,website_crm,website_event_exhibitor,website_event_track, website_forum,website_livechat,website_sale,website_slides,website_sms In this commit we have simplified the kanban arch for the…
The point of sale dashboard layout has been simplified to use newer, standard card styling. This makes the dashboard easier to maintain and helps keep the user interface consistent without changing core business workflows.
Original PR description
In this commit we have simplified the kanban arch for the point_of_sale module dashboard. the goal is to simplify them, make them easier to read and use bootstrap utility classnames. - Previously, we used kanban-box, but now we are using kanban-card instead. - Deprecated oe_kanban_global_click and oe_kanban_global_click_edit. - More use of `<field/>` tags - Removed the oe_kanban_colorpicker class and replaced it with the kanban_color_picker widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - kanban_image from rendering context, is deprecated so we use `<field name=... widget=image/>` instead - kanban_color, kanban_getcolor and kanban_getcolorname are deprecated use new attribute highlight_color=color_field_name on root node Task-3992107 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Spreadsheet files now have a generated file name when downloaded, making saved files easier to identify. This updates the spreadsheet dashboard naming behavior with a computed value for more consistent downloads.
Original PR description
This commit adds a computed field to download spreadsheet files. Note that it replaces the field `file_name` in model `spreadsheet.dashboard` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Manufacturing kanban cards were simplified to make them easier to maintain and align with current Odoo interface standards. This is a low-risk visual and technical cleanup that should preserve existing behavior while improving consistency in manufacturing screens and related main-flow tests.
Original PR description
In this commit we have simplified the kanban arch for the mrp module. The goal is to simplify them, make them easier to read, and use bootstrap utility classnames. - Previously, we used `kanban-box`, but now we are using `kanban-card` instead. - Deprecated `oe_kanban_global_click` and `oe_kanban_global_click_edit`. - More use of `<field/>` tags - Removed the `oe_kanban_colorpicker` class and replaced it with the `kanban_color_picker` widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - `kanban_image` from rendering context, is deprecated so we use `<field name=... widget=image/>` instead Task-3992107 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Spanish Facturae e-invoicing module now uses a dedicated report to determine invoice period boundaries more accurately. This helps ensure period dates are calculated from the actual report data, supporting more reliable electronic invoicing for Spanish localization needs.
Original PR description
With the period boundaries based on the report we need a report to compute the actual boundaries related: https://github.com/odoo/enterprise/pull/68551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Google Calendar synchronization now better detects when external credentials are provided. This helps show a more accurate sync status in the calendar header, reducing confusion for users and administrators.
Original PR description
This commit adds a boolean function that indicates if external credentials are being provided for the calendar synchronization. Adjustments on the synchronizations status in the calendar view's header were made to consider the external credentials presence (or absence). task-3864685
Accounting dashboard links for sales and purchase journals now open the main invoice and bill records instead of detailed journal lines. This makes navigation more consistent and gives users a clearer view of outstanding amounts when reviewing invoices or bills.
Original PR description
Before this commit, some links of the dashboard on sale and purchase journal were linked to account.move.line which was not consistent with the rest of the actions. We change that to target account.move instead. To do that we will use the same actions as when going on the tree view of invoices or bills. But in the context we will pass some new default_search and the 'show_amount_due' key to change the view so that we can have the column amount due is optional show. task: 4156150 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Breadcrumb tooltips now make it clearer when an item leads to a form page, including collapsed breadcrumb items. The underlying breadcrumb loading behavior was also standardized, improving reliability for future navigation enhancements without changing the user workflow.
Original PR description
This commit adds the 'form' suffix in tooltips displayed when hovering breadcrumb entries related to form views. Note that this commit also adds a tooltip on collapsed breadcrumb items. task-id: 4070508 ---------- [REF] web: uniformize load_breadcrumbs API This commit corrects the `load_breadcrumb` controller API. Before this commit, the controller returned an array containing strings (the display_name if it was found) and/or objects when errors occurred. Now the controller always returns an array of objects, with keys "display_name" or "error". This commit also opens the door for future improvements of the API without breaking the retro-compatibility.
The Mail app's notification settings screen was simplified by moving a small template directly into the related code file. This reduces unnecessary maintenance overhead without changing what users see or how the feature works.
Original PR description
This PR removes the discuss_notification_settings_client_action.xml file. This template is simple enough to be embedded in the javascript file, avoiding xml boilerplate.
Spreadsheet chart data sources now get a placeholder name when the chart title is left blank. This prevents empty labels and makes chart-related data easier to identify for users.
Original PR description
Currently, we will use the chart title to generate the related datasource display name. However, if we decide to empty the chart title, then the datasource display name will be empty as well. This revision adds a placeholder to be used in those cases. task-4187464 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
The timesheet timer start and stop buttons now regain focus when appropriate, making keyboard actions more reliable. This helps users and guided onboarding flows start or stop timers consistently without disrupting typing in input fields.
Original PR description
Before this commit when we try to get the focus off the start button and stop button and tried pressing ENTER key to start or stop the timer. It works fine as it is handled by onClick.But all key press are not taken into consideration(key strokes recorded in input or text-area fields). During the step in onboarding tour of using Stop Button we are out of focus of stop_timer button as we have clicked on input field before this step. In tour every button has events both click and Enter but the target must the source of the element(given in tour trigger). After this commit the start and stop button will be in focus when no modal is displayed or the element focused is not an input and textarea. task-3997245
The rental ecommerce product editing screen now uses the updated “tags” wording instead of the older “shop” label. This keeps the rental workflow aligned with the broader website sales interface, reducing confusion for staff managing online rental products.
Original PR description
task-4011651
The timesheet Kanban view no longer shows the status field on each card. This simplifies the display so users can scan timesheet entries more easily without extra visual clutter.
Original PR description
After this commit: - remove the status from kanban view of timesheets task-3996705 COM PR: odoo/odoo#170251
Barcode batch transfer cards now show the description field, giving warehouse teams more context directly in the kanban view. This helps users identify and prioritize batch or wave transfers without opening each record.
Original PR description
The description field added in odoo/odoo#157869 is added to the barcode batch transfers kanban view. Task-3724421
The social app and related social channel integrations now use simpler, more consistent kanban card layouts. This makes the underlying screens easier to maintain while preserving the same day-to-day user experience.
Original PR description
\* = [social_facebook, social_crm, social_instagram, social_sale, social_twitter, social_youtube] In this commit we have simplified the kanban arch for the social and its related modules. The goal is to simplify them, make them easier to read, and use bootstrap utility classnames. - Previously, we used `kanban-box`, but now we are using `kanban-card` instead. - Deprecated `oe_kanban_global_click` and `oe_kanban_global_click_edit`. - More use of `<field/>` tags - Removed the `oe_kanban_colorpicker` class and replaced it with the `kanban_color_picker` widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - `kanban_image` from rendering context, is deprecated so we use `<field name=... widget=image/>` instead Task-3992107
The manufacturing maintenance kanban views were cleaned up to use newer layout standards and simpler building blocks. This makes the screens easier to maintain while preserving the existing user experience for maintenance teams.
Original PR description
In this commit we have simplified the kanban arch for the mrp_maintenance module. The goal is to simplify them, make them easier to read, and use bootstrap utility classnames. - Previously, we used `kanban-box`, but now we are using `kanban-card` instead. - Deprecated `oe_kanban_global_click` and `oe_kanban_global_click_edit`. - More use of `<field/>` tags - Removed the `oe_kanban_colorpicker` class and replaced it with the `kanban_color_picker` widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - `kanban_image` from rendering context, is deprecated so we use `<field name=... widget=image/>` instead Task-3992107
The push notification visitor views were simplified to use newer, standard kanban layout patterns. This makes the screens easier to maintain and helps keep the user interface consistent with current Odoo behavior.
Original PR description
In this commit we have simplified the kanban arch for the website and their related modules.the goal is to simplify them, make them easier to read and use bootstrap utility classnames. - Previously, we used kanban-box, but now we are using kanban-card instead. - Deprecated oe_kanban_global_click and oe_kanban_global_click_edit. - More use of `<field/>` tags - Removed the oe_kanban_colorpicker class and replaced it with the kanban_color_picker widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - kanban_image from rendering context, is deprecated so we use <field name="..." widget="image"/> instead - kanban_color, kanban_getcolor and kanban_getcolorname are deprecated use new attribute highlight_color="color_field_name" on root node Task-3992107
The German point-of-sale certification dashboard has been cleaned up to use newer interface building blocks. This makes the screen easier to maintain and helps keep the dashboard aligned with current Odoo design standards, with little expected change for day-to-day users.
Original PR description
In this commit we have simplified the kanban arch for the point_of_sale module dashboard. the goal is to simplify them, make them easier to read and use bootstrap utility classnames. - Previously, we used kanban-box, but now we are using kanban-card instead. - Deprecated oe_kanban_global_click and oe_kanban_global_click_edit. - More use of `<field/>` tags - Removed the oe_kanban_colorpicker class and replaced it with the kanban_color_picker widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - kanban_image from rendering context, is deprecated so we use `<field name=... widget=image/>` instead - kanban_color, kanban_getcolor and kanban_getcolorname are deprecated use new attribute highlight_color=color_field_name on root node Task-3992107
The Frontdesk dashboard layout was simplified to use newer, standard interface building blocks. This should make the dashboard easier to maintain while keeping the user experience consistent with modern Odoo behavior.
Original PR description
In this commit we have simplified the kanban arch for the frontedsk module dashboard. The goal is to simplify them, make them easier to read and use bootstrap utility classnames. - Previously, we used kanban-box, but now we are using kanban-card instead. - Deprecated oe_kanban_global_click and oe_kanban_global_click_edit. - More use of <field/> tags - Removed the oe_kanban_colorpicker class and replaced it with the kanban_color_picker widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - kanban_image from rendering context, is deprecated so we use <field name=... widget=image/> instead - kanban_color, kanban_getcolor and kanban_getcolorname are deprecated use new attribute highlight_color=color_field_name on root node Task-3992107
Asset records now use one shared company fiscal country field instead of separate versions for Indian and Romanian reporting. This reduces duplication and makes the information available consistently for other local reporting needs.
Resolved issues and error corrections
Point of Sale now clears the order screen status after payment when automatic receipt printing is enabled. This prevents orders from appearing in the wrong state, helping cashier workflows continue smoothly after checkout.
Original PR description
When automatic receipt printing is set, the order screen_state wasn't correctly set. This commit fixes the issue by setting the screen_state to empty string after the payment is done.
Code cleanup and technical improvements
This change makes it easier for Odoo deployments to customize Microsoft API credentials used for account and calendar integrations. It supports more flexible configuration without changing the core integration behavior for end users.
Original PR description
This commit allows to override easily api credentials by defining a function to return the client_id (within 'microsoft.service') and a private python function to retrieve the client_secret. Inspired on odoo/odoo#95744. task-3864685
Miscellaneous changes
Some translations were missing in the DIN5008 modules. This commit updates the terms and completes missing translations. [opw-3961574](https://www.odoo.com/odoo/project.task/3961574?cids=1) Forward-Port-Of: odoo/odoo#179320 Forward-Port-Of: odoo/odoo#175360
Original PR description
Some translations were missing in the DIN5008 modules. This commit updates the terms and completes missing translations. [opw-3961574](https://www.odoo.com/odoo/project.task/3961574?cids=1) Forward-Port-Of: odoo/odoo#179320 Forward-Port-Of: odoo/odoo#175360
*website_blog,website_crm,website_event_exhibitor,website_event_track, website_forum,website_livechat,website_sale,website_slides,website_sms In this commit we have simplified the kanban arch for the website and their related modules.the goal is to simplify them, make them easier to read and use bootstrap utility classnames. - Previously, we used kanban-box, but now we are using kanban-card instead. - Deprecated oe_kanban_global_click and oe_kanban_global_click_edit. - More use of `<field/>` tags - Removed the oe_kanban_colorpicker class and replaced it with the kanban_color_picker widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - kanban_image from rendering context, is deprecated so we use `<field name="..." widget="image"/>` instead - kanban_color, kanban_getcolor and kanban_getcolorname are deprecated use new attribute highlight_color="color_field_name" on root node Task-3992107 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A failing automated test was corrected so it is properly skipped when the CRM app is not installed. This helps keep Odoo's validation pipeline reliable and prevents false errors during testing.
Original PR description
when crm is not installed, test_webjson_access_error_crm was supposed to skip a test, but was using skip instead of skipTest, which gave error. Now it's fixed. Runbot error https://runbot.odoo.com/web#id=75057&menu_id=424&action=573&model=runbot.build.error&view_type=form --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The project profitability panel now shows expected, billed, and to-bill cost values under the correct column headings. This helps users read project financial information accurately and avoid confusion when reviewing costs.
Original PR description
The current title and value of the expected/billed/to billed column are incorrect. This commit's purpose is to put the expected value under the expected title, the billed value under the billed value and the to billed value under the to billed value. task - 4179342 affected version: master 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
The point of sale order screen now shows the event ticket printing option only when an order actually includes event tickets. This reduces clutter and avoids confusing staff with an action that has nothing to print.
Original PR description
In pos order form view, the button for printing the event tickets for the events bought in the order is always shown. In this commit we make it visible only when there actually are tickets to print. Task: 4189185 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes overly long and noisy error messages produced by Odoo's internal record-checking test helper. The change makes test failures easier for developers to understand, helping teams diagnose issues faster without affecting end users.
Original PR description
odoo/odoo#178332 attempted to simplify `assertRecordValues` and clarify its messages, it failed quite significantly at the second one, fix that: - Reformat error diffs using udiff rather than the…
odoo/odoo#178332 attempted to simplify `assertRecordValues` and clarify its messages, it failed quite significantly at the second one, fix that: - Reformat error diffs using udiff rather than the default ndiff (which always displays the entire thing), ndiff provides either completely cutoff output (because it's very easy to get above maxDiff = 640 when comparing pprints of lists of dicts) or extremely large output as it always displays the entire thing, when comparing either lots of records or very large dicts this is unusable. Not quite sure how I missed that Python uses ndiff, I assume it's because a previous version did the diffing explicitly using udiff and I didn't validate it when I changed to straight `assertEqual`. `pytest` has the exact same behavior so it's not like I got confused with that. Add tests to check that the formatting is as intended (use large lists from account as basis). Note: for now only swap out cutoff diffs, if the caller sets `maxDiff = None` then assume they want the entire thing. - Don't decorate the `Approx` values inside `assertRecordValues`, that formats out as differences on every failure even when those values are irrelevant. This makes the diff unreadable as basically every float value (which has rounding applied but that's most of them, in accounting anyway) gets prefixed by `~` which shows up during the diff. There is still an edge case if the rounding was necessary to make values match, it might be a good idea to `round` the values based on the input information in that case if that turns out to be a common problem.
The Point of Sale mobile view now hides product categories when using the scan option. This keeps the screen cleaner and makes scanning products easier for staff on smaller devices.
Original PR description
Steps: - Open Point of Sale - Switch to mobile view - Click on the scan option in navbar. Issue: Product categories are visible. Fix: - For mobile view we have restrict showing categories for better user experience. task-4160847
The rental eCommerce pages were updated to stay aligned with recent website shop layout changes. This helps prevent display or configuration issues when rental products appear in the online shop.
Original PR description
Follow the changes made in community which introduced the `shop_grid_header` template. task-3986938 part of task-3986921 Community PR: https://github.com/odoo/odoo/pull/177034
This change prevents an error that appeared when activating test asset debugging with the Colombian electronic invoicing website sales module installed. It removes an unsupported setting so the debugging mode can be enabled normally, improving reliability for testing and development workflows.
Original PR description
version: ----------- - master Steps to reproduce: --------------------------- - Install module l10n_co_edi_website_sale - Enable debug mode. - Click on Activate tests assets debugging. Issue: --------- - A traceback occurs when activating test assets debugging. Cause: --------- - The error occurs because the system does not recognize the stepDelay key. Solution: ------------ - the fix is to remove the stepDelay key from the tour setup to prevent the error. task-3628329
This fix restores intended customizations on the point of sale login screen and receipt header by correcting where the system applies them. It helps ensure employees and customers see the right branded and operational information in affected point of sale flows.
Original PR description
The login screen overrides were not working as expected. This commit fixes the issue by updating the file paths. Also, override target wasn't set correctly. This commit fixes the override target for the receipt_header.xml file.
This change cleans up how the HTML editor restores text selections by removing an outdated internal flag. It helps ensure the editor correctly restores the default selection state, reducing the chance of small editing glitches for users.
Original PR description
In the odoo/odoo#179985 PR, we forgot to remove the concept of isDefault, which is no longer necessary thanks to canApplySelectionToDocument. We therefore forgot to set canApplySelectionToDocument to true during the restore when it was the default selection. 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
This update tidies how several Kanban cards display fields and images, aligning them with Odoo's newer, simpler view approach. It should not change business workflows, but helps keep screens consistent and easier to maintain over time.
Original PR description
*fleet,hr_holidays,mrp,purchase,stock,website Kanban archs are being converted to a simpler API [1]. This is a long process that requires rewritting/reviewing all kanban archs. This commit is a…
*fleet,hr_holidays,mrp,purchase,stock,website Kanban archs are being converted to a simpler API [1]. This is a long process that requires rewritting/reviewing all kanban archs. This commit is a followup of those simplications and aims at fixing some leftovers that have been forgotten/that we didn't see on review: - do not use t-esc to display a field, use the <field> tag instead (t-esc still works for now, but by convention and for the sake of consistency with the form view, we encourage using <field>) - t-att-alt on many2one fields with image widget is useless, the correct alt attribute is already generated by the widget. In particular: - some t-esc were done on datetime fields to not display the time, we can use a classic <field> with show_time option set to false - in website, t-esc was used because we manipulated the displayed string, but it didn't seem useful (couldn't see any change before/after). - t-att-alt and t-att-title removed from <field widget="image"/> as the first one is useless and the second doesn't work (and the name was displayed next to the image anyway). [1] task~3992107 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
Before this commit when opening a CRM Lead from the URL, the breadcrumb doesn't show the multi-record controller. This occurs, because the CRM action is a server action that returns a window action, and the lazy controller is never created. Now, the lazy controller is correctly created also for the server actions. Forward-Port-Of: odoo/odoo#180323 Forward-Port-Of: odoo/odoo#179916
Original PR description
Before this commit when opening a CRM Lead from the URL, the breadcrumb doesn't show the multi-record controller. This occurs, because the CRM action is a server action that returns a window action, and the lazy controller is never created. Now, the lazy controller is correctly created also for the server actions. Forward-Port-Of: odoo/odoo#180323 Forward-Port-Of: odoo/odoo#179916
Steps --- 1. install `mrp,sales_management` 2. Create a manufacture-routed product P with a manufacturing BOM: * Operation OP1, duration = 1 hr * some component 3. Create a reording rule for P with a manufacturing route: * min qty = 0 * max qty = 0 4. Create an SO for 15 > Confirm * (A MO for 15 P should have been generated) 6. duplicate the SO > Confirm * (The **same** MO is now for 30 P) 7. duplicate the SO > Confirm => The MO is for 75 P instead of 45 Cause
Original PR description
Steps --- 1. install `mrp,sales_management` 2. Create a manufacture-routed product P with a manufacturing BOM: * Operation OP1, duration = 1 hr * some component 3. Create a reording rule for P with a…
Steps --- 1. install `mrp,sales_management` 2. Create a manufacture-routed product P with a manufacturing BOM: * Operation OP1, duration = 1 hr * some component 3. Create a reording rule for P with a manufacturing route: * min qty = 0 * max qty = 0 4. Create an SO for 15 > Confirm * (A MO for 15 P should have been generated) 6. duplicate the SO > Confirm * (The **same** MO is now for 30 P) 7. duplicate the SO > Confirm => The MO is for 75 P instead of 45 Cause --- When the reordering rule is triggered, we attempt create a procurement for the opposite of the forecast quantity of product P and add it to the MO. But the reordering rule's visibility days is 0 (default), so once the MO's expected finished date (now + qty * 1 hr) is tomorrow or more [1] we do not consider the quantity coming from the MO for the stock forecast. Therefore the procurement is for the sum of all the previous orders for P (ie 15 * 3 = 45), so the MO's quantity will be 30 + 45 = 75 instead of 30 + 15 = 45 [1] (cf commit 1) There is another bug this PR fixes where the date finished for MOs is not computed at creation time but only at write time, therefore, we need to be at least on the 3rd SO for the bug to appear. (The 2nd one writes to the MO) Fix --- When computing the quantity in progress for product P, take into account MOs such that `date_start <= end_of_orderpoint_forecast < date_finished` \+ [1] Do compute the finished date at creation when it isn't specified in the vals and do not specify it in the above flow. opw-4034475 Forward-Port-Of: odoo/odoo#173842
Steps to reproduce =================== 1. Create a new lead in CRM with only an email address. 2. Send a message to the email through the chatter. -> The contact is created but it has no name. Issue ================= The issue was in _get_customer_information() for CRM. The function uses parse_contact_from_email which returns an empty name for a simple email. After this commit ================= Email will serve as a name for the contact created through the chatter in CRM. Task
Original PR description
Steps to reproduce =================== 1. Create a new lead in CRM with only an email address. 2. Send a message to the email through the chatter. -> The contact is created but it has no name. Issue ================= The issue was in _get_customer_information() for CRM. The function uses parse_contact_from_email which returns an empty name for a simple email. After this commit ================= Email will serve as a name for the contact created through the chatter in CRM. Task-4129454 Forward-Port-Of: odoo/odoo#178797
Steps --- * create a set-up with 2 companies using different currencies. eg: * company 1: usd * company 2: eur * from the company 2: set a conversion rate from eur to usd in *Currencies* * from company 1: create a based on rules shipping method (with prices in usd) * from company 2: * create an SO for some products * add the shipping method * => the price in dollars is used unconverted as the price in eur Cause --- when we have a base_on_rule delivery without a speci
Original PR description
Steps --- * create a set-up with 2 companies using different currencies. eg: * company 1: usd * company 2: eur * from the company 2: set a conversion rate from eur to usd in *Currencies* * from company 1: create a based on rules shipping method (with prices in usd) * from company 2: * create an SO for some products * add the shipping method * => the price in dollars is used unconverted as the price in eur Cause --- when we have a base_on_rule delivery without a specified company, we convert prices as if the price was in the current company's currency. Fix --- Consider the price to be in the main company's currency instead opw-4105047 Forward-Port-Of: odoo/odoo#180227 Forward-Port-Of: odoo/odoo#177932
If the IoT Box is in access point mode, it should mean that it has no internet connection. Thus, we avoid returning the linked db url to avoid fetching it. We used to check the access point mode with a `subprocess` call to `hostapd` service. We now check the IP, as it is set to `10.11.12.1` when in AP mode. Task: 4182947 Forward-Port-Of: odoo/odoo#180159
Original PR description
If the IoT Box is in access point mode, it should mean that it has no internet connection. Thus, we avoid returning the linked db url to avoid fetching it. We used to check the access point mode with a `subprocess` call to `hostapd` service. We now check the IP, as it is set to `10.11.12.1` when in AP mode. Task: 4182947 Forward-Port-Of: odoo/odoo#180159
Before this commit, due to some changes in #153989, the project field is no longer displayed in the search view displayed in the modal displayed when the user would like to add a task as blocking task. This commit reverts the invisible condition added on that field in the search since that change was not really needed for project sharing since project sharing feature does not really use that search view. Steps to reproduce: ================== 1. Install project 2. Enable `Task depende
Original PR description
Before this commit, due to some changes in #153989, the project field is no longer displayed in the search view displayed in the modal displayed when the user would like to add a task as blocking…
Before this commit, due to some changes in #153989, the project field is no longer displayed in the search view displayed in the modal displayed when the user would like to add a task as blocking task. This commit reverts the invisible condition added on that field in the search since that change was not really needed for project sharing since project sharing feature does not really use that search view. Steps to reproduce: ================== 1. Install project 2. Enable `Task dependencies` feature in Settings > Configuration of project app. 3. Create a project with `Task dependencies` feature enabled. 4. Add a new task in that project and click on `Add a line` in `Blocked By` tab inside the form view. 5. Search another project inside the search by taping the name of another project. Current behavior ---------------- The project field is not in the search and so it is impossible to quickly search tasks in another project. Expected behavior ----------------- The project field should be displayed in the search view to be able to search tasks in another project instead of search in all projects (if the default filter is removed). Forward-Port-Of: odoo/odoo#180290
This PR will edit some export templates. - Services: change "invoice_policy" to "service_policy" - Projects Costs & Revenues: change "so_line/product_id" to "product_id" Forward-Port-Of: odoo/odoo#180345
Original PR description
This PR will edit some export templates. - Services: change "invoice_policy" to "service_policy" - Projects Costs & Revenues: change "so_line/product_id" to "product_id" Forward-Port-Of: odoo/odoo#180345
**Current behaviour before PR:** In table, empty single cell is not selectable through mouse. This happens because isVisible function fails to check if cell is empty or not. **Desired behaviour after PR:** Now it is possible to select empty cell through mouse. Now we are using isEmptyBlock to check if cell is empty or not. task-4067376 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174663
Original PR description
**Current behaviour before PR:** In table, empty single cell is not selectable through mouse. This happens because isVisible function fails to check if cell is empty or not. **Desired behaviour after PR:** Now it is possible to select empty cell through mouse. Now we are using isEmptyBlock to check if cell is empty or not. task-4067376 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174663
**Current behavior before PR:** - Pressing Enter after selecting all columns in a row would break the table format. **Desired behavior after PR is merged:** - Now, when the Enter key is pressed, all the contents of the anchor `<td>` will be removed first, and then the Enter process within that `<td>` will be executed. task-3557503 Forward-Port-Of: odoo/odoo#177775 Forward-Port-Of: odoo/odoo#139312
Original PR description
**Current behavior before PR:** - Pressing Enter after selecting all columns in a row would break the table format. **Desired behavior after PR is merged:** - Now, when the Enter key is pressed, all the contents of the anchor `<td>` will be removed first, and then the Enter process within that `<td>` will be executed. task-3557503 Forward-Port-Of: odoo/odoo#177775 Forward-Port-Of: odoo/odoo#139312
Current behavior before PR: When creating a table in email marketing using the powerbox command `/table`, the table picker would open at an incorrect position. Desired behavior after PR is merged: Now, when using the `/table` powerbox command to create a table in email marketing, the table picker will open at the cursor position. task-4113199 Forward-Port-Of: odoo/odoo#176712
Original PR description
Current behavior before PR: When creating a table in email marketing using the powerbox command `/table`, the table picker would open at an incorrect position. Desired behavior after PR is merged: Now, when using the `/table` powerbox command to create a table in email marketing, the table picker will open at the cursor position. task-4113199 Forward-Port-Of: odoo/odoo#176712
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#180362 Forward-Port-Of: odoo/odoo#180316
Original PR description
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#180362 Forward-Port-Of: odoo/odoo#180316
Steps: - Open restaurant and delete to existing draft orders. - Open table 1. - Add order items and pay the order until "New Order" button. Clicking New Order will change the screen to Floor Screen. - Open table 1 again. - In Actions button, select Refund. - The order you just paid will be in the list. - Refund the order. - Repeat steps 2 to 7. The new order is not there. Issue: Order list is not updated when refunding the order. Cause: When we navigate from the receipt screen to
Original PR description
Steps: - Open restaurant and delete to existing draft orders. - Open table 1. - Add order items and pay the order until "New Order" button. Clicking New Order will change the screen to Floor Screen. - Open table 1 again. - In Actions button, select Refund. - The order you just paid will be in the list. - Refund the order. - Repeat steps 2 to 7. The new order is not there. Issue: Order list is not updated when refunding the order. Cause: When we navigate from the receipt screen to the floor screen, the onWillUnmount method will be called to remove the order from the local database and server. So, when we navigate to the order list then new orders will not be there as they are removed. FIX: Pass false argument to "removeFromServer" in the removeOrder function, so it will not delete the order from the server. So, the order list will be updated task-4155780 Forward-Port-Of: odoo/odoo#179853
Currently a traceback may arises when there is no `filter_domain`, while the user tries to group projects. Error:- ``` AttributeError: 'bool' object has no attribute '_name' File "odoo/models.py", line 6643, in __and__ if self._name != other._name: TypeError: unsupported operand types in: project.project(2,) & False File "odoo/http.py", line 2383, in __call__ response = request._serve_db() File "odoo/http.py", line 1913, in _serve_db return self._transactioning
Original PR description
Currently a traceback may arises when there is no `filter_domain`, while the user tries to group projects. Error:- ``` AttributeError: 'bool' object has no attribute '_name' File "odoo/models.py",…
Currently a traceback may arises when there is no `filter_domain`,
while the user tries to group projects.
Error:-
```
AttributeError: 'bool' object has no attribute '_name'
File "odoo/models.py", line 6643, in __and__
if self._name != other._name:
TypeError: unsupported operand types in: project.project(2,) & False
File "odoo/http.py", line 2383, in __call__
response = request._serve_db()
File "odoo/http.py", line 1913, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1976, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1943, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2187, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 227, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 757, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 459, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 242, in web_read_group
groups = self._web_read_group(domain, fields, groupby, limit, offset, orderby, lazy)
File "addons/web/models/models.py", line 268, in _web_read_group
groups = self.read_group(domain, fields, groupby, offset=offset, limit=limit,
File "addons/project/models/project_task.py", line 1982, in read_group
return super().read_group(domain, fields, groupby, offset, limit, orderby, lazy)
File "odoo/models.py", line 2800, in read_group
rows_dict = self._read_group_fill_results(
File "odoo/models.py", line 2247, in _read_group_fill_results
values = group_expand(self, groups, domain).sudo()
File "home/odoo/src/enterprise/saas-17.4/industry_fsm/models/project_task.py", line 194, in _group_expand_project_ids
res &= search_on_comodel
File "odoo/models.py", line 6648, in __and__
raise TypeError(f"unsupported operand types in: {self} & {other!r}")
```
This is because of the recent changes from the below commit
Commit:- https://github.com/odoo/odoo/pull/172973/commits/600b379c91059bfce5ebf6c53a9d282a07e5c640
When the `_search_on_comodel` method returns `False` if there is no `filter_domain`,
it leads to a traceback because `&` is used between an empty recordset and a False.
https://github.com/odoo/enterprise/blob/ce508a604bf70af06347e43000f25426473fb867/industry_fsm/models/project_task.py#L149-L151
We can resolve this issue by returning an empty record, Instead of returning False.
sentry-5836960027
Forward-Port-Of: odoo/odoo#180265With an AR setup Create a branch company with: - Tax ID: same as in the parent company - Address: same as in the parent company - Certificate/Private key: same as parent company Create an invoice in Journal "Factura electrónica (FE)" Set customer "ADHOC SA" Confirm When the system attempt to send the e-invoice raceback pops up "ValueError: External ID not found in the system: account.5_tax_group_percepcion_ganancias" This occurs because the sytem looks for an xmlid which is only prese
Original PR description
With an AR setup Create a branch company with: - Tax ID: same as in the parent company - Address: same as in the parent company - Certificate/Private key: same as parent company Create an invoice in Journal "Factura electrónica (FE)" Set customer "ADHOC SA" Confirm When the system attempt to send the e-invoice raceback pops up "ValueError: External ID not found in the system: account.5_tax_group_percepcion_ganancias" This occurs because the sytem looks for an xmlid which is only present in the parent company opw-4151003 Forward-Port-Of: odoo/odoo#178992
-Probably miss by script since https://github.com/odoo/odoo/commit/332c117f60a36f723c450f61ce2e0e7181d66c21 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#177707
Original PR description
-Probably miss by script since https://github.com/odoo/odoo/commit/332c117f60a36f723c450f61ce2e0e7181d66c21 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#177707
In this Pr: https://github.com/odoo/odoo/pull/176313, we did a fix for the order of the lines in the report but included only the invoices in the t-set. task: 4179612 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180274 Forward-Port-Of: odoo/odoo#179935
Original PR description
In this Pr: https://github.com/odoo/odoo/pull/176313, we did a fix for the order of the lines in the report but included only the invoices in the t-set. task: 4179612 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180274 Forward-Port-Of: odoo/odoo#179935
Followup of task~3866837 (fp request) Forward-Port-Of: odoo/odoo#180217
Original PR description
Followup of task~3866837 (fp request) Forward-Port-Of: odoo/odoo#180217
How to reproduce: 1. signup as a fresh user, let's say contact@domain.tld 2. as admin, create a company over the partner, let's say Domain. Open Domain and click on the Contact to check that its type is Contact. 3. as Contact, add something to the cart 4. as admin again, find the SO and change the Invoice address to Domain (instead of Domain, Contact) 5. as Contact again, go to the cart and click on Checkout => 403. From now on, if we are effectively locked from buying anything, as odo
Original PR description
How to reproduce: 1. signup as a fresh user, let's say contact@domain.tld 2. as admin, create a company over the partner, let's say Domain. Open Domain and click on the Contact to check that its type…
How to reproduce: 1. signup as a fresh user, let's say contact@domain.tld 2. as admin, create a company over the partner, let's say Domain. Open Domain and click on the Contact to check that its type is Contact. 3. as Contact, add something to the cart 4. as admin again, find the SO and change the Invoice address to Domain (instead of Domain, Contact) 5. as Contact again, go to the cart and click on Checkout => 403. From now on, if we are effectively locked from buying anything, as odoo will always take the invoice address of the parent company, so if we try to empty cart, or cancell the sale order alltogether and try again, we will still get 403 error. Before this commit, if the last SO invoice address for contact was one of the company, and contact didn't have right to change parent companies invoice address, they were effectively blocked out of our shop, as the checkout gave 403 error. This fix checks that and if partner does not have right to change invoice address of the company, it sets partners invoice adress instead. Fixes: opw-4143122 opw-4166266 opw-4163258 opw-4131725 opw-4139971 opw-4127426 opw-4162361 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179456
the search logic for productions by component availability is currently incorrect: it matches productions for which at least one bom line has the requested availability. We align it with the compute method's logic Note: at the current time we have to perform a search within the search method, which will hurt performance if we have many MO, but it is not possible to compute the domain without accessing the records because the relevant product fields are compute and non-searchable opw-405
Original PR description
the search logic for productions by component availability is currently incorrect: it matches productions for which at least one bom line has the requested availability. We align it with the compute method's logic Note: at the current time we have to perform a search within the search method, which will hurt performance if we have many MO, but it is not possible to compute the domain without accessing the records because the relevant product fields are compute and non-searchable opw-4055859 Forward-Port-Of: odoo/odoo#180228 Forward-Port-Of: odoo/odoo#174178
[ADD] l10n_qa: Add localization package for qatar Add CoA and account groups with all the default account mappings for qatar Improve user experience in qatar task-id#3927918 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178370
Original PR description
[ADD] l10n_qa: Add localization package for qatar Add CoA and account groups with all the default account mappings for qatar Improve user experience in qatar task-id#3927918 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178370
### Steps to reproduce: - Create a product tracked by lot and register 4 lots of 10 units in stock : LOT001, LOT002, LOT003, LOT004 - Inventory > Configuration > Products > Product Categories - Change the Removal strategy of the "All" category to LIFO - Create and confirm a delivery order for 40 units of your product > Move lines are created for reservation in order LOT003, LOT002, LOT001 - Do not click on the detailed operation to see these LOTS and decrease the quantity of the move to
Original PR description
### Steps to reproduce: - Create a product tracked by lot and register 4 lots of 10 units in stock : LOT001, LOT002, LOT003, LOT004 - Inventory > Configuration > Products > Product Categories -…
### Steps to reproduce: - Create a product tracked by lot and register 4 lots of 10 units in stock : LOT001, LOT002, LOT003, LOT004 - Inventory > Configuration > Products > Product Categories - Change the Removal strategy of the "All" category to LIFO - Create and confirm a delivery order for 40 units of your product > Move lines are created for reservation in order LOT003, LOT002, LOT001 - Do not click on the detailed operation to see these LOTS and decrease the quantity of the move to 15 units ### Expected behavior: Since the lines were created respecting the removal strategy, they should be removed accordingly from the last one created to the first created > LOT001 and LOT002 should be removed and 5 units should be decreased from LOT003 ### Current behavior: LOT004 and LOT004 are removed and 5 units is removed from LOT002 ### Cause of the issue: On qty decrease, the `_process_decrease` of the `set_quantity` is called to decrease the qties on the associated sml and to unlink the one resulting with a 0 qty. However, the loop used to make this action is not based on the reversed order of creation of the lines but on their order itself. #### Note: This doe snot solve the issue for complex removal strategy that would require a complete recompute of the reservation on qty decrease such as "use the minimal amount of packages". ### Note 2: An other issue exists when you increase the demand of the move instead of decreasing it: while the qty done is increased no assignments are done so that a move line without lot id would be created to fulfill the increase of qty. This is because the `_action_assign` can not be triggered again in this process increase since the stockpocalypse the line was even commented here: https://github.com/odoo/odoo/blob/9f364cde276b8b3be73c30617515bd55a9f25aba/addons/stock/models/stock_move.py#L376-L378 he reason is that if an `_action_assign` was performed instead and if the units were not in stock to fulfill it the qty would only be increased by the available qty and the desired flow would be bloqued. THe behavior is being improved in master (18.0+) but the required change of the `_process_increase` is to risky to be applied in stable. co-authored by @naja628 opw-4074174 and opw-4071479 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180188 Forward-Port-Of: odoo/odoo#180082
This error occurs when we modify the ``Level Weight`` in ``Partner Assignment`` within Contacts, then uninstall the ``Website`` module, and subsequently attempt to access the modified contact again. Steps to reproduce: - Install the ``website_crm_partner_assign`` module - Change the ``Level Weight`` in ``Partner Assignment`` in Contacts - Now uninstall the ``Website`` module - Now open the changed contact again Traceback: ``AttributeError: 'NoneType' object has no attribute 'is_acces
Original PR description
This error occurs when we modify the ``Level Weight`` in ``Partner Assignment`` within Contacts, then uninstall the ``Website`` module, and subsequently attempt to access the modified contact again. Steps to reproduce: - Install the ``website_crm_partner_assign`` module - Change the ``Level Weight`` in ``Partner Assignment`` in Contacts - Now uninstall the ``Website`` module - Now open the changed contact again Traceback: ``AttributeError: 'NoneType' object has no attribute 'is_accessible'`` The error in [1] occurred because the field name from ``tracking.field_id.name`` was not found in ``tracking.field_id.model``. [1]- https://github.com/odoo/odoo/blob/d9d0b1c66dd608e475bdb7d29c162b6251b0f329/addons/mail/models/mail_tracking_value.py#L48-L49 sentry-5664351482 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179902
This error occurs when attempting to save a manufacturing order that is in a confirmed state. Steps to reproduce: - Install the ``mrp_workorder_hr_account`` module - Create a new MO, add a line, and ``Confirm`` - Now remove a line and click on the ``Save`` button Traceback: ``ValueError: not enough values to unpack (expected 3, got 2)`` The error at [1] occurred because we were not receiving the expected value of ``field_values`` in ``move_vals``. We expected 3 values but only recei
Original PR description
This error occurs when attempting to save a manufacturing order that is in a confirmed state. Steps to reproduce: - Install the ``mrp_workorder_hr_account`` module - Create a new MO, add a line, and ``Confirm`` - Now remove a line and click on the ``Save`` button Traceback: ``ValueError: not enough values to unpack (expected 3, got 2)`` The error at [1] occurred because we were not receiving the expected value of ``field_values`` in ``move_vals``. We expected 3 values but only received 2. [1]- https://github.com/odoo/odoo/blob/c48d62098b2809cd046742435afd4f7ba3a4cbe1/addons/mrp/models/mrp_production.py#L843-L844 sentry-5819387893 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179642
Before this commit: While generating E-waybill from a SO/PO with different currency the price unit in E-waybill is displayed incorrect in INR, the currency conversion rate is not applied and the price unit is displayed as it is in INR which is incorrect After this commit: We resolve the above issue. Now the currency conversation rate is applied correctly on the price unit while generating E-waybill from SO/PO Description of the issue/feature this PR addresses: Current behavior before
Original PR description
Before this commit: While generating E-waybill from a SO/PO with different currency the price unit in E-waybill is displayed incorrect in INR, the currency conversion rate is not applied and the price unit is displayed as it is in INR which is incorrect After this commit: We resolve the above issue. Now the currency conversation rate is applied correctly on the price unit while generating E-waybill from SO/PO 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#180289
Open a partner contact Go to Accounting tab Try to set 'DateV Vendor' field Issue: Traceback will raise ''' psycopg2.errors.UndefinedColumn: column "l10n_de_datev_identifier" does not exist LINE 3: WHERE l10n_de_datev_identifier != 0 ''' This occurs because l10n_de_datev_identifier is set as comapny_dependant, so its value isn't stored on the model table, but it is registered as `ir.property`. opw-4163804 Forward-Port-Of: odoo/enterprise#69900
Original PR description
Open a partner contact Go to Accounting tab Try to set 'DateV Vendor' field Issue: Traceback will raise ''' psycopg2.errors.UndefinedColumn: column "l10n_de_datev_identifier" does not exist LINE 3: WHERE l10n_de_datev_identifier != 0 ''' This occurs because l10n_de_datev_identifier is set as comapny_dependant, so its value isn't stored on the model table, but it is registered as `ir.property`. opw-4163804 Forward-Port-Of: odoo/enterprise#69900
[This commit] added in a new Carta Porte 3.0 PDF for Mexico in version saas-17.3 that inherits from the standard delivery slip, by removing all the tables related to the products etc. (for security reasons: the driver doesn't need to know what's in the cargo) and adding in some new required fields. This commit backports the report from saas-17.3 with the following changes: - We improved the layout a bit to make the report even clearer. - We corrected the "Num Reg ID Trib" and "Residencia Fi
Original PR description
[This commit] added in a new Carta Porte 3.0 PDF for Mexico in version saas-17.3 that inherits from the standard delivery slip, by removing all the tables related to the products etc. (for security reasons: the driver doesn't need to know what's in the cargo) and adding in some new required fields. This commit backports the report from saas-17.3 with the following changes: - We improved the layout a bit to make the report even clearer. - We corrected the "Num Reg ID Trib" and "Residencia Fiscal" of the "Figura"'s to use the right value and show them per figura. - We corrected the departure and arrival date (they were swapped). These changes will be forward-ported again to the upper versions. [This commit]: https://github.com/odoo/enterprise/commit/af14612ec5942acdc06584ec8ff9d8bf26998ae7 task-3990042 Forward-Port-Of: odoo/enterprise#69853 Forward-Port-Of: odoo/enterprise#65337
With a CO Company setup with missing VAT (NIT) number Have a partner with missing Country Create an invoice to the partner Confirm, Send&Print with option 'DIAN' checked Issue: The system will raise a traceback for each one of the missing info. We need to safely provide a fallback and then generate the corresponding error message so that user may take action opw-4148661 Forward-Port-Of: odoo/enterprise#69937
Original PR description
With a CO Company setup with missing VAT (NIT) number Have a partner with missing Country Create an invoice to the partner Confirm, Send&Print with option 'DIAN' checked Issue: The system will raise a traceback for each one of the missing info. We need to safely provide a fallback and then generate the corresponding error message so that user may take action opw-4148661 Forward-Port-Of: odoo/enterprise#69937
When making an order paid with customer account, the total due of the customer where not updated correctly until the session is closed. Steps to reproduce: ------------------- * Make sure pos_settle_due module is installed * Open PoS make an order and pay with customer account and Customer A * Open Customer list > Observation: Check the total due of Customer A, it's still 0 Why the fix: ------------ When computing the total due we take into account the pos orders that are still in a
Original PR description
When making an order paid with customer account, the total due of the customer where not updated correctly until the session is closed. Steps to reproduce: ------------------- * Make sure pos_settle_due module is installed * Open PoS make an order and pay with customer account and Customer A * Open Customer list > Observation: Check the total due of Customer A, it's still 0 Why the fix: ------------ When computing the total due we take into account the pos orders that are still in an open session opw-4094546 Forward-Port-Of: odoo/enterprise#69754 Forward-Port-Of: odoo/enterprise#69080
Steps ----- On runbot: 1. Enable Time Billing for a Helpdesk team. 2. Create a ticket for Deco Addict. 3. Remove the "Sales Order Item". 4. Try to search a "Sales Order Item". ** No results appear ** Change ----- Correct domain, `commercial_partner_id` needs to be unquoted or it will be interpreted as a string. opw-4177705 Forward-Port-Of: odoo/enterprise#69950
Original PR description
Steps ----- On runbot: 1. Enable Time Billing for a Helpdesk team. 2. Create a ticket for Deco Addict. 3. Remove the "Sales Order Item". 4. Try to search a "Sales Order Item". ** No results appear ** Change ----- Correct domain, `commercial_partner_id` needs to be unquoted or it will be interpreted as a string. opw-4177705 Forward-Port-Of: odoo/enterprise#69950
Before this commit: - In the project update, budgets in the 'Confirmed', 'Revised' and 'Done' state are visible in the project update panel. After this commit: - In the project update, only budgets in the 'Confirmed' or 'Done' state are visible in the project update panel. Task-4180079 Forward-Port-Of: odoo/enterprise#70020
Original PR description
Before this commit: - In the project update, budgets in the 'Confirmed', 'Revised' and 'Done' state are visible in the project update panel. After this commit: - In the project update, only budgets in the 'Confirmed' or 'Done' state are visible in the project update panel. Task-4180079 Forward-Port-Of: odoo/enterprise#70020
This commit is checking that we have a value before checking it with the today's date. no task id Forward-Port-Of: odoo/enterprise#70103
Original PR description
This commit is checking that we have a value before checking it with the today's date. no task id Forward-Port-Of: odoo/enterprise#70103
Problem: Auto-vacuum is incorrectly archiving reformatted spreadsheet documents that were generated from unsupported file uploads. Specifically, when an .xlsx file is uploaded, Odoo creates a new, compatible spreadsheet document. However, this newly generated document is mistakenly deleted during the auto-vacuum process if it is older than 24 hours. Purpose: Add a domain to prevent Odoo created spreadsheets from uploads being caught by autocron vacuum from improvement to 17.0 last year S
Original PR description
Problem: Auto-vacuum is incorrectly archiving reformatted spreadsheet documents that were generated from unsupported file uploads. Specifically, when an .xlsx file is uploaded, Odoo creates a new, compatible spreadsheet document. However, this newly generated document is mistakenly deleted during the auto-vacuum process if it is older than 24 hours. Purpose: Add a domain to prevent Odoo created spreadsheets from uploads being caught by autocron vacuum from improvement to 17.0 last year Steps to reproduce bug: 1.) Upload an xlsx file 2.) Click on the xlsx file 3.) It will generate an Odoo file of the same type 4.) Set the date of the new file to older than 24 hours 5.) The formatted file will be deleted when the autocron hits opw-4087851 Forward-Port-Of: odoo/enterprise#68581
## Description: Previously, attempting to reinsert a pivot with an invalid range resulted in a traceback error. This commit resolves the issue by hiding the menu item when the specified pivot range is invalid. Task: [4137926](https://www.odoo.com/odoo/project/2328/tasks/4137926) Forward-Port-Of: odoo/enterprise#69838
Original PR description
## Description: Previously, attempting to reinsert a pivot with an invalid range resulted in a traceback error. This commit resolves the issue by hiding the menu item when the specified pivot range is invalid. Task: [4137926](https://www.odoo.com/odoo/project/2328/tasks/4137926) Forward-Port-Of: odoo/enterprise#69838
Before this commit, the is_zero attribute was not recomputed correctly when updating the columns. task: 4188758 Forward-Port-Of: odoo/enterprise#70097
Original PR description
Before this commit, the is_zero attribute was not recomputed correctly when updating the columns. task: 4188758 Forward-Port-Of: odoo/enterprise#70097
Currently, an error occurs when enabling 'Email Alias' in the helpdesk team and helpdesk team name is not available. Step to produce: - Install the 'helpdesk' module. - Navigate to Helpdesk / Configuration / Helpdesk Teams. - Open any record remove a name and disable 'Email Alias'. - Then enable 'Email Alias'. ```AttributeError: 'bool' object has no attribute 'replace'``` An error occurs when the system tries to replace a helpdesk team name at [1] but it is not available. Link
Original PR description
Currently, an error occurs when enabling 'Email Alias' in the helpdesk team and helpdesk team name is not available. Step to produce: - Install the 'helpdesk' module. - Navigate to Helpdesk / Configuration / Helpdesk Teams. - Open any record remove a name and disable 'Email Alias'. - Then enable 'Email Alias'. ```AttributeError: 'bool' object has no attribute 'replace'``` An error occurs when the system tries to replace a helpdesk team name at [1] but it is not available. Link [1]: https://github.com/odoo/enterprise/blob/f9b1be600825651c9a893920d7532b9b95e3dc02/helpdesk/models/helpdesk_team.py#L574 To resolve the issue, add a condition that calls the '_alias_get_creation_values' method if the helpdesk team name is available. Sentry-5831429098 Forward-Port-Of: odoo/enterprise#69921
When the customer creates a helpdesk ticket and the user of helpdesk team is deleted, a traceback will appear. Steps to reproduce the error: - Go to Settings > Users & Companies > Users > Create a user - Go to Helpdesk > Configuration > Helpdesk Teams > Open Team A Select Assignment Method: Random > Select that user in the members > Save - Delete that user - Go to Helpdesk > All Tickets > Create a ticket > Select Team A Traceback: ``` IndexError: list index out of range File "
Original PR description
When the customer creates a helpdesk ticket and the user of helpdesk team is deleted, a traceback will appear. Steps to reproduce the error: - Go to Settings > Users & Companies > Users > Create a…
When the customer creates a helpdesk ticket and
the user of helpdesk team is deleted, a traceback will appear.
Steps to reproduce the error:
- Go to Settings > Users & Companies > Users > Create a user
- Go to Helpdesk > Configuration > Helpdesk Teams > Open Team A
Select Assignment Method: Random > Select that user in the members > Save
- Delete that user
- Go to Helpdesk > All Tickets > Create a ticket > Select Team A
Traceback:
```
IndexError: list index out of range
File "odoo/http.py", line 2248, in __call__
response = request._serve_db()
File "odoo/http.py", line 1823, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1843, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1821, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1828, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2053, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 756, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 866, in onchange
defaults = self.default_get(missing_names)
File "home/odoo/src/enterprise/saas-17.2/helpdesk/models/helpdesk_ticket.py", line 40, in default_get
result['user_id'] = team._determine_user_to_assign()[team.id].id
File "home/odoo/src/enterprise/saas-17.2/helpdesk/models/helpdesk_team.py", line 959, in _determine_user_to_assign
result[team.id] = self.env['res.users'].browse(member_ids[index])
```
https://github.com/odoo/enterprise/blob/947b6ab9447aa069fd5edd150c932d9a0884a3cb/helpdesk/models/helpdesk.py#L502 When the related user is deleted, "member_ids" will be an empty list.
so when it tries to access the index of "member_ids",
it will lead to the above traceback.
behavior after the commit:
It will ensure that at least one user is selected in "member_ids".
sentry-5630888721
Forward-Port-Of: odoo/enterprise#70085
Forward-Port-Of: odoo/enterprise#67240Purpose ======= Fix the inactive records fetching in the gantt view. Specification ============= When fetching the records to display in the gantt view from their ids, we don't specify if the inactive records need to be included in the search. This is an issue as further down the execution flow, the '_where_calc' method by default excludes inactive records except if they are explicitly asked for. => This means that filtering on inactive records doesn't display any records. Fixing that
Original PR description
Purpose ======= Fix the inactive records fetching in the gantt view. Specification ============= When fetching the records to display in the gantt view from their ids, we don't specify if the inactive records need to be included in the search. This is an issue as further down the execution flow, the '_where_calc' method by default excludes inactive records except if they are explicitly asked for. => This means that filtering on inactive records doesn't display any records. Fixing that by setting the 'active_test' key in the context to 'False' to be sure we search records with these ids both in active and inactive records. Related commit: 836909419893b522890776d3ec2f16476ae21108 Forward-Port-Of: odoo/enterprise#70100 Forward-Port-Of: odoo/enterprise#70032
Before this commit: - When the achieved amount exceeds the budgeted amount, it is displayed in red. This indicates an over-budget status, which is misleading for `revenue` and `both` budget types where exceeding the budget is actually a positive sign. After this commit: - When the achieved amount exceeds the budgeted amount, the red color will be applied only to the expense budget. Task-4167662 Forward-Port-Of: odoo/enterprise#69699
Original PR description
Before this commit: - When the achieved amount exceeds the budgeted amount, it is displayed in red. This indicates an over-budget status, which is misleading for `revenue` and `both` budget types where exceeding the budget is actually a positive sign. After this commit: - When the achieved amount exceeds the budgeted amount, the red color will be applied only to the expense budget. Task-4167662 Forward-Port-Of: odoo/enterprise#69699
As we replaced the individual config files by a single `odoo.conf`, we need to adapt the code to keep compatibility between updated and non-updated IoT Boxes. As we did not update this one in the migration method from [this PR](https://github.com/odoo/odoo/pull/173866), we have to try both old and new methods to get the config value. opw-4183138 Forward-Port-Of: odoo/enterprise#70033
Original PR description
As we replaced the individual config files by a single `odoo.conf`, we need to adapt the code to keep compatibility between updated and non-updated IoT Boxes. As we did not update this one in the migration method from [this PR](https://github.com/odoo/odoo/pull/173866), we have to try both old and new methods to get the config value. opw-4183138 Forward-Port-Of: odoo/enterprise#70033