Monday, November 25, 2024
36 changes · saas-17.4
Resolved issues and error corrections
This fix ensures that applying a down payment to a sales order in Point of Sale no longer creates duplicate payment lines when the order includes note lines and taxed items. It helps keep orders accurate and avoids confusion or overstatement during checkout.
Original PR description
Before this commit, if a sale order had some note lines and the rest of the lines had tax on them, there would be two lines created when applying a down payment. opw-4281589 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product links shown in accounting document line labels now use the updated Odoo URL format. This prevents broken links and helps users navigate reliably from accounting lines to related product records.
Original PR description
The links created with the product_label_section_and_note_field widget won't work correctly. This commit, will change the link to the new format. This commit is a followup of odoo/odoo@98f7486
The restaurant POS now only shows the Bill button when early receipt printing is enabled in the POS settings. This prevents staff from seeing an unavailable action and reduces confusion during order handling.
Original PR description
This commit fixes an issue where the Bill button was displayed even when early receipt printing was not enabled in the POS configuration. opw-4274728 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Uploading PDFs for sales quote documents could fail when the file contained harmless warning conditions, such as repeated metadata from multiple exports. The update ensures those warnings are ignored so users can upload valid PDFs without unnecessary interruptions.
Original PR description
Trying to upload a PDF, in some circumstances (e.g. multiple info due to pypdf being exported multiple times), would raise some warnings that were caught instead of being ignored.
Public visitors no longer trigger an unnecessary session expired message when viewing forum pages. The translation toolbar option is now shown only to signed-in users, reducing confusion for website visitors.
Original PR description
Before this commit: When a public user accessed a forum page, a "Odoo session expired" notification would appear unnecessarily. After this commit: The loadLanguages RPC call is now executed only for authenticated (non-public) users. The "Translate" button in the toolbar is hidden for public users. task-4348290 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A label issue was fixed for project and timesheet-related fields that can appear when users add custom search fields. The change keeps explanatory helper text separate from field names, so users see clearer labels in custom search options.
Original PR description
Before this commit, the #162167 PR changes the help into string for 2 fields since the string will not be translated and those fields are not displayed in the UI. However, those fields could be selected in custom search (when the user would like to add a custom field) and so the label displayed will be the helper. This commit makes sure the helper is inside the help instead of `string` even if the field is a technical one since the field can be selected in the custom search. opw-4348264
This fix restores the missing activity view configuration for field service task actions. It helps users access the expected activity planning view consistently in Field Service, avoiding confusion when managing tasks.
Original PR description
- In version 17.3, the activity view mode is defined for both the project_task_action_fsm action and the project_task_action_fsm_map action. However, it has been observed that a record named…
- In version 17.3, the activity view mode is defined for both the project_task_action_fsm action and the project_task_action_fsm_map action. However, it has been observed that a record named project_task_action_fsm_map_view_activity also exists. This redundancy causes the project_task_action_fsm action to not be properly configured with the activity view mode, as no corresponding view link or defined view exists. - Additionally, the record project_task_action_fsm_map_view_activity has the same name, but no corresponding record has been created. To resolve this issue, I have renamed the record to ensure consistency with its definition in the XML file. **Steps to Reproduce:** 1) Create a database in version saas-17.4 and install the industry_fsm module. 2) Check the project_task_action_fsm action and note that the activity view mode and view are not defined. [Reference](https://github.com/odoo/enterprise/commit/f16c338c2c20a0424ef749bdf35d1b7863347a8e#diff-170f2bf3c03ad1bf01ffe9fd0d8490e6ee7e193f96da6ad8d8babfe6e3867706R471) upg-2202488 tbg-1597
Miscellaneous changes
It is not necessary useful to prevent the event in our case, so we can just stop doing it while maintaining the same functionality. Preventing the event writes a log in the console, and we prefer to avoid having a log if we can keep the service without it. Forward-Port-Of: odoo/odoo#188418
Original PR description
It is not necessary useful to prevent the event in our case, so we can just stop doing it while maintaining the same functionality. Preventing the event writes a log in the console, and we prefer to avoid having a log if we can keep the service without it. Forward-Port-Of: odoo/odoo#188418
Before this commit: Some logger.error(...) were ambigious and would just catch the exception to log it's error name without much details. Therefore it was wasting time trying to figure the cause of the error as we lack the traceback details After this commit: Most of them were switch to logger.exception which does add the Exception information to the logging messages automatically. Which include the error message alongside the full traceback. Log messages were also rewrote to be more
Original PR description
Before this commit: Some logger.error(...) were ambigious and would just catch the exception to log it's error name without much details. Therefore it was wasting time trying to figure the cause of the error as we lack the traceback details After this commit: Most of them were switch to logger.exception which does add the Exception information to the logging messages automatically. Which include the error message alongside the full traceback. Log messages were also rewrote to be more comprehensive than the: "An error encountered" Example of logs that would be improved: ``` 2024-11-19 07:19:50,611 1138 ERROR ? odoo.addons.hw_drivers.tools.helpers: Unable to load file: PrinterInterface_L.py 2024-11-19 07:19:50,612 1138 ERROR ? odoo.addons.hw_drivers.tools.helpers: An error encountered : (1280, 'Success') ``` Forward-Port-Of: odoo/odoo#187959 Forward-Port-Of: odoo/odoo#186162
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#188235
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#188235
Based on the received OXP feedback we are: * Activating cash basis by default. * All taxes are based on payment. task-4226448 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188106
Original PR description
Based on the received OXP feedback we are: * Activating cash basis by default. * All taxes are based on payment. task-4226448 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188106
### Steps to reproduce: - Install "l10n_sa" and the Arabic language - Create a product and translate its name to Arabic - Create an invoice and print it - In the invoice lines under the description column only one translation displays and not both as it should. ### Cause: The code was changed to only display the current language in this [commit](https://github.com/odoo/odoo/commit/67b041521d05cbcf5adaf04998278c10fa046790). The goal of this commit was to prevent the duplication of the pro
Original PR description
### Steps to reproduce: - Install "l10n_sa" and the Arabic language - Create a product and translate its name to Arabic - Create an invoice and print it - In the invoice lines under the description…
### Steps to reproduce: - Install "l10n_sa" and the Arabic language - Create a product and translate its name to Arabic - Create an invoice and print it - In the invoice lines under the description column only one translation displays and not both as it should. ### Cause: The code was changed to only display the current language in this [commit](https://github.com/odoo/odoo/commit/67b041521d05cbcf5adaf04998278c10fa046790). The goal of this commit was to prevent the duplication of the product name because it is already contained in line.name. ### Solution: The way line.name is computed is by taking the sales description (or purchase one) and concatenating it with the product name. It can also be changed manually in the invoice form view under "label". So to display the product name in both languages and this label without any duplicate this commit adds conditions: - the label is always displayed - the Arabic name is displayed if the label does not contains it - the English name is displayed if the label does not contains it and if it is different from the Arabic one (ie if it is translated) opw-4187577 Forward-Port-Of: odoo/odoo#188298 Forward-Port-Of: odoo/odoo#186449
This PR fixes readability issues within the forecast details table. Prior to this PR, the table was using arbitrary color that were out of our color maps, meaning that they were not dark mode proof by default. As no variation was defined for these color in dark mode, some readability issues would occur in some cases (e.g link color over that background in dark mode). To handle this issue, we go back to basics and use Bootstrap default table utility classes, easing the maintenance and pr
Original PR description
This PR fixes readability issues within the forecast details table. Prior to this PR, the table was using arbitrary color that were out of our color maps, meaning that they were not dark mode proof by default. As no variation was defined for these color in dark mode, some readability issues would occur in some cases (e.g link color over that background in dark mode). To handle this issue, we go back to basics and use Bootstrap default table utility classes, easing the maintenance and preventing. readability issues. | 16.0 | This PR | |--------|--------| | <img width="459" alt="image" src="https://github.com/user-attachments/assets/571d9dea-2f42-479d-9fb1-85c9e1afbc76"> | <img width="451" alt="image" src="https://github.com/user-attachments/assets/121ec777-5a24-48da-912e-41f51e662e7a"> | task-4344045 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188308 Forward-Port-Of: odoo/odoo#187719
_*=payment_razorpay In This PR Razorpay payment onboarding form to take advantage of the Razorpay Connect Onboarding Flow. It integrates the Razorpay Onboarding using the IAP proxy. **Purpose** ======== Help users easily onboard with Razorpay by using the Razorpay Connect API. **Specification** =========== **1.Connect and authorized the razorpay account.** - To connect to a sub-merchant's Razorpay account, the application redirects the user to a Razorpay-hosted webpage. The
Original PR description
_*=payment_razorpay In This PR Razorpay payment onboarding form to take advantage of the Razorpay Connect Onboarding Flow. It integrates the Razorpay Onboarding using the IAP proxy. **Purpose**…
_*=payment_razorpay In This PR Razorpay payment onboarding form to take advantage of the Razorpay Connect Onboarding Flow. It integrates the Razorpay Onboarding using the IAP proxy. **Purpose** ======== Help users easily onboard with Razorpay by using the Razorpay Connect API. **Specification** =========== **1.Connect and authorized the razorpay account.** - To connect to a sub-merchant's Razorpay account, the application redirects the user to a Razorpay-hosted webpage. The user can approve or deny the authorisation request on this page. **2.Get an access token.** - After you obtain an access token, you can use it to access the sub-merchant data on Razorpay APIs. The access is controlled based on the scope requested for and granted by the user during the authorization process. **3.Get a refresh token.** - You can use refresh tokens to generate a new access token. If your access token expires, you will receive a 4XX response from the API. You can make a request using your refresh token to generate a new access token. **4.Revoke token.** - The API supports token revocation to enhance security and manage access. If needed, tokens can be revoked through this mechanism. **5.Create & update webhook.** - This method is responsible for creating or updating the Razorpay webhook associated with the current Odoo instance.The webhook is crucial for updating payment states within Odoo when changes occur in Razorpay. **6.Revoke the application from Razorpay.** - User can initiate the revocation of their application from the Razorpay side facilitating a seamless process for application revocation. task-3537535 Forward-Port-Of: odoo/odoo#158578
After discussion with Pagero support, the BIC of the Payee must be set, therefore we add a constraint to enforce it when invoicing to Chorus Pro. opw-4139689 Forward-Port-Of: odoo/odoo#187535
Original PR description
After discussion with Pagero support, the BIC of the Payee must be set, therefore we add a constraint to enforce it when invoicing to Chorus Pro. opw-4139689 Forward-Port-Of: odoo/odoo#187535
# First fix Steps to reproduce: ------------------- 1. Install Project and Sales apps 2. Log in as admin user (e.g. Mitchell Admin), and create a billable project for a customer A 3. Invite user B (e.g. Marc Demo) to the project 4. Only give project (user) access rights to the user B, remove all other access rights 5. Create an SO with customer A as partner, add a service product (e.g. Junior Architect), confirm the SO and create a timesheet 6. Log in as user B, create a task in the bi
Original PR description
# First fix Steps to reproduce: ------------------- 1. Install Project and Sales apps 2. Log in as admin user (e.g. Mitchell Admin), and create a billable project for a customer A 3. Invite user B…
# First fix Steps to reproduce: ------------------- 1. Install Project and Sales apps 2. Log in as admin user (e.g. Mitchell Admin), and create a billable project for a customer A 3. Invite user B (e.g. Marc Demo) to the project 4. Only give project (user) access rights to the user B, remove all other access rights 5. Create an SO with customer A as partner, add a service product (e.g. Junior Architect), confirm the SO and create a timesheet 6. Log in as user B, create a task in the billable project from the task form, make sure customer A is set as partner 7. Save the task, an access error is raised Fix: ------------------- When creating a new task from the form, _inverse_partner_id() is called, which calls task._get_last_sol_of_customer(). As the user has no Sales access, the search of the SOL in _get_last_sol_of_customer() will raise an Access Error in such case. We add a sudo() before calling _get_last_sol_of_customer() to give the user access to the SOL we are looking for. # Second fix Steps to reproduce: ------------------- 1. Configure a user with the project > user and sales > user: own documents access rights 2. Log in with this user 3. Create a task in a billable project (e.g. for Deco Addict) 4. The compute automatically sets an SOL but the current user doesn't have access to the SOL (make sure that the user does not have access to the SOL that is set) 5. Error when trying to update the value of the SOL Fix: ------------------- We add a sudo() in _get_partner_display() to give the user access to the SO. As the user may not have access to the SO of the SOL that is currently set in the task. task-4207245 version-17.2 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182184
Before this commit, a KeyError would occur if 'entryPointType' was missing in the entryPoints dictionary. opw-4009884 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188002
Original PR description
Before this commit, a KeyError would occur if 'entryPointType' was missing in the entryPoints dictionary. opw-4009884 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188002
* Deferred expense: 110300 Prepayments (current assets) * Deferred revenue: 210900 Accruals (current liabilities) task-4338265 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187704
Original PR description
* Deferred expense: 110300 Prepayments (current assets) * Deferred revenue: 210900 Accruals (current liabilities) task-4338265 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187704
Description of the issue this PR addresses: Previously, selection using Shift + Arrow keys was not possible across contenteditable=false elements such as banners and clipboards. This commit makes sure now selection be done across these elements using Shift + Arrow keys. task-3502724 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182503
Original PR description
Description of the issue this PR addresses: Previously, selection using Shift + Arrow keys was not possible across contenteditable=false elements such as banners and clipboards. This commit makes sure now selection be done across these elements using Shift + Arrow keys. task-3502724 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182503
Versions -------- - 16.0+ Steps (16.0+) ------------- 1. Create a no-variant attribute with multiple values; 2. Create a product and assign it those attributes; 3. Add an extra product media from the sales tab; 4. Go to the website and add an extra image through the web editor; 5. Go back and check the extra product media field. The only image displayed is the one you uploaded in step 3. Issue ----- Both images should be shown as this product only has no-variant attributes so th
Original PR description
Versions -------- - 16.0+ Steps (16.0+) ------------- 1. Create a no-variant attribute with multiple values; 2. Create a product and assign it those attributes; 3. Add an extra product media from the sales tab; 4. Go to the website and add an extra image through the web editor; 5. Go back and check the extra product media field. The only image displayed is the one you uploaded in step 3. Issue ----- Both images should be shown as this product only has no-variant attributes so they don't create product variants. Cause ----- In Step 4, the uploaded image is saved to the product variant based on the evaluation of the `has_configurable_attributes` field on the product template and the presence of the variant. Solution -------- Check if the attributes are all `no_variant`. In that case, no product variant is created, so the images should be saved on the product template. opw-4174331 Forward-Port-Of: odoo/odoo#188019 Forward-Port-Of: odoo/odoo#187544
Versions -------- - 17.0+ Steps ----- 1. Have 50% discount program; 2. have a deliverable $300 product; 3. have a $10 shipping method that's free for orders over $250; 4. in eCommerce, add the $300 product to your cart; 5. go to checkout; 6. remove the automatically applied discount; 7. proceed to payment; 8. select the $10 shipping method; 9. click the "Claim" button for the 50% discount. Issue ----- Shipping is still free despite the order being below $250. Cause -----
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have 50% discount program; 2. have a deliverable $300 product; 3. have a $10 shipping method that's free for orders over $250; 4. in eCommerce, add the $300 product to your cart; 5. go to checkout; 6. remove the automatically applied discount; 7. proceed to payment; 8. select the $10 shipping method; 9. click the "Claim" button for the 50% discount. Issue ----- Shipping is still free despite the order being below $250. Cause ----- Delivery rate isn't recomputed after applying rewards. Solution -------- After applying a reward in eCommerce, update programs & rewards. If the reward isn't a payment program (gift card or eWallet), and the selected carrier has a `free_over` rule, recompute shipping costs. opw-4319533 Forward-Port-Of: odoo/odoo#188150 Forward-Port-Of: odoo/odoo#187296
Since October 2024, the Facebook mobile site (m.facebook.com) uses an 'X-Frame-Options' header set to 'deny', preventing iframe embedding across different domains. This header enforces a security policy restricting cross-origin access to the content. Meta has not provided any communication regarding this change. Until it is resolved, we have no choice but to hide the iframe on mobile to prevent users from seeing a "unavailable content" icon. Steps to reproduce: - In website edit mode. -
Original PR description
Since October 2024, the Facebook mobile site (m.facebook.com) uses an 'X-Frame-Options' header set to 'deny', preventing iframe embedding across different domains. This header enforces a security policy restricting cross-origin access to the content. Meta has not provided any communication regarding this change. Until it is resolved, we have no choice but to hide the iframe on mobile to prevent users from seeing a "unavailable content" icon. Steps to reproduce: - In website edit mode. - Drag and drop the "Facebook" snippet into the footer. - Save the page. - Open the dev tools and enable the mobile preview. - Bug: The "Facebook" snippet crashes. More info about the issue: https://developers.facebook.com/community/threads/550478830783215/ opw-4302563 opw-4309180 opw-4222359 opw-4277045 Forward-Port-Of: odoo/odoo#187965 Forward-Port-Of: odoo/odoo#186813
When a SO is partially invoiced, and we change the 'Invoicing Switch Threshold' such that the partial invoices are before the new threshold, the SO will not take invoices into account for computation of amount to invoice / invoiced. Steps to reproduce (needs account_accountant installed): - Create a SO with a line having prod invoiced on delivery and qty 3 - Set delivered quantity to 1 - Click Create Invoice > create the draft invoice, set a date (date1) in the past - set a date2 Settin
Original PR description
When a SO is partially invoiced, and we change the 'Invoicing Switch Threshold' such that the partial invoices are before the new threshold, the SO will not take invoices into account for computation of amount to invoice / invoiced. Steps to reproduce (needs account_accountant installed): - Create a SO with a line having prod invoiced on delivery and qty 3 - Set delivered quantity to 1 - Click Create Invoice > create the draft invoice, set a date (date1) in the past - set a date2 Settings > Accounting > Invoicing Switch Threshold later than date1 - Back to the SO, set delivered quantity to 2 - Click Create Invoice > create a new invoice and confirm it Issue: Sale order amount invoiced will take into account only the latest invoice, while it should account also for the legacy invoices opw-4295531 Forward-Port-Of: odoo/odoo#187211
Computing the field in su = False was not working as assigned the variable on the sudo environment. The test in 0baa908385 was working as the read computes the display_name in sudo. Forward-Port-Of: odoo/odoo#188363 Forward-Port-Of: odoo/odoo#188310
Original PR description
Computing the field in su = False was not working as assigned the variable on the sudo environment. The test in 0baa908385 was working as the read computes the display_name in sudo. Forward-Port-Of: odoo/odoo#188363 Forward-Port-Of: odoo/odoo#188310
Before this commit: duplicate words appeared in the GST state validation warning. After this commit: the duplicate words have been removed from the GST state validation warning. Forward-Port-Of: odoo/odoo#188243 Forward-Port-Of: odoo/odoo#187986
Original PR description
Before this commit: duplicate words appeared in the GST state validation warning. After this commit: the duplicate words have been removed from the GST state validation warning. Forward-Port-Of: odoo/odoo#188243 Forward-Port-Of: odoo/odoo#187986
In #183165 the override of the PdfReader constructor was forcing the `strict` parameter to True[1][1] in the pdf shim for PyPDF2 1.x. So, when a PdfReader is instanciated with strict set to False, with that PyPDF version installed, the strict parameter is not taken into account. In that case, it impossible to upload some PDF documents that were allowed before the shims. With this commit, the override of the constructor is removed in the 1.x shim and the PdfReader override is only made once
Original PR description
In #183165 the override of the PdfReader constructor was forcing the `strict` parameter to True[1][1] in the pdf shim for PyPDF2 1.x. So, when a PdfReader is instanciated with strict set to False,…
In #183165 the override of the PdfReader constructor was forcing the `strict` parameter to True[1][1] in the pdf shim for PyPDF2 1.x. So, when a PdfReader is instanciated with strict set to False, with that PyPDF version installed, the strict parameter is not taken into account. In that case, it impossible to upload some PDF documents that were allowed before the shims. With this commit, the override of the constructor is removed in the 1.x shim and the PdfReader override is only made once at the upper level. The `strict` parameter is defaulting to True but not enforced as it was the default behavior in PyPDF2 1.x. It should be changed later to follow the behavior of PyPDF2 >= 2.x. Also, any other parameter of the constructor are discarded as they are useless in PyPDF 1.x and not compatible at all with PyPDF >= 2.x. On the other hand, the new `password` parameter of 2.x is not backward compatible. [1]: odoo/odoo@f03a12c9296c90e6e371f0970fc3760eb5514ab1/odoo/tools/pdf/_pypdf2_1.py#L19 Forward-Port-Of: odoo/odoo#187900
Before this commit, there was no check to see if the microphone was still needed when starting recording, which could leave the stream active with no reference to it. This commit fixes this issue by checking if the component is destroyed when the microphone promise is resolved. Forward-Port-Of: odoo/odoo#187979 Forward-Port-Of: odoo/odoo#187870
Original PR description
Before this commit, there was no check to see if the microphone was still needed when starting recording, which could leave the stream active with no reference to it. This commit fixes this issue by checking if the component is destroyed when the microphone promise is resolved. Forward-Port-Of: odoo/odoo#187979 Forward-Port-Of: odoo/odoo#187870
tax_group_id was not set since company_id was didn't have any country and class wasn't extending from common class. runbot id: 105616 Forward-Port-Of: odoo/odoo#188020
Original PR description
tax_group_id was not set since company_id was didn't have any country and class wasn't extending from common class. runbot id: 105616 Forward-Port-Of: odoo/odoo#188020
Issue ----- With helpdesk_fsm installed, uninstall helpdesk_fsm or any module that will trigger its uninstallation (e.g. helpdesk): Error: ``` in fields.py: fields = records.pool.field_computed[self] KeyError: 'helpdesk.team.fsm_project_id' ``` Cause ----- Issue since 1da1467115726263e5cdc50354b4413f8bb7ca7d and the addition of `use_fsm` as a dependency of `_compute_fsm_project_id` When we uninstall any helpdesk module, we set to False the associated fields of all helpdesk team
Original PR description
Issue ----- With helpdesk_fsm installed, uninstall helpdesk_fsm or any module that will trigger its uninstallation (e.g. helpdesk): Error: ``` in fields.py: fields = records.pool.field_computed[self]…
Issue ----- With helpdesk_fsm installed, uninstall helpdesk_fsm or any module that will trigger its uninstallation (e.g. helpdesk): Error: ``` in fields.py: fields = records.pool.field_computed[self] KeyError: 'helpdesk.team.fsm_project_id' ``` Cause ----- Issue since 1da1467115726263e5cdc50354b4413f8bb7ca7d and the addition of `use_fsm` as a dependency of `_compute_fsm_project_id` When we uninstall any helpdesk module, we set to False the associated fields of all helpdesk teams (mapped in `_get_field_modules`) for all uninstalled modules. https://github.com/odoo/enterprise/blob/9fba5f841c3c0710eb0cce00263bf914dac03dc6/helpdesk/models/ir_module.py#L13-L16 The change of `use_fsm` means `fsm_project_id` is marked as a field to be recomputed. This happens at some point during a `flush_all`, but after the field has been deleted in DB and a new registry has been loaded without that field. Change ----- Force a recomputation by flushing the records. opw-4338172 opw-4339801 Forward-Port-Of: odoo/enterprise#74255
In case we are not in a multi currency environment the currency of the journal is falsy, so if there is not a currency set, we take the one from the company task: 4293986 Forward-Port-Of: odoo/enterprise#73006
Original PR description
In case we are not in a multi currency environment the currency of the journal is falsy, so if there is not a currency set, we take the one from the company task: 4293986 Forward-Port-Of: odoo/enterprise#73006
Currently, when an operation is loaded in the barcode app, the frontend executes a request to get_barcode_data which will perform a read on all relevant barcode data from the backend to cache it on the frontend. The problem is, when loading the records of `stock.quant.packages`, it will attempt to read all empty packages with no location id. There are cases where these packages are way too many i.e. 500K and thus to read fields on these records, it would be terribly slow. As this is done upon op
Original PR description
Currently, when an operation is loaded in the barcode app, the frontend executes a request to get_barcode_data which will perform a read on all relevant barcode data from the backend to cache it on…
Currently, when an operation is loaded in the barcode app, the frontend executes a request to get_barcode_data which will perform a read on all relevant barcode data from the backend to cache it on the frontend. The problem is, when loading the records of `stock.quant.packages`, it will attempt to read all empty packages with no location id. There are cases where these packages are way too many i.e. 500K and thus to read fields on these records, it would be terribly slow. As this is done upon opening every operation in the barcode app, it's making the app feel sluggish. To workaround the problem, this PR introduces a config paramter `stock_barcode.usable_packages_limit` which will limit the total number of empty packages being read to feed the frontend cache. This gives the option to tradeoff between cache locality and network connection. Setting this limit to a smaller number will result in more rpc calls instead of suffering a slowdown on one big rpc call to load all data once. Benchmarks: This will totally depend on the configured limit. Lower limit would mean higher speedup and vice versa. As an example, setting a limit of 1000 cut down the loading of get_barcode_data from 13.87 s to 768 ms opw-4245980 Forward-Port-Of: odoo/enterprise#74096
Users have encountered invoice rejections from the ISS due to an incompatible document type when creating automatic invoices. This modification ensures that the correct document type is assigned based on the customer's taxpayer type, allowing the invoice to be approved by the ISS. task-4299210 Forward-Port-Of: odoo/enterprise#73945
Original PR description
Users have encountered invoice rejections from the ISS due to an incompatible document type when creating automatic invoices. This modification ensures that the correct document type is assigned based on the customer's taxpayer type, allowing the invoice to be approved by the ISS. task-4299210 Forward-Port-Of: odoo/enterprise#73945
This commit add the export to xml button on the intrastat report for Germany. More information can be found here: - https://erhebungsportal.estatistik.de/Erhebungsportal/informationen/hilfe-zur-meldungsabgabe-3749 task-4194404 Forward-Port-Of: odoo/enterprise#74249 Forward-Port-Of: odoo/enterprise#71785
Original PR description
This commit add the export to xml button on the intrastat report for Germany. More information can be found here: - https://erhebungsportal.estatistik.de/Erhebungsportal/informationen/hilfe-zur-meldungsabgabe-3749 task-4194404 Forward-Port-Of: odoo/enterprise#74249 Forward-Port-Of: odoo/enterprise#71785
Currently, the accounting firm's VAT is used for the CodaBox connection but sometimes, accounting firms need to use a different VAT as their contract number. This adds a system parameter that if filled, is used instead of the firm's VAT. task-4335294 Forward-Port-Of: odoo/enterprise#74368 Forward-Port-Of: odoo/enterprise#73883
Original PR description
Currently, the accounting firm's VAT is used for the CodaBox connection but sometimes, accounting firms need to use a different VAT as their contract number. This adds a system parameter that if filled, is used instead of the firm's VAT. task-4335294 Forward-Port-Of: odoo/enterprise#74368 Forward-Port-Of: odoo/enterprise#73883
Issue: In the subscription order user portal, the anticipate payment included products with the invoice policy set to delivered quantity that were not delivered yet. -Enable online payment and demo payment provider in the configuration. -Create a new subscription order in the subscription module. -Add a product with its invoice policy set to ordered quantity. -Add another product with its invoice policy set to delivered quantity. -Confirm the order and click on preview to access the user
Original PR description
Issue: In the subscription order user portal, the anticipate payment included products with the invoice policy set to delivered quantity that were not delivered yet. -Enable online payment and demo payment provider in the configuration. -Create a new subscription order in the subscription module. -Add a product with its invoice policy set to ordered quantity. -Add another product with its invoice policy set to delivered quantity. -Confirm the order and click on preview to access the user portal. -Proceed with the payment through the portal. It is now not possible to pay in advance through the user portal for recurring products with an invoice policy set to delivered quantity if they haven't been delivered yet. We still allow advance payments for partially delivered products. opw-3775930 Forward-Port-Of: odoo/enterprise#72578
Users require the name of the invoice report to be the same as the xml. task-4284482 Forward-Port-Of: odoo/enterprise#73335
Original PR description
Users require the name of the invoice report to be the same as the xml. task-4284482 Forward-Port-Of: odoo/enterprise#73335