Thursday, June 15, 2023
71 changes · master
Enhancements to existing features
Recruitment teams can now manually reorder refusal reasons to match their preferred workflow. This makes the list easier to organize and helps users find the right reason more quickly when processing applicants.
Original PR description
In this commit, We have added the sequence field so that the user can easily reorder the Refusal Reason. task-3336247
The timesheet search screen has been simplified to make it easier for users to find relevant sales-related timesheet entries. Users can now search directly by sales order and sales order line, while less useful search and grouping options have been removed.
Original PR description
improve the UX for search view: - remove the group by on 'Sale Order' - remove the quick search on 'sales order item' - add quick search for SO and SOL instead of 'Sale Order' task-3265251
Tasks no longer show the sales order line field to users without sales access when there is no value to display. This reduces clutter and avoids showing a read-only empty field that is not useful to those users.
Original PR description
Before this commit SOL field on task visible when user no sale access and field is set but SOL field is readonly when user has no sale access there is not point showing readonly empty field. This commit hide SOL field when user has no sale access and field is not set. task-3186438
The CRM lost lead wizard no longer requires users to turn on a separate option before entering a loss reason. This makes marking leads as lost faster and removes an unnecessary step while still letting users add a reason when useful.
Original PR description
To set the lost reason you currently need to toggle a field in the wizard if you are marking a lead as lost. As the loss reason isn't technically necessary, we can just let users choose whether to input anything or not without having to click anything task-3356095 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Demo data now enables the right routes for table-related products, making manufacturing and bill of materials examples more realistic. This helps users evaluating or demonstrating the system see clearer results in manufacturing overview screens.
Original PR description
Activated the route in demo data of Table Top, Table Leg and Wood Panel so that bom overview and MO overview can yield better demo results. task id: 3357025
This update adds shared helper tools that make Odoo's interface react more smoothly to data changes. It is mainly an internal improvement for Point of Sale and related services, helping future updates be simpler and more reliable without changing day-to-day workflows directly.
Original PR description
This commit adds a new module in web that contains a few helpers to make it easier to use reactive in Odoo. 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 preparation display now uses shared web update helpers to keep its data handling more consistent. This is an internal improvement that should support smoother, more maintainable preparation screen behavior without changing daily workflows.
The Stool demo product now has its route activated, making manufacturing-related demo screens show more complete and useful examples. This helps users better understand the bill of materials and manufacturing order overviews during demonstrations.
Original PR description
Activated the route in demo data of Stool so that bom overview and MO overview can yield better demo results. task id: 3357025
Helpdesk SLA policies now use the clearer label "Within" instead of "In" for timing rules. SLA policy list and kanban views are also ordered by team, making policies easier to scan and manage.
Original PR description
Change "time" field's label from "In" to "Within". Order list and kanban view by team. task-3251732
The Project Helpdesk module now includes demo data that illustrates how support tickets can be converted into project tasks. This helps users and evaluators better understand the workflow using realistic sample records.
Original PR description
This PR adds some demo data to showcase the ticket/task conversion feature. Task-3180982
Helpdesk ticket lists now show the total hours spent at the bottom of the view. This helps users quickly understand workload or effort across selected tickets without manually adding timesheet entries.
Original PR description
Purpose: allow users to view at a glance the total number of hours spent on a set a ticket. Specs: in tickets list view, display sum of hours spent at the bottom. task-3330300
The Helpdesk overview dashboard now uses the clearer label “Top Assignees” instead of “Top Agents.” This makes the dashboard wording more accurate for users reviewing who work items are assigned to.
Original PR description
Improve the following generic UX - Earlier assignees were named as Top Agents so we renamed it to Top Assignees task-3324591
Resolved issues and error corrections
This change adjusts an automated test so it waits for the system to finish updating a related field before checking the result. It helps prevent occasional false test failures, improving confidence in future updates without changing user-facing behavior.
Original PR description
To test the onchange on uom, the service type is first change. Checking the value of the uom input right after introduces underteministic behavior which makes the test fail in some cases. To try to solve this, another step is processed inbetween, before checking the value of the uom input. related-https://github.com/odoo/odoo/pull/105951
Code cleanup and technical improvements
The Helpdesk search and reporting filters have been reorganized to use a shared base setup instead of duplicated definitions. This makes future updates easier to maintain and helps keep ticket and report views consistent across related Helpdesk apps.
Original PR description
Before this PR in-order to make both view same we add same content (filter,group_by..) twice which was making it hard to keep track as lots of search content coming from other bridge application and we have redundant code. So this PR make a base search view which contains all content of search view and use it in both helpdesk and helpdesk report search views. task-3186587
Miscellaneous changes
This commit changes the way the we-many2one and we-many2many fields work so that they check if the model they are attached to has a website_id field, if so, the data loaded from the model will be that related to the current website. After this commit, developers can get rid of the website_id field when they add a many2X field. The domain will be automatically computed. task-3316278 Forward-Port-Of: odoo/odoo#124916 Forward-Port-Of: odoo/odoo#121107
Original PR description
This commit changes the way the we-many2one and we-many2many fields work so that they check if the model they are attached to has a website_id field, if so, the data loaded from the model will be that related to the current website. After this commit, developers can get rid of the website_id field when they add a many2X field. The domain will be automatically computed. task-3316278 Forward-Port-Of: odoo/odoo#124916 Forward-Port-Of: odoo/odoo#121107
This fix prevents portal layouts from crashing when no language is set for a user or request. It improves reliability for customers accessing portal pages in edge cases where language information is unavailable.
Original PR description
language can be None -> we don't want to crash if that is the case --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Chat notifications now show special characters like angle brackets and ampersands exactly as sent. This avoids confusing escaped text in out-of-focus message popups and makes notifications easier to read.
Original PR description
**Before this commit:** In discuss when a user receives a message containing strings from any of these '>,<,&' it gets converted to `>,<,&` respectively. For example, if a user sends '<abc>', when the chat is out of focus, the toaster notification will show a notification with an escaped message i.e.`<abc>`. **After this commit:** The message will be shown as it is, in the toaster notification. **Task**-3284244
This fixes an issue in the Mail app where some conversation actions did not receive the information they needed to display or work correctly. It helps ensure mail and discussion interface actions behave reliably for users.
Original PR description
Since [1] thread actions are stored in a specific registry. Some of those actions require props to be passed to their component. Those props are not correctly passed as the `componentProps` key is in fact a function that returns the props but is treated as the props themselves. This commit fixes this issue by transforming `componentProps` into a getter, so that `action` is internally passed to `componentProps` definition. The templates using thread actions can still use `t-props="componentProps"` as getter, as the active action is deduced by transform automatically. [1]: https://github.com/odoo/odoo/pull/123454
Fixes an issue in Mail where removing an attachment from the message composer could cause the message to be sent twice. This prevents duplicate communications and reduces confusion for users and recipients.
Original PR description
When removing the attachment, message is sent twice.
This update ensures an existing IAP website test runs as part of regular nightly website checks. It also adds Arabic to the tested languages so translation quality for industry content can be verified earlier.
Original PR description
A test of IAP has been introduced by [this commit]. We want it to be part of the website nightly tests, so that we can easily check if it passes. [this commit]: https://github.com/odoo/odoo/commit/9177076caee4f83590704e3af8e51ec6f7eaa0bc --- This commit adds arabic in the list of iap languages so that we can test that the industries are correctly translated in arabic. related to task-3343616
This fix prevents an error when users open valuation details after completing a manufacturing order. It helps keep the manufacturing workflow running smoothly and avoids an unexpected interruption at a key accounting step.
Original PR description
Steps to reproduce --- - Create Manufacturing Orders and confirm it. - Validate the done quantities. - Click on valuation button. It will raise trackback Error caused by commit: a080337
This fixes an issue in Odoo Mail where some conversation actions did not receive the information they needed to work correctly. Users should see more reliable behavior when using mail discussion actions, especially flows such as channel invitations.
Original PR description
Since [1] thread actions are stored in a specific registry. Some of those actions require props to be passed to their component. Those props are not correctly passed as the `componentProps` key is in fact a function that returns the props but is treated as the props themselves. This commit fixes this issue by transforming `componentProps` into a getter, so that `action` is internally passed to `componentProps` definition. The templates using thread actions can still use `t-props="componentProps"` as getter, as the active action is deduced by transform automatically. [1]: https://github.com/odoo/odoo/pull/123454
This update fixes unstable automated tests in the Knowledge app that were repeatedly failing during internal build checks. It helps keep development and release validation reliable without changing the user-facing Knowledge experience.
Original PR description
This commit fixes a bug where the test `test_knowledge_template_command_tour` would be failing inside runbot build and create error on every runbot build. We removed te `@users` decorator from the test. task-3345004
When there are too many (millions) of POS order lines associated to opened POS sessions we get too many taxes, most are duplicated. This causes a MemoryError. Example queries from a real DB: ``` > select count(distinct r.account_tax_id) from pos_order_line l join pos_order o on o.id = l.order_id join pos_session s on s.id = o.session_id join account_tax_pos_order_line_rel r on r.pos_order_line_id = l.id where s.state != 'closed' +-------+ | count | |-------| | 24 | +-------+ > sele
Original PR description
When there are too many (millions) of POS order lines associated to opened POS sessions we get too many taxes, most are duplicated. This causes a MemoryError. Example queries from a real DB: ``` > select count(distinct r.account_tax_id) from pos_order_line l join pos_order o on o.id = l.order_id join pos_session s on s.id = o.session_id join account_tax_pos_order_line_rel r on r.pos_order_line_id = l.id where s.state != 'closed' +-------+ | count | |-------| | 24 | +-------+ > select count(r.account_tax_id) from pos_order_line l join pos_order o on o.id = l.order_id join pos_session s on s.id = o.session_id join account_tax_pos_order_line_rel r on r.pos_order_line_id = l.id where s.state != 'closed' +---------+ | count | |---------| | 2504539 | +---------+ ``` opw-3295467 Forward-Port-Of: odoo/odoo#124375 Forward-Port-Of: odoo/odoo#124119
Steps to reproduce: ------------------- - activate "Count Extra Hours" in Attendances settings; - create attendances for an employee to create an overtime (select one day of the weekend for example); - create an Extra Hours type leave for this employee; - remove the attendance that creates extra hours; The extra hours of the employee is negative - refuse the leave created before; Issue: ------ A Validation Error occurs with the message: "The employee does not have enough extra h
Original PR description
Steps to reproduce: ------------------- - activate "Count Extra Hours" in Attendances settings; - create attendances for an employee to create an overtime (select one day of the weekend for example); - create an Extra Hours type leave for this employee; - remove the attendance that creates extra hours; The extra hours of the employee is negative - refuse the leave created before; Issue: ------ A Validation Error occurs with the message: "The employee does not have enough extra hours to extend this leave.". Solution: --------- Refuse leave based on extra hours should not require any control because we are not trying to extend leave. opw-3342778 Forward-Port-Of: odoo/odoo#124219
To reproduce: - Activate analytic accounting - Create an analytic plan - Click on Subplans - Create a Subplan - Come back to the list view of subplans (with the breadcrumb) => The new plan does not appear The children_ids are not recomputed, so we inverse the logic. task-3359643 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.odo
Original PR description
To reproduce: - Activate analytic accounting - Create an analytic plan - Click on Subplans - Create a Subplan - Come back to the list view of subplans (with the breadcrumb) => The new plan does not appear The children_ids are not recomputed, so we inverse the logic. task-3359643 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#124404
Since [1] the `value` prop is no longer part of the standard field props, and its value must be accessed as `this.props.record.data[this.props.name]`. This commit fixes a traceback when opening a mailing in read-only mode, which resulted from reading `length` of `this.props.value`, which is undefined. [1]: 688986f888f2fe2371d58b74ded81315ba6bb353 Forward-Port-Of: odoo/odoo#124499
Original PR description
Since [1] the `value` prop is no longer part of the standard field props, and its value must be accessed as `this.props.record.data[this.props.name]`. This commit fixes a traceback when opening a mailing in read-only mode, which resulted from reading `length` of `this.props.value`, which is undefined. [1]: 688986f888f2fe2371d58b74ded81315ba6bb353 Forward-Port-Of: odoo/odoo#124499
Before this commit, the kanban title's tooltip was set on the parent element of the column's title. So the lifecycle (display/hide) of the tooltip was not handled correctly when we clicked on the "quick create" button or the "gear dropdown". This commit moves the tooltip on the title's element to avoid that. Steps to reproduce: 1. Open the "Event" app 2. Mouseenter the first kanban header 3. A wild tooltip appears (Gotta Catch 'Em All) 4. Click on the quick create button or the gear
Original PR description
Before this commit, the kanban title's tooltip was set on the parent element of the column's title. So the lifecycle (display/hide) of the tooltip was not handled correctly when we clicked on the "quick create" button or the "gear dropdown". This commit moves the tooltip on the title's element to avoid that. Steps to reproduce: 1. Open the "Event" app 2. Mouseenter the first kanban header 3. A wild tooltip appears (Gotta Catch 'Em All) 4. Click on the quick create button or the gear dropdown. => the tooltip isn't disposed => bug Task ID: 3336233 Forward-Port-Of: odoo/odoo#124884 Forward-Port-Of: odoo/odoo#123094
Description of the issue/feature this PR addresses: There are some inconsistencies in price between the original record and tax document due to decimal place rounding. Previously, all the prices are rounded to the nearest integer, resulting to an inconsistent sum of the invoice line's subtotal with the invoice's total. After checking with local accounting software in Indonesia, Accurate, which is government certified, we find out that rounding to the nearest integer is not necessary. This i
Original PR description
Description of the issue/feature this PR addresses: There are some inconsistencies in price between the original record and tax document due to decimal place rounding. Previously, all the prices are rounded to the nearest integer, resulting to an inconsistent sum of the invoice line's subtotal with the invoice's total. After checking with local accounting software in Indonesia, Accurate, which is government certified, we find out that rounding to the nearest integer is not necessary. This issue is now mitigated by having a more accurate decimal-place rounding. Task ID: 3019692 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#124773 Forward-Port-Of: odoo/odoo#110068
When you use the salary configurator on existing employee, you get an error because you cannot modify a trusted bank account. Since we cannot modify the partner_id on a bank account when it is trusted, we should only modify the partner on the accout when it is needed, and untrust the account when it is changed. This has been introduced in https://github.com/odoo/odoo/pull/120423 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after
Original PR description
When you use the salary configurator on existing employee, you get an error because you cannot modify a trusted bank account. Since we cannot modify the partner_id on a bank account when it is trusted, we should only modify the partner on the accout when it is needed, and untrust the account when it is changed. This has been introduced in https://github.com/odoo/odoo/pull/120423 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#124879
The test would fail when running on a weekend, as the employee would be considered not working. Runbot error-21971. Forward-Port-Of: odoo/odoo#124877 Forward-Port-Of: odoo/odoo#124814
Original PR description
The test would fail when running on a weekend, as the employee would be considered not working. Runbot error-21971. Forward-Port-Of: odoo/odoo#124877 Forward-Port-Of: odoo/odoo#124814
When the browser is zoomed, the value of the `border-width` CSS properties obtained through `getComputedStyle` are impacted by the zoom. Because of this, entering a "10px" border in a Chrome zoomed at 125% turns it into "9.6px" when leaving the input field. This commit neutralizes the zoom effect by rounding the value up. The rounding operation was empirically determined by observing values, see table below. When zoomed out this does not always work: e.g. at 50% zoom, a value of 11px
Original PR description
When the browser is zoomed, the value of the `border-width` CSS properties obtained through `getComputedStyle` are impacted by the zoom. Because of this, entering a "10px" border in a Chrome zoomed…
When the browser is zoomed, the value of the `border-width` CSS properties obtained through `getComputedStyle` are impacted by the zoom. Because of this, entering a "10px" border in a Chrome zoomed at 125% turns it into "9.6px" when leaving the input field. This commit neutralizes the zoom effect by rounding the value up. The rounding operation was empirically determined by observing values, see table below. When zoomed out this does not always work: e.g. at 50% zoom, a value of 11px becomes 10px. But zooming out is an unxpected use case, that situation is therefore not handled by this fix. Observed values of the border-width property: Set value => `getComputedStyle` ``` Value Chrome 125% Firefox 120% 1px 0.8px 0.83333px 2px 1.6px 1.66667px 3px 2.4px 2.50000px 4px 4.0px 3.33333px 5px 4.8px 5.00000px 6px 5.6px 5.83333px 7px 6.4px 6.66667px 8px 8.0px 7.50000px 9px 8.8px 8.33333px 10px 9.6px 10.00000px 11px 10.4px 10.83333px 12px 12.0px 11.66667px ``` Steps to reproduce: - Drop a "Text - Image" block. - Select the text column. - Zoom with ctrl+mouse wheel or ctrl-plus. - Set a 10px border. - Leave input field. => Border option field displayed a different size. task-3172235 Forward-Port-Of: odoo/odoo#119084
task-3332640 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#122436
Original PR description
task-3332640 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#122436
When user will open the video in any course, it will be marked as completed directly which behaves like any other content(pdf, image). This behavior was introduced when 'slide_view' was modified in https://github.com/odoo/odoo/commit/4c291fe30468dab7cef9d2e5a0377c78484f5045, but in the case of video, it must not be marked as completed before the video is watched up until(near) the end, as per the previous behavior. **Task**-3346507 Forward-Port-Of: odoo/odoo#124123
Original PR description
When user will open the video in any course, it will be marked as completed directly which behaves like any other content(pdf, image). This behavior was introduced when 'slide_view' was modified in https://github.com/odoo/odoo/commit/4c291fe30468dab7cef9d2e5a0377c78484f5045, but in the case of video, it must not be marked as completed before the video is watched up until(near) the end, as per the previous behavior. **Task**-3346507 Forward-Port-Of: odoo/odoo#124123
**Steps to reproduce the bug:** - Install mrp_plm - Create a BoM with an analytic account - Create an ECO - Start the revision **Problem:** The new BoM version doesn't have the analytic account from the original one opw-3329901 Forward-Port-Of: odoo/odoo#124841
Original PR description
**Steps to reproduce the bug:** - Install mrp_plm - Create a BoM with an analytic account - Create an ECO - Start the revision **Problem:** The new BoM version doesn't have the analytic account from the original one opw-3329901 Forward-Port-Of: odoo/odoo#124841
**Steps to reproduce the bug:** - create a new transfer - Click on new line but leave it empty - Change operation type **Problem:** A traceback is triggered, because the onchange of picking_type is triggered, so we try to get the description of each product in each move. However, since the move does not have a product set, an error is thrown: https://github.com/odoo/odoo/blob/16.0/addons/stock/models/product.py#L235-L239 opw-3349646 Forward-Port-Of: odoo/odoo#125010
Original PR description
**Steps to reproduce the bug:** - create a new transfer - Click on new line but leave it empty - Change operation type **Problem:** A traceback is triggered, because the onchange of picking_type is triggered, so we try to get the description of each product in each move. However, since the move does not have a product set, an error is thrown: https://github.com/odoo/odoo/blob/16.0/addons/stock/models/product.py#L235-L239 opw-3349646 Forward-Port-Of: odoo/odoo#125010
Steps to reproduce: 1. Create Indian Company Database 2. Install Accounting module, Install one more app " Indian - UPI " 3. Go to Setting > General Settings > Company information update > fill details in "UPI Id" field with 7874353637@paytm Issue Create and confirm vendor bill and Print the same at a bottom you will see QR code of our company UPI id. And we don't want the qr-code to be printed on a bill. opw-3284324 Forward-Port-Of: odoo/odoo#123859
Original PR description
Steps to reproduce: 1. Create Indian Company Database 2. Install Accounting module, Install one more app " Indian - UPI " 3. Go to Setting > General Settings > Company information update > fill details in "UPI Id" field with 7874353637@paytm Issue Create and confirm vendor bill and Print the same at a bottom you will see QR code of our company UPI id. And we don't want the qr-code to be printed on a bill. opw-3284324 Forward-Port-Of: odoo/odoo#123859
Steps to reproduce: - create an invoice with a certain number of items so that when printed there are multiple pages Issue: - the invoice name does not appear on each page According to the French legislation it is mandatory See https://entreprendre.service-public.fr/vosdroits/F31808 opw-3199906 Forward-Port-Of: odoo/odoo#124811 Forward-Port-Of: odoo/odoo#117043
Original PR description
Steps to reproduce: - create an invoice with a certain number of items so that when printed there are multiple pages Issue: - the invoice name does not appear on each page According to the French legislation it is mandatory See https://entreprendre.service-public.fr/vosdroits/F31808 opw-3199906 Forward-Port-Of: odoo/odoo#124811 Forward-Port-Of: odoo/odoo#117043
When we create a sale order with multiples services which have different project templates , he projects created will have the sum of all hours which is not true. Steps to reproduce the error : 1- create at least 2 product with type service and choose create on order : project & task , and create a template for each one on the fly 2- create a sale order with the created services and choose some quantity for each one of them 3- confirm it 4- Click on the smart button projects 5- you wi
Original PR description
When we create a sale order with multiples services which have different project templates , he projects created will have the sum of all hours which is not true. Steps to reproduce the error : 1- create at least 2 product with type service and choose create on order : project & task , and create a template for each one on the fly 2- create a sale order with the created services and choose some quantity for each one of them 3- confirm it 4- Click on the smart button projects 5- you will see that the allocated hours for each project have the sum of all the quantities The origin of the problem is that we don't check on the template_id when calculating the allocated hours so we sum the allocated hours of all the services having project & task for each one of them . opw-3341546 Forward-Port-Of: odoo/odoo#124867 Forward-Port-Of: odoo/odoo#123646
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#124783
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#124783
Version: 16.0 Prerequisites: - "Pricelist" enabled - "Prevent Sale of Zero Priced Product" enabled Steps: - Create a product: - Sales Price: 0 - In the "Sales" tab set "website" to a website - Add Extra Prices (smart button) - Public Pricelist (USD) - Min. Quantity: 0 - Price: 100 - Go to the shop, choose the correct pricelist and try to add the product to the cart Issue: UserError: The given product does not have a price therefore it cannot be added to cart. Ca
Original PR description
Version: 16.0 Prerequisites: - "Pricelist" enabled - "Prevent Sale of Zero Priced Product" enabled Steps: - Create a product: - Sales Price: 0 - In the "Sales" tab set "website" to a website - Add Extra Prices (smart button) - Public Pricelist (USD) - Min. Quantity: 0 - Price: 100 - Go to the shop, choose the correct pricelist and try to add the product to the cart Issue: UserError: The given product does not have a price therefore it cannot be added to cart. Cause: It doesn't compare the good price list considering the context opw-3339524 Forward-Port-Of: odoo/odoo#124805
[FIX] mail: Send message/log note in chatter style with MILK - Send button has text "Send" or "Log" depending on composer mode - When button is active, it has `btn-primary` and composer mode buttons use `btn-outline-primary` - Add hint to use Send keyboard shortcut for fast send in chatter Other changes: - Re-introduce missing feature to jump to present when posting a new message in a thread. - In chatter, the topbar and composer are sticky. Whole chatter is scrollable rather than
Original PR description
[FIX] mail: Send message/log note in chatter style with MILK - Send button has text "Send" or "Log" depending on composer mode - When button is active, it has `btn-primary` and composer mode buttons…
[FIX] mail: Send message/log note in chatter style with MILK - Send button has text "Send" or "Log" depending on composer mode - When button is active, it has `btn-primary` and composer mode buttons use `btn-outline-primary` - Add hint to use Send keyboard shortcut for fast send in chatter Other changes: - Re-introduce missing feature to jump to present when posting a new message in a thread. - In chatter, the topbar and composer are sticky. Whole chatter is scrollable rather than just a part of it. As a result, `Chatter-scrollable` becomes `Chatter-content`. - Editing a message in chatter now uses the extended composer Task-3356271 https://github.com/odoo/enterprise/pull/42508 <img width="931" alt="Screenshot 2023-06-07 at 12 03 27" src="https://github.com/odoo/odoo/assets/6569390/43807c78-ee5a-4ef3-90a9-7838acba2dfd"> <img width="932" alt="Screenshot 2023-06-07 at 12 03 17" src="https://github.com/odoo/odoo/assets/6569390/e3675cdc-1563-4651-b33d-ed90e462672e"> <img width="929" alt="Screenshot 2023-06-07 at 12 03 21" src="https://github.com/odoo/odoo/assets/6569390/e03e0eba-0cad-4508-a574-2eee87216e25"> <img width="927" alt="message" src="https://github.com/odoo/odoo/assets/6569390/32cd005d-7a73-4c18-a84e-0bc3d8c13f70"> <img width="926" alt="note" src="https://github.com/odoo/odoo/assets/6569390/961dfa7a-c044-4451-bb18-23ddaab0d220"> Forward-Port-Of: odoo/odoo#124088
[IMP] sql_db: find and log queried table when the query is multiline [IMP] sql_db: allow to track queried table on cursor outside --log-sql [IMP] website, test_website: strengthen the perf testing suite Forward-Port-Of: odoo/odoo#119268
Original PR description
[IMP] sql_db: find and log queried table when the query is multiline [IMP] sql_db: allow to track queried table on cursor outside --log-sql [IMP] website, test_website: strengthen the perf testing suite Forward-Port-Of: odoo/odoo#119268
Steps to reproduce the problem: - Drop a popup snippet in a page. - On another language, click on translate. - Problem -> It is impossible to translate the popup. To resolve this problem, the function `_updateInvisibleDOM` is called even in translation mode. Thanks to this function, the invisible snippets are now filled in the edit bar and the user has the opportunity to display them or to hide them. task-3098517 opw-3268592 Forward-Port-Of: odoo/odoo#121219 Forward-Port-Of: odoo/o
Original PR description
Steps to reproduce the problem: - Drop a popup snippet in a page. - On another language, click on translate. - Problem -> It is impossible to translate the popup. To resolve this problem, the function `_updateInvisibleDOM` is called even in translation mode. Thanks to this function, the invisible snippets are now filled in the edit bar and the user has the opportunity to display them or to hide them. task-3098517 opw-3268592 Forward-Port-Of: odoo/odoo#121219 Forward-Port-Of: odoo/odoo#112011
Before this commit, when posting a message in discuss with some urls, the url was not linkified. Example of such linkify not working: ``` https://www.45017478-master-all.runbot134.odoo.com/web ``` The url regexp was changed with [1] to make punctuation mark the end of url to linkify. The 1st dot removed in diff was a mistake. This commit reverts this part, so that url above is correctly linkified while fixing the problem of [1]. [1] https://github.com/odoo/odoo/pull/122621 Forward-
Original PR description
Before this commit, when posting a message in discuss with some urls, the url was not linkified. Example of such linkify not working: ``` https://www.45017478-master-all.runbot134.odoo.com/web ``` The url regexp was changed with [1] to make punctuation mark the end of url to linkify. The 1st dot removed in diff was a mistake. This commit reverts this part, so that url above is correctly linkified while fixing the problem of [1]. [1] https://github.com/odoo/odoo/pull/122621 Forward-Port-Of: odoo/odoo#124974
Before this commit, the seen indicator in squashed messages was not centered. This is especially noticeable in comparison to shorten date when hovering on this squashed message in chat window. before / after <img width="362" alt="before" src="https://github.com/odoo/odoo/assets/6569390/71ab961a-1ff0-4192-baa7-51744ed23fd0"> <img width="359" alt="after" src="https://github.com/odoo/odoo/assets/6569390/1dd7b633-7b8c-44e8-8264-2e7fd9007b24"> Forward-Port-Of: odoo/odoo#124993
Original PR description
Before this commit, the seen indicator in squashed messages was not centered. This is especially noticeable in comparison to shorten date when hovering on this squashed message in chat window. before / after <img width="362" alt="before" src="https://github.com/odoo/odoo/assets/6569390/71ab961a-1ff0-4192-baa7-51744ed23fd0"> <img width="359" alt="after" src="https://github.com/odoo/odoo/assets/6569390/1dd7b633-7b8c-44e8-8264-2e7fd9007b24"> Forward-Port-Of: odoo/odoo#124993
Steps to reproduce the bug (in 16.0): - Create a hoverable mega menu - Drop inline Search snippet inside the menu - Search for something. - Hover on the search result and move the cursor outside of the search result. => Result Error. Since [1], is having a fix to the overflows of the page. In that fix we are triggering hide(), and show() events on a 'dropdown-toggle' element without checking whether the element is exist in the target or not. this commit will make sure that element should
Original PR description
Steps to reproduce the bug (in 16.0): - Create a hoverable mega menu - Drop inline Search snippet inside the menu - Search for something. - Hover on the search result and move the cursor outside of the search result. => Result Error. Since [1], is having a fix to the overflows of the page. In that fix we are triggering hide(), and show() events on a 'dropdown-toggle' element without checking whether the element is exist in the target or not. this commit will make sure that element should be present in the target before triggering the event [1] : https://github.com/odoo/odoo/commit/5846a05fe7bf587d3bfb3ace3e863cb4abd52132 Forward-Port-Of: odoo/odoo#125004 Forward-Port-Of: odoo/odoo#118803
task-3237693 Forward-Port-Of: odoo/odoo#125015 Forward-Port-Of: odoo/odoo#124187
Original PR description
task-3237693 Forward-Port-Of: odoo/odoo#125015 Forward-Port-Of: odoo/odoo#124187
<img width="367" alt="Screenshot 2023-06-14 at 15 57 05" src="https://github.com/odoo/odoo/assets/6569390/56780fe7-0104-4fbf-b585-2ad87125555a"> Forward-Port-Of: odoo/odoo#125042
Original PR description
<img width="367" alt="Screenshot 2023-06-14 at 15 57 05" src="https://github.com/odoo/odoo/assets/6569390/56780fe7-0104-4fbf-b585-2ad87125555a"> Forward-Port-Of: odoo/odoo#125042
In case the journal currency is set on the company currency, we should compute the 'Bills to Pay' sum on amount_residual_signed as it is the residual amount in the company currency. In the current state, you can have differences between the sum in the dashboard and the sum showed in the list view from the 'Bills To Pay' button. Steps to reproduce (clean db with accounting): -Set a foreign currency with 2 different rates (significant if you want to see the issue clearly). -Create an invoi
Original PR description
In case the journal currency is set on the company currency, we should compute the 'Bills to Pay' sum on amount_residual_signed as it is the residual amount in the company currency. In the current…
In case the journal currency is set on the company currency, we should compute the 'Bills to Pay' sum on amount_residual_signed as it is the residual amount in the company currency. In the current state, you can have differences between the sum in the dashboard and the sum showed in the list view from the 'Bills To Pay' button. Steps to reproduce (clean db with accounting): -Set a foreign currency with 2 different rates (significant if you want to see the issue clearly). -Create an invoice in a sale/purchase journal which has no currency set (like Vendor Bills), with the foreign currency and with an invoice_date corresponding to one of the rate. -Register a payment for that invoice, with a date corresponding to the other rate and having an amount lower (like half) than the invoice, so the invoice is partially reconciled. -> Go to the accounting dashboard, the amount next to 'Bills to Pay' is different than the amount (the sum of the column 'Amount Due') in the list view generated after clicking that button. I think that these two values should be the same. They are currently different because the dashboard takes the amount_residual, which is expressed in the invoice currency, and apply the exchange rate to get the residual in the journal currency. But if the target currency is the company currency, the field amount_residual_signed is already the residual amount in the company currency. Unfortunately, in case of partial reconciliation, it is not always equal to amount_residual expressed in the company currency anymore. Because amount_residual and amount_residual_signed are substracted by the payment amount, expressed in each currency, using the payment date exchange rate. opw-3184567 Forward-Port-Of: odoo/odoo#124347 Forward-Port-Of: odoo/odoo#114603
The triangle pointing towards an option in the editor is pointing right. In a RTL setting, this does not make sense and should be mirrored. task-3284274 Forward-Port-Of: odoo/odoo#125091 Forward-Port-Of: odoo/odoo#120134
Original PR description
The triangle pointing towards an option in the editor is pointing right. In a RTL setting, this does not make sense and should be mirrored. task-3284274 Forward-Port-Of: odoo/odoo#125091 Forward-Port-Of: odoo/odoo#120134
After creating a sales order for a product with cost 0, automatic inventory valuation and AVCO, and validating the delivery, no account move is created for the stock move. If an invoice is then created from the sales order, it will create 0 amount COGS lines. Automatic reconciliation of the invoice with the corresponding stock account move will fail because no such entry exists, resulting in unreconciled lines remaining in the invoices. This issue can be prevented by either creating a 0 amoun
Original PR description
After creating a sales order for a product with cost 0, automatic inventory valuation and AVCO, and validating the delivery, no account move is created for the stock move. If an invoice is then created from the sales order, it will create 0 amount COGS lines. Automatic reconciliation of the invoice with the corresponding stock account move will fail because no such entry exists, resulting in unreconciled lines remaining in the invoices. This issue can be prevented by either creating a 0 amount journal entry for the stock move, or preventing the creation of the 0 amount COGS lines on the invoice. Not creating unnecessary COGS lines is preferable and this was also the solution used for the same problem with purchase order invoices: https://github.com/odoo/odoo/pull/106785 . So this fix does the same for sales order invoices. opw-3000320 Forward-Port-Of: odoo/odoo#125021 Forward-Port-Of: odoo/odoo#124125
Following an FP-Request, this PR aims to ease the life of the user by indicating the full name of the elements that are truncated due to their length as a tooltip. task-3332648 Forward-Port-Of: odoo/odoo#121963
Original PR description
Following an FP-Request, this PR aims to ease the life of the user by indicating the full name of the elements that are truncated due to their length as a tooltip. task-3332648 Forward-Port-Of: odoo/odoo#121963
Fix wrongly generated link when "Other" department filter is active (introduced by odoo/odoo@54f246f9c) To reproduce (on runbot): - Log-in as 'admin' - Go to the website /jobs page - Edit page and enable both 'Country' and 'Department' search filters then save changes - Choose "Others" in the departments filter - Choose any country in the countries filter => traceback with: `ValueError: invalid literal for int() with base 10: '233is_other_department=1'` --- I confirm I have signe
Original PR description
Fix wrongly generated link when "Other" department filter is active (introduced by odoo/odoo@54f246f9c) To reproduce (on runbot): - Log-in as 'admin' - Go to the website /jobs page - Edit page and enable both 'Country' and 'Department' search filters then save changes - Choose "Others" in the departments filter - Choose any country in the countries filter => traceback with: `ValueError: invalid literal for int() with base 10: '233is_other_department=1'` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#123020
In [HTTPocalypse] the `odoo/service/wsgi_server.py` file has been removed and its features has been spread to other files. One of the feature was reseting those few thread-local variables[^1] before processing any new request: if hasattr(threading.current_thread(), 'uid'): del threading.current_thread().uid if hasattr(threading.current_thread(), 'dbname'): del threading.current_thread().dbname if hasattr(threading.current_thread(), 'url'): del threadin
Original PR description
In [HTTPocalypse] the `odoo/service/wsgi_server.py` file has been removed and its features has been spread to other files. One of the feature was reseting those few thread-local variables[^1] before…
In [HTTPocalypse] the `odoo/service/wsgi_server.py` file has been removed and its features has been spread to other files. One of the feature was reseting those few thread-local variables[^1] before processing any new request:
if hasattr(threading.current_thread(), 'uid'):
del threading.current_thread().uid
if hasattr(threading.current_thread(), 'dbname'):
del threading.current_thread().dbname
if hasattr(threading.current_thread(), 'url'):
del threading.current_thread().url
In [HTTPocalypse] the `url`[^2] is correctly set at its definitive value at the beginning of the request so there is no need to delete it before processing.
On the other hand, `dbname`[^3][^4] and `uid`[^5] are only set when the request is processed by `_serve_db`, i.e. that the user is connected to a database already. Those values weren't reset at the begining of the next request so in case that next request was processed by `_serve_nodb` or `_serve_static`, the dbname and uid of the previous request would still be present.
This commit restores both `del uid` and `del dbname` at the beginning of the http stack, before the request is processed.
[HTTPocalypse]: odoo/odoo#78857
[^1]: https://github.com/odoo/odoo/blob/a1361d6629a829fd622f2a1a1b3e5b025050eaf9/odoo/service/wsgi_server.py#L80-L85
[^2]: https://github.com/odoo/odoo/blob/0e629cd2a1fc3623b579a38ae534fbdfae9b38a3/odoo/http.py#L1987
[^3]: https://github.com/odoo/odoo/blob/0e629cd2a1fc3623b579a38ae534fbdfae9b38a3/odoo/http.py#L1563
[^4]: https://github.com/odoo/odoo/blob/0e629cd2a1fc3623b579a38ae534fbdfae9b38a3/odoo/modules/registry.py#L70
[^5]: https://github.com/odoo/odoo/blob/0e629cd2a1fc3623b579a38ae534fbdfae9b38a3/odoo/http.py#L1582
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#124932
Forward-Port-Of: odoo/odoo#124842To reproduce: 1. Create a storable product with ordered quantities policy for purchase and with a category set as FIFO automated 2. Create a purchase order in a different currency and set quantities for partial deliveries 3. Create a partial delivery 4. Fully invoice the purchase order 5. Create the delivery of the complementary units 6. Check the stock valuation layer The valuation of backorder is wrong. The value on valuation layer is in company's currency, while the value on invoice
Original PR description
To reproduce: 1. Create a storable product with ordered quantities policy for purchase and with a category set as FIFO automated 2. Create a purchase order in a different currency and set quantities for partial deliveries 3. Create a partial delivery 4. Fully invoice the purchase order 5. Create the delivery of the complementary units 6. Check the stock valuation layer The valuation of backorder is wrong. The value on valuation layer is in company's currency, while the value on invoice line is in the PO's currency. When create valuation line for backorder, we didn't convert them to same currency. opw-3300266 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#125074 Forward-Port-Of: odoo/odoo#123118
Currently, a duplicate database (via SaaS, SH, or Local) does not neutralize social accounts. This means that in testing what is assumed to be a neutralized database, social media posts can still be sent. Solution: To fix this, we add a neutralization sql script to each module to clear the offending fields from `social.account` that is used to post to. Side Effect: This means that in neutralized databases, social media streams will fail to pull the latest posts or refresh the stream when
Original PR description
Currently, a duplicate database (via SaaS, SH, or Local) does not neutralize social accounts. This means that in testing what is assumed to be a neutralized database, social media posts can still be sent. Solution: To fix this, we add a neutralization sql script to each module to clear the offending fields from `social.account` that is used to post to. Side Effect: This means that in neutralized databases, social media streams will fail to pull the latest posts or refresh the stream when you click on one, however, this is better than being able to delete a post accidentally from a support duplicate. opw-3330423 Forward-Port-Of: odoo/enterprise#41225
Have a parent contact with a child contact having billing address with email Create an overdue invoice for the billing address contact Go to the Follow up report under customers and try to follow up via email Issue: The email sent will go to the company parent contact and not the child billing contact opw-3264529 Forward-Port-Of: odoo/enterprise#40615
Original PR description
Have a parent contact with a child contact having billing address with email Create an overdue invoice for the billing address contact Go to the Follow up report under customers and try to follow up via email Issue: The email sent will go to the company parent contact and not the child billing contact opw-3264529 Forward-Port-Of: odoo/enterprise#40615
Steps to reproduce: ------------------- - go to "My Timesheets" view; - open the chatter; - press ENTER in the chatter (as for sendinf a message). Issue: ------ Chatter inputs interact with timesheet dashboard. Solution: --------- Check that we are not in an 'input' or 'textarea' to interact with the dashboard. opw-3334853 Forward-Port-Of: odoo/enterprise#42543
Original PR description
Steps to reproduce: ------------------- - go to "My Timesheets" view; - open the chatter; - press ENTER in the chatter (as for sendinf a message). Issue: ------ Chatter inputs interact with timesheet dashboard. Solution: --------- Check that we are not in an 'input' or 'textarea' to interact with the dashboard. opw-3334853 Forward-Port-Of: odoo/enterprise#42543
When the user tries to access the partners in 'approvals' module from contacts, where in the context the category_id is 'active_id'. To reproduce the issue: - Install 'Approvals' - In Approvals, go to Configuration > Approvals Type - Select any type and change the 'Contact' field to 'Required' - Save the changes - Go to My Approvals > New Request - Click on any category - In 'Contacts' drop down list click on 'Search More...' - Error: A traceback appear: "ValueError: Expected singlet
Original PR description
When the user tries to access the partners in 'approvals' module from contacts, where in the context the category_id is 'active_id'. To reproduce the issue: - Install 'Approvals' - In Approvals, go…
When the user tries to access the partners in 'approvals' module from contacts, where in the context the category_id is 'active_id'.
To reproduce the issue:
- Install 'Approvals'
- In Approvals, go to Configuration > Approvals Type
- Select any type and change the 'Contact' field to 'Required'
- Save the changes
- Go to My Approvals > New Request
- Click on any category
- In 'Contacts' drop down list click on 'Search More...'
- Error: A traceback appear: "ValueError: Expected singleton: res.partner.category ('a', 'c', 't', 'i', 'v', 'e', '_', 'i', 'd')"
see:-
```
KeyError: ('res.partner', <function Model._get_view_cache at 0x7f348ffe25f0>, (False, 'form', None, 'en_US', None, res.company(1,), None, None))
File "odoo/tools/cache.py", line 91, in lookup
r = d[key]
File "<decorator-gen-3>", line 2, in __getitem__
File "odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "odoo/tools/lru.py", line 34, in __getitem__
a = self.d[obj]
ValueError: too many values to unpack (expected 1)
File "odoo/models.py", line 5379, in ensure_one
_id, = self._ids
ValueError: Expected singleton: res.partner.category('a', 'c', 't', 'i', 'v', 'e', '_', 'i', 'd')
File "odoo/http.py", line 2114, in __call__
response = request._serve_db()
File "odoo/http.py", line 1699, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1726, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1921, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 190, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 716, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 30, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 26, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 457, in call_kw
result = _call_kw_model(method, model, args, kwargs)
File "odoo/api.py", line 430, in _call_kw_model
result = method(recs, *args, **kwargs)
File "odoo/addons/base/models/ir_ui_view.py", line 2525, in get_views
result['views'] = {
File "odoo/addons/base/models/ir_ui_view.py", line 2526, in <dictcomp>
v_type: self.get_view(
File "odoo/addons/base/models/ir_ui_view.py", line 2710, in get_view
result = dict(self._get_view_cache(view_id, view_type, **options))
File "<decorator-gen-48>", line 2, in _get_view_cache
File "odoo/tools/cache.py", line 96, in lookup
value = d[key] = self.method(*args, **kwargs)
File "odoo/addons/base/models/ir_ui_view.py", line 2673, in _get_view_cache
arch, models = view.postprocess_and_fields(arch, model=self._name, **options)
File "odoo/addons/base/models/ir_ui_view.py", line 1050, in postprocess_and_fields
name_manager = self._postprocess_view(node, model or self.model, **options)
File "odoo/addons/base/models/ir_ui_view.py", line 1190, in _postprocess_view
postprocessor(node, name_manager, node_info)
File "odoo/addons/base/models/ir_ui_view.py", line 1323, in _postprocess_tag_form
result = name_manager.model.view_header_get(False, node.tag)
File "odoo/addons/base/models/res_partner.py", line 994, in view_header_get
category=self.env['res.partner.category'].browse(self.env.context['category_id']).name,
File "odoo/fields.py", line 1151, in __get__
record.ensure_one()
File "odoo/models.py", line 5382, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
The category_id is set to active_id which is passed as a string due to which the traceback is generated.
sentry-4237907737
Forward-Port-Of: odoo/enterprise#42481This commit fixes a bug where you would lose the optional columns set inside the embedded view when opening the view in fullscreen. This bug occurs because the optional columns are stored inside the localStorage under a key generated by the renderers, but in Knowledge we patched each view type to add the id of the embedded view, in order to have embedded views with different configuration. The problem is that when opening the embed in fullscreen the embedId is no longer taken into account ins
Original PR description
This commit fixes a bug where you would lose the optional columns set inside the embedded view when opening the view in fullscreen. This bug occurs because the optional columns are stored inside the localStorage under a key generated by the renderers, but in Knowledge we patched each view type to add the id of the embedded view, in order to have embedded views with different configuration. The problem is that when opening the embed in fullscreen the embedId is no longer taken into account inside the optionalFieldsKey, meaning that the view goes to its default state. We changed the override of `createKeyOptionalFields` inside `views_renderers_patches` to take into account the embeddedViewId that we are now adding in the additionalContext when executing the action of opening the view in fullscreen. task-3293109 Forward-Port-Of: odoo/enterprise#42275 Forward-Port-Of: odoo/enterprise#40635
`helpdesk_timesheet` module contains extra class (pt-3) in xpath which provides padding to the project_id field due to which gap between the 'timesheets' feature description and the project field increase. causes: in latest version new class is created which provide default margin to the fields. Therefore padding class is no required. solution: removed extra class (class=pt-3) from xpath in helpdesk_timesheet module. task-3187910 Forward-Port-Of: odoo/enterprise#37444
Original PR description
`helpdesk_timesheet` module contains extra class (pt-3) in xpath which provides padding to the project_id field due to which gap between the 'timesheets' feature description and the project field increase. causes: in latest version new class is created which provide default margin to the fields. Therefore padding class is no required. solution: removed extra class (class=pt-3) from xpath in helpdesk_timesheet module. task-3187910 Forward-Port-Of: odoo/enterprise#37444
[FIX] mail: Send message/log note in chatter style with MILK - Send button has text "Send" or "Log" depending on composer mode - When button is active, it has `btn-primary` and composer mode buttons use `btn-outline-primary` - Add hint to use Send keyboard shortcut for fast send in chatter Other changes: - Re-introduce missing feature to jump to present when posting a new message in a thread. - In chatter, the topbar and composer are sticky. Whole chatter is scrollable rather th
Original PR description
[FIX] mail: Send message/log note in chatter style with MILK - Send button has text "Send" or "Log" depending on composer mode - When button is active, it has `btn-primary` and composer mode buttons use `btn-outline-primary` - Add hint to use Send keyboard shortcut for fast send in chatter Other changes: - Re-introduce missing feature to jump to present when posting a new message in a thread. - In chatter, the topbar and composer are sticky. Whole chatter is scrollable rather than just a part of it. As a result, `Chatter-scrollable` becomes `Chatter-content`. - Editing a message in chatter now uses the extended composer Task-3356271 https://github.com/odoo/odoo/pull/124905 Forward-Port-Of: odoo/enterprise#42111
Before this commit, when a pdf was already generated from an invoice, the pdf was joined to the followup reminder, even if 'join_invoices' was set to False on the followup line. Steps: - Create a followup level to send an email and set 'join_invoices' field to False - Create an invoice - Go to Followup Reports - Select the customer from invoice above, and click on Follo Up button -> On the wizard, the join_invoices checkbox is unchecked but attachment is still attached, you can see i
Original PR description
Before this commit, when a pdf was already generated from an invoice, the pdf was joined to the followup reminder, even if 'join_invoices' was set to False on the followup line. Steps: - Create a followup level to send an email and set 'join_invoices' field to False - Create an invoice - Go to Followup Reports - Select the customer from invoice above, and click on Follo Up button -> On the wizard, the join_invoices checkbox is unchecked but attachment is still attached, you can see it if you check the checkbox, therefore the pdf will be joined to the email. With this comit, we remove the attachment if the checkbox is not checked on the wizard when processing the followup. opw-3328105 Forward-Port-Of: odoo/enterprise#42498
For financial reports, in a multi-company and multi-currency context, when activating the comparison with previous periods, only the currency rate of the first period is applied for all periods. Steps to reproduce (with demo-data and account_reports installed): -install a localization with a foreign currency (like `l10n_be`). -go to the new company. -create invoices with an invoice date from the previous months (like one in march, one in february, one in january). -go back to your first c
Original PR description
For financial reports, in a multi-company and multi-currency context, when activating the comparison with previous periods, only the currency rate of the first period is applied for all periods.…
For financial reports, in a multi-company and multi-currency context, when activating the comparison with previous periods, only the currency rate of the first period is applied for all periods. Steps to reproduce (with demo-data and account_reports installed): -install a localization with a foreign currency (like `l10n_be`). -go to the new company. -create invoices with an invoice date from the previous months (like one in march, one in february, one in january). -go back to your first company. -create different rates for the other company currency (one for march, one for february, one for january). -go the profit & loss report, being on the first company but with the other company activated. -Select 'Last Month' as date, then activate the comparison filter for several periods. ->only the rate of 'Last Month' will be applied for all periods, instead of one for each. The fix is to compute the rate for each period. opw-3262140 Forward-Port-Of: odoo/enterprise#42195 Forward-Port-Of: odoo/enterprise#41471
For the sake of consistency the half day should be grey in the time-off app. Simply changed the `hr.leave.gantt` precision tag for month from 'day:full' to 'day:half' task-3339041 Forward-Port-Of: odoo/enterprise#42009
Original PR description
For the sake of consistency the half day should be grey in the time-off app.
Simply changed the `hr.leave.gantt` precision tag for month from 'day:full' to 'day:half'
task-3339041
Forward-Port-Of: odoo/enterprise#42009Since the variable_contract variable is assigned in the condition `kw.get('employee_contract_id')` we get an error saying it is referenced before assignement if we don't go into the first condition Forward-Port-Of: odoo/enterprise#42496
Original PR description
Since the variable_contract variable is assigned in the condition `kw.get('employee_contract_id')` we get an error saying it is referenced before assignement if we don't go into the first condition
Forward-Port-Of: odoo/enterprise#42496The tour fails sometimes. Most probably because the first footnote was not always deleted instantly when clicking on the trash button. But the next step was on the wrong element, so it was on the one that was sometimes deleted before the test, sometimes not. Forward-Port-Of: odoo/enterprise#42476
Original PR description
The tour fails sometimes. Most probably because the first footnote was not always deleted instantly when clicking on the trash button. But the next step was on the wrong element, so it was on the one that was sometimes deleted before the test, sometimes not. Forward-Port-Of: odoo/enterprise#42476
When user input some string value in 'Taxcloud Category' in product form view. As the field 'Taxcloud Category' of 'code' field is integer as it is given as a 'rec_name'. It will give an error with the message - 'invalid literal for int() with base 10' Steps to Produce:- 1. Install 'account_taxcloud' module 2. Go to 'invoicing' module 3. Go to 'Vendors' -> 'Products' 4. Click on any product or create new 5. In 'TaxCloud Category' field input any string 6. Press enter Trace-ba
Original PR description
When user input some string value in 'Taxcloud Category' in product form view. As the field 'Taxcloud Category' of 'code' field is integer as it is given as a 'rec_name'. It will give an error with…
When user input some string value in 'Taxcloud Category' in product form view. As the field 'Taxcloud Category' of 'code' field is integer as it is given as a 'rec_name'.
It will give an error with the message -
'invalid literal for int() with base 10'
Steps to Produce:-
1. Install 'account_taxcloud' module
2. Go to 'invoicing' module
3. Go to 'Vendors' -> 'Products'
4. Click on any product or create new
5. In 'TaxCloud Category' field input any string
6. Press enter
Trace-back will be generated.
```
ValueError: invalid literal for int() with base 10: 'VAT TAX 18%'
File "odoo/http.py", line 2115, in __call__
response = request._serve_db()
File "odoo/http.py", line 1698, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1725, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1922, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 154, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 715, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 28, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 24, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 457, in call_kw
result = _call_kw_model(method, model, args, kwargs)
File "odoo/api.py", line 430, in _call_kw_model
result = method(recs, *args, **kwargs)
File "odoo/models.py", line 1603, in name_create
record = self.create({self._rec_name: name})
File "<decorator-gen-10>", line 2, in create
File "odoo/api.py", line 409, in _model_create_multi
return create(self, [arg])
File "odoo/models.py", line 4023, in create
records = self._create(data_list)
File "odoo/models.py", line 4203, in _create
colval = field.convert_to_column(stored[fname], self, stored)
File "odoo/fields.py", line 1406, in convert_to_column
return int(value or 0)
```
Applying these changes will resolve this issue.
sentry - 3960203288
Forward-Port-Of: odoo/enterprise#42271
Forward-Port-Of: odoo/enterprise#41551### Current behavior: In some instances, like when the customer is on a shared instance worker the query execution time is suboptimal resulting in significant delays in loading the KPI report in the subscription module. Missing indexes in standard fields primarily caused the issue and the query takes around 50 seconds to execute and sometimes it results in a deadlock. ### Error: Slow down in loading the KPI report. ### Expected behavior: Open KPI report with no problem. ### Fix: To
Original PR description
### Current behavior: In some instances, like when the customer is on a shared instance worker the query execution time is suboptimal resulting in significant delays in loading the KPI report in the subscription module. Missing indexes in standard fields primarily caused the issue and the query takes around 50 seconds to execute and sometimes it results in a deadlock. ### Error: Slow down in loading the KPI report. ### Expected behavior: Open KPI report with no problem. ### Fix: To address this issue, we added the necessary indexes and as a result, the query execution time improved significantly, reducing it from approximately 50 seconds to just 100 milliseconds. ### Affected versions: all > 14 opw-3249090 Forward-Port-Of: odoo/enterprise#42473 Forward-Port-Of: odoo/enterprise#41165
Currently, favorites are ignored if there is a saved SearchModel state for the embedded view. This commit forces the loading of favorites stored in the data-behavior-props attribute of embedded views behaviors. task-3349339 Forward-Port-Of: odoo/enterprise#41928
Original PR description
Currently, favorites are ignored if there is a saved SearchModel state for the embedded view. This commit forces the loading of favorites stored in the data-behavior-props attribute of embedded views behaviors. task-3349339 Forward-Port-Of: odoo/enterprise#41928