Tuesday, March 12, 2024
44 changes · saas-17.1
Resolved issues and error corrections
This fix updates the newsletter editing test so it selects the newsletter form instead of relying on the subscribe button text. This prevents occasional test failures when the button has not refreshed yet, helping keep website newsletter quality checks stable.
Original PR description
A failing step can happen when reaching the step to click on the newsletter subscribe button after activating the edit mode. When reaching the edit mode, the button seems to not have the time to be updated to its initial value (Subscribe) and still displays the "Thanks" design. This break the step as the button is not displayed. Instead we click on the newsletter subscribe form to access the Customize tab of the edit mode. runbot-55302
A small issue in the Timesheets grid was corrected so task-related processing follows the expected standard behavior. This helps avoid inconsistent results when using timesheet tasks while keeping the change limited and low risk.
Original PR description
This PR fixes a method override not calling the method on super()
A previously added automated test was not being run because of a naming mistake. This fix ensures the test runs correctly and validates the intended spreadsheet dashboard document behavior, reducing the chance of future regressions.
Original PR description
The test added in PR #51275 was never run since the method name did not start with the correct prefix. This commit fixes te commit name as well as the test content that did not test the introduced behaviour.
This update corrects a bug where the employee search bar incorrectly displayed duplicate results for employees with the same name within the same company. The issue stemmed from a misconfiguration in the search domain, which wasn't properly applied to the front-end search functionality. This ensures accurate and consistent employee search results.
Original PR description
STEP TO REPRODUCE : =================== - Select only one company - Write "marc demo" in employee search bar You will see two Marc Demo for manager line. task : 3716448 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a visual inconsistency in mass mailing emails. Previously, applying text color and font size adjustments automatically set the text color to black. Now, the text color will remain the user-defined color, ensuring consistent branding and appearance across all emails.
Original PR description
**Current behavior before PR:** When we apply a text color and change its font size, the text color defaults to black. This occurs because the default black color is applied to a span within `o_basic_theme.o_layout`. **Desired behavior after PR is merged:** Now, when applying text color and adjusting its font size, the color of the text remains unchanged. task-3770351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155715
This update prevents the system from incorrectly flagging changes in x2many fields as modifications, which was causing unnecessary recalculations of SO totals. The fix ensures that the system only updates totals when there's a genuine change in the data, improving performance and stability. This resolves a potential issue impacting SO reporting accuracy.
Original PR description
In some conditions, a x2many field can be considered as modified by the webclient when in fact there is no change in 'meaningful' stored fields. In this case, on save, an empty list of magic commands…
In some conditions, a x2many field can be considered as modified by the webclient when in fact there is no change in 'meaningful' stored fields. In this case, on save, an empty list of magic commands will be sent to the server, potentially triggering unexpected recomputations. Steps to reproduce: * install sale_stock & sale_management * create a new storable product * create a new SO * create a new line with this product * Confirm the SO * Set or Update the SO delivery date (Other info tab) * Save -> In the chatter, you will notice an useless tracking value being printed for the SO Total, with identical values before and after update. Cause Since the server received an empty list of commands for the `order_line` field, this triggered a recomputation of the total amounts of the SO, even though there were no effective changes in the lines. Solution Do not send empty command lists for x2m fields. This will avoid unexpected recomputation and also improve performance since the fields were recomputed for 'nothing' --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155549
This update ensures that QR codes are now printed on all receipt reprints. Previously, reprinted receipts lacked this crucial code, causing problems with validating receipts and scanning them. This improvement enhances the reliability of our point-of-sale system and improves the customer experience.
Original PR description
Before this commit, if a receipt was reprinted, the QR code was not included. This could lead to issues with receipt validation and scanning. opw-3763169 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156948
This update resolves an issue where record sorting unintentionally disrupted data prefetching and filtered out newly created records. The fix maintains prefetching functionality and avoids filtering new records during sorting, ensuring data integrity and stability.
Original PR description
BaseModel's sorted() has two problems: - It breaks the prefetch of self for no reason - When it is called without an argument, it filters out new records because the search() used in sorted() doesn't return new records. Keep the same prefetch as self to fix the first problem. We partially fix/support the second issue, we just avoid filtering out new records (but we don't actually sort them) Forward-Port-Of: odoo/odoo#157033 Forward-Port-Of: odoo/odoo#156729
This update fixes an issue where localization modules, like l10n_pe, couldn't properly handle special characters in UBL invoice notes. By allowing localization modules to format the Note node content, this change ensures invoices are correctly displayed and processed across different regions and languages. This improves the accuracy of invoice data.
Original PR description
In UBL 2.0, the Note node can contain the narration field of an invoice. Its content can be some complex HTML. Some localization (e.g. l10n_pe) doesn't support special characters like '\n' or '\u00A0'. This fix allows the localization modules to format the value used by Note node. opw-3744946 Linked enterprise PR: https://github.com/odoo/enterprise/pull/57268 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155081
This update fixes an issue where link coloring in the Odoo editor was inconsistent, only affecting the first and last links in a list. Now, when a list of links is colored, the font element is correctly created within each link, ensuring consistent background color alignment with the font size. This improves the visual appearance and functionality of the editor.
Original PR description
Currently, when we color a list of links with more than three items in the list, only the first and last links are colored. Now when the li element is colored in a list, the font element is created inside the link. We also make sure when the font size is defined the font element is created inside so that the background color is aligned with the font size task-3677214 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156932 Forward-Port-Of: odoo/odoo#149056
This update corrects a bug that prevented public users from successfully entering their email addresses during Xendit payment transactions. Previously, an error would occur, disrupting donation processing. This fix ensures a smoother payment experience for all users, regardless of their account type.
Original PR description
When there's a payment that involves public user, an error will occur when they've input the email. An example is as you can see on the task when user wants to send donation as a public user task-3789416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157195
This update resolves an issue where custom snippets created from event pages would retain original branding and styling, causing layout problems when the snippet was used elsewhere. The fix ensures that branding is cleaned from snippets before they are saved, preventing this disruption and maintaining consistent page formatting. This improves the reliability of custom content creation.
Original PR description
Steps to reproduce the bug: - Go to an event "Introduction" page - Enter edit mode - Click on the pre-existing "Introduction" title (note that it cannot be removed because of the way the page is built, we might want to improve that in master) - Save it as a new custom snippet - Go to your homepage - Drop that new custom snippet that was saved => It cannot be removed, the rest of the content is kinda broken as wells, etc etc. This is because the original branding was saved with the snippet. Indeed the event pages are made in such a way those pre-defined titles are snippets but which are "editable root elements", i.e. elements whose ancestors cannot be edited since themselves or their neighbors contain dynamic elements. opw-3633326 Forward-Port-Of: odoo/odoo#157191 Forward-Port-Of: odoo/odoo#157110
This update resolves an issue where a test for image gallery updates could produce unreliable results. The fix adds a deliberate click to ensure the editor panel is refreshed, preventing a potential error caused by checking outdated values. This improves the stability and reliability of the image gallery feature.
Original PR description
[FIX] website: adapt test tour to avoid undeterministic error Since [1], image options like "Filter" are kept when a user changes the position of an image in an "Image Gallery" snippet. [1] also…
[FIX] website: adapt test tour to avoid undeterministic error Since [1], image options like "Filter" are kept when a user changes the position of an image in an "Image Gallery" snippet. [1] also adapted the `snippet_image_gallery` tour (moved in `snippet_image_gallery_reorder` from version 16) to test this behavior. To do so, the test adds a filter on an image in an "Image Gallery" snippet, checks that the filter is displayed on the editor panel, moves the image, clicks on it and finally checks that the filter is still displayed on the editor panel. The problem is that the steps that check if the filter is displayed on the editor panel are the same before and after the move of the image which means that the second check is true also before the move of the image. This situation is a typical case where an undeterministic error could happen. Indeed, we do not know if the second check tests an old value or an updated one. To solve the problem, the test has been adapted; after the move of the image, the test clicks somewhere else (on the footer in this case), and then back on the moved image to finally check that the filter is still displayed on the editor panel. The goal of the click on the footer is to be sure to have a loaded version of the editor panel. By doing so, we remove the risk of an undeterministic error situation where a condition is already true before an action is done. Note: this problem has been discovered because the test `snippet_image_gallery_reorder` succeeds on version 16.3 without the fix of [1]. Now, the adapted test fails on version 16.3 without the fix of [1]. [1]: https://github.com/odoo/odoo/commit/0fd2477d993e822fe6fd4497aace9f746af7a481 task-3717041 Forward-Port-Of: odoo/odoo#156943 Forward-Port-Of: odoo/odoo#153014
This update fixes a gap in our HR contract management system by adding essential fields. Previously, certain contract details were not consistently tracked, leading to potential data inconsistencies. Now, all contracts will include the required information, improving accuracy and streamlining HR processes.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157012
This update corrects a problem where deleting an action in Odoo would sometimes display an error message related to a missing filter. The fix ensures that user-defined filters are automatically removed when their parent action is deleted, preventing these errors and improving data consistency.
Original PR description
When deleting records from ir.action.action, the user-defined filters(ir.filters) will not be deleted automatically, thus causing an error. Steps to reproduce: - Create a User-defined Filter under any action - Remove that action - Go to User-defined Filter again -> There will be an error message pop out that says action record does not exist Cause The User-defined Filters will not be automatically removed when the parent action gets deleted Solution Remove all the User-defined Filters when deleting the parent action Forward-Port-Of: odoo/odoo#156622
This update fixes a display issue where the domain picker incorrectly reversed in RTL mode, showing email addresses in the wrong format (domain@alias instead of alias@domain). Now, the domain picker functions correctly regardless of the user's language settings, ensuring accurate email address display.
Original PR description
**Description of the issue/feature this PR addresses:** This PR resolves an issue where the domain picker was being unintentionally reverted in RTL mode, leading to a disruption in the email format. **Current behavior before PR:** Switching to RTL mode would inadvertently revert the domain picker, causing a disruption in the email format. The expected format is Alias@domain, but it was displaying as domain@alias. **Desired behavior after PR is merged:** Now, the domain picker remains intact in RTL mode, ensuring that the email format is correctly displayed as alias@domain. Task link: https://www.odoo.com/web#model=project.task&id=3624012 Task-3624012 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157091 Forward-Port-Of: odoo/odoo#154834
This update resolves an issue where the email composer could display inconsistent data due to user-specific inconsistencies. The fix ensures that the composer consistently accesses reliable information, leading to a more stable and accurate email creation experience. This improves the overall reliability of the email functionality.
Original PR description
Avoid accessing inconsistent data based on the user Forward-Port-Of: odoo/odoo#157098
A recent test related to Odoo's image handling was intermittently failing. This update increases the test's waiting period, ensuring the image is properly set before the test completes. This resolves a minor issue that could have impacted the reliability of image functionality.
Original PR description
Before this commit, the changed test sometimes failed because we expected the image to be set, but it wasn't (yet). This commit increases the delay. Runbot error 56099 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#157335
This pull request updates the core spreadsheet component used in Odoo. It addresses several bug fixes and performance improvements related to data validation, calculations, and autofill functionality, ensuring a smoother and more reliable spreadsheet experience for users. These changes contribute to overall stability and efficiency within the Odoo platform.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/3a9f33458 [REL] 17.1.7 https://github.com/odoo/o-spreadsheet/commit/7d7fddba9 [FIX] header_positions: perfs of update…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/3a9f33458 [REL] 17.1.7 https://github.com/odoo/o-spreadsheet/commit/7d7fddba9 [FIX] header_positions: perfs of update style Task: 3797400 https://github.com/odoo/o-spreadsheet/commit/41682f930 [PERF] functions: return #N/A instead of throwing Task: 3775565 https://github.com/odoo/o-spreadsheet/commit/1c3a9fca1 [FIX] automatic_sum: wrong behaviour with spreaded values Task: 3782971 https://github.com/odoo/o-spreadsheet/commit/2133f544a [FIX] DataValidationCheckbox: Fix input positioning in FF Task: 3774645 https://github.com/odoo/o-spreadsheet/commit/81b1983d8 [FIX] evaluation: ensure value to evaluated cell https://github.com/odoo/o-spreadsheet/commit/1b104b810 [FIX] GridComposer: Reset the cell reference visibility on stop edition Task: 3736211 https://github.com/odoo/o-spreadsheet/commit/99390b35a [FIX] data validation: checkbox not disabled in readonly Task: 3773923 https://github.com/odoo/o-spreadsheet/commit/f2fe5d0a7 [IMP] data validation: performance of icons Task: 3773923 https://github.com/odoo/o-spreadsheet/commit/ce113cc3c [PERF] evaluation: apply compute function Task: 3775636 https://github.com/odoo/o-spreadsheet/commit/b1aeca88d [FIX] autofill: allow to autofill a mix of number values and formulas Task: 3700733
This update fixes an issue where images, like user profile pictures, weren't loading correctly when viewed outside of the current record. The system was using an outdated method for caching images, leading to inconsistent display. This change ensures all images, including user images, load properly in Kanban and Activity views.
Original PR description
The way we cache the image is not right when that image is not on the current record. For instance displaying a partner/user image. The unique key used is not related to that record. Introduced by https://github.com/odoo/odoo/pull/97544 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#157199 Forward-Port-Of: odoo/odoo#157004
This update ensures that a unique security identifier (secure_sequence_id) is automatically created when a new journal is set up with specific security restrictions. Previously, this ID wasn't generated unless the journal was manually modified. This change improves security by consistently tracking journal configurations and preventing potential vulnerabilities.
Original PR description
**Description of the issue/feature this PR addresses:** The secure_sequence_id is not generated when creating a journal with restrict_mode_hash_table set to True. It only happens if you trigger a…
**Description of the issue/feature this PR addresses:** The secure_sequence_id is not generated when creating a journal with restrict_mode_hash_table set to True. It only happens if you trigger a write() on the record. Even changing it's name on edit triggers the creation of the sequence. On runbot is correctly created because account_check_printing triggers a write() after the create of the account.journal. But this module is not a dependency from account (or any of it's dependencies) and if it is uninstalled, this behaviour occurs. **Current behavior before PR:** When creating an account.journal with restrict_mode_hash_table set to True we should generate the secure_sequence_id but it's not happing. It is only contemplated on the write() **Desired behavior after PR is merged:** When creating an account.journal with restrict_mode_hash_table set to True we generate the secure_sequence_id. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157134 Forward-Port-Of: odoo/odoo#155188
This update addresses a technical issue within the Odoo system related to a test for user avatars. The original fix attempted a problematic workaround, which has now been removed. This change ensures the test runs correctly and maintains the system's stability.
Original PR description
This PR fixes an infinite setTimout loop in a m2x avatar test. Patching the setTimeout method is not a good idea anyway since it makes it synchronous which totally changes the flow that is tested. This PR removes this patch as the assertion that relies on it is too technical anyway. fixes runbot-55891
This update resolves an issue where non-administrator users were unable to access journal items within the accounting module. Previously, access was restricted, preventing users from performing essential accounting tasks. This change ensures all users, regardless of their permissions, can manage journal items correctly.
Original PR description
Steps to reproduce: - Install Accounting - Connect with a user without "Administration: Settings" rights (e.g. Marc Demo) - Go to "Accounting / Accounting / Journals / Journal Items" Issue: An Access Error is raised when trying to access a "ir.ui.view" record that is restricted to "Administration/Settings" group. opw-3787114 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#157363
Miscellaneous changes
Issue --> In `_onClickSaleOrder`, we load in the partner on the sale order using `load_new_partners()`. However, the search on the `res.partner` model made in this method has the potential to return every single `res.partner` record because of the domain that it uses --> https://github.com/odoo/odoo/blob/6c2dd5fbd9898f0efecdc35593af69bfd7d4eb50/addons/point_of_sale/static/src/js/models.js#L783-L785 This can cause SQL to overwork especially when computing the 'total_due' field. After doing
Original PR description
Issue --> In `_onClickSaleOrder`, we load in the partner on the sale order using `load_new_partners()`. However, the search on the `res.partner` model made in this method has the potential to return…
Issue --> In `_onClickSaleOrder`, we load in the partner on the sale order using `load_new_partners()`. However, the search on the `res.partner` model made in this method has the potential to return every single `res.partner` record because of the domain that it uses --> https://github.com/odoo/odoo/blob/6c2dd5fbd9898f0efecdc35593af69bfd7d4eb50/addons/point_of_sale/static/src/js/models.js#L783-L785 This can cause SQL to overwork especially when computing the 'total_due' field. After doing so, we check if the partner has been loaded and we grab the id using `get_partner_by_id`. If the partner is not loaded, we use `_loadPartners` to load them. Since we are already checking and reloading the partner on the sale order using `_loadPartners`, using `load_new_partners()` earlier is redundant. Solution --> Remove the try-catch block that loads multiple `res.partner` records during the process of clicking on a sale order via POS. opw-3619941 Forward-Port-Of: odoo/odoo#157171 Forward-Port-Of: odoo/odoo#156836
This fix ensures country settings are applied only to the main chart of accounts localization modules, not to dependent add-ons. It also corrects payroll localization dependencies so payroll and accounting components install in the right order, reducing setup issues for localized payroll deployments.
List labels gets less hyphened Quant... > Quantity, Unit P... -> Unit Price The issue was more specific to float/integer fields, whose space was limited. So the padding around the arrow was utting a lot of space for he label. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146803
Original PR description
List labels gets less hyphened Quant... > Quantity, Unit P... -> Unit Price The issue was more specific to float/integer fields, whose space was limited. So the padding around the arrow was utting a lot of space for he label. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146803
Currently, there's a mistake in the Belgian tax report checks, which can cause the tax report to fail validation even though it's correct. ### Steps to reproduce * install `l10n_be_reports` * switch to a Belgian company. * activate the `21% EU S` purchase tax * make sure you don't have any posted journal entry * create and confirm a vendor bill with a line for $5000 and the `21% EU S` tax * open the tax report The tax report is correct, but the system displays a validation error at
Original PR description
Currently, there's a mistake in the Belgian tax report checks, which can cause the tax report to fail validation even though it's correct. ### Steps to reproduce * install `l10n_be_reports` * switch to a Belgian company. * activate the `21% EU S` purchase tax * make sure you don't have any posted journal entry * create and confirm a vendor bill with a line for $5000 and the `21% EU S` tax * open the tax report The tax report is correct, but the system displays a validation error at the bottom: `[44] < ([00] + [01] + [02] + [03] + [45] + [46] + [47] + [48] + [49]) * 200 if [88] > 99.999` opw-3767675 Note: confirmed by TSB on the ticket Forward-Port-Of: odoo/enterprise#58343
The test for `sw` fails every time because we don't have identifiers. We don't have any, so we just get rid of the test. Also added the message to the error, so we can know why it failed. (Other tests failed some time, but we can't reproduce and know why it failed). Linked to runbot error 25908 Forward-Port-Of: odoo/enterprise#58443
Original PR description
The test for `sw` fails every time because we don't have identifiers. We don't have any, so we just get rid of the test. Also added the message to the error, so we can know why it failed. (Other tests failed some time, but we can't reproduce and know why it failed). Linked to runbot error 25908 Forward-Port-Of: odoo/enterprise#58443
Before this commit: Switching to RTL mode would inadvertently revert the domain picker, causing a disruption in the email format. The expected format is Alias@domain, but it was displaying as domain@alias. After this commit: Now, the domain picker remains intact in RTL mode, ensuring that the email format is correctly displayed as alias@domain. Task-3624012 Forward-Port-Of: odoo/enterprise#58364 Forward-Port-Of: odoo/enterprise#58251
Original PR description
Before this commit:
Switching to RTL mode would inadvertently revert the domain picker,
causing a disruption in the email format. The expected format is Alias@domain,
but it was displaying as domain@alias.
After this commit:
Now, the domain picker remains intact in RTL mode, ensuring that
the email format is correctly displayed as alias@domain.
Task-3624012
Forward-Port-Of: odoo/enterprise#58364
Forward-Port-Of: odoo/enterprise#58251when database uploaded without demo data and there is no any record in mrp production, and customer used load sample demo data, then it will create some demo record from this file which was actually defined in mrp/data/mrp_demo.xml with noupdate= True. but as this xmlids has been created from python file using load samples it's noupdate='f' . so without demo flag, we have `mrp.mrp_inventory_1` and `mrp.mrp_inventory_2` quant entry with noupdate='f' so during upgrade as there was no demo f
Original PR description
when database uploaded without demo data and there is no any record in mrp production, and customer used load sample demo data, then it will create some demo record from this file which was actually…
when database uploaded without demo data and there is no any record in mrp production, and customer used load sample demo data, then it will create some demo record from this file which was actually defined in mrp/data/mrp_demo.xml with noupdate= True.
but as this xmlids has been created from python file using load samples it's noupdate='f' .
so without demo flag, we have `mrp.mrp_inventory_1` and `mrp.mrp_inventory_2` quant entry with noupdate='f'
so during upgrade as there was no demo file loaded, and this entry are with noupdate='f'
ORM try to remove those record quants record
in `_process_end` during upgrade from 17.0 to
saas-17.1, and which was create issues as
that quant contain some qty for storable product
so after upgrade as this qunts removed we have mismatched qty compare to before upgrade ( original database) so to fix that we need to pass noupdate='t'
and also need to fix in upgrade script with force_noupdate TRue.
```
Traceback (most recent call last):
File "/tmp/tmpf_o_71pk/migrations/testing.py", line 207, in test_check
self.check(value)
File "/tmp/tmpf_o_71pk/migrations/stock/tests/test_on_hand_quantity.py", line 58, in check
self.assertEqual(before_results, self.convert_check(after_results), self.message)
AssertionError: Lists differ: [[3, '1'], [4, '4'], [6, '2'], [7, '5'], [8[541 chars]36']] != [[6, '2'], [7, '5'], [8, '2'], [9, '1'], [1[521 chars]36']]
First differing element 0:
[3, '1']
[6, '2']
```
Forward-Port-Of: odoo/enterprise#58007In commit 355250d, the domain was adjusted to automatically select the invoice document type for customers with a RUC and limit others to the "boleta" document type. This generally holds true, except for export invoices requiring the 01 document type. This commit addresses the current restriction, allowing the selection of document type 01 other than "boleta" or "debit note boleta." For this, inherit the compute method, and extend the depends to add the operation type and allow generate invoi
Original PR description
In commit 355250d, the domain was adjusted to automatically select the invoice document type for customers with a RUC and limit others to the "boleta" document type. This generally holds true, except for export invoices requiring the 01 document type. This commit addresses the current restriction, allowing the selection of document type 01 other than "boleta" or "debit note boleta." For this, inherit the compute method, and extend the depends to add the operation type and allow generate invoice for exportation cases. [Odoo PR related](https://github.com/odoo/odoo/pull/154511) Forward-Port-Of: odoo/enterprise#56465
The orm doesn't match monetary amounts using the related currency. It means, -208.73 != 208.730000000000002. Let's match the amount using an sql query instead. ticket_id: 3741689 X-original-commit: ae848e9 Forward-Port-Of: odoo/enterprise#58333
Original PR description
The orm doesn't match monetary amounts using the related currency. It means, -208.73 != 208.730000000000002. Let's match the amount using an sql query instead. ticket_id: 3741689 X-original-commit: ae848e9 Forward-Port-Of: odoo/enterprise#58333
Allow the user to set back the debit or credit to 0. It's a bug introduced by https://github.com/odoo/odoo/commit/c3793357d823273cb4297b0eb31308ad73a9dff8 Allow to create an opening balance for an account having a foreign currency. opw: 3665557 Forward-Port-Of: odoo/enterprise#58462 Forward-Port-Of: odoo/enterprise#56520
Original PR description
Allow the user to set back the debit or credit to 0. It's a bug introduced by https://github.com/odoo/odoo/commit/c3793357d823273cb4297b0eb31308ad73a9dff8 Allow to create an opening balance for an account having a foreign currency. opw: 3665557 Forward-Port-Of: odoo/enterprise#58462 Forward-Port-Of: odoo/enterprise#56520
* Account 2104 'Prelevamenti extra gestione' was not referenced in the Balance Sheet. This account tracks withdrawals made by an individual entrepreneur during the fiscal year, before determination of profits, and therefore decreases capital. ([source1](https://www.wincoge2.it/Manuale%20Con%20Esempi/Manuale_Contabilita8.html#:~:text=I%20%E2%80%9CPrelevamenti%20extra%20gestione%E2%80%9D%20sono,nell'arco%20dell'anno.&text=Al%2031%2F12%20la%20voce,la%20destinazione%20dell'utile%20stesso.)) ([source
Original PR description
* Account 2104 'Prelevamenti extra gestione' was not referenced in the Balance Sheet. This account tracks withdrawals made by an individual entrepreneur during the fiscal year, before determination of profits, and therefore decreases capital. ([source1](https://www.wincoge2.it/Manuale%20Con%20Esempi/Manuale_Contabilita8.html#:~:text=I%20%E2%80%9CPrelevamenti%20extra%20gestione%E2%80%9D%20sono,nell'arco%20dell'anno.&text=Al%2031%2F12%20la%20voce,la%20destinazione%20dell'utile%20stesso.)) ([source2](https://www.economiaziendale.net/scritture/spese_extragestione.htm)) * The Current Year Earnings line was not showing just the result from the Profit and Loss for the current fiscal year. This has been fixed. Any non-closed results from previous fiscal years now automatically appear under the Previous Years' Earnings line. taskid: 3060790 Forward-Port-Of: odoo/enterprise#58393 Forward-Port-Of: odoo/enterprise#57219
Steps to reproduce: - Install Accounting and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - Configure Peruvian localization (https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/peru.html) - Create an invoice: * Customer: Comercial Constructora los Patitos S.A. * Operation Type: [0101] Internal sale * Invoice Lines: - Product: Arroz descascarillado (arroz cargo o arroz pardo) - Taxes: 18% - Terms and Conditions: [text containing
Original PR description
Steps to reproduce:
- Install Accounting and l10n_pe_edi
- Switch to a Peruvian company (e.g. PE Company)
- Configure Peruvian localization (https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/peru.html)
- Create an invoice:
* Customer: Comercial Constructora los Patitos S.A.
* Operation Type: [0101] Internal sale
* Invoice Lines:
- Product: Arroz descascarillado (arroz cargo o arroz pardo)
- Taxes: 18% - Terms and Conditions: [text containing several consecutive spaces and/or several lines]
- Confirm the invoice
- Process UBL 2.1
Issue:
The service responds with an error because the <cbc:Note> node doesn't comply with the supported format.
Special characters like '\n' and '\u00A0' are not supported.
opw-3744946
Linked community PR: https://github.com/odoo/odoo/pull/155081
Forward-Port-Of: odoo/enterprise#57268task-3610704 Forward-Port-Of: odoo/enterprise#52297
Original PR description
task-3610704 Forward-Port-Of: odoo/enterprise#52297
Issue: ----------- Even if the contract is archived, the contract is still visible in the contract menu. Fixed: -------------- If the contract is archived, then the contract will not be visible task-3522177 Forward-Port-Of: odoo/enterprise#48534
Original PR description
Issue: ----------- Even if the contract is archived, the contract is still visible in the contract menu. Fixed: -------------- If the contract is archived, then the contract will not be visible task-3522177 Forward-Port-Of: odoo/enterprise#48534
It makes it very difficult to translate Forward-Port-Of: odoo/enterprise#53297
Original PR description
It makes it very difficult to translate Forward-Port-Of: odoo/enterprise#53297
…ct warning * a regular user error can be displayed user-side instead of the redirect warning, in case we don't want to propose to contact the support (in case there's no need) Forward-Port-Of: odoo/enterprise#58308 Forward-Port-Of: odoo/enterprise#56935
Original PR description
…ct warning * a regular user error can be displayed user-side instead of the redirect warning, in case we don't want to propose to contact the support (in case there's no need) Forward-Port-Of: odoo/enterprise#58308 Forward-Port-Of: odoo/enterprise#56935
**Issue** website_appointment_tour was not working properly because of some changes done in the mail.py and appointment app. **After this PR** Now the appointment tour is working perfectly as expected. Task-3774280 Forward-Port-Of: odoo/enterprise#57898
Original PR description
**Issue** website_appointment_tour was not working properly because of some changes done in the mail.py and appointment app. **After this PR** Now the appointment tour is working perfectly as expected. Task-3774280 Forward-Port-Of: odoo/enterprise#57898
Current behavior: When trying to refund a pos order you had an error saying you can't refund the order. Steps to reproduce: - Create a pos order - Validate the order - Go in the backend without closing the session - Try to refund the order This was happening because here (https://github.com/odoo/odoo/blob/c1b86a946d74ea6fbd1d1932da5221ec770ed3a8/addons/point_of_sale/models/pos_order.py#L1050) we trigger this constrains (https://github.com/odoo/enterprise/blob/cc86cdefb375c60b0d1f26e74
Original PR description
Current behavior: When trying to refund a pos order you had an error saying you can't refund the order. Steps to reproduce: - Create a pos order - Validate the order - Go in the backend without closing the session - Try to refund the order This was happening because here (https://github.com/odoo/odoo/blob/c1b86a946d74ea6fbd1d1932da5221ec770ed3a8/addons/point_of_sale/models/pos_order.py#L1050) we trigger this constrains (https://github.com/odoo/enterprise/blob/cc86cdefb375c60b0d1f26e747bb5c2bc3b7f9e3/l10n_mx_edi_pos/models/pos_order.py#L269) but at this point in the code the lines aren't copied in the refund order and so it is triggering the error. To fix it we make sure to check that the order contains atleast one order line. opw-3750165 Forward-Port-Of: odoo/enterprise#58291
This commit fixes an issue with the comments panel when creating comment. When you have the panel opened and you want to create a comment, after logging your message the temporary box is not removed, leading to issues like boxes not being handled or crashes. This is caused because when syncing the handler and the panel when creating the comment, the insertion function was still the one from the handler meaning that the KnowledgeComment was not using the correct function which led to thos
Original PR description
This commit fixes an issue with the comments panel when creating comment. When you have the panel opened and you want to create a comment, after logging your message the temporary box is not removed, leading to issues like boxes not being handled or crashes. This is caused because when syncing the handler and the panel when creating the comment, the insertion function was still the one from the handler meaning that the KnowledgeComment was not using the correct function which led to those issues. Now when the panel is adding the comment from the handler we change the function so that it uses the correct one. task-3792116 Forward-Port-Of: odoo/enterprise#58253
Forward-Port-Of: odoo/enterprise#58326
Original PR description
Forward-Port-Of: odoo/enterprise#58326
Steps to reproduce: - - Create an SO with two lines containing the product “Field Service” - Confirm the SO > 2 fsm tasks are created - Open the first task > access catalog via the `Products` smartbutton - Add any product to the SO. - Open the second task > access catalog via the `Products` smartbutton - Add the same product to the SO. - Open the first task > access catalog via the `Products` smartbutton - Try to add more of that product **IMPOSSIBLE : “You can’t edit this product in
Original PR description
Steps to reproduce: - - Create an SO with two lines containing the product “Field Service” - Confirm the SO > 2 fsm tasks are created - Open the first task > access catalog via the `Products`…
Steps to reproduce: - - Create an SO with two lines containing the product “Field Service” - Confirm the SO > 2 fsm tasks are created - Open the first task > access catalog via the `Products` smartbutton - Add any product to the SO. - Open the second task > access catalog via the `Products` smartbutton - Add the same product to the SO. - Open the first task > access catalog via the `Products` smartbutton - Try to add more of that product **IMPOSSIBLE : “You can’t edit this product in the catalog”** Cause of the issue: - The way the catalogue is computed was refactored between 16.4 and 17.0 see: odoo commit bc01c7bcec974ee095f5855f225667645ef40213 The above situtation is not yet handled by this refactoring. In 16.4, since the catalogue was acceced from the task linked to the Field service, the quantities it displayed were computed with respect to that task. However, in 17.0 the quantities appearing in the catalogue are computed from the main SO containing both `Field services` SOL instead of being computed contextually from the task they are linked to. To be more precise: - When clicking on the smart button, the quantities appearing in the calatalogue are computed by the `_get_product_catalog_order_line_info`. This method starts by grouping the SOL referencing each product of the catalogue using the `_get_product_catalog_record_lines`: https://github.com/odoo/odoo/blob/c7f982774654459a2db6decd6ae1948e05e7d622/addons/product/models/product_catalog_mixin.py#L91-L92 https://github.com/odoo/odoo/blob/c7f982774654459a2db6decd6ae1948e05e7d622/addons/sale/models/sale_order.py#L1823-L1829 But here is the problem, since both SOL were able to reference the same product of the catalogue the product of the catalog will be set to 'readOnly' here (because `self` will contain both SOL): https://github.com/odoo/odoo/blob/c91ffa3bdbff845088111bc3036500c2c03fc357/addons/sale/models/sale_order_line.py#L1222-L1227 Hence, we will not be able to edit its value from the catalogue: https://github.com/odoo/odoo/blob/c91ffa3bdbff845088111bc3036500c2c03fc357/addons/product/static/src/product_catalog/order_line/order_line.xml#L18-L20 Fix: - As discussed with the PO of the Field Service module (see conversation of the ticket), the catalogue should be computed contextually using the task from which we access it and not from all tasks referring to that product in the main SO. Doing so will solve the problem since only one SOL will be associated to that product of the catalogue and the product will be set to `'readOnly' : False`: https://github.com/odoo/odoo/blob/c91ffa3bdbff845088111bc3036500c2c03fc357/addons/sale/models/sale_order_line.py#L1212-L1216 opw-3748833 --- Forward-Port-Of: odoo/enterprise#57561