Thursday, November 14, 2024
78 changes
17 changes
Resolved issues and error corrections
Fixes an issue where the mailing editor sidebar could cover part of the editable email area after reopening a saved mailing based on a non-basic template. This helps users continue editing email campaigns without layout obstruction or confusion.
Original PR description
related commit: [1] Issue: ====== mass_mailing view is covered by the snippet sidebar Steps to reproduce the issue: ============================= - Create a new mass mailing with any template except the basic - Save it - Go back - Enter again to the mailing - The sidebar covers a part of the editable area Spec: ===== This is an application of the mentioned commit in the case when we don't have to select a new theme. opw-4227663 [1]: https://github.com/odoo/odoo/commit/3aa9a36ed47d0446e51c8dc991d0f7f6f2bacc80
Miscellaneous changes
To reproduce: Go to Accounting/Invoicing, Customers and create a new Customer. Delete it. You get an error talking about audit trail while you don't have it activated. The issue is that we block based on customer/supplier rank when there is no company on the partner. We now check if we should block the deletion of a message of a partner if this partner has at least one journal entry with a company that has audit trail activated. --- I confirm I have signed the CLA and read the
Original PR description
To reproduce: Go to Accounting/Invoicing, Customers and create a new Customer. Delete it. You get an error talking about audit trail while you don't have it activated. The issue is that we block based on customer/supplier rank when there is no company on the partner. We now check if we should block the deletion of a message of a partner if this partner has at least one journal entry with a company that has audit trail activated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181891
8 changes
Enhancements to existing features
52 changes
Enhancements to existing features
The Point of Sale interface now keeps input fields at a consistent width while users type during opening, cash movement, product search, and partner search flows. Receipt previews also stay the same width regardless of the company logo, making the checkout experience more stable and predictable.
Original PR description
Before this commit: ========== - The width of the input field changes when text is added during the session's opening, cash in/cash out, search products, and search partner processes. - The company logo affects the width of the PoS receipt preview. After this commit: ========== - The input field's width stays fixed while adding text during the session's opening, cash in/cash out, search products, and search partner processes. - The width of the PoS receipt preview remains fixed as well. task-4285446
1 change
Resolved issues and error corrections
This update ensures quality checks are only triggered for products that have actually been received into inventory. Previously, a product could trigger a quality check even if it was part of a pending order. This change corrects a bug related to backorders, improving inventory accuracy and preventing unnecessary quality check processes.
Original PR description
**Steps to reproduce the bug:** - Create a tracked product by SN: “P1.” - Create a storable product: "P2." - Create a receipt for one unit of P1 and P2. - Mark it as "To Do." - Set the done quantity of P1 to 0. - Attempt to perform the quality check. **Problem:** You must perform a quality check for P1 even though it has yet to be received. Since the move_line is set to 0 rather than deleted in the original picking, it will be linked to the backorder when it is created. Therefore, to avoid unexpected behavior we can ignore linking its quality check to the backorder. https://github.com/odoo/odoo/blob/00057f8efd3c728e13a981290a725878e058d2c6/addons/stock/models/stock_picking.py#L832 opw-4187521
When switching between threads, `composer.thread` changed but the func to remove the typing indicator was not called to the previous thread. The fix is to call the func to remove the typing indicator when the thread changes. task-4285488 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186808
Original PR description
When switching between threads, `composer.thread` changed but the func to remove the typing indicator was not called to the previous thread. The fix is to call the func to remove the typing indicator when the thread changes. task-4285488 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186808
**Steps to reproduce:** - Install l10n_mx_reports (not mandatory but easier to reproduce) - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Select "Last Month" as data filter - Select "Previous Month: 9" as comparison filter - Click on dropdown button next to PDF button - Click on a button that is displayed in front of the header of the report (e.g. XLSX) **Issue:** The action is not triggered. Once the butto
Original PR description
**Steps to reproduce:** - Install l10n_mx_reports (not mandatory but easier to reproduce) - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Reporting / Audit Reports /…
**Steps to reproduce:** - Install l10n_mx_reports (not mandatory but easier to reproduce) - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Go to "Accounting / Reporting / Audit Reports / Trial Balance" - Select "Last Month" as data filter - Select "Previous Month: 9" as comparison filter - Click on dropdown button next to PDF button - Click on a button that is displayed in front of the header of the report (e.g. XLSX) **Issue:** The action is not triggered. Once the button has been clicked, the dropdown menu disappears behind the header of the report. **Cause:** The buttons in the dropdown menu have z-index:1000 and the thead of the report has the z-index:999, which displays the buttons in front the header of the report. However, when clicked, the button becomes active and its z-index falls to 2, putting it behind the header. opw-4265087 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186277
Before this commit, elements on which tooltip were attached were used in a `Map` as keys. That caused the elements to be retained even after being detached from DOM. This commit changes the `Map` to a `WeakMap` to not keep the element's reference and clears properties that kept an element when the tooltip is closed. Forward-Port-Of: odoo/odoo#187053 Forward-Port-Of: odoo/odoo#186579
Original PR description
Before this commit, elements on which tooltip were attached were used in a `Map` as keys. That caused the elements to be retained even after being detached from DOM. This commit changes the `Map` to a `WeakMap` to not keep the element's reference and clears properties that kept an element when the tooltip is closed. Forward-Port-Of: odoo/odoo#187053 Forward-Port-Of: odoo/odoo#186579
Currently, if an order has a downpayment made from the POS, when we invoice it, the unit price of the downpayment becomes 0 on the sale order. The same flow using only sale will correctly show the downpayment price. Steps to reproduce: ------------------- * Create a quotation in the **Sale** app * In the **Point of Sale** app, open shop session * Create a downpayment for the order * Go back in the **Sale** app * Open sale order > Observation: The downpayment line has a price unit set
Original PR description
Currently, if an order has a downpayment made from the POS, when we invoice it, the unit price of the downpayment becomes 0 on the sale order. The same flow using only sale will correctly show the…
Currently, if an order has a downpayment made from the POS, when we invoice it, the unit price of the downpayment becomes 0 on the sale order. The same flow using only sale will correctly show the downpayment price. Steps to reproduce: ------------------- * Create a quotation in the **Sale** app * In the **Point of Sale** app, open shop session * Create a downpayment for the order * Go back in the **Sale** app * Open sale order > Observation: The downpayment line has a price unit set * If needed, deliver the items * Create an invoice (regular invoice) * Confirm the invoice * Go back to the sale order > Observation: The downpayment line has a price unit of 0.0 Why the fix: ------------ The difference between the two flows (pos/sale) mainly resides in those few lines: https://github.com/odoo/odoo/blob/b3b1fe6a78f9e5b6f1d993b5aa2fed11e33c793e/addons/sale/models/account_move.py#L75-L85 `dpl.invoice_lines` will include 2 items when using the sale flow whereas only one when making the downpayment in pos. Downpayments from pos are not automatically invoiced and even if they are, the model `pos.order.line` does not have the field `invoice_lines`. However each downpayment **sale order line** that comes from the POS is linked to its downpayment **pos order line** with the field `pos_order_line_ids`. The only element left in `dpl.invoice_lines` will not be counted as it is included in `real_invoice` (the current invoice). The idea of the fix is to include the price unit of the downpayment made in pos in this sum. opw-4160111 Forward-Port-Of: odoo/odoo#186753 Forward-Port-Of: odoo/odoo#185788
This commit fixes an issue where, in an editable list view on a small screen, once trying to modify a record the "Save" and "Discard" buttons doesn't appear. This is due to those buttons being put inside a dropdown... but hidden on small screen. Steps to reproduce (on a small screen): - Install CRM module - Go to CRM > Configuration > Pipeline > Tags - Try to modify one of the list's record ⇾ The "New" button disappears, but the "Save" and "Discard" buttons are not displayed Note: re
Original PR description
This commit fixes an issue where, in an editable list view on a small screen, once trying to modify a record the "Save" and "Discard" buttons doesn't appear. This is due to those buttons being put inside a dropdown... but hidden on small screen. Steps to reproduce (on a small screen): - Install CRM module - Go to CRM > Configuration > Pipeline > Tags - Try to modify one of the list's record ⇾ The "New" button disappears, but the "Save" and "Discard" buttons are not displayed Note: reported during the mobile tests conversion to HOOT in master. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187110
The rounding method 'HALF-UP' is confusing for regular users when they see it in the UI. Replacing the user-facing term by the less specific 'Nearest' is clearer, since people naturally expect that to round halves up. Also the other UI strings were in all caps and have been changed to capitalized strings. [opw-4266444](https://www.odoo.com/odoo/all-tasks/4266444) Related to https://github.com/odoo/enterprise/pull/73285 Forward-Port-Of: odoo/odoo#186279 Forward-Port-Of: odoo/odoo#186237
Original PR description
The rounding method 'HALF-UP' is confusing for regular users when they see it in the UI. Replacing the user-facing term by the less specific 'Nearest' is clearer, since people naturally expect that to round halves up. Also the other UI strings were in all caps and have been changed to capitalized strings. [opw-4266444](https://www.odoo.com/odoo/all-tasks/4266444) Related to https://github.com/odoo/enterprise/pull/73285 Forward-Port-Of: odoo/odoo#186279 Forward-Port-Of: odoo/odoo#186237
Versions -------- - 16.0 _(sale_product_configurator)_ - 17.0 _(website_sale_product_configurator)_ - 17.2 _(website_sale_product_configurator)_ Steps ----- 1. Have 2 products with variants; 2. for both, add the other as optional product; 3. in eCommerce, add one to the cart; 4. select the other in the product configurator. Issue ----- The attributes get messed up due to first product being listed twice in the wizard, once in the cart, and once as an option for the second produc
Original PR description
Versions -------- - 16.0 _(sale_product_configurator)_ - 17.0 _(website_sale_product_configurator)_ - 17.2 _(website_sale_product_configurator)_ Steps ----- 1. Have 2 products with variants; 2. for both, add the other as optional product; 3. in eCommerce, add one to the cart; 4. select the other in the product configurator. Issue ----- The attributes get messed up due to first product being listed twice in the wizard, once in the cart, and once as an option for the second product. Solution -------- ### Front-end: Get the IDs of the currently displayed product templates, and pass them to the controller when fetching additional variants. ### Back-end: Before rendering the configurator template, update the cache to remove the currently displayed products from the added product's `optional_product_ids` field. Re-add them after rendering is done. opw-4071002 opw-4189450 Forward-Port-Of: odoo/odoo#186789 Forward-Port-Of: odoo/odoo#185103
We were misconfiguring some accounts in ec localization: - Sale and purchase journals default accounts - Missing default valuation accounts on Adjustement and Production locations opw-4127252 Forward-Port-Of: odoo/odoo#183879 Forward-Port-Of: odoo/odoo#179361
Original PR description
We were misconfiguring some accounts in ec localization: - Sale and purchase journals default accounts - Missing default valuation accounts on Adjustement and Production locations opw-4127252 Forward-Port-Of: odoo/odoo#183879 Forward-Port-Of: odoo/odoo#179361
Description of the issue/feature this PR addresses: Updated the code to make sure that the context object includes the current context. This change makes it easier to use all the relevant context-specific info in the process. Current behavior before PR: Currently, it only adds the warehouse information to the context variable. Desired behavior after PR is merged: The context object will include the warehouse information and the current context, ensuring that all necessary context
Original PR description
Description of the issue/feature this PR addresses: Updated the code to make sure that the context object includes the current context. This change makes it easier to use all the relevant context-specific info in the process. Current behavior before PR: Currently, it only adds the warehouse information to the context variable. Desired behavior after PR is merged: The context object will include the warehouse information and the current context, ensuring that all necessary context data is properly included when making the call. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178546
Some users are using custom domains in their loyalty programs. This include using fields that are not loaded in the PoS. This will fix the specific usecase of one client. But this could be improved and fields should be loaded dynamically based on the needed fields. opw-4262960 Forward-Port-Of: odoo/odoo#186804
Original PR description
Some users are using custom domains in their loyalty programs. This include using fields that are not loaded in the PoS. This will fix the specific usecase of one client. But this could be improved and fields should be loaded dynamically based on the needed fields. opw-4262960 Forward-Port-Of: odoo/odoo#186804
use `assertSteps` to rather than `assert.verifySteps` to make sure the steps are executed in the correct order. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187191
Original PR description
use `assertSteps` to rather than `assert.verifySteps` to make sure the steps are executed in the correct order. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187191
The Send & Print dialog will not consider attachments that have the same name as removed ones, example: - Create an invoice - Confirm it - From the action menu: `Print` > `Invoice` - Download the file to disk - e.g. `INV_2024_00001.pdf` - Open the `Send & Print` dialog - Select `Email` only - Remove the generated attachment `INV_2024_00001.pdf` (on the dialog) - Add the `INV_2024_00001.pdf` attachment (the one on disk) - Send the email The invoice will not be attached to the email,
Original PR description
The Send & Print dialog will not consider attachments that have the same name as removed ones, example: - Create an invoice - Confirm it - From the action menu: `Print` > `Invoice` - Download the file to disk - e.g. `INV_2024_00001.pdf` - Open the `Send & Print` dialog - Select `Email` only - Remove the generated attachment `INV_2024_00001.pdf` (on the dialog) - Add the `INV_2024_00001.pdf` attachment (the one on disk) - Send the email The invoice will not be attached to the email, you can check in the chatter. This occurs because we filter out attachments by checking their names, and the name is the same as the auto-generated one. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4260237) opw-4260237 Forward-Port-Of: odoo/odoo#186489
Current Behavior: When an invoice is sent via Send & Print, is_move_sent is set to True. If the move is reverted to draft, is_move_sent is set to False. After that, if the invoice is resent via Send & Print, is_move_sent is not set to True again. To reproduce: 1. Optional: add the field is_move_sent to the view, to see its value 2. Create and confirm an invoice (is_move_sent = False) 3. Send it via the Send & Print button (is_move_sent = True) 4. Reset move to draft (is_move_sent = False
Original PR description
Current Behavior: When an invoice is sent via Send & Print, is_move_sent is set to True. If the move is reverted to draft, is_move_sent is set to False. After that, if the invoice is resent via Send & Print, is_move_sent is not set to True again. To reproduce: 1. Optional: add the field is_move_sent to the view, to see its value 2. Create and confirm an invoice (is_move_sent = False) 3. Send it via the Send & Print button (is_move_sent = True) 4. Reset move to draft (is_move_sent = False) 5. Confirm and send it again (is_move_sent = False) Desired behavior: is_move_sent should be set to True after being sent via Send & Print, even if it is not the first time the invoice is being sent. Fix: We don't reset the is_move_sent to False when we set the invoice to draft. opw-4245126 Backport of #170713 Forward-Port-Of: odoo/odoo#185830
## Issue: - When a database is set to a language other than English, the 'Expected Date' for product replenishment does not adapt according to the set vendor lead time. This issue does not occur when the database is set to English. ## Steps To Reproduce: - Create a storable product. - Define a vendor for this product and add a delivery lead time. - Navigate to the product template and click on the "Replenish" button. - Observe that in an English language setting, the schedule date is cal
Original PR description
## Issue: - When a database is set to a language other than English, the 'Expected Date' for product replenishment does not adapt according to the set vendor lead time. This issue does not occur when…
## Issue: - When a database is set to a language other than English, the 'Expected Date' for product replenishment does not adapt according to the set vendor lead time. This issue does not occur when the database is set to English. ## Steps To Reproduce: - Create a storable product. - Define a vendor for this product and add a delivery lead time. - Navigate to the product template and click on the "Replenish" button. - Observe that in an English language setting, the schedule date is calculated correctly considering the vendor's delivery lead time. - Change the language of the database to a different language. - Repeat the replenish process. - Observe that the schedule date is not calculated correctly. ## Solution: - Replaced route name check with action check in `_get_date_planned` for better reliability, as action-based conditions reduce errors compared to route name comparisons.. opw-4199660 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183552
To reproduce the issue: 1) Create a company A, with a branch B 2) Define a currency rate for A, for currency C 3) Open currency C's form view with only B as active company ==> The rate created in 2) is not shown Forward-Port-Of: odoo/odoo#187239
Original PR description
To reproduce the issue: 1) Create a company A, with a branch B 2) Define a currency rate for A, for currency C 3) Open currency C's form view with only B as active company ==> The rate created in 2) is not shown Forward-Port-Of: odoo/odoo#187239
This update adjusts how Odoo retrieves related records across several accounting, approvals, data cleaning, and helpdesk features. The change supports ongoing platform compatibility work and should help keep these workflows reliable without changing day-to-day user behavior.
Original PR description
odoo/odoo#185630 task-4139293
The mobile user menu tests were moved to a newer testing approach. This helps maintain confidence in the mobile interface while making future updates easier for the development team.
Original PR description
task-4028335
This update standardizes how session information is accessed, making it behave more like a regular dictionary. It affects appointment-related flows and helps keep future development more predictable while preserving key frequently used shortcuts.
Original PR description
The session must be used like a "classic" dictionnary. Only very frequently used keys will be accessible via a property. task-3305304
Resolved issues and error corrections
The PDF viewer used for signing and document previews now hides built-in buttons that were unnecessary or could cause confusion. This creates a more consistent, focused experience when users review or sign documents.
Original PR description
The native viewer of PDF.js adds some buttons that we don't want as useless or problematic. This commit aims to uniformize add remove these buttons. task-4286512
Code cleanup and technical improvements
This change restores the previous internal model naming approach after a related typing initiative was canceled. It helps keep the system aligned with established Odoo conventions without introducing functional changes for end users.
Original PR description
Following internal discussions, the python typing and inheritance task is canceled. The use of the class name instead of '_name' was done to allow notations such as `partner_id = fields.Many2one[base.ResParter](string='Partner')`. Since this notation is canceled, we put `_name` back (although the class name is sufficient). Partial revert: https://github.com/odoo/enterprise/pull/69762 https://github.com/odoo/odoo/pull/178200
Miscellaneous changes
**Before this PR:** Dragging and dropping documents from the TRASH to another folder will result in a traceback or user error. Dragging and dropping documents within the TRASH will trigger an unusual notification. **After this PR:** Disable dragging in the TRASH folder and inform the user with a valid reason. Task-4231709 Forward-Port-Of: odoo/enterprise#71633
Original PR description
**Before this PR:** Dragging and dropping documents from the TRASH to another folder will result in a traceback or user error. Dragging and dropping documents within the TRASH will trigger an unusual notification. **After this PR:** Disable dragging in the TRASH folder and inform the user with a valid reason. Task-4231709 Forward-Port-Of: odoo/enterprise#71633
We have 2 errors in the generation of report "Certificado de Retencion de la fuente" General setup: - With a CO Company - Open Vendor Journal and disable the "Electronic Invoice: DIAN 2.1" check - Create a Vendor Bill with a VAT 19% Tax and "4% RteFte S L", add bill date and confirm **Error 1** Go to Reports -> Certificado de Retencion de la fuente Error will raise ``` psycopg2.errors.UndefinedFunction: operator does not exist: text ->> unknown LINE 14: ...R || ' ' || "account_mo
Original PR description
We have 2 errors in the generation of report "Certificado de Retencion de la fuente" General setup: - With a CO Company - Open Vendor Journal and disable the "Electronic Invoice: DIAN 2.1" check -…
We have 2 errors in the generation of report "Certificado de Retencion de la fuente"
General setup:
- With a CO Company
- Open Vendor Journal and disable the "Electronic Invoice: DIAN 2.1" check
- Create a Vendor Bill with a VAT 19% Tax and "4% RteFte S L", add bill date and confirm
**Error 1**
Go to Reports -> Certificado de Retencion de la fuente
Error will raise
```
psycopg2.errors.UndefinedFunction: operator does not exist: text ->> unknown
LINE 14: ...R || ' ' || "account_move_line__account_id"."name"->>'en_US'...
^
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
```
**Error 2**
Enable and activate language "Spanish (Latin America)"
Go to Reports -> Certificado de Retencion de la fuente
Expand the partner for which the vendor was crated, click on PDF
Error will raise
```
psycopg2.errors.UndefinedTable: missing FROM-clause entry for table "aa"
LINE 21: GROUP BY rp.id , aa.id
```
opw-4284787
Forward-Port-Of: odoo/enterprise#72918Steps to reproduce: - Insert a non-odoo pivot - Add a formula with `=PIVOT.VALUE` or `PIVOT.HEADER` - Try to autofill => Traceback This commit fixes the issue by disabling the autofill for non-odoo pivots, as the autofill is not supported for them. Task: 4277518 Forward-Port-Of: odoo/enterprise#72564
Original PR description
Steps to reproduce: - Insert a non-odoo pivot - Add a formula with `=PIVOT.VALUE` or `PIVOT.HEADER` - Try to autofill => Traceback This commit fixes the issue by disabling the autofill for non-odoo pivots, as the autofill is not supported for them. Task: 4277518 Forward-Port-Of: odoo/enterprise#72564
Several common website landing pages are now treated as read-only when visitors use search or filtering options. This helps avoid unnecessary changes during browsing and can improve reliability and performance across public website areas such as events, forums, eCommerce, courses, profiles, and partner pages.
Original PR description
Some common 'landing pages' used in combination with search parameters can be set as read-only.
This update adjusts accounting report tests to match the newer way accounting entries receive their official numbers when they are posted, rather than while still in draft. It helps keep automated checks reliable after the related accounting behavior change, with no direct change expected for business users.
Original PR description
Description of the issue this commit addresses: The community PR linked to this one modified the naming behavior of moves and therefore tests have broken. This PR adapts thoses tests to the new…
Description of the issue this commit addresses: The community PR linked to this one modified the naming behavior of moves and therefore tests have broken. This PR adapts thoses tests to the new behavior. --- Old vs. New naming behavior: Let's consider an empty journal. In this journal three moves are added with decreasing date (move1 is the most recent, move2 is in the middle and move3 is the oldest). now we batch the moves and post them together. Before, the first move of a journal would consume the first sequence number upon its creation even in draft and subsequent moves in would be named "/". When batched and posted afterwards, in the `_compute_name()` method, a `.sorted()` would order the moves by date (account.move(3, 2, 1)) and would use that order to name them. As the first sequence number is burned, move3 will use the second number and move2 will use the third number in the sequence. Resulting names: move1: 1, move2: 3 and move3: 2. With x moves: move1: 1, move2: x, move3: x-1, move4: x-2, ... Now, since no sequence number name is ever assigned to a draft entry, upon their creation, all three moves are named "/". And then, when they are batched and posted. they will be ordered 3,2,1 just like before but when naming move3, the first sequence number isn't consumed anymore so it will be named 1, move2 will be name 2 and move1 will be name 3. Resulting names: move1: 3, move2: 2 and move3: 1. With x moves: move1: x, move2: x-1, move3: x-2, move4: x-3, ... --- Desired behavior after this commit is merged: Tests that were relying on the fact that the first move of a sequence uses the first sequence number upon creation and not when posted are now adapted to take into account that sequence number are consumed when posted. --- Community PR: https://github.com/odoo/odoo/pull/185326 task-4241510
Resolved issues and error corrections
Fixes an issue in the HTML editor color picker where choosing the radial gradient option that extends to the farthest corner would not stay selected on the first attempt. This makes gradient styling more predictable for users editing text or backgrounds.
Original PR description
**Behaviour before PR:** Steps to reproduce issue: - Add some text, select it. - Open color picker to apply text or background color. - Switch the gradient tab, select radial gradient type. - Try to…
**Behaviour before PR:** Steps to reproduce issue: - Add some text, select it. - Open color picker to apply text or background color. - Switch the gradient tab, select radial gradient type. - Try to select 4th option of size (extend to the farthest corner). - Selected option is deselected and gets switched to first option. - If we try to select it again then it gets selected. The issue happens because `fathest-corner` is the default size parameter for radial gradient. When we apply background-image property for farthest-corner it gets simplified later and rendered without keyword `'farthest-size'`. E.g.` radial-gradient(circle farthest-corner at 50% 50%, rgb(255,..` will be simplified to `radial-gradient(circle at 50% 50%, rgb(255,..` Due to this reason when we get background-image property using `style['background-image']` we get simplified value. As result in `setGradientFromString` method regex fails to extract the value of `'farthest-corner'` and `state.size` is set to `'closest-side'` which is our first option. **Desired behaviour after PR:** Now, default size is set to `'farthest-corner'` and 4th option is selectable. task-4240711 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the translation button behavior when editing the base structure of form views. It helps administrators using technical settings access translations reliably after a previous interface structure change.
Original PR description
The html structure translation button is changed in https://github.com/odoo/odoo/pull/184900 This commit fixes the hack for the translation button for ir.ui.view.arch_base reproduce the bug Settings -> Technical -> Views -> open any form view  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
Order lines in Point of Sale and restaurant orders are now only marked as changed when they have actually been edited. This avoids unnecessary follow-up synchronization work and helps keep order status more accurate.
Original PR description
Before this commit, lines was always set as dirty when synchronizing orders. This was due to the fact that the line was marked as dirty in the synchronization process, even if the line was not modified. This commit fixes this issue by only marking the line as dirty if it has been modified. taskId: 4314110
This fix adds a missing dependency so purchase orders can correctly calculate related repair counts. It prevents setup or loading issues when the repair and purchasing features are used together without relying on automatic module installation order.
Original PR description
The field [`purchase.order.repair_count`](https://github.com/odoo/odoo/blob/a4b21175dec1c09b0b02e31350de4b9848fa1728/addons/purchase_repair/models/purchase_order.py#L8-L13) depends on field `order_line.move_dest_ids.repair_id`, and [`move_dest_ids`](https://github.com/odoo/odoo/blob/a4b21175dec1c09b0b02e31350de4b9848fa1728/addons/purchase_stock/models/purchase_order_line.py#L28) is defined in module `purchase_stock`, but it is not an explicit dependency and the autoinstall does not guarantee the existence of the module. Fixing the dependency to ensure the field `purchase.order.repair_count` can be computed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes the background color used in the outstanding credits section of customer invoices when dark mode is enabled. It improves readability and visual consistency for users reviewing invoice credits.
Original PR description
Fix the background color for customer invoices on the outstanding credits section. task-4326841 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Discuss app now displays the Threads and Invite People popovers at a stable width, preventing unwanted horizontal scrolling. This makes these actions easier to read and use, especially in constrained panel layouts.
Original PR description
Before this commit, the "Threads" and "Invite People" actions in Discuss app could overflow and have horizontal scroll. This happens because the `ActionPanel` has some responsive width when in a…
Before this commit, the "Threads" and "Invite People" actions in Discuss app could overflow and have horizontal scroll. This happens because the `ActionPanel` has some responsive width when in a panel, but these panels could also be displayed in popover in which this rule shouldn't apply. This commit fixes the issue by fixing a constant width to these action panels in popover, with similar width as the messaging menu. Task-4292021 Before / After - Threads <img width="400" alt="Screenshot 2024-11-13 at 18 42 41" src="https://github.com/user-attachments/assets/5701333c-9623-4ae8-bc10-0900251d353f"> <img width="593" alt="Screenshot 2024-11-13 at 18 45 41" src="https://github.com/user-attachments/assets/62393043-5a88-468d-acde-7fbee837be2e"> Before / After - Invite People <img width="407" alt="Screenshot 2024-11-13 at 18 42 48" src="https://github.com/user-attachments/assets/03025c09-1e9c-4790-a708-627f0aa731ec"> <img width="691" alt="Screenshot 2024-11-13 at 18 43 10" src="https://github.com/user-attachments/assets/8ef9ad7c-d7b1-4a44-a0b3-f1e4525e0fa4">
This fix speeds up an automated website menu editing test so it is less likely to fail because of timing limits. It helps keep quality checks reliable without changing the customer-facing website experience.
Original PR description
In this commit, we force checkDelay to 100ms (default is 500ms) to make the tour faster and avoid script timeout exceeded error. 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 fix removes an unnecessary warning from the mail-related logs by correcting how a text replacement option is passed internally. It helps keep system logs cleaner and avoids distracting administrators with a harmless technical warning.
Original PR description
Description of the issue/feature this PR addresses: Passing the regex flags in place of positional argument `count` generates a warning. Pass correct argument to `re.sub()` Current behavior before PR: Warning appears in log about incorrect use of positional parameter `count`. Desired behavior after PR is merged: No warning appears in log by `mail` addon due to usage of `re.sub`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A typo in the sale PDF quote builder test was corrected. This helps keep automated checks reliable and prevents false test failures during development.
Original PR description
There was a typo in test_pdf_qoute_builder. This commit corrects it. [broken test](https://runbot.odoo.com/web#id=74907&view_type=form&model=runbot.build.error&menu_id=405&cids=1) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers paying through Worldline are now sent back to the website where they started checkout, even when the business runs multiple websites. This prevents users from landing on the wrong site after payment and keeps the checkout experience consistent.
Original PR description
In multi-website context, we should return the user to the root of the origin website which is not necessarily the same as the one from `web.base.url` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an installation problem where the Repair module could fail if Inventory was already installed but not yet updated. The change makes the Repair setup compatible with both older and newer Inventory layouts, reducing upgrade and installation interruptions.
Original PR description
Following https://github.com/odoo/odoo/pull/186831, the installation of the repair module would fail if stock was previously installed without upgrading it first. This is due to the new xpath defined…
Following https://github.com/odoo/odoo/pull/186831, the installation of the repair module would fail if stock was previously installed without upgrading it first. This is due to the new xpath defined in the repair module that reference the changed form in the stock module. However, if stock wasn't upgraded, then the new label / div don't exist yet, leading to an error as the xpaths link to something that doesn't exist yet. This means that this patch needs to work with two possible versions of stock: - The old one, with only <field> in the form - The new one, with <field> and <label> in the form Due to that singular situation, it made the declaration of xpath in repair impossible to have a proper target, as both versions of stock would require different targets and cannot co-exist. To solve that situation, the choice was made to overwrite completely the common ancestor of the two versions (i.e. the locations <group>) and write it back in repair as if every previously declared xpath have been applied to it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue in Belgian reporting where a description could be too short for expected form requirements. It helps keep generated tax/reporting forms compliant and reduces the risk of validation errors during submission.
Original PR description
The aim of this commit is Context: Before the commit: After the commit: Community-PR: Enterprise-PR: Upgrade-PR: task-id:
Sign request emails now use the recipient-selected language consistently across both the message body and email layout. This avoids mixed-language emails, making signature requests clearer and more professional for recipients.
Original PR description
**Email layout is not translated to targeted sender's language with Sign mails** Impacted versions: - 18.0 Steps to reproduce: 1. Create a partner with language other than the current user's language. 2. Create a sign request and send the request to the created partner. 3. The strings from the email layout like Odoo's `Powered By` and `Your Document` (Your Signature Request) are not translated to the partner's language, but translated with the user's language. This differs from the language in the body. Current behavior: Before this commit, the language of the logged in user and the language given in kwargs would be used to translate the content. The email layout would translate to the user language and the body content would use the kwarg's language. This lead to translation discrepancies. Expected behavior: After this commit, only the language given in the kwargs is used and therefore fixing the translations issues.
Code cleanup and technical improvements
This update reorganizes how the HTML editor coordinates toolbar actions, shortcuts, power buttons, and internal editor events. It makes the editor code clearer and easier to maintain, reducing future development and debugging complexity without changing the intended user experience.
Original PR description
# Use delegate There is a common pattern in the editor plugins where we allow other plugins to take over the handling of a command. In order to make it explicit in the code, this commit introduces a…
# Use delegate There is a common pattern in the editor plugins where we allow other plugins to take over the handling of a command. In order to make it explicit in the code, this commit introduces a new utility function called delegate that will be used to call the handlers. # Use trigger In the editor, the pattern to dispatch events from one plugin to other plugins is to use the resource mechanism that aggregates callbacks to a specific resource. In order to make it clear when reading code that we want to dispatch an event, this commit introduces the util function trigger that communicates the intent to the reader. # Remove dispatch Reasons: 1) It is a redundant mechanism, we can achieve the same result though the use of shared and resources. 2) Using the shared or the resources is more explicit. If we need to call a command from a specific plugin, we should depend on the plugin and use the shared. If we need multiple plugins to react to an "event", we should use the resources. 3) We should distinguish between a "user command" and a "system command" or "system event". - A "user command" is anything that a user could configure as a shortcut, toolbar item, powerbox item, or power button. - A "system command" is a shared method. - A "system event" is a resource. 4) When debugging, it was harder to "step into" a dispatched command as we would step into the `handleCommand` of every plugins. For `toolbarItems` and `powerboxItems` now inherit the properties of a user command through the `commandId` property (if specified). The power buttons now use the definition of the user commands instead of the powerbox items. The `toolbarItem` `Component` does not includes dispatch in the props by default anymore, we need to specify the callbacks in the props of the `toolbarItem` explicitly.
Miscellaneous changes
Problem: Account tour was reworked in 17.4, but the markup was lost in the initial `goToAccountMenu` step Solution: Restore the markup to display message as intended opw-4311046 Forward-Port-Of: odoo/odoo#186345
Original PR description
Problem: Account tour was reworked in 17.4, but the markup was lost in the initial `goToAccountMenu` step Solution: Restore the markup to display message as intended opw-4311046 Forward-Port-Of: odoo/odoo#186345
In [1], the gauge widget was converted to OWL, but the option to use the widget with a fixed `max_value` was removed. This commit restores that functionality in the OWL framework. [1]: https://github.com/odoo/odoo/commit/e857e8d7 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186958 Forward-Port-Of: odoo/odoo#185620
Original PR description
In [1], the gauge widget was converted to OWL, but the option to use the widget with a fixed `max_value` was removed. This commit restores that functionality in the OWL framework. [1]: https://github.com/odoo/odoo/commit/e857e8d7 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186958 Forward-Port-Of: odoo/odoo#185620
rendererProps was not called on the component. This causes issues when assigning a variable on `this` and referencing it later. See: https://github.com/odoo/owl/commit/df59ec49aefce2e0913fdc1792d42b9680fb28b6 https://github.com/odoo/odoo/commit/f76955a5615cf7950c014c4f7a64d8f3aeafdda0 Forward-Port-Of: odoo/odoo#187074 Forward-Port-Of: odoo/odoo#186814
Original PR description
rendererProps was not called on the component. This causes issues when assigning a variable on `this` and referencing it later. See: https://github.com/odoo/owl/commit/df59ec49aefce2e0913fdc1792d42b9680fb28b6 https://github.com/odoo/odoo/commit/f76955a5615cf7950c014c4f7a64d8f3aeafdda0 Forward-Port-Of: odoo/odoo#187074 Forward-Port-Of: odoo/odoo#186814
This commit fixes an issue where, in an editable list view on a small screen, once trying to modify a record the "Save" and "Discard" buttons doesn't appear. This is due to those buttons being put inside a dropdown... but hidden on small screen. Steps to reproduce (on a small screen): - Install CRM module - Go to CRM > Configuration > Pipeline > Tags - Try to modify one of the list's record ⇾ The "New" button disappears, but the "Save" and "Discard" buttons are not displayed Note: re
Original PR description
This commit fixes an issue where, in an editable list view on a small screen, once trying to modify a record the "Save" and "Discard" buttons doesn't appear. This is due to those buttons being put inside a dropdown... but hidden on small screen. Steps to reproduce (on a small screen): - Install CRM module - Go to CRM > Configuration > Pipeline > Tags - Try to modify one of the list's record ⇾ The "New" button disappears, but the "Save" and "Discard" buttons are not displayed Note: reported during the mobile tests conversion to HOOT in master. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187110
Currently, a traceback occurs when the user tries to duplicate multiple pos payment methods. To reproduce this issue: 1) Install Point of Sale 2) Try to duplicate multiple payment methods from the POS configuration Error:- ``` ValueError: Expected singleton: account.journal(14, 18) ``` This is because of the changes from the recent commit https://github.com/odoo/odoo/pull/175530/commits/0fbd47bdd2fe06feda7df747e8560b810a666386 In `copy` method, when multiple records are dupli
Original PR description
Currently, a traceback occurs when the user tries to duplicate multiple pos payment methods. To reproduce this issue: 1) Install Point of Sale 2) Try to duplicate multiple payment methods from the…
Currently, a traceback occurs when the user tries to duplicate multiple pos payment methods. To reproduce this issue: 1) Install Point of Sale 2) Try to duplicate multiple payment methods from the POS configuration Error:- ``` ValueError: Expected singleton: account.journal(14, 18) ``` This is because of the changes from the recent commit https://github.com/odoo/odoo/pull/175530/commits/0fbd47bdd2fe06feda7df747e8560b810a666386 In `copy` method, when multiple records are duplicated it executed the method at multiple times. so `self` should have a single record at a time. From the `saas-17.2`, the `copy` method changes to `copy_data`, So it is executed at a time when the `self` having multiple recordsets. This leads to a traceback as `self.journal_id.type` is used. https://github.com/odoo/odoo/blob/88604332ae37d75c1435a298319a378841abf25a/addons/point_of_sale/models/pos_payment_method.py#L166-L168 sentry-5790593911 Forward-Port-Of: odoo/odoo#187061 Forward-Port-Of: odoo/odoo#179058
mrp: fix 2 state concerns correctly track production fields avoid recursion error --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187040 Forward-Port-Of: odoo/odoo#185092
Original PR description
mrp: fix 2 state concerns correctly track production fields avoid recursion error --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187040 Forward-Port-Of: odoo/odoo#185092
When a failure occurs when sending an email or a sms, it is displayed in the messaging menu. Before this PR, it could not be removed after a record was deleted. Steps to reproduce: - Send a message on a record, add a recipient with an incorrect email. - A red enveloppe is displayed next to the message and a notification is added in the messaging menu. - Delete this record. - Try to mark this failure as read. - Nothing happens. This occurs because the message deletion is only notified
Original PR description
When a failure occurs when sending an email or a sms, it is displayed in the messaging menu. Before this PR, it could not be removed after a record was deleted. Steps to reproduce: - Send a message on a record, add a recipient with an incorrect email. - A red enveloppe is displayed next to the message and a notification is added in the messaging menu. - Delete this record. - Try to mark this failure as read. - Nothing happens. This occurs because the message deletion is only notified to the recipients, not the author. This PR fixes the issue. opw-4272165 Forward-Port-Of: odoo/odoo#186595 Forward-Port-Of: odoo/odoo#186000
Use cases: send an email to "Bike@Home" <info@bike.com> (name containing @) "robert@exampl.com" <robert@example.com> (result of partner name_create) When there is an email in the name field, emails are sent twice and thus may be counted twice in various tooling, introduce unwanted or extra recipients, ... This happens notably due to https://github.com/odoo/odoo/commit/795091c69d2bc40e3bd2b5ae29451ea3af07d908 combined to https://github.com/odoo/odoo/pull/74474 which improved support of
Original PR description
Use cases: send an email to "Bike@Home" <info@bike.com> (name containing @) "robert@exampl.com" <robert@example.com> (result of partner name_create) When there is an email in the name field, emails…
Use cases: send an email to "Bike@Home" <info@bike.com> (name containing @) "robert@exampl.com" <robert@example.com> (result of partner name_create) When there is an email in the name field, emails are sent twice and thus may be counted twice in various tooling, introduce unwanted or extra recipients, ... This happens notably due to https://github.com/odoo/odoo/commit/795091c69d2bc40e3bd2b5ae29451ea3af07d908 combined to https://github.com/odoo/odoo/pull/74474 which improved support of multiemails and formatted emails in various email input. This notably leads to better formatted email computation on partner that generates emails like '"email@example.com" <email@example.com>' when email is used both as name and email. When sending emails to this partner only a single email should be sent and counted. A fix is been done to remove duplicates in that tool, making the returned list unique. In this PR we allow to receive a pre-validated list of emails that restricts emails found by 'extract_rfc2822'. When going through classic flows, we already computed emails using 'email_split' and its subtools, hence we just need the encoding check of 'extract_rfc2822'. Additional emails found by that tool are ignored as we consider those are fake emails. This PR contains tests and fixes related to that issue as well as multi and formatted emails management. Task-3704658 Forward-Port-Of: odoo/odoo#186967 Forward-Port-Of: odoo/odoo#185793
Before this commit, elements on which tooltip were attached were used in a `Map` as keys. That caused the elements to be retained even after being detached from DOM. This commit changes the `Map` to a `WeakMap` to not keep the element's reference and clears properties that kept an element when the tooltip is closed. Forward-Port-Of: odoo/odoo#187053 Forward-Port-Of: odoo/odoo#186579
Original PR description
Before this commit, elements on which tooltip were attached were used in a `Map` as keys. That caused the elements to be retained even after being detached from DOM. This commit changes the `Map` to a `WeakMap` to not keep the element's reference and clears properties that kept an element when the tooltip is closed. Forward-Port-Of: odoo/odoo#187053 Forward-Port-Of: odoo/odoo#186579
- Update CoA - Update taxes - Update tax groups - Update reports - Update fiscal positions Courtesy of `Editor.si` for providing data in order to update the files. Enterprise PR: odoo/enterprise#65817 Task [link](https://www.odoo.com/odoo/project/967/tasks/3901247) task-3901247 Forward-Port-Of: odoo/odoo#166559
Original PR description
- Update CoA - Update taxes - Update tax groups - Update reports - Update fiscal positions Courtesy of `Editor.si` for providing data in order to update the files. Enterprise PR: odoo/enterprise#65817 Task [link](https://www.odoo.com/odoo/project/967/tasks/3901247) task-3901247 Forward-Port-Of: odoo/odoo#166559
Before this commit: When a user creates multiple scheduled activities and clicks the "Close" button the newly created activities are not updated in the activity view. After this commit: When a user creates multiple scheduled activities and clicks the "Close" button, the newly created activities should update and visible in the activity view. Task-4057815 Forward-Port-Of: odoo/odoo#187049 Forward-Port-Of: odoo/odoo#180304
Original PR description
Before this commit: When a user creates multiple scheduled activities and clicks the "Close" button the newly created activities are not updated in the activity view. After this commit: When a user creates multiple scheduled activities and clicks the "Close" button, the newly created activities should update and visible in the activity view. Task-4057815 Forward-Port-Of: odoo/odoo#187049 Forward-Port-Of: odoo/odoo#180304
Version: - saas 17.4 Steps to reproduce: - Install the website_sale module. - Open the pricelist and apply a discount to a product. Issue: - The discount price on the product page appears in a red "danger" color. Solution: - Changed the text class from "text-danger" to "text-muted" to fix the issue. opw-4277128 Forward-Port-Of: odoo/odoo#185038
Original PR description
Version: - saas 17.4 Steps to reproduce: - Install the website_sale module. - Open the pricelist and apply a discount to a product. Issue: - The discount price on the product page appears in a red "danger" color. Solution: - Changed the text class from "text-danger" to "text-muted" to fix the issue. opw-4277128 Forward-Port-Of: odoo/odoo#185038
Issue: Currently, if the related user is removed from an employee, the link with the res.partner is also removed. This makes it impossible to post expense reports, as a partner is required to do so. To reproduce: 1. Create a new user. 2. Click ‘Create Employee’ in the user view 3. Go to the employee through the smart button 4. In the tab HR Settings, remove the related user 5. Create an expense report and try to post it (Expenses => New => Create Report => Submit to Manager => Approve =
Original PR description
Issue: Currently, if the related user is removed from an employee, the link with the res.partner is also removed. This makes it impossible to post expense reports, as a partner is required to do so.…
Issue: Currently, if the related user is removed from an employee, the link with the res.partner is also removed. This makes it impossible to post expense reports, as a partner is required to do so. To reproduce: 1. Create a new user. 2. Click ‘Create Employee’ in the user view 3. Go to the employee through the smart button 4. In the tab HR Settings, remove the related user 5. Create an expense report and try to post it (Expenses => New => Create Report => Submit to Manager => Approve => Post Journal Entries) 6. An error message about missing vendor (res.partner) appears Cause: The field work_contact_id keeps the link between hr.employee and res.partner, and is updated in the function _sync_user. Since work_contact_id=user.partner_id.id, when the user is removed from the hr.employee, work_contact_id is also removed. Fix: The link between hr.employee and res.partner should be kept until the user is assigned to another employee. In this case, the partner associated to the user should also be associated with the second employee, and no longer to the first employee. To do so, _sync_user assigns _origin.user_partner_id to work_contact_id if no user is passed (in case the user is removed). A helper function is called when creating or writing an employee, to unlink the partner and the previous employee in case the user is assigned to another employee. task-4049996 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186998 Forward-Port-Of: odoo/odoo#175478
This commit adds a new helper to create a headless model from grid data. This helper is used for a test in enterprise, but should be used in the future. Task: 4277518 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#184826
Original PR description
This commit adds a new helper to create a headless model from grid data. This helper is used for a test in enterprise, but should be used in the future. Task: 4277518 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#184826
Before this commit, the tester did not account for the use of an SQL wrapper inside of the constructor of an other SQL wrapper, This lead to a RecusionError when trying to infer the value of the Call node. This simple fix prevent the check of an other SQL wrapper during the classical call node analysis. This Call node would be analysed anyway during the visit_call function. Forward-Port-Of: odoo/odoo#187071
Original PR description
Before this commit, the tester did not account for the use of an SQL wrapper inside of the constructor of an other SQL wrapper, This lead to a RecusionError when trying to infer the value of the Call node. This simple fix prevent the check of an other SQL wrapper during the classical call node analysis. This Call node would be analysed anyway during the visit_call function. Forward-Port-Of: odoo/odoo#187071
The aim of this commit is to prevent traceback when mapping local and eu taxes to oss taxes. Before the commit: If the company chart template to use resolves to a CoA coming from a module not installed, it will crash when trying to resolve the xml_id for that specific localization. After the commit: If the l10n module isn't installed, it won't try to reference any tax tag as the tax report line wouldn't be there anyway Note: 1) This case is unlikely as if the customer has a vat n
Original PR description
The aim of this commit is to prevent traceback when mapping local and eu taxes to oss taxes. Before the commit: If the company chart template to use resolves to a CoA coming from a module not installed, it will crash when trying to resolve the xml_id for that specific localization. After the commit: If the l10n module isn't installed, it won't try to reference any tax tag as the tax report line wouldn't be there anyway Note: 1) This case is unlikely as if the customer has a vat number for a specific country, it means they have a tax report to fill and thus must have installed the related localization either as main CoA or as a foreing fiscal position. 2) This was spotted through a runbot single l10n build error. Nevertheless, it is something that is possible and thus should be working smoothly. runbot-100532 Forward-Port-Of: odoo/odoo#186942
When manually assigning leads to salespeople in a team, only leads created in the past 7 days were being assigned. If all leads were created more than 7 days ago, they would not be assigned, causing missed assignments. To fix this, the parameter `creation_delta_days` is now set to 0 during manual assignment, bypassing the 7-day creation filter. This ensures that all leads, regardless of creation date, are assignable manually. https://github.com/odoo/odoo/blob/saas-17.4/addons/crm/models/crm_t
Original PR description
When manually assigning leads to salespeople in a team, only leads created in the past 7 days were being assigned. If all leads were created more than 7 days ago, they would not be assigned, causing…
When manually assigning leads to salespeople in a team, only leads created in the past 7 days were being assigned. If all leads were created more than 7 days ago, they would not be assigned, causing missed assignments. To fix this, the parameter `creation_delta_days` is now set to 0 during manual assignment, bypassing the 7-day creation filter. This ensures that all leads, regardless of creation date, are assignable manually. https://github.com/odoo/odoo/blob/saas-17.4/addons/crm/models/crm_team.py#L441#L445 Steps to reproduce: 1. Go to CRM settings and activate `Rule-Based Assignment` and `Leads`. 2. Navigate to CRM Configuration > Sales Teams. 3. Create a new sales team with `Leads` active. 4. Add a member to the team, save, and try to assign leads. Expected behavior: All leads, regardless of creation date, should be assignable when manually assigned. opw-4217088 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185529
Description of the issue/feature this PR addresses: Current l10n_sa_edi module does not affect POS behavior, such as forcing Invoice creation on POS orders for Saudi companies Current behavior before PR: Invoicing on POS orders is not enforced for Saudi Companies Desired behavior after PR is merged: Invoicing on POS orders is enforced for Saudi Companies --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170303 Fo
Original PR description
Description of the issue/feature this PR addresses: Current l10n_sa_edi module does not affect POS behavior, such as forcing Invoice creation on POS orders for Saudi companies Current behavior before PR: Invoicing on POS orders is not enforced for Saudi Companies Desired behavior after PR is merged: Invoicing on POS orders is enforced for Saudi Companies --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170303 Forward-Port-Of: odoo/odoo#124300
When you made a downpayment on an order that contained product with fixed amount taxes, the tax would be paid multiple times. Steps to reproduce: ------------------- * Create a tax T1 with a fixed amount of 10€ * Create a product P1 using the tax T1 * Make a sale order and add the product P1 to it * Open PoS and make a downpayment for the sale order (e.g 50%) * You will already pay the 10€ of tax * Now if you make a second downpayment (e.g. 10%) > Observation: You still have the 10€ t
Original PR description
When you made a downpayment on an order that contained product with fixed amount taxes, the tax would be paid multiple times. Steps to reproduce: ------------------- * Create a tax T1 with a fixed amount of 10€ * Create a product P1 using the tax T1 * Make a sale order and add the product P1 to it * Open PoS and make a downpayment for the sale order (e.g 50%) * You will already pay the 10€ of tax * Now if you make a second downpayment (e.g. 10%) > Observation: You still have the 10€ tax to pay Why the fix: ------------ We match the behavior of sales app, and ignore the fixed price taxes when creating the downpayment lines. opw-4163579 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183385 Forward-Port-Of: odoo/odoo#182380
When an error is thrown sufficiently early in the webclient's "boot" process, sometimes the error handlers might not be ready *enough* eg: the dialog service has not been loaded yet. In those cases, the way to handle the error is to log it as an an error (console.log) along with some kind of hint as to why it has not been handled in a user-friendly manner. Before this commit, the original error appeared twice: one because of our logs, the second because of the browser's default behavior.
Original PR description
When an error is thrown sufficiently early in the webclient's "boot" process, sometimes the error handlers might not be ready *enough* eg: the dialog service has not been loaded yet. In those cases, the way to handle the error is to log it as an an error (console.log) along with some kind of hint as to why it has not been handled in a user-friendly manner. Before this commit, the original error appeared twice: one because of our logs, the second because of the browser's default behavior. After this commit, we prevnt the browser to apply its behavior. 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#186964 Forward-Port-Of: odoo/odoo#186566
Gift cards would have a description in the original language of the creator and could never be changed. Adds the description field to the form view of the loyalty rewards even for gift cards and ewallet programs. opw-4177262 Forward-Port-Of: odoo/odoo#180509
Original PR description
Gift cards would have a description in the original language of the creator and could never be changed. Adds the description field to the form view of the loyalty rewards even for gift cards and ewallet programs. opw-4177262 Forward-Port-Of: odoo/odoo#180509
Follow-up of https://github.com/odoo/odoo/pull/178057 PR above fixed an issue of persistent notification in messaging menu in iOS, due to push notifications being only available through PWA. At the time of the fix, installing PWA apps on iOS had necessarily push notification enabled. However this no longer seems to be the case: PWA apps on iOS must now explicitly asks for enabling push notifications. This is also a necessary step in order for the PWA apps to be shown in iOS Settings > Noti
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/178057 PR above fixed an issue of persistent notification in messaging menu in iOS, due to push notifications being only available through PWA. At the…
Follow-up of https://github.com/odoo/odoo/pull/178057 PR above fixed an issue of persistent notification in messaging menu in iOS, due to push notifications being only available through PWA. At the time of the fix, installing PWA apps on iOS had necessarily push notification enabled. However this no longer seems to be the case: PWA apps on iOS must now explicitly asks for enabling push notifications. This is also a necessary step in order for the PWA apps to be shown in iOS Settings > Notifications. This commit fixes the issue by not showing button to enable push notifications specifically on iOS outside of app. That way there's no persistent notification on Safari while push notifications can still be enabled. Extra notes: - iOS requests for push notifications seem to require HTTPS, otherwise they are necessarily blocked. - iOS 17 does not show the dialog to accept or deny push notifications. This is likely an iOS bug that has apparently been fixed with iOS 18. Forward-Port-Of: odoo/odoo#187038
Tax closing with fiscal positions was not working properly. 1. If the generic tax report doesn't have a specific country and the filter for fiscal position, it should take into account `all` fiscal positions. 3. The closing mechanism until version 18.0 does not work properly with the oss reports. It was not intended for the user to be able to do a closing there before version 18.0. opw-3974388 Forward-Port-Of: odoo/enterprise#73486 Forward-Port-Of: odoo/enterprise#66901
Original PR description
Tax closing with fiscal positions was not working properly. 1. If the generic tax report doesn't have a specific country and the filter for fiscal position, it should take into account `all` fiscal positions. 3. The closing mechanism until version 18.0 does not work properly with the oss reports. It was not intended for the user to be able to do a closing there before version 18.0. opw-3974388 Forward-Port-Of: odoo/enterprise#73486 Forward-Port-Of: odoo/enterprise#66901
### Steps to reproduce: - In the settings: Enable "product packaging" - Create a storable product - Inventory > Configuration > Product Packaging > New - Create a packaging for that product with a quantity of 15 units - In the barcode app > inventory adjustment > + Add product > You are redirected towards a digipad without any set product_id. - Add a product #### > The packaging button is not displayed for you to add multiples of 15 Follow up of Commit 8db17ef7aa7d0f989da1ab3f05de66
Original PR description
### Steps to reproduce: - In the settings: Enable "product packaging" - Create a storable product - Inventory > Configuration > Product Packaging > New - Create a packaging for that product with a quantity of 15 units - In the barcode app > inventory adjustment > + Add product > You are redirected towards a digipad without any set product_id. - Add a product #### > The packaging button is not displayed for you to add multiples of 15 Follow up of Commit 8db17ef7aa7d0f989da1ab3f05de661fba7a9fc7 opw-4156249 --- Forward-Port-Of: odoo/enterprise#73473 Forward-Port-Of: odoo/enterprise#72626
Steps to reproduce: - Create a subscription product with two or more plans - Go to the product's page on eCommerce - Choose another plan than the default one - Add it to the cart - Notice the default plan is the one added to the cart Current behavior before PR: After this change https://github.com/odoo/enterprise/pull/71347/commits/a847237eaf91df641d6af6c7122a1e7216621f9a there is a div got added before the tag of the select dropdown menu. So when we are getting the value of the pl
Original PR description
Steps to reproduce: - Create a subscription product with two or more plans - Go to the product's page on eCommerce - Choose another plan than the default one - Add it to the cart - Notice the default plan is the one added to the cart Current behavior before PR: After this change https://github.com/odoo/enterprise/pull/71347/commits/a847237eaf91df641d6af6c7122a1e7216621f9a there is a div got added before the tag of the select dropdown menu. So when we are getting the value of the plan_id selected https://github.com/odoo/enterprise/blob/18.0/website_sale_subscription/static/src/js/website_sale_subscription.js#L14 we don't find any element with this path. Desired behavior after PR is merged: We are changing the path that we get the value of the selected plan out of so we can make sure it is getting the right element which will get the right value accordingly. opw-4296527 Forward-Port-Of: odoo/enterprise#73768 Forward-Port-Of: odoo/enterprise#73677
The `delivery_ups_rest` module icon was using the old one. This commit replaces it for the new UPS icon. task-4317822 Forward-Port-Of: odoo/enterprise#73582
Original PR description
The `delivery_ups_rest` module icon was using the old one. This commit replaces it for the new UPS icon. task-4317822 Forward-Port-Of: odoo/enterprise#73582
Users of the Certification Provider Quadrum (finkok) may experience failed validation of the payment cfdi due to the wrong payment rate computed by the system Use case: - In an MX Company with PAC Quadrum - Enable currency USD - Set up 2 rates, date1: 0.051571645909, date2: 0.049598992148 - Create an invoice in USD, date 1, with a line of qty 1, price 13125.00, tax 16% - Confirm - Make 2 partial payments of 100'000 MXN - On the Invoice, click 'Update Payments' - In the CFDI tab, on one
Original PR description
Users of the Certification Provider Quadrum (finkok) may experience failed validation of the payment cfdi due to the wrong payment rate computed by the system Use case: - In an MX Company with PAC…
Users of the Certification Provider Quadrum (finkok) may experience failed validation of the payment cfdi due to the wrong payment rate computed by the system Use case: - In an MX Company with PAC Quadrum - Enable currency USD - Set up 2 rates, date1: 0.051571645909, date2: 0.049598992148 - Create an invoice in USD, date 1, with a line of qty 1, price 13125.00, tax 16% - Confirm - Make 2 partial payments of 100'000 MXN - On the Invoice, click 'Update Payments' - In the CFDI tab, on one of the payments, click 'Force CFDI' Issue: Validation will fail with error Note: This does not occur with other providers (Solucion Factibles) ``` Code : CRP20275 Message : La suma de los valores registrados en el campo ImpPagado del nodo DoctoRelacionado, convertidos a la moneda del pago, no es menor o igual que el valor del campo Monto. ``` This occurs because, when computing the payment rate in USD, we obtain 4959.90. Due to rounding, this amount, reconverted in MXN is 100000.02 so we need to transmit an adjusted rate for Providers with a lower error tolerance opw-4314798 Forward-Port-Of: odoo/enterprise#73696
opw-4272165 community: https://github.com/odoo/odoo/pull/186595 Forward-Port-Of: odoo/enterprise#73715
Original PR description
opw-4272165 community: https://github.com/odoo/odoo/pull/186595 Forward-Port-Of: odoo/enterprise#73715
Steps to reproduce ================== - Go to documents - Switch to the list view - Select a record - Resize a column => The selection is lost Solution ======== Ignore clicks in the header opw-4203375 Forward-Port-Of: odoo/enterprise#71774
Original PR description
Steps to reproduce ================== - Go to documents - Switch to the list view - Select a record - Resize a column => The selection is lost Solution ======== Ignore clicks in the header opw-4203375 Forward-Port-Of: odoo/enterprise#71774
Before this commit: The logo is not updated when users change the icon or image and click the confirm button. The updated logo appears after refreshing the page. After this commit: When users change the icon or image and click the confirm button, the logo is now updated Task-4219545 Forward-Port-Of: odoo/enterprise#73728 Forward-Port-Of: odoo/enterprise#71512
Original PR description
Before this commit: The logo is not updated when users change the icon or image and click the confirm button. The updated logo appears after refreshing the page. After this commit: When users change the icon or image and click the confirm button, the logo is now updated Task-4219545 Forward-Port-Of: odoo/enterprise#73728 Forward-Port-Of: odoo/enterprise#71512
This commit will add the ec sales list report for Slovenian localisation Community PR: odoo/odoo#166559 Task [link](https://www.odoo.com/odoo/project/967/tasks/3901247) task-3901247 Forward-Port-Of: odoo/enterprise#65817
Original PR description
This commit will add the ec sales list report for Slovenian localisation Community PR: odoo/odoo#166559 Task [link](https://www.odoo.com/odoo/project/967/tasks/3901247) task-3901247 Forward-Port-Of: odoo/enterprise#65817
Steps to reproduce: - Install Attendances - New employee > New Contract > Set a wage - Set 'Work Entry Source' to 'Attendances' - Payroll app > New Payslip > Compute Sheet - Salary Computation tab > Basic salary = contract Wage Steps to check salary configurator: - Install Salary Configurator and Recruitment - Recruitment > Any Job Position > New Application - Generate Offer > Pick template > Configure your package - Under 'Net Salary' click Details The basic salary should be 0 as
Original PR description
Steps to reproduce: - Install Attendances - New employee > New Contract > Set a wage - Set 'Work Entry Source' to 'Attendances' - Payroll app > New Payslip > Compute Sheet - Salary Computation tab >…
Steps to reproduce: - Install Attendances - New employee > New Contract > Set a wage - Set 'Work Entry Source' to 'Attendances' - Payroll app > New Payslip > Compute Sheet - Salary Computation tab > Basic salary = contract Wage Steps to check salary configurator: - Install Salary Configurator and Recruitment - Recruitment > Any Job Position > New Application - Generate Offer > Pick template > Configure your package - Under 'Net Salary' click Details The basic salary should be 0 as no work hours have been recorded, note that this is different from having leaves recorded we're talking about a case where no records are available to compute the payslip basic salary. We might still want to generate a payslip in such cases to account for the flat allowances / deductions the employee might have on their contract's salary structure. We can't just set it to 0 though: This workaround is needed because the salary configurator also uses salary computation, where we do want to get the monthly wage (Since the contract is still provisional we don't have worked hours, but we still want it to be reflective of the position's monthly wage). In the case of an active employee however, paying a basic wage when no hours have been worked does not make sense so it should invariably be 0. This could also be relevant with other work entry sources than attendances but a contract based on worked entries automatically generates worked hours according to the schedule so it is more difficult to reach. opw-4266880 Forward-Port-Of: odoo/enterprise#73469
Steps to reproduce: - Insert a non-odoo pivot - Add a formula with `=PIVOT.VALUE` or `PIVOT.HEADER` - Try to autofill => Traceback This commit fixes the issue by disabling the autofill for non-odoo pivots, as the autofill is not supported for them. Task: 4277518 Forward-Port-Of: odoo/enterprise#72564
Original PR description
Steps to reproduce: - Insert a non-odoo pivot - Add a formula with `=PIVOT.VALUE` or `PIVOT.HEADER` - Try to autofill => Traceback This commit fixes the issue by disabling the autofill for non-odoo pivots, as the autofill is not supported for them. Task: 4277518 Forward-Port-Of: odoo/enterprise#72564
Brazil is now requiring that each line includes the barcode [1]. This is being rolled out gradually per state, as of now it's only rolled out in Paraná as far as we are aware. We're applying this change to Odoo 17 and later because it only affects EDI. Odoo 16 only supported tax calculation. Validation is done based on the Avalara documentation [2]. [1] As outlined in "Nota Técnica 2021.003 Validação GTIN" https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=SrQT9ys8OD
Original PR description
Brazil is now requiring that each line includes the barcode [1]. This is being rolled out gradually per state, as of now it's only rolled out in Paraná as far as we are aware.
We're applying this change to Odoo 17 and later because it only affects EDI. Odoo 16 only supported tax calculation.
Validation is done based on the Avalara documentation [2].
[1] As outlined in "Nota Técnica 2021.003 Validação GTIN"
https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=SrQT9ys8ODo=
[2] https://avataxbr-docs.avalarabrasil.com.br/#/Calculations/payloadCalculation
task-4222168
Forward-Port-Of: odoo/enterprise#73536
Forward-Port-Of: odoo/enterprise#735172 small fixes for the quality worksheet in the shop floor. Please refer to the individual feature commits for details. Forward-Port-Of: odoo/enterprise#73592 Forward-Port-Of: odoo/enterprise#70703
Original PR description
2 small fixes for the quality worksheet in the shop floor. Please refer to the individual feature commits for details. Forward-Port-Of: odoo/enterprise#73592 Forward-Port-Of: odoo/enterprise#70703