Wednesday, May 15, 2024
48 changes · saas-17.2
Enhancements to existing features
The SMS module's automated tests were migrated to a newer testing framework. This helps maintain the quality and reliability of SMS-related features without changing how users interact with them.
Original PR description
Purpose this PR: This PR converts the all the qunit testcases of the sms module to hoot. Part of task: [3818666](https://www.odoo.com/web#id=3818666&cids=2&model=project.task&view_type=form)
Resolved issues and error corrections
This fixes an issue where a company's country could stay unset after address details changed, because the system was not recalculating it. The change helps prevent incorrect company address data in flows that depend on localization or partner enrichment.
Original PR description
In the test `test_enrich`, we create a new company, without country. With the split from `l10n_fr` to `l10n_fr` and `l10n_fr_account`, `l10n_fr` is installed before `partner_autocomplete`. So the test is ran with `l10n_fr` already installed. In this module, there is a check on country_id in the create. It reveals an issue when the country_id (=False) is put in cache. Because there are no dependencies, it's then not recomputed. To fix it, we add a dependency for all the fields of the address. Linked to runbot error 57113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Before this commit, when a livechat operator had livechats open, making a draft record result to crash. Steps to reproduce: - Log in as Admin; - Set a livechat user name in Preferences then Save; - In incognito, open livechat from website then post a message; - In admin tab, when livechat is open, make a new record e.g. make a new sale order => Crash with: ``` TypeError: can't access property "channel_type", this.message.thread is undefined ``` This happens because when making a
Original PR description
Before this commit, when a livechat operator had livechats open, making a draft record result to crash. Steps to reproduce: - Log in as Admin; - Set a livechat user name in Preferences then Save; -…
The live chat bot's temporary canned response is now translated into the user's language. This helps customers and operators see automated chat content in the expected language, improving clarity in multilingual support conversations.
Original PR description
Since odoo/odoo#164145, we create a temporary canned response in chat with odoo bot. The content of this record should be translated to the user's language.
Before this commit, when a livechat operator had livechats open, making a draft record result to crash. Steps to reproduce: - Log in as Admin; - Set a livechat user name in Preferences then Save; - In incognito, open livechat from website then post a message; - In admin tab, when livechat is open, make a new record e.g. make a new sale order => Crash with: ``` TypeError: can't access property "channel_type", this.message.thread is undefined ``` This happens because when making a draft record, the chatter contains the message "Creating a new record...". This record was missing `thread`, which is assumed to be necessarily known for any message. Thankfully this is not a problem most of the time, but with livechat open and livechat operator having a custom livechat name, this executes evaluation of `this.message.thread.type`, which crashes due to unset `thread`. This commit fixes the issue by properly setting the thread of the "Creating a new record..." message. opw-3913228 Forward-Port-Of: odoo/odoo#165265
This PR fixes a layout issue inside the eCommerce categories form view on mobile devices. Prior to this PR, a `.oe_left` class was applied to the content of the sheet, moving it "out of the flow", resulting in a wrong sized `form_sheet`. To fix the issue, we have to provide a CSS workaround to modify the view without modifying the XML directly. To do so, we set a `float:none` that will cancel the utility class, and we apply a `.col-md-6` and a `.pe-3` class to ensure that the labels
Original PR description
This PR fixes a layout issue inside the eCommerce categories form view on mobile devices. Prior to this PR, a `.oe_left` class was applied to the content of the sheet, moving it "out of the flow", resulting in a wrong sized `form_sheet`. To fix the issue, we have to provide a CSS workaround to modify the view without modifying the XML directly. To do so, we set a `float:none` that will cancel the utility class, and we apply a `.col-md-6` and a `.pe-3` class to ensure that the labels are not placed right next to the image in mobile and the layout doesn't take the full width on larger devices. task-3847917 Forward-Port-Of: odoo/odoo#165543 Forward-Port-Of: odoo/odoo#162034
Steps to reproduce: - Install stock_account and UAE account (l10N_ae) "UAE has nothing to do with the bug it's just a pain to setup a new company accounting otherwise" - Create and configure a product FIFO automated with on hand qty for both companies - In stock valuation select UAE and try to reavluate that product Bug: wrong company (the default one) is set on the context Fix: set the correct allowed_company_ids from the cids in the request cookies opw-3765174 Forward-Port-Of: o
Original PR description
Steps to reproduce: - Install stock_account and UAE account (l10N_ae) "UAE has nothing to do with the bug it's just a pain to setup a new company accounting otherwise" - Create and configure a product FIFO automated with on hand qty for both companies - In stock valuation select UAE and try to reavluate that product Bug: wrong company (the default one) is set on the context Fix: set the correct allowed_company_ids from the cids in the request cookies opw-3765174 Forward-Port-Of: odoo/odoo#165473 Forward-Port-Of: odoo/odoo#158074
When mass producing products that needs serial numbers, the quality check warning is thrown before being able to generate multiple serial numbers. The main fix is done in the enterprise pr, this commit only adds hooks for the enterprise changes enterprise : https://github.com/odoo/enterprise/pull/59382 task-id: 3821092 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
Original PR description
When mass producing products that needs serial numbers, the quality check warning is thrown before being able to generate multiple serial numbers. The main fix is done in the enterprise pr, this commit only adds hooks for the enterprise changes enterprise : https://github.com/odoo/enterprise/pull/59382 task-id: 3821092 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#159268
This implements a new approach to solve selection issues around links (allowing the cursor at the inner _and_ outer edges of links). In the sanitization process, every link now receives 4 zero-width non-breaking spaces (unicode FEFF characters, hereafter referred to as ZWNBSP): - one before the link - one as the link's first child - one as the link's last child - one after the link like so: `//ZWNBSP//<a>//ZWNBSP//label//ZWNBSP//</a>//ZWNBSP`. An advantage of ZWNBSP over regular ZWS
Original PR description
This implements a new approach to solve selection issues around links (allowing the cursor at the inner _and_ outer edges of links). In the sanitization process, every link now receives 4 zero-width…
This implements a new approach to solve selection issues around links (allowing the cursor at the inner _and_ outer edges of links). In the sanitization process, every link now receives 4 zero-width non-breaking spaces (unicode FEFF characters, hereafter referred to as ZWNBSP): - one before the link - one as the link's first child - one as the link's last child - one after the link like so: `//ZWNBSP//<a>//ZWNBSP//label//ZWNBSP//</a>//ZWNBSP`. An advantage of ZWNBSP over regular ZWSP (unicode 200B) is they're less likely to be used deliberately by the user, so much so that we can safely assume all of them are technical and can be removed indiscriminately. ZWSP and ZWNBSP are used to mark a separation between words in languages that don't use spaces for that purpose (eg, Lao). ZWNBSP are to ZWSP what NBSP (unicode 00A0) are to regular spaces. Because of that advantage, we don't need to track the ZWNBSP (so there is no need to wrap them in `span` elements), simplifying the code considerably. We therefore now remove all ZWNBSP when saving. There is a possibility to introduce "orphaned" ZWNBSP during the editing process, if for instance the link has a big enough padding or margin that it's possible to click between two of a link's ZWNBSP (one outer, the other inner). Inserting a character or a paragraph break in such a position will move the ZWNBSP to a place where it's not useful anymore. The sanitizer will then reintroduce the useful ZWNBSP in their rightful places. We remove the orphaned ZWNBSP from the sanitizer whenever that is possible without risking to break the selection. To properly deal with this change, we also change the handlers for the delete/backspace/deleteRange, enter and arrow keys. This PR also makes some indirectly related changes: - It fixes a bug with Bootstrap buttons in the "backend" where it's currently impossible to put the selection within them (and the wrong cursor appears) because of a Boostrap CSS. - It introduces a debugging utility function to log the selection. - It slightly modifies the way the `enter` key handler works at the inner edges of links so that a paragraph break will never be inserted at the end of the link (creating an empty link). Co-authored-by: Sébastien Geelen <sge@odoo.com> task-3604728 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164400 Forward-Port-Of: odoo/odoo#157200
This pr contains a second set of fix for ubuntu noble, mainly regarding python 3.12 and lxml 5.2 For easier forwardport, the pr is split in multiple parts ## This PR ### [FIX] base, tools: adapt optcode for python ### [FIX] mail: addapt lxml.html.defs Will be useful when using new package lxml_hmtl_clean. Done in another ### [FIX] test_lint: adapt for pylint 3.0.0 ## Other pr ### [FIX] *: SyntaxWarning: invalid escape sequence Automatic fix in all versions -
Original PR description
This pr contains a second set of fix for ubuntu noble, mainly regarding python 3.12 and lxml 5.2 For easier forwardport, the pr is split in multiple parts ## This PR ### [FIX] base, tools: adapt…
This pr contains a second set of fix for ubuntu noble, mainly regarding python 3.12 and lxml 5.2 For easier forwardport, the pr is split in multiple parts ## This PR ### [FIX] base, tools: adapt optcode for python ### [FIX] mail: addapt lxml.html.defs Will be useful when using new package lxml_hmtl_clean. Done in another ### [FIX] test_lint: adapt for pylint 3.0.0 ## Other pr ### [FIX] *: SyntaxWarning: invalid escape sequence Automatic fix in all versions - [x] 15.0 https://github.com/odoo/odoo/pull/163493 https://github.com/odoo/enterprise/pull/61571 - [x] 16.0 https://github.com/odoo/odoo/pull/163753 https://github.com/odoo/enterprise/pull/61658 - [x] 16.3 https://github.com/odoo/odoo/pull/163754 https://github.com/odoo/enterprise/pull/61659 - [x] 16.4 https://github.com/odoo/odoo/pull/163755 https://github.com/odoo/enterprise/pull/61660 - [x] 17.0 https://github.com/odoo/odoo/pull/163756 https://github.com/odoo/enterprise/pull/61661 - [x] 17.1 https://github.com/odoo/odoo/pull/163757 https://github.com/odoo/enterprise/pull/61662 - [x] 17.2 https://github.com/odoo/odoo/pull/163758 https://github.com/odoo/enterprise/pull/61663 - [x] master https://github.com/odoo/odoo/pull/163759 https://github.com/odoo/enterprise/pull/61664 ### [FIX] netsvc: silent utcnow errors (temp) - [x] done in #163794 (easier forwardport, may conflict) ### [FIX] tests: avoid to fork in multithread - [x] #163562 ### [FIX] ast - [x] 15.0: mute warning #163559 (python 3.7 - Python 3.13) - [x] 16.0+: fix it #163487 (python 3.8 - python 3.14 + ) ### [FIX] packaging of lxml_html_clean - [ ] Will be done in #163788 ### [FIX] root xpath deprecation warning - [x] done in https://github.com/odoo/enterprise/pull/61570 Forward-Port-Of: odoo/odoo#165315 Forward-Port-Of: odoo/odoo#162438
Payment term on reversed invoices should not be displayed in the preview page. Steps: - Create and confirm an invoice - Open the preview - The invoice due date is displayed on the top left of the page just above the "Download" and "Print" buttons - Go back to the invoice and make a full refund - The payment state of the invoice is "reversed" - Go back to the invoice preview -> The invoice due date is still displayed, it should not be opw-3894596 Forward-Port-Of: odoo/odoo#164
Original PR description
Payment term on reversed invoices should not be displayed in the preview page. Steps: - Create and confirm an invoice - Open the preview - The invoice due date is displayed on the top left of the page just above the "Download" and "Print" buttons - Go back to the invoice and make a full refund - The payment state of the invoice is "reversed" - Go back to the invoice preview -> The invoice due date is still displayed, it should not be opw-3894596 Forward-Port-Of: odoo/odoo#164897
This commit removes the dead and undeterministic test added by mistake after an unsucessful merge. This test assumes that the organizer of the event might always be on the position 0 of the attendees list but it is not always the case. Issue from: odoo/odoo#164408 Forward-Port-Of: odoo/odoo#165346
Original PR description
This commit removes the dead and undeterministic test added by mistake after an unsucessful merge. This test assumes that the organizer of the event might always be on the position 0 of the attendees list but it is not always the case. Issue from: odoo/odoo#164408 Forward-Port-Of: odoo/odoo#165346
This is an extension of odoo/odoo#160055 as this issue is also present for allocations --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165249
Original PR description
This is an extension of odoo/odoo#160055 as this issue is also present for allocations --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165249
[REM] account: remove validation on bills ref Remove validation on bills ref and allow users to have multiple bills with same ref Reason: improve user experience with the system as it's a pain for them in a real life senario Task-3869240 enterprise-PR#https://github.com/odoo/enterprise/pull/62395 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165388 Forward-Port-Of: odoo/odoo#161995
Original PR description
[REM] account: remove validation on bills ref Remove validation on bills ref and allow users to have multiple bills with same ref Reason: improve user experience with the system as it's a pain for them in a real life senario Task-3869240 enterprise-PR#https://github.com/odoo/enterprise/pull/62395 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165388 Forward-Port-Of: odoo/odoo#161995
Currently, an error is generated when unarchiving multiple products which have dynamic attributes & variants. Step to produce: - Install a 'Sales' module. - Navigate to the Sales / Products / Products, And create a product. - Add a 'Product Name' and save a record, and then add dynamic Attributes & Variants. - Repeat the process described in the above step to create another product with the same configuration as the first one. -Go to list view of 'Product'. select both products that we
Original PR description
Currently, an error is generated when unarchiving multiple products which have dynamic attributes & variants. Step to produce: - Install a 'Sales' module. - Navigate to the Sales / Products /…
Currently, an error is generated when unarchiving multiple products which have dynamic attributes & variants. Step to produce: - Install a 'Sales' module. - Navigate to the Sales / Products / Products, And create a product. - Add a 'Product Name' and save a record, and then add dynamic Attributes & Variants. - Repeat the process described in the above step to create another product with the same configuration as the first one. -Go to list view of 'Product'. select both products that we made recently and click on the Action button to archive both products. - Click on 'Filters' to see the archive product, And select those products to Unarchive. ValueError: Expected singleton: product.template(39, 37, 40, 42, 38, 46, 34) The issue occurs when unarchive multiple products that contain dynamic attributes & variants. As a result, the system receives multiple product templates at [1]. link[1]: https://github.com/odoo/odoo/blob/e5635c38810a745f00b106d7a075ae1553de50c7/addons/product/models/product_template.py#L745 To resolve the issue, replace a 'self' with 'tmpl_id' to get a single product template record instead of multiple. sentry-5222160918 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165394
In this PR, if the user has created a leave request for today and it remains unvalidated, they can delete it However, past leave cannot be deleted Task-3775186 Forward-Port-Of: odoo/odoo#165351
Original PR description
In this PR, if the user has created a leave request for today and it remains unvalidated, they can delete it However, past leave cannot be deleted Task-3775186 Forward-Port-Of: odoo/odoo#165351
Problem: when adding attendees to a course, the sent email is not translated into the recipient's language. Fix: Upon sending, translate the email on a per recipient basis, but **only when** the final message to sent is exactly the same as the template. (i.e. the body was not edited from the dialog box) This is a compromise to permit emails being translated while not breaking the following 2 current features: * there can be many recipients (with different languages) * the body is pre-f
Original PR description
Problem: when adding attendees to a course, the sent email is not translated into the recipient's language. Fix: Upon sending, translate the email on a per recipient basis, but **only when** the final message to sent is exactly the same as the template. (i.e. the body was not edited from the dialog box) This is a compromise to permit emails being translated while not breaking the following 2 current features: * there can be many recipients (with different languages) * the body is pre-filled with a template but can be edited further by the user directly from the dialog box. opw-3862369 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162237
Steps to reproduce: - create a new spreadsheet - right click any cell => boom `Cannot read properties of undefined (reading 'id')` Bug introduced by odoo/enterprise@31401c7 opw-3900571 X-original-commit: odoo/enterprise@78218c9 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165270 Forward-Port-Of: odoo/odoo#165183
Original PR description
Steps to reproduce: - create a new spreadsheet - right click any cell => boom `Cannot read properties of undefined (reading 'id')` Bug introduced by odoo/enterprise@31401c7 opw-3900571 X-original-commit: odoo/enterprise@78218c9 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165270 Forward-Port-Of: odoo/odoo#165183
Issue: ====== The whole content is removed when deleting empty line Steps to reproduce the issue: ============================= - Go to to-do - Add some text in the first line - Keep the second line empty - Add some text in the third line - Select some prefix of the third line with the second line too - delete - All the content before the empty line is removed Origin of the issue: ==================== We are in this case: `<p>abc</p>` `<p>[<br></p>` `<p>d]ef</p>` - The
Original PR description
Issue: ====== The whole content is removed when deleting empty line Steps to reproduce the issue: ============================= - Go to to-do - Add some text in the first line - Keep the second line…
Issue: ====== The whole content is removed when deleting empty line Steps to reproduce the issue: ============================= - Go to to-do - Add some text in the first line - Keep the second line empty - Add some text in the third line - Select some prefix of the third line with the second line too - delete - All the content before the empty line is removed Origin of the issue: ==================== We are in this case: `<p>abc</p>` `<p>[<br></p>` `<p>d]ef</p>` - The `startContainer` in this case is the `p` element and not the `br` so we will not insert the `zws` node inside the `p`. - We assign `next` as the text node containing `ef` - Extract content will remove all the content inside the second `p` element and will be like this `<p>abc</p>` `<p></p>` `<p>ef</p>` - We set selection at the end of the `start` node `<p>[]</p>`so it's like we set the selection in `<p>[]ef</p>` so now `getRange` will return `startContainer=endContainer=textNode(ef)` so `joinWith` is equal to next which is the text node containing `ef` - In the join `while` loop , we have `doJoin=true`, `next` always truthy, `next.previousSibling` will never be equal to `joinWith` since `next=joinWith` so it will keep deleting until we don't have anymore previousSiblings which is basically remove everything before. Note: This doesn't happen in the case the second line has some text because we insert a `zws` before the text node. Solution: ========= Since we apply `fillEmpty` on `start` after extracting the content, we need to get the range after we insert the `br` again to make sure we get the correct `startContainer` and `endContainter`. opw-3878575 Forward-Port-Of: odoo/odoo#165104
Issue: ====== History steps aren't cleared when we click discard Steps to reproduce the issue: ============================= - Add anything to a todo record - Click discard - Click ctrl+Z - The block reappears but in reverse order Origin of the issue: ==================== This commit introduced the behavior: https://github.com/odoo/odoo/commit/0e22763a85ee2f4caf663185eb70d3d181b954b0 We only set the value of the edtior and we don't reset it that's why the history stays. Solut
Original PR description
Issue: ====== History steps aren't cleared when we click discard Steps to reproduce the issue: ============================= - Add anything to a todo record - Click discard - Click ctrl+Z - The block reappears but in reverse order Origin of the issue: ==================== This commit introduced the behavior: https://github.com/odoo/odoo/commit/0e22763a85ee2f4caf663185eb70d3d181b954b0 We only set the value of the edtior and we don't reset it that's why the history stays. Solution: ========= When we discard the field, it will have `dirty=false` , we can use this information in the field to check if we are in a discard flow or not. task-3768456 Forward-Port-Of: odoo/odoo#155511
Commit that introduced the issue: https://github.com/odoo/odoo/commit/e806328bc5bd8526594e8e2b90685c03504dea79 Issue: ===== when an icon is converted to png it's cropped. Steps to reproduce the issue: ============================= - Go to this url: {host}/web_editor/font_to_img/61802/rgb(0,143,140)/rgb(255,255,255)/190x200 - The icon is cropped. Origin of the issue: ===================== In this case we are using `top` and `left` as they are the top left corner of the icon insid
Original PR description
Commit that introduced the issue:
https://github.com/odoo/odoo/commit/e806328bc5bd8526594e8e2b90685c03504dea79
Issue:
=====
when an icon is converted to png it's cropped.
Steps to reproduce the issue:
=============================
- Go to this url: {host}/web_editor/font_to_img/61802/rgb(0,143,140)/rgb(255,255,255)/190x200
- The icon is cropped.
Origin of the issue:
=====================
In this case we are using `top` and `left` as they are the top left corner of the icon inside the image , but in reality the returned value is 0 , and the top left corner is represented by `box[0]` and `box[1]`.
Solution:
=========
Use of `box` values instead of `top` and `left`
Before:
======
After:
====
opw-3865845
Forward-Port-Of: odoo/odoo#163006Previously: - Users without create access could see the 'Duplicate' action. After this fix: - Users without create access cannot see the 'Duplicate' action. task-3898435 Forward-Port-Of: odoo/odoo#163776
Original PR description
Previously: - Users without create access could see the 'Duplicate' action. After this fix: - Users without create access cannot see the 'Duplicate' action. task-3898435 Forward-Port-Of: odoo/odoo#163776
The class doesn't have the post_install tag, and so, is skipped. runbot-25903 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165240
Original PR description
The class doesn't have the post_install tag, and so, is skipped. runbot-25903 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165240
Steps to reproduce: - Enable event barcode in Event settings - Create a new event - Add an attendee and send him the ticket by email - Download the ticket - Scan the ticket in the registraion desk - Server Error: 'payment_status_value': dict(self._fields['payment_status']._description_selection(self.env))[self.payment_status], KeyError: False Bug: the field is a selection field we use _description_selection to get the string to display but in this case the ticket is not linked to a sal
Original PR description
Steps to reproduce: - Enable event barcode in Event settings - Create a new event - Add an attendee and send him the ticket by email - Download the ticket - Scan the ticket in the registraion desk - Server Error: 'payment_status_value': dict(self._fields['payment_status']._description_selection(self.env))[self.payment_status], KeyError: False Bug: the field is a selection field we use _description_selection to get the string to display but in this case the ticket is not linked to a sale so the value is False Note: -the value is correctly checked before being displayed \<tr t-if="registration.payment_status_value"> -in V17 same for sale_status instead opw-3870653 Forward-Port-Of: odoo/odoo#164193
Description: The Attendee List report uses `date_begin` and `date_end` to display the Event's Dates, however these values are always UTC rather than using the `date_tz` set on the Event. In order to show the times with the correct tz, we should use the already existing `date_begin_located` and `date_end_located` fields instead, which already formats the fields with tz. Desired Behavior after fix: Attendee List report properly displays the datetime based on the tz set on the record. opw-3
Original PR description
Description: The Attendee List report uses `date_begin` and `date_end` to display the Event's Dates, however these values are always UTC rather than using the `date_tz` set on the Event. In order to show the times with the correct tz, we should use the already existing `date_begin_located` and `date_end_located` fields instead, which already formats the fields with tz. Desired Behavior after fix: Attendee List report properly displays the datetime based on the tz set on the record. opw-3895264 Forward-Port-Of: odoo/odoo#164851
To reproduce the issue: 1) Create a company MAIN, and a branch BRANCH 2) Create a payment term in MAIN, with company_id = MAIN 3) Make MAIN your active company 4) Create a new invoice, and try to assign it the payment term created in 2). ==> It's not possible. This is because the company check ran for the payment term assigned to an invoice only check for equality of the company ; it does not consider the fact the payment term could be defined in a parent of the current branch. This f
Original PR description
To reproduce the issue: 1) Create a company MAIN, and a branch BRANCH 2) Create a payment term in MAIN, with company_id = MAIN 3) Make MAIN your active company 4) Create a new invoice, and try to assign it the payment term created in 2). ==> It's not possible. This is because the company check ran for the payment term assigned to an invoice only check for equality of the company ; it does not consider the fact the payment term could be defined in a parent of the current branch. This fix makes it possible to use payment terms defined for the parent companies. Forward-Port-Of: odoo/odoo#164767
Before this PR, on smaller screens the onboarding steps illustration sometimes overlapped the close button, making it difficult to dismiss the onboarding steps. This fix ensures the close button is no longer obscured. task-3749740 <details> <summary>Preview (See changes)</summary> <table> <tr> <td>Before</td> <td>After </td> <tr> <td><img src="https://github.com/odoo/odoo/assets/80678921/01cd9478-1e9d-4736-9599-3df8bda380b1" alt="before"></td> <td><img src="https://github.
Original PR description
Before this PR, on smaller screens the onboarding steps illustration sometimes overlapped the close button, making it difficult to dismiss the onboarding steps. This fix ensures the close button is no longer obscured. task-3749740 <details> <summary>Preview (See changes)</summary> <table> <tr> <td>Before</td> <td>After </td> <tr> <td><img src="https://github.com/odoo/odoo/assets/80678921/01cd9478-1e9d-4736-9599-3df8bda380b1" alt="before"></td> <td><img src="https://github.com/odoo/odoo/assets/80678921/b8d2ec5a-3bea-48d9-8320-b0872ae04be8" alt="after"</td> </table> </details> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163966
In production we are encountering an issue wherein the message number is exceeding the maximum value (255). This results in an error when converting the integer into its byte value representation. The solution to this is to reset the message number upon each send. task-id: none Forward-Port-Of: odoo/odoo#165242
Original PR description
In production we are encountering an issue wherein the message number is exceeding the maximum value (255). This results in an error when converting the integer into its byte value representation. The solution to this is to reset the message number upon each send. task-id: none Forward-Port-Of: odoo/odoo#165242
Problem: The arabic_english_invoice report displays product name twice since the description includes the product name by default. Solution:The report should only display the description if the description is not the same as the products' name. Otherwise, the report should display the products' name in the same language as the customer. Steps to Reproduce on Runbot: 1. Install `sale`, `l10n_sa`, `l10n_gcc_invoice` 2. Switch to SA Company 3. Create a product with sales description 4. Cr
Original PR description
Problem: The arabic_english_invoice report displays product name twice since the description includes the product name by default. Solution:The report should only display the description if the description is not the same as the products' name. Otherwise, the report should display the products' name in the same language as the customer. Steps to Reproduce on Runbot: 1. Install `sale`, `l10n_sa`, `l10n_gcc_invoice` 2. Switch to SA Company 3. Create a product with sales description 4. Create an invoice with the product from step 3 5. Print the invoice report 6. Observe the product name is displayed twice 7. If Arabic is enabled as a language, the product name will be displayed three times, with the 3rd being in Arabic. [Ticket link](https://www.odoo.com/web#model=project.task&id=3768196) opw-3768196 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157774
This commit adds the missing neutralization necessary for the pos_mercado_pago module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or wont result in actual changes), or impact the customers of the operator of the production database. This is main
Original PR description
This commit adds the missing neutralization necessary for the pos_mercado_pago module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or wont result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] https://github.com/odoo/odoo/pull/154962 Forward-Port-Of: odoo/odoo#165335
-Remove duplicate dialog_size 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#165353
Original PR description
-Remove duplicate dialog_size 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#165353
Before this commit, if the form view of an x2many (non editable inline) field contained a custom footer (i.e. a <footer> node in its arch, to override the default footer of the FormViewDialog), the custom footer was correctly displayed for the first dialog to open, but as of the second one, the default footer was displayed instead. The issue has been introduced by [1], since which we directly receive the arch as an xmlDoc, shared between all instances of FormViewDialog that can be opened from th
Original PR description
Before this commit, if the form view of an x2many (non editable inline) field contained a custom footer (i.e. a <footer> node in its arch, to override the default footer of the FormViewDialog), the custom footer was correctly displayed for the first dialog to open, but as of the second one, the default footer was displayed instead. The issue has been introduced by [1], since which we directly receive the arch as an xmlDoc, shared between all instances of FormViewDialog that can be opened from that x2many. So manipulating it (e.g. to remove the <footer> from it), impacts the subsequent dialogs that can be opened. This commit ensures that we manipulate a copy. [1] #136376 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#160181
When producing all the products of a MO, the quality check error is raised before the serial number autocomplete wizard is shown. This should be the opposite. task-id: 3821092 Forward-Port-Of: odoo/enterprise#59382
Original PR description
When producing all the products of a MO, the quality check error is raised before the serial number autocomplete wizard is shown. This should be the opposite. task-id: 3821092 Forward-Port-Of: odoo/enterprise#59382
Community PR: https://github.com/odoo/odoo/pull/159995 task-3604728 Forward-Port-Of: odoo/enterprise#61979 Forward-Port-Of: odoo/enterprise#60751
Original PR description
Community PR: https://github.com/odoo/odoo/pull/159995 task-3604728 Forward-Port-Of: odoo/enterprise#61979 Forward-Port-Of: odoo/enterprise#60751
Steps to reproduce: - Create a QC of type operation - Set it on reciepts Bug: you are able to validate reciepts without passing the QC Fix: use the same logic as in "check_quality" opw-3839794 Forward-Port-Of: odoo/enterprise#62259
Original PR description
Steps to reproduce: - Create a QC of type operation - Set it on reciepts Bug: you are able to validate reciepts without passing the QC Fix: use the same logic as in "check_quality" opw-3839794 Forward-Port-Of: odoo/enterprise#62259
Sometimes companies might not have a vat number. In this case they are often prevented from exporting a report. They've been using a workaround by enterping '-' or '/' but that prevents from easily setting proper default values elsewhere, for example in l10n_lu_reports. mentioned in opw-3802589 Forward-Port-Of: odoo/enterprise#62410 Forward-Port-Of: odoo/enterprise#62391
Original PR description
Sometimes companies might not have a vat number. In this case they are often prevented from exporting a report. They've been using a workaround by enterping '-' or '/' but that prevents from easily setting proper default values elsewhere, for example in l10n_lu_reports. mentioned in opw-3802589 Forward-Port-Of: odoo/enterprise#62410 Forward-Port-Of: odoo/enterprise#62391
task-3908271 Forward-Port-Of: odoo/enterprise#61944
Original PR description
task-3908271 Forward-Port-Of: odoo/enterprise#61944
When zooming in on the gantt view, the gantt header slots could be badly displayed with an observed decalage with the grid cells. We fix that problem by making the gantt header be a grid and putting grid coordinates to some of its children. opw-3850750 Forward-Port-Of: odoo/enterprise#61939 Forward-Port-Of: odoo/enterprise#61849
Original PR description
When zooming in on the gantt view, the gantt header slots could be badly displayed with an observed decalage with the grid cells. We fix that problem by making the gantt header be a grid and putting grid coordinates to some of its children. opw-3850750 Forward-Port-Of: odoo/enterprise#61939 Forward-Port-Of: odoo/enterprise#61849
Forward-Port-Of: odoo/enterprise#61025
Original PR description
Forward-Port-Of: odoo/enterprise#61025
[REM] account: remove validation on bills ref Remove validation on bills ref and allow users to have multiple bills with same ref Reason: improve user experience with the system as it's a pain for them in a real life senario Task-3869240 odoo-pr: https://github.com/odoo/odoo/pull/161995 Forward-Port-Of: odoo/enterprise#62441 Forward-Port-Of: odoo/enterprise#62395
Original PR description
[REM] account: remove validation on bills ref Remove validation on bills ref and allow users to have multiple bills with same ref Reason: improve user experience with the system as it's a pain for them in a real life senario Task-3869240 odoo-pr: https://github.com/odoo/odoo/pull/161995 Forward-Port-Of: odoo/enterprise#62441 Forward-Port-Of: odoo/enterprise#62395
Before this commit, the upsell lines were not translated into the customer lang. taskid: 3911032 Forward-Port-Of: odoo/enterprise#62394 Forward-Port-Of: odoo/enterprise#62086
Original PR description
Before this commit, the upsell lines were not translated into the customer lang. taskid: 3911032 Forward-Port-Of: odoo/enterprise#62394 Forward-Port-Of: odoo/enterprise#62086
Quality check wizard shows '- False' instead of Serial number in title if no lot_name opw-3839794 Forward-Port-Of: odoo/enterprise#62260
Original PR description
Quality check wizard shows '- False' instead of Serial number in title if no lot_name opw-3839794 Forward-Port-Of: odoo/enterprise#62260
the nssf number restriction should not be apply given the real world scenario where the number can be in other format (eg 000000000x) task-3908312 Forward-Port-Of: odoo/enterprise#61947
Original PR description
the nssf number restriction should not be apply given the real world scenario where the number can be in other format (eg 000000000x) task-3908312 Forward-Port-Of: odoo/enterprise#61947
In the BE loca, we were flexible on the notion of complete month. This was useful for odoo but did not make sense for the localization. A complete month of work is if you work from the first work day of the month to the last. Non-working days and public holidays are excluded. Forward-Port-Of: odoo/enterprise#62258
Original PR description
In the BE loca, we were flexible on the notion of complete month. This was useful for odoo but did not make sense for the localization. A complete month of work is if you work from the first work day of the month to the last. Non-working days and public holidays are excluded. Forward-Port-Of: odoo/enterprise#62258
**Steps:** - Install indian payroll(l10n_in_hr_payroll) - Create an employee. - Create contract on that employee. - Generate payslip. - Go to employee app > Report . - Print the `Yearly Salary by Head` or `Yearly Salary by Employee`. **Description of the issue/feature this PR addresses:** In the payroll module, - when we print employee salary report it will give traceback. - The `yearly salary by employee` report was generating duplicate lines for the net salary category. **Cause
Original PR description
**Steps:** - Install indian payroll(l10n_in_hr_payroll) - Create an employee. - Create contract on that employee. - Generate payslip. - Go to employee app > Report . - Print the `Yearly Salary by…
**Steps:** - Install indian payroll(l10n_in_hr_payroll) - Create an employee. - Create contract on that employee. - Generate payslip. - Go to employee app > Report . - Print the `Yearly Salary by Head` or `Yearly Salary by Employee`. **Description of the issue/feature this PR addresses:** In the payroll module, - when we print employee salary report it will give traceback. - The `yearly salary by employee` report was generating duplicate lines for the net salary category. **Cause** printing the employee salary report resulted in a traceback error. This was caused by an update (reference: https://github.com/odoo/enterprise/pull/53816) that made category_id in the payslip_line module unstored. As a result, the SQL query couldn't find the category_id and failed. **Fix:** This PR fix issues by modifying the SQL query used in the reports. Instead of relying on the unstored category_id from payslip_line, the query now retrieves the category ID directly from the hr_salary_rule_category table. task-3791974 Forward-Port-Of: odoo/enterprise#58933
Child asset has an `asset_lifetime_days` that depends on it's parent's. So, we need to add `recursive=True` to the field. Forward-Port-Of: odoo/enterprise#62351
Original PR description
Child asset has an `asset_lifetime_days` that depends on it's parent's. So, we need to add `recursive=True` to the field. Forward-Port-Of: odoo/enterprise#62351
Before this PR: - IGST is not applicable for intra-state transactions. - Transactions within special economic zones were not properly handled. After this PR: - Enhanced condition to exclude IGST for intra-state transactions. - Improved handling of transactions within special economic zones for accurate GST treatment. Forward-Port-Of: odoo/enterprise#62021
Original PR description
Before this PR: - IGST is not applicable for intra-state transactions. - Transactions within special economic zones were not properly handled. After this PR: - Enhanced condition to exclude IGST for intra-state transactions. - Improved handling of transactions within special economic zones for accurate GST treatment. Forward-Port-Of: odoo/enterprise#62021
Changed the chart_template_ref that wasn't adapted for a fw-port. Also added the tag, so the test's requests are not blocked in 17+ runbot-64732 runbot-62320 Forward-Port-Of: odoo/enterprise#62375
Original PR description
Changed the chart_template_ref that wasn't adapted for a fw-port. Also added the tag, so the test's requests are not blocked in 17+ runbot-64732 runbot-62320 Forward-Port-Of: odoo/enterprise#62375
The goal of this PR is to simply disable the "Text Animation" button from the editor's toolbar in translate mode. An adaptation of code in stable `17.0` will be added to allow the use of text options (text animations & text highlights) in the translation mode, mainly by allowing the creation of snippet editors if the target is a text option snippet. opw-3686777 Forward-Port-Of: odoo/odoo#157726 Forward-Port-Of: odoo/odoo#157087
Original PR description
The goal of this PR is to simply disable the "Text Animation" button from the editor's toolbar in translate mode. An adaptation of code in stable `17.0` will be added to allow the use of text options (text animations & text highlights) in the translation mode, mainly by allowing the creation of snippet editors if the target is a text option snippet. opw-3686777 Forward-Port-Of: odoo/odoo#157726 Forward-Port-Of: odoo/odoo#157087