Thursday, October 17, 2024
92 changes
15 changes
Miscellaneous changes
When reconciliing and invoice with a misc entry line, we display the amount currency of the total amount of the entry instead of the partial. Steps: - With USD company currency and EUR foreign currency - Make an invoice for 2000 EUR - Register a payment for 1000 EUR - Make a journal entry in USD, 3 credit lines 1000 USD each on the receivable account, for the invoice's partner - Come back to the invoice and reconcile it with two misc lines via the outstanding credit widget - O
Original PR description
When reconciliing and invoice with a misc entry line, we display the amount currency of the total amount of the entry instead of the partial. Steps: - With USD company currency and EUR foreign currency - Make an invoice for 2000 EUR - Register a payment for 1000 EUR - Make a journal entry in USD, 3 credit lines 1000 USD each on the receivable account, for the invoice's partner - Come back to the invoice and reconcile it with two misc lines via the outstanding credit widget - Open the payment and print the payment receipt -> The Amount Currency column of the misc entry lines show -$3000 instead of $-1000 and $-528.89 (depending of the current rate) With this commit we take the debit or credit amount currency from the partial instead of the total amount of the entry. opw-4089534 Forward-Port-Of: odoo/odoo#183819 Forward-Port-Of: odoo/odoo#180189
Versions -------- - 17.0+ Steps ----- 1. Have an SO selling a timesheet-based service; 2. have at least some hours delivered via timesheets; 3. click on "Create Invoice"; 4. select a date for "Timesheets Period". Issue ----- It first shows a datepicker for only the start date, only after closing it can you select a second date. Cause ----- The `daterange` widget doesn't actually default to a range, unless the date field is marked as required. As seen in the `isRange` funct
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have an SO selling a timesheet-based service; 2. have at least some hours delivered via timesheets; 3. click on "Create Invoice"; 4. select a date for "Timesheets Period". Issue ----- It first shows a datepicker for only the start date, only after closing it can you select a second date. Cause ----- The `daterange` widget doesn't actually default to a range, unless the date field is marked as required. As seen in the `isRange` function, it opens a range picker when there are two values present, the field is required, or the `alwaysRange` property is `true`: https://github.com/odoo/odoo/blob/39029710bbce55889c6b951fc423c1254e05ff22/addons/web/static/src/views/fields/datetime/datetime_field.js#L215-L224 Solution -------- Force the range picker on the `daterange` widget by setting the `always_range` option. opw-4049959 Forward-Port-Of: odoo/odoo#181079
*: test_website Since [1], the code responsible for resetting broken view failed to consider that during a "hard" reset, the 'arch_updated' field should be set to False. Steps to reproduce (on a local server): - Activate the developer mode - Navigate to Website and click on "Go to Website" - Click on the menu "Pages" > "Manage Pages" - At the /contactus line, click on the "bug" button to access the view - Click on "Edit" to be able to change the architecture - Add something that
Original PR description
*: test_website Since [1], the code responsible for resetting broken view failed to consider that during a "hard" reset, the 'arch_updated' field should be set to False. Steps to reproduce (on a…
*: test_website Since [1], the code responsible for resetting broken view failed to consider that during a "hard" reset, the 'arch_updated' field should be set to False. Steps to reproduce (on a local server): - Activate the developer mode - Navigate to Website and click on "Go to Website" - Click on the menu "Pages" > "Manage Pages" - At the /contactus line, click on the "bug" button to access the view - Click on "Edit" to be able to change the architecture - Add something that breaks the view in the template (i.e : ```<p t-field="no_field.exists"></p>```) - Click on "Save" and after "Go to Page Manager" - Click on the /contactus url link - An internal server error page appears with the possibility to restore the previous version of the view (soft reset) or to reset to initial version (hard reset). Click on "Hard Reset" - With your DB manager, search in the table ir.ui.view, the record with the key website.contactus. Observe that the field arch_updated is still True while the view is reset and shouldn't be in an updated state. This commit ensures consistent updating of this field. A "Hard" reset of a broken view will remove its previous architecture used for "Soft" reset, since there is no real usage where a "Previous" reset is needed after a "Hard" one. [1]: https://github.com/odoo/odoo/commit/479585140caca9fdc758709f043da500297e8046 task-3743850 Forward-Port-Of: odoo/odoo#164929
Before this commit, logging into the PoS with a user not present in another session and then navigating back to the backend to open a different session resulted in an error due to the missing employee. This commit resolves the issue by incorporating the confid ID when saving employee ID in sessionStorage, ensuring employee information is accurately maintained. opw-4255768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#1
Original PR description
Before this commit, logging into the PoS with a user not present in another session and then navigating back to the backend to open a different session resulted in an error due to the missing employee. This commit resolves the issue by incorporating the confid ID when saving employee ID in sessionStorage, ensuring employee information is accurately maintained. opw-4255768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183566
When changing the move associated with the bank statement line we i.e. update the `amount_currency` field on the bank statement line. But currently we just set it to the `amount_currency` value of the suspense line. This may not be correct in case we also have other lines on the move: We should have (liquidity = suspense + other) and the `amount_currency` on the bank statement line expresses the liquidity (total amount) and not the suspense (residual amount). After this commit we also include t
Original PR description
When changing the move associated with the bank statement line we i.e. update the `amount_currency` field on the bank statement line. But currently we just set it to the `amount_currency` value of the suspense line. This may not be correct in case we also have other lines on the move: We should have (liquidity = suspense + other) and the `amount_currency` on the bank statement line expresses the liquidity (total amount) and not the suspense (residual amount). After this commit we also include the other lines in the computation. (Note: We cannot just use the liquidity line It is in journal currency / company currency but the `amount_currency` of the bank statement line may be in a foreign currency that is neither the company nor the journal currency.) enterprise PR which needs the change: https://github.com/odoo/enterprise/pull/71243 Forward-Port-Of: odoo/odoo#182589
Reproduce --- - -i hr_holidays - open two secure user sessions - 1st user session: set to handle notifications in odoo - 2nd user session: tag 1st user in the chatter of a approved time off - 1st user session: receives notification just fine - 2nd user session: Refuse opened time off - 1st user session: Traceback opw-4138108 Forward-Port-Of: odoo/odoo#183759
Original PR description
Reproduce --- - -i hr_holidays - open two secure user sessions - 1st user session: set to handle notifications in odoo - 2nd user session: tag 1st user in the chatter of a approved time off - 1st user session: receives notification just fine - 2nd user session: Refuse opened time off - 1st user session: Traceback opw-4138108 Forward-Port-Of: odoo/odoo#183759
Issue: ===== The cover template of the training theme template doesn't show in the sent email. Steps to reproduce the issue: ============================= - Create a new mailing with training template - Send a test email - Cover snippet missing Origin of the issue: ==================== While converting the template from bootstrap to table we expect to have `container` -> `row` -> `col` classes but the template was missing the `col` class opw-3944347 Forward-Port-Of: odoo/odoo#1
Original PR description
Issue: ===== The cover template of the training theme template doesn't show in the sent email. Steps to reproduce the issue: ============================= - Create a new mailing with training template - Send a test email - Cover snippet missing Origin of the issue: ==================== While converting the template from bootstrap to table we expect to have `container` -> `row` -> `col` classes but the template was missing the `col` class opw-3944347 Forward-Port-Of: odoo/odoo#183105
**Behaviour before PR:** - In chatgpt prompt dialog, `submitPrompt` method gets called twice when user presses `ctrl + enter` after writing something. As result chatgpt responds twice with same content. This happens because in `dialog.js` a hotkey service is active on `ctrl + enter` which is responsible to trigger a click event on submit button of dialog and `submitPrompt` gets called second time. - Moreover, if text-area is empty and user hits `enter` then an empty prompt is sent to chatGPT
Original PR description
**Behaviour before PR:** - In chatgpt prompt dialog, `submitPrompt` method gets called twice when user presses `ctrl + enter` after writing something. As result chatgpt responds twice with same content. This happens because in `dialog.js` a hotkey service is active on `ctrl + enter` which is responsible to trigger a click event on submit button of dialog and `submitPrompt` gets called second time. - Moreover, if text-area is empty and user hits `enter` then an empty prompt is sent to chatGPT resulting in a meaningless response. **Behaviour after PR:** - Now, `submitPrompt` method gets called once on `ctrl + enter.` - If text-area is empty then pressing `enter` will not submit prompt. task-4207108 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181334
Steps to reproduce ================== - Go to CRM - Open a lead - Open studio - Add a new notebook page - Add a many2many field - Select the task model - Save and exit studio - Switch to the new notebook page - Add a new task => Record does not exist or has been deleted. Cause of the issue ================== The CrmFormRecord is also used for the Many2Many popup. project.task also has a stage_id field, checkRainbowmanMessage is then called, but with the id of the task ht
Original PR description
Steps to reproduce ================== - Go to CRM - Open a lead - Open studio - Add a new notebook page - Add a many2many field - Select the task model - Save and exit studio - Switch to the new notebook page - Add a new task => Record does not exist or has been deleted. Cause of the issue ================== The CrmFormRecord is also used for the Many2Many popup. project.task also has a stage_id field, checkRainbowmanMessage is then called, but with the id of the task https://github.com/odoo/odoo/blob/54d6a19444bfa4f01d03117e4542a5244f274429/addons/crm/static/src/views/crm_form/crm_form.js#L44-L51 Solution ======== It makes no sense to do this if we are not acting on a crm.lead record => We check the resModel before proceeding opw-4101752 Forward-Port-Of: odoo/odoo#183375
The LATERAL was destroying perfs to compute the account roots. It took more than 7 sec on a db that only had 660k move lines. Replaced it by a simple JOIN which reduced it to 1.2 sec. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170689
Original PR description
The LATERAL was destroying perfs to compute the account roots. It took more than 7 sec on a db that only had 660k move lines. Replaced it by a simple JOIN which reduced it to 1.2 sec. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170689
Commands that stop and start the LED service in `posbox_update.sh` were removed in commit `bf96199`, however these were necessary to prevent the filesystem getting stuck in write-mode and potentially getting corrupted (see #54339). The fix is to restore these commands in `posbox_update.sh`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183868
Original PR description
Commands that stop and start the LED service in `posbox_update.sh` were removed in commit `bf96199`, however these were necessary to prevent the filesystem getting stuck in write-mode and potentially getting corrupted (see #54339). The fix is to restore these commands in `posbox_update.sh`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183868
Issue: ====== Going to next record in to do overrides the next record content with the older one. Steps to reproduce the issue: ============================== - Go to do and create 2 to-dos - Add an image using copy paste - Go to next record using the pager - The record has the same content as the first one Origin of the issue: ==================== The main reason behind the issue is a race condition. Basically there are 2 flows being executed in parallel: - First flow is from `o
Original PR description
Issue: ====== Going to next record in to do overrides the next record content with the older one. Steps to reproduce the issue: ============================== - Go to do and create 2 to-dos - Add an…
Issue: ====== Going to next record in to do overrides the next record content with the older one. Steps to reproduce the issue: ============================== - Go to do and create 2 to-dos - Add an image using copy paste - Go to next record using the pager - The record has the same content as the first one Origin of the issue: ==================== The main reason behind the issue is a race condition. Basically there are 2 flows being executed in parallel: - First flow is from `onWysiygBlur` which calls commit changes and save image changes. Since we have an image in the content, it will take longer to finish. the commit that was called now is fron emty content to the base64 image. - The scond flow comes from the pager update which finds the content dirty because its old content is the base64 image ans its new content is the image with the url so it will call commit changes itself and it will load the next id. - Currently we have the `_update` of the `commitChanges` from the `blur` event isn't done yet but we already changed the id of the record to the id of the new recod (comes fron pager). - Now when the `_update` of the old `blur` event is executed, it will update the body of the new record and not the old record. Solution: ========= If the html field is already saving sonething we wait for it first. so In our case, the commit changes of the paged will do nothing since it will wait for the one of the `blur` event and the editable after it will be not dirty. task-4082860 Forward-Port-Of: odoo/odoo#180759
revert commit 30c561b422d58d7622f7ee173fae2f8158a14657 because it broke existing optimization and users were unable to access the website instead the functionality was moved to `_get_pl_partner_order()` because it's a cached method and the extra search added by the `.sorted()` wouldn't be an issue. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183805
Original PR description
revert commit 30c561b422d58d7622f7ee173fae2f8158a14657 because it broke existing optimization and users were unable to access the website instead the functionality was moved to `_get_pl_partner_order()` because it's a cached method and the extra search added by the `.sorted()` wouldn't be an issue. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183805
Prior to this commit, when a URL started with an underscore (_) and didn’t match any existing controller, Odoo attempted to resolve the first part of the URL as a language code. If the first segment started with an underscore and was not a valid language code, Odoo would split at the underscore and attempt to match the empty string (''), causing it to default to the first available language. For example, accessing https://www.odoo.com/__NULL__ on odoo.com would result in the language being
Original PR description
Prior to this commit, when a URL started with an underscore (_) and didn’t match any existing controller, Odoo attempted to resolve the first part of the URL as a language code.
If the first segment started with an underscore and was not a valid language code, Odoo would split at the underscore and attempt to match the empty string (''), causing it to default to the first available language.
For example, accessing https://www.odoo.com/__NULL__ on odoo.com would result in the language being incorrectly set to Arabic, and a redirection to https://www.odoo.com/ar.
Forward-Port-Of: odoo/odoo#182982Currently, the cron job "Base Action Rule: check and execute" has its frequency set dynamically based on the shortest delay of time based automated actions. Nevertheless, when a time based automated action has a negative delay, the frequency of the cron job is set to shortest frequency. This causes load on the server more than needed. This can be solved by adding an absolute and treating the negative delay like the a normal delay which results in more representative frequency.
Original PR description
Currently, the cron job "Base Action Rule: check and execute" has its frequency set dynamically based on the shortest delay of time based automated actions. Nevertheless, when a time based automated action has a negative delay, the frequency of the cron job is set to shortest frequency. This causes load on the server more than needed. This can be solved by adding an absolute and treating the negative delay like the a normal delay which results in more representative frequency. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183182 Forward-Port-Of: odoo/odoo#182799
22 changes
Enhancements to existing features
The manufacturing maintenance app now explicitly relies on the stock maintenance component. This helps ensure the right supporting features are installed together, reducing setup issues and improving reliability.
Resolved issues and error corrections
This update simplifies how the system checks and opens files inside zipped documents such as spreadsheets and Mexican e-invoicing downloads. It avoids relying on internal software details, making these tests and related file handling more reliable over time.
Original PR description
Checking the filelist size before checking for existence based on `NamedToInfo` is unnecessarily convoluted, we can just compare the list of expected filenames to the `namelist()`. And using entry positions to open them is pretty much insane, just address the files by name, that's both clearer and more reliable. *Technically* for xlsx files we should probably go through `[Content_Types].xml` to retrieve the actual path to the shared strings file, but accessing that file directly is already an improvement I think.
Code cleanup and technical improvements
This update reduces unnecessary stored duplicate data in manufacturing and quality workflows now that the system can still report, group, and sort on those fields directly. The change helps simplify maintenance and may reduce database overhead without changing day-to-day user functionality.
Original PR description
Since https://github.com/odoo/odoo/pull/127353, we can groupby/aggregate/sort on non-store related field. Remove store=True of some related fields (tradeoff is taken in account) for every logistics modules. https://github.com/odoo/odoo/pull/153463 https://github.com/odoo/upgrade/pull/5793
Miscellaneous changes
This commit addresses the issue of applying incorrect exchange rates for foreign currency transactions. Previously, we were using the rate from the last closing date instead of the rate applicable to the transaction day. Moving forward, the correct exchange rate will be used based on the day to which the quote applies, as outlined in the official guidelines for foreign currency operations by the Dirección General Impositiva (DGI). For reference: https://www.gub.uy/direccion-general-impositiva/
Original PR description
This commit addresses the issue of applying incorrect exchange rates for foreign currency transactions. Previously, we were using the rate from the last closing date instead of the rate applicable to the transaction day. Moving forward, the correct exchange rate will be used based on the day to which the quote applies, as outlined in the official guidelines for foreign currency operations by the Dirección General Impositiva (DGI). For reference: https://www.gub.uy/direccion-general-impositiva/comunicacion/publicaciones/operaciones-moneda-extranjera. latam-task: 1264 adhoc-side-task: 43762 Forward-Port-Of: odoo/enterprise#70335
Before, the tax period filter was always shown even if the dates could be made from the other filters Now we hide it if the periodicity is monthly or quarterly and that the start date is the first day of the year. Otherwise we can show it because it will create different dates not possible with the default filters unless we use the custom dates filter. task-4197475 Forward-Port-Of: odoo/enterprise#71634
Original PR description
Before, the tax period filter was always shown even if the dates could be made from the other filters Now we hide it if the periodicity is monthly or quarterly and that the start date is the first day of the year. Otherwise we can show it because it will create different dates not possible with the default filters unless we use the custom dates filter. task-4197475 Forward-Port-Of: odoo/enterprise#71634
In the deferred computations, we always assume that both the start and end date are inclusive E.g: 1st January -> 31st December is *exactly* 1 year = 12 months However, the user may instead put 1st January -> 1st January of next year which is then 12 months + 1/30 month = 12.03 months which may result in odd amounts when deferrals are created For this reason, we now alert the user if we detect such a case with a warning banner and yellow highlight in the abnormal dates. Other cases were the num
Original PR description
In the deferred computations, we always assume that both the start and end date are inclusive E.g: 1st January -> 31st December is *exactly* 1 year = 12 months However, the user may instead put 1st January -> 1st January of next year which is then 12 months + 1/30 month = 12.03 months which may result in odd amounts when deferrals are created For this reason, we now alert the user if we detect such a case with a warning banner and yellow highlight in the abnormal dates. Other cases were the number of months is not round should not be handled. task-id: none Forward-Port-Of: odoo/enterprise#72138 Forward-Port-Of: odoo/enterprise#71423
In this commit, Remove the duplicate check for next_invoice_date Forward-Port-Of: odoo/enterprise#71310
Original PR description
In this commit, Remove the duplicate check for next_invoice_date Forward-Port-Of: odoo/enterprise#71310
This avoids a manual operation when testing DIAN's webservice for support documents. no task Forward-Port-Of: odoo/enterprise#72166
Original PR description
This avoids a manual operation when testing DIAN's webservice for support documents. no task Forward-Port-Of: odoo/enterprise#72166
Before this commit, the worksheet button is wrongly placed in the navbar of the portal form view of a task and so, it will lead to a wrong design for that button. This commit moves that button in the right place to be sure to have the same style than the other nav buttons (this is, `Task`, `History`,...) task-4251535 Forward-Port-Of: odoo/enterprise#71891
Original PR description
Before this commit, the worksheet button is wrongly placed in the navbar of the portal form view of a task and so, it will lead to a wrong design for that button. This commit moves that button in the right place to be sure to have the same style than the other nav buttons (this is, `Task`, `History`,...) task-4251535 Forward-Port-Of: odoo/enterprise#71891
In this pr we refactor the methods that rely on `jquery` in favor of `fetch`. Forward-Port-Of: odoo/enterprise#70771
Original PR description
In this pr we refactor the methods that rely on `jquery` in favor of `fetch`. Forward-Port-Of: odoo/enterprise#70771
Currently, you view subscription quotations in the portal with a Brazilian company. ### Steps to reproduce * install `l10n_br_sales` * switch to a Brazilian company * attempt to "Preview" the subscription quotation You should be met with the following traceback: ``` AttributeError: 'NoneType' object has no attribute 'decimal_places' Template: l10n_br_sales.document_tax_totals_brazil Path: /t/tr[2]/td[2]/strong Node: <strong t-out="tax_totals[\'total_amount_currency\']" t-options=
Original PR description
Currently, you view subscription quotations in the portal with a Brazilian company.
### Steps to reproduce
* install `l10n_br_sales`
* switch to a Brazilian company
* attempt to "Preview" the subscription quotation
You should be met with the following traceback:
```
AttributeError: 'NoneType' object has no attribute 'decimal_places'
Template: l10n_br_sales.document_tax_totals_brazil
Path: /t/tr[2]/td[2]/strong
Node: <strong t-out="tax_totals[\'total_amount_currency\']" t-options="{"widget": "monetary", "display_currency": currency}"/>
```
opw-4247492
Forward-Port-Of: odoo/enterprise#72092After [this commit], there was an issue for reports where we don't have accounts as the first column. It would offset the cell too far to the left, assuming there is an account code column. This commit fixes that, so reports like the partner ledger are exporting correctly again showing the partner names. [this commit]: https://github.com/odoo/enterprise/commit/a3d76fc2b39428b7ea7c41bf98b2ecbe741a67fb Forward-Port-Of: odoo/enterprise#72038 Forward-Port-Of: odoo/enterprise#72010
Original PR description
After [this commit], there was an issue for reports where we don't have accounts as the first column. It would offset the cell too far to the left, assuming there is an account code column. This commit fixes that, so reports like the partner ledger are exporting correctly again showing the partner names. [this commit]: https://github.com/odoo/enterprise/commit/a3d76fc2b39428b7ea7c41bf98b2ecbe741a67fb Forward-Port-Of: odoo/enterprise#72038 Forward-Port-Of: odoo/enterprise#72010
Before this commit, when we export the journal report as a pdf, the side of the content were extended to the side of the page. This commit adds a css property to set margin to the content of the page. task-4260189 Forward-Port-Of: odoo/enterprise#71997
Original PR description
Before this commit, when we export the journal report as a pdf, the side of the content were extended to the side of the page. This commit adds a css property to set margin to the content of the page. task-4260189 Forward-Port-Of: odoo/enterprise#71997
When the user presses `Ctrl` + `p` to print an article, the page appears blank because the assets for print media queries are only loaded after the user clicks the "Export" button. To ensure that the print-specific styles are loaded, we will move the `knowledge_print.scss` file to the `web.assets_web_print` asset bundle. The generated stylesheet will then be linked to the page using a `link` tag with the `media="print"` attribute. The browser will then be able to load the stylesheet when the
Original PR description
When the user presses `Ctrl` + `p` to print an article, the page appears blank because the assets for print media queries are only loaded after the user clicks the "Export" button. To ensure that the print-specific styles are loaded, we will move the `knowledge_print.scss` file to the `web.assets_web_print` asset bundle. The generated stylesheet will then be linked to the page using a `link` tag with the `media="print"` attribute. The browser will then be able to load the stylesheet when the user is printing the page or previewing it for print. Steps to reproduce the issue: 1. Go to the Knowledge app. 2. Open an article 3. Press `Ctrl` + `p` to print the article. => The print rules are not loaded and the page appears blank. TO BE: The print rules should be loaded. task-4191390 Forward-Port-Of: odoo/enterprise#70243
Problem: The `is_available` flag was used to check both product availability and conflicts with other rentals. However, the UI message was misleading, stating "Other rental(s) in conflict" even when the product was simply not available. Steps to reproduce: - Create a rental product with a quantity of 0. - Add a rental order for that product. - In the Schedule Gantt view, hover over the order. - A warning appears stating "Other rental(s) in conflict," even though no other rentals exist
Original PR description
Problem: The `is_available` flag was used to check both product availability and conflicts with other rentals. However, the UI message was misleading, stating "Other rental(s) in conflict" even when the product was simply not available. Steps to reproduce: - Create a rental product with a quantity of 0. - Add a rental order for that product. - In the Schedule Gantt view, hover over the order. - A warning appears stating "Other rental(s) in conflict," even though no other rentals exist on the same date; the actual issue is that the product is not available. opw-4085496 Forward-Port-Of: odoo/enterprise#69783
Similarly to odoo/odoo@f02bcfadcbb66fb237a5af3a10a35e36355b8b2e we no longer use the binary field which encodes the data to base64 because we were decoding it right after, which is useless work. We now directly read the raw data from the binary field underlying attachment Time spent in `_get_spreadsheet_snapshot` when opening a spreadsheet with a 16.7Mb snapshot: before: 189ms after: 101ms Forward-Port-Of: odoo/enterprise#71971
Original PR description
Similarly to odoo/odoo@f02bcfadcbb66fb237a5af3a10a35e36355b8b2e we no longer use the binary field which encodes the data to base64 because we were decoding it right after, which is useless work. We now directly read the raw data from the binary field underlying attachment Time spent in `_get_spreadsheet_snapshot` when opening a spreadsheet with a 16.7Mb snapshot: before: 189ms after: 101ms Forward-Port-Of: odoo/enterprise#71971
Problem: In version 17.0, the `partner_id` doesnt exist, and instead, the correct field to use is `partner`. This mismatch causes a traceback when processing invoices in the PoS. Steps to Reproduce: - Install the Chilean localization module (`l10n_cl`). - Go to PoS > Order > Invoice > Pay. - A traceback appears in the console due to the incorrect field reference. opw-4204528 Forward-Port-Of: odoo/enterprise#71737
Original PR description
Problem: In version 17.0, the `partner_id` doesnt exist, and instead, the correct field to use is `partner`. This mismatch causes a traceback when processing invoices in the PoS. Steps to Reproduce: - Install the Chilean localization module (`l10n_cl`). - Go to PoS > Order > Invoice > Pay. - A traceback appears in the console due to the incorrect field reference. opw-4204528 Forward-Port-Of: odoo/enterprise#71737
Before this commit, when installing the account_reports and l10n_ae modules, the l10n_ae_reports and corporate_tax_report modules were not installed, even though they depended on these modules. This caused an issue during an account report test, as the necessary field was not created, leading to an "Invalid field" error: ('l10n_ae_tax_report_liabilities_account' on model 'res.company') By removing the countries field from the manifest, the modules now auto-install as expected, and the test
Original PR description
Before this commit, when installing the account_reports and l10n_ae modules, the l10n_ae_reports and corporate_tax_report modules were not installed, even though they depended on these modules. This caused an issue during an account report test, as the necessary field was not created, leading to an "Invalid field" error: ('l10n_ae_tax_report_liabilities_account' on model 'res.company')
By removing the countries field from the manifest, the modules now auto-install as expected, and the test no longer fails. But why? If a module depends on another module that has the countries attribute, there’s no need to include it back; the auto-installation will only be triggered if there is a company that belongs to that country.
Forward-Port-Of: odoo/enterprise#72132Steps to reproduce: - Insert a pivot view of timesheet - Insert a list view of project - Add a new global filter based on project => you actually cannot select id for the list view of project, but we should be able to filter the list view based on the project id. This commit adds the id field to the allowed fields for the relation global filters. Task: 4228916 Forward-Port-Of: odoo/enterprise#71856 Forward-Port-Of: odoo/enterprise#71365
Original PR description
Steps to reproduce: - Insert a pivot view of timesheet - Insert a list view of project - Add a new global filter based on project => you actually cannot select id for the list view of project, but we should be able to filter the list view based on the project id. This commit adds the id field to the allowed fields for the relation global filters. Task: 4228916 Forward-Port-Of: odoo/enterprise#71856 Forward-Port-Of: odoo/enterprise#71365
This commit fixes the test. When there is extra company then test is failing because it replaces the companies in user, instead of adding the new company. Forward-Port-Of: odoo/enterprise#72069
Original PR description
This commit fixes the test. When there is extra company then test is failing because it replaces the companies in user, instead of adding the new company. Forward-Port-Of: odoo/enterprise#72069
Steps to reproduce: - open a first tab - create a new spreadsheet - open a second tab - from that new tab, delete the spreadsheet (send to trash, then permanently delete it from the trash) - create a new spreadsheet => update a few cells, the websocket connection is broken. Task: 4252590 Forward-Port-Of: odoo/enterprise#71936 Forward-Port-Of: odoo/enterprise#71802
Original PR description
Steps to reproduce: - open a first tab - create a new spreadsheet - open a second tab - from that new tab, delete the spreadsheet (send to trash, then permanently delete it from the trash) - create a new spreadsheet => update a few cells, the websocket connection is broken. Task: 4252590 Forward-Port-Of: odoo/enterprise#71936 Forward-Port-Of: odoo/enterprise#71802
Before this commit, the data given to the spreadsheet init callback in the case of inserting a pivot view was not used. This could lead to an error if the data was too big to be stored in the browser's session storage. This commit removes the useless data given to the spreadsheet init. Note that it's not necessary to write a new test for this, as the existing tests already cover this case. Task: 4255049 Forward-Port-Of: odoo/enterprise#71847
Original PR description
Before this commit, the data given to the spreadsheet init callback in the case of inserting a pivot view was not used. This could lead to an error if the data was too big to be stored in the browser's session storage. This commit removes the useless data given to the spreadsheet init. Note that it's not necessary to write a new test for this, as the existing tests already cover this case. Task: 4255049 Forward-Port-Of: odoo/enterprise#71847
53 changes
Enhancements to existing features
Users can now manually unpin sub-threads in Mail instead of having them remain pinned by default. This gives users more control over their discussion sidebar and helps keep conversations organized around what matters to them.
Original PR description
Sub-thread is pinned by default and user couldn't unpin it. This commit lets user unpin the sub-thread manually. Backport of https://github.com/odoo/odoo/pull/183758
The tax report now hides the tax period filter when standard date filters can already produce the same monthly or quarterly periods. This reduces clutter and helps users focus on only the filters needed for their reporting scenario.
Original PR description
Before, the tax period filter was always shown even if the dates could be made from the other filters Now we hide it if the periodicity is monthly or quarterly and that the start date is the first day of the year. Otherwise we can show it because it will create different dates not possible with the default filters unless we use the custom dates filter. task-4197475
Resolved issues and error corrections
This fixes an internal issue where grouped list results could be ordered incorrectly when custom field sorting logic contained spaces or line breaks. The change makes ordering more reliable for customized Odoo models and adds tests to prevent regressions.
Original PR description
`_read_group_orderby` used `cr.mogrify`, `split(",")` and `split()[0]` for the
result coming from the `_order_to_sql` which may come from `_field_to_sql`
As a side effect, SQL code after a space/newline not adjacent to a comma will
be dropped after `split()[0]`. So the mogrified customized `_field_to_sql`
shoudn't have any space/newline not adjacent to a comma if the field is used
for `Model._order`.
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-prThis fixes an issue where the correct PDF report option was not always shown in the accounting Print & Send flow. It helps users reliably select and send the intended document without confusion or extra manual steps.
Original PR description
The display_pdf_report_id is not correctly computed. task-no
This fixes the placement of editor action buttons when using right-to-left languages such as Arabic. It makes editing content smoother for users working in those languages by respecting the direction set on the main editable area.
Original PR description
Description of the issue this PR addresses: Previously, the positioning of powerbuttons only considered the `dir` attribute on the closest block element. However for true RTL languages like Arabic, the `dir` attribute is applied to the editable container, not the individual nodes. This commit makes sure that `dir` attribute of editable is taken into account when the closest block does not have its own `dir` attribute. task-4259040 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sales users will no longer see a general warning when changing a product's type on sales-related products. This reduces unnecessary interruptions while existing safeguards still block changes when they are not allowed.
Original PR description
Before the commit: Previously, when the product type of an item in a sales order was changed, a warning would be displayed, but users were still allowed to make the change. Although there are other checks in place to prevent changes to the product type under certain conditions, the general warnings were unnecessary. After the commit: Now, there will be no general warning when changing a product's type.
This fix makes the interactive sales walkthrough more reliable by ensuring guidance appears at the right time, users can continue after editing a line price without extra clicks, and the walkthrough does not fail when no document layout setup is needed. It helps users complete the sales flow with fewer interruptions during guided onboarding or training.
Original PR description
This change fixes the following issues, which occured when running the tour interactively: - The tooltip prompting the user to select or create a product wasn't shown, - After setting the SOL's price, the user had to click on the SOL again to trigger the next step (whereas they should be able to click anywhere), - If there was no document layout to configure, the tour would fail.
The Print & Send wizard now shows sending method names in the user's selected language instead of always showing English labels. This improves clarity for multilingual users and helps reduce confusion when sending accounting documents.
Original PR description
The sending methods displayed in the Print & Send wizard were populated using the selection field's `selection` field. This only gave the English terms as defined in the code. This commit fixes that by using another method that gets the values in the current user's language.
This update corrects how accrual carry-over validity is shown in Time Off settings. It prevents an unset validity value from appearing to users and fixes a related display widget name, reducing confusion when configuring leave accrual rules.
Original PR description
in this commit, fixes a issue where carry over validity isn't set value is still visible in view. task-4207945 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the Calendar app from creating user settings records when they are not actually needed. It reduces unnecessary background data creation, helping keep user data cleaner without changing the visible calendar experience.
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
When accounting accounts are merged, their translated names are now preserved instead of being lost. This helps multilingual companies keep accurate account labels for users working in different languages.
Original PR description
At the moment, when we merge accounts, we don't merge the account name's translations. This is a bit annoying since one account might have been called 'Account Receivable' in English, and another one might have been called 'Clientes' in Spanish. At the moment, the translations of the other accounts are lost. This commit makes us merge the translations when merging the accounts. taskid: 4210775
This fix ensures project forecast users see the correct error messages when something needs their attention. Clearer messages reduce confusion and help users understand what action to take.
Original PR description
Fixed incorrect error messages that were previously displayed. task-4193991
The worksheet button on field service task portal pages now appears in the same navigation area as related options like Task and History. This keeps the page layout consistent and prevents the button from looking out of place for customers using the portal.
Original PR description
Before this commit, the worksheet button is wrongly placed in the navbar of the portal form view of a task and so, it will lead to a wrong design for that button. This commit moves that button in the right place to be sure to have the same style than the other nav buttons (this is, `Task`, `History`,...) task-4251535
The customer portal now shows the correct upcoming invoice amount for subscriptions instead of zero. This prevents customers from seeing misleading billing information when previewing a sales order.
Original PR description
Version: - 18.0 Steps to reproduce: - Install the sale_subscription module - Create a Sales Order and preview it in the portal Issue: - The next billing amount in the portal shows as zero. Cause: - The wrong amount value is being used in the condition. Solution: - Use the correct total_amount to fix the issue. task-4247106
Features or functions removed from Odoo
This update removes a repeated check related to subscription invoice dates. It simplifies the subscription sales logic without changing expected customer-facing behavior, reducing minor maintenance risk.
Original PR description
In this commit, Remove the duplicate check for next_invoice_date
Documentation and clarification updates
This update records Codeforward B.V.'s corporate Contributor License Agreement signature. It supports legal compliance for contributions to Odoo and does not change any product functionality.
Original PR description
Adds a corporate signature for Codeforward B.V. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
- sale_project: fix domain as it is not possible to select a SOL on a task in the case where the SOL's contact belongs to the same company than the contact set as the task's customer. The `.id` was removed by https://github.com/odoo/odoo/commit/e095ef5153fb1a8364a4f53896a522fefa35ecd9 and is actually necessary if we want to have SOLs where the `order_partner_id` is the parent of the `partner_id` or shares the same parent than `parent_id`. - sale: remove SOLs of discount products from th
Original PR description
- sale_project: fix domain as it is not possible to select a SOL on a task in the case where the SOL's contact belongs to the same company than the contact set as the task's customer. The `.id` was removed by https://github.com/odoo/odoo/commit/e095ef5153fb1a8364a4f53896a522fefa35ecd9 and is actually necessary if we want to have SOLs where the `order_partner_id` is the parent of the `partner_id` or shares the same parent than `parent_id`. - sale: remove SOLs of discount products from the SOLs considered as sellable. The discount products are "fake" products used to manage discounts. opw-4212956 Forward-Port-Of: odoo/odoo#183735 Forward-Port-Of: odoo/odoo#183121
When User Clicks on Send payment status to SInvoice action, a traceback will appear. Steps to reproduce the error: - Install ``l10n_vn_edi_viettel`` module - Switch to VN Company - Go to Invoicing > Customers > Invoices > Select any invoice > Actions > Send payment status to SInvoice Traceback: ``` SyntaxError: syntax error at or near ")" LINE 1: SELECT * FROM account_move WHERE id IN () FOR UPDATE SKIP LO... ^ File "odoo/tool
Original PR description
When User Clicks on Send payment status to SInvoice action, a traceback will appear. Steps to reproduce the error: - Install ``l10n_vn_edi_viettel`` module - Switch to VN Company - Go to Invoicing >…
When User Clicks on Send payment status to SInvoice action,
a traceback will appear.
Steps to reproduce the error:
- Install ``l10n_vn_edi_viettel`` module
- Switch to VN Company
- Go to Invoicing > Customers > Invoices > Select any invoice > Actions >
Send payment status to SInvoice
Traceback:
```
SyntaxError: syntax error at or near ")"
LINE 1: SELECT * FROM account_move WHERE id IN () FOR UPDATE SKIP LO...
^
File "odoo/tools/safe_eval.py", line 391, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "ir.actions.server(2134,)", line 3, in <module>
File "addons/l10n_vn_edi_viettel/models/account_move.py", line 299, in action_l10n_vn_edi_update_payment_status
self.env['res.company']._with_locked_records(self)
File "addons/account/models/company.py", line 785, in _with_locked_records
self._cr.execute(f'SELECT * FROM {records._table} WHERE id IN %s FOR UPDATE SKIP LOCKED', [tuple(records.ids)])
File "odoo/sql_db.py", line 347, in execute
res = self._obj.execute(query, params)
ValueError: <class 'psycopg2.errors.SyntaxError'>: "syntax error at or near ")"
LINE 1: SELECT * FROM account_move WHERE id IN () FOR UPDATE SKIP LO...
^
```
https://github.com/odoo/odoo/blob/072da22e72e66e6332d073502b987682f1b6e88b/addons/account/models/company.py#L745
Here, when there are no records for sending their payment status to SInvoice,
records.ids will be empty,
It will lead to the above traceback.
This commit will fix the above issue by preventing the execution of the query
when ``records.ids`` is empty.
sentry-5954926261
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#182621Currently there is the following problem when loading a chart template on a company. In case the company has no country set the loading of the template may set it. This can i.e. happen when the template specifies a `account_fiscal_country_id`. Setting a country on a company (`write`) may trigger the installation of additional localization modules related to the country (`install_l10n_modules`). The problematic `write` happens in `_pre_load_data` but the actual template data is not loaded y
Original PR description
Currently there is the following problem when loading a chart template on a company. In case the company has no country set the loading of the template may set it. This can i.e. happen when the…
Currently there is the following problem when loading a chart template on a company.
In case the company has no country set the loading of the template may set it.
This can i.e. happen when the template specifies a `account_fiscal_country_id`.
Setting a country on a company (`write`) may trigger the installation of additional
localization modules related to the country (`install_l10n_modules`).
The problematic `write` happens in `_pre_load_data` but the actual
template data is not loaded yet (happens later in `_load_data`).
This can cause the following 2 issues.
Issue (1)
The new modules may add new data to the current template (modifies the
result of `_get_chart_template_data`).
But this new data is not considered during the current loading
since the template data is fetched before the automatic installation happens.
The module may not work as intended for companies w/o the new data though.
So we would have to reload the chart template manually.
Issue (2)
The auto-installation happens after the chart template info (field `chart_template`)
is set on the company but before the data is actually loaded.
The module installation may trigger a post init hook to set up new
data on companies with the current template (field `chart_template`).
This new setup may rely on the chart template data (from before the
module was installed) being laoded already though.
Issue (2) i.e. causes runbut build error-60149.
During the populate test a company with chart_template 'generic_coa'
is created which causes the installation of module `l10n_us_reports`
during the 'generic_coa' chart template loading.
There the deferred expense and revenue accounts are loaded in a post init hook
via `_load_data` for every company where the `chart_template` field has value 'generic_coa'.
```python
ChartTemplate._load_data({
'res.company': , {
company.id: {
'deferred_expense_account_id': 'prepaid_expenses',
'deferred_revenue_account_id': 'deferred_revenue',
}
}
})
```
Here 'prepaid_expenses' and 'deferred_revenue' are xmlids of accounts of the
'generic_coa' chart template from module 'account'.
Since the template data has not been loaded yet we cannot derefence
these 2 xmlids. In the log we get the following warning:
> Failed when trying to recover prepaid_expenses for field=res.company.deferred_expense_account_id
To avoid this problem we just skip the automatic installing in case we are in the process
of loading a chart template.
runbot build error-60149
Forward-Port-Of: odoo/odoo#183792Issue: ===== The cover template of the training theme template doesn't show in the sent email. Steps to reproduce the issue: ============================= - Create a new mailing with training template - Send a test email - Cover snippet missing Origin of the issue: ==================== While converting the template from bootstrap to table we expect to have `container` -> `row` -> `col` classes but the template was missing the `col` class opw-3944347 Forward-Port-Of: odoo/odoo#1
Original PR description
Issue: ===== The cover template of the training theme template doesn't show in the sent email. Steps to reproduce the issue: ============================= - Create a new mailing with training template - Send a test email - Cover snippet missing Origin of the issue: ==================== While converting the template from bootstrap to table we expect to have `container` -> `row` -> `col` classes but the template was missing the `col` class opw-3944347 Forward-Port-Of: odoo/odoo#183999 Forward-Port-Of: odoo/odoo#183105
Steps --- * In the setting enable *Multi Step Routes* * Create an internal transfer with 1 operation for some product > *Mark as Todo* * On the stock.move operation line click the list icon for detailed operations. * *Add a line* => this opens a Wizard where we can choose the quant from which to pick the product for the sml * After adding the line *Add a line* again, we cannot pick the same quant Use case --- For internal transfers, we would like to be able to pick products from the s
Original PR description
Steps --- * In the setting enable *Multi Step Routes* * Create an internal transfer with 1 operation for some product > *Mark as Todo* * On the stock.move operation line click the list icon for detailed operations. * *Add a line* => this opens a Wizard where we can choose the quant from which to pick the product for the sml * After adding the line *Add a line* again, we cannot pick the same quant Use case --- For internal transfers, we would like to be able to pick products from the same quant and dispatch them to several sub-locations of the picking's destination location. Side Fix --- Delete `onRecordDiscarted` method, which wasn't being used because of the typo and doesn't appear to be necessary. opw-4072541 Co-authored-by: @ajf-odoo Forward-Port-Of: odoo/odoo#183815 Forward-Port-Of: odoo/odoo#174984
Reproduce --- - -i event_crm_sale,website_event_questions - Create new "Lead Generation Rule" (Events/Configuration/Lead Generation) - "If the Attendees meet these Conditions": `[("lead_ids", "=", False)]` - add some tag - Add new attendee to an EVENT - Add new question to the EVENT - BUG: `KeyError: 'registration_answer_ids'` opw-4125944 Forward-Port-Of: odoo/odoo#179734
Original PR description
Reproduce
---
- -i event_crm_sale,website_event_questions
- Create new "Lead Generation Rule" (Events/Configuration/Lead Generation)
- "If the Attendees meet these Conditions": `[("lead_ids", "=", False)]`
- add some tag
- Add new attendee to an EVENT
- Add new question to the EVENT
- BUG: `KeyError: 'registration_answer_ids'`
opw-4125944
Forward-Port-Of: odoo/odoo#179734Commands that stop and start the LED service in `posbox_update.sh` were removed in commit `bf96199`, however these were necessary to prevent the filesystem getting stuck in write-mode and potentially getting corrupted (see #54339). The fix is to restore these commands in `posbox_update.sh`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183868
Original PR description
Commands that stop and start the LED service in `posbox_update.sh` were removed in commit `bf96199`, however these were necessary to prevent the filesystem getting stuck in write-mode and potentially getting corrupted (see #54339). The fix is to restore these commands in `posbox_update.sh`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183868
Follow-up of https://github.com/odoo/odoo/pull/177238 PR above improved showing of new messages in Odoo while being out of focus by showing it in tab title and blinking the text. However this felt too obstructive in practice. This commit removes the blinking part, and instead show the out-of-focus amount of unread messages as a counter as prefix of the tab title. For example, if the action is "Inbox", it shows "(4) Inbox" when there are 4 unread and important messages received while odo
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/177238 PR above improved showing of new messages in Odoo while being out of focus by showing it in tab title and blinking the text. However this felt too obstructive in practice. This commit removes the blinking part, and instead show the out-of-focus amount of unread messages as a counter as prefix of the tab title. For example, if the action is "Inbox", it shows "(4) Inbox" when there are 4 unread and important messages received while odoo is out-of-focus. Also take new inbox messages into account for the out-of-focus counter. Task-4242524 Inbox contains a single message, 21 messages are posted in a DM. Before  After  Forward-Port-Of: odoo/odoo#182347
Before this commit, archived combinations were computed using a different method, despite the existence of a specific function designed for this purpose. opw-4261061 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183886
Original PR description
Before this commit, archived combinations were computed using a different method, despite the existence of a specific function designed for this purpose. opw-4261061 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183886
When reconciliing and invoice with a misc entry line, we display the amount currency of the total amount of the entry instead of the partial. Steps: - With USD company currency and EUR foreign currency - Make an invoice for 2000 EUR - Register a payment for 1000 EUR - Make a journal entry in USD, 3 credit lines 1000 USD each on the receivable account, for the invoice's partner - Come back to the invoice and reconcile it with two misc lines via the outstanding credit widget - O
Original PR description
When reconciliing and invoice with a misc entry line, we display the amount currency of the total amount of the entry instead of the partial. Steps: - With USD company currency and EUR foreign currency - Make an invoice for 2000 EUR - Register a payment for 1000 EUR - Make a journal entry in USD, 3 credit lines 1000 USD each on the receivable account, for the invoice's partner - Come back to the invoice and reconcile it with two misc lines via the outstanding credit widget - Open the payment and print the payment receipt -> The Amount Currency column of the misc entry lines show -$3000 instead of $-1000 and $-528.89 (depending of the current rate) With this commit we take the debit or credit amount currency from the partial instead of the total amount of the entry. opw-4089534 Forward-Port-Of: odoo/odoo#183819 Forward-Port-Of: odoo/odoo#180189
The "mark as read" banner helps users keep track of where they last left off in a conversation. Currently, the banner is removed in the following situations: - When returning to the thread twice. - When posting a message. - When clicking on the "mark as read" button on the banner. However, this approach is insufficient, as the banner appears too frequently. This pull request streamlines the conditions under which the banner disappears. The banner will now be removed wheni on top of
Original PR description
The "mark as read" banner helps users keep track of where they last left off in a conversation. Currently, the banner is removed in the following situations: - When returning to the thread twice. - When posting a message. - When clicking on the "mark as read" button on the banner. However, this approach is insufficient, as the banner appears too frequently. This pull request streamlines the conditions under which the banner disappears. The banner will now be removed wheni on top of the other conditions: - The user scrolls to the bottom of the thread. - The user opens a thread that does not have a scrollbar. Both circumstances are sufficient to indicate that the user has actually read the messages. task-4102924 Forward-Port-Of: odoo/odoo#183551
Issue: ====== We can't click twice on the transform button. Steps to reproduce the issue: ============================= - Create a todo - Add an image - Select it - Click on the transform button in the toolbar - The toolbar disappears so we can't click another time Origin of the issue: ==================== The issue was introduced in [1]. Removing the selection will trigger a selectionChange which itself triggers updateToolbar but now we don't have any selection so we hide the to
Original PR description
Issue: ====== We can't click twice on the transform button. Steps to reproduce the issue: ============================= - Create a todo - Add an image - Select it - Click on the transform button in the toolbar - The toolbar disappears so we can't click another time Origin of the issue: ==================== The issue was introduced in [1]. Removing the selection will trigger a selectionChange which itself triggers updateToolbar but now we don't have any selection so we hide the toolbar. Solution: ========= Revert the old fix and instead we ignore any `keydown` event when the transform container is in the dom (which means we are currently transforming an image). task-4235140 [1]: https://github.com/odoo/odoo/commit/463c248e291a53c80365ae606c7cf39e13cd290b Forward-Port-Of: odoo/odoo#183702 Forward-Port-Of: odoo/odoo#182723
**Behaviour before PR:** - In chatgpt prompt dialog, `submitPrompt` method gets called twice when user presses `ctrl + enter` after writing something. As result chatgpt responds twice with same content. This happens because in `dialog.js` a hotkey service is active on `ctrl + enter` which is responsible to trigger a click event on submit button of dialog and `submitPrompt` gets called second time. - Moreover, if text-area is empty and user hits `enter` then an empty prompt is sent to chatGPT
Original PR description
**Behaviour before PR:** - In chatgpt prompt dialog, `submitPrompt` method gets called twice when user presses `ctrl + enter` after writing something. As result chatgpt responds twice with same content. This happens because in `dialog.js` a hotkey service is active on `ctrl + enter` which is responsible to trigger a click event on submit button of dialog and `submitPrompt` gets called second time. - Moreover, if text-area is empty and user hits `enter` then an empty prompt is sent to chatGPT resulting in a meaningless response. **Behaviour after PR:** - Now, `submitPrompt` method gets called once on `ctrl + enter.` - If text-area is empty then pressing `enter` will not submit prompt. task-4207108 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181334
Steps to reproduce ================== - Go to CRM - Open a lead - Open studio - Add a new notebook page - Add a many2many field - Select the task model - Save and exit studio - Switch to the new notebook page - Add a new task => Record does not exist or has been deleted. Cause of the issue ================== The CrmFormRecord is also used for the Many2Many popup. project.task also has a stage_id field, checkRainbowmanMessage is then called, but with the id of the task ht
Original PR description
Steps to reproduce ================== - Go to CRM - Open a lead - Open studio - Add a new notebook page - Add a many2many field - Select the task model - Save and exit studio - Switch to the new notebook page - Add a new task => Record does not exist or has been deleted. Cause of the issue ================== The CrmFormRecord is also used for the Many2Many popup. project.task also has a stage_id field, checkRainbowmanMessage is then called, but with the id of the task https://github.com/odoo/odoo/blob/54d6a19444bfa4f01d03117e4542a5244f274429/addons/crm/static/src/views/crm_form/crm_form.js#L44-L51 Solution ======== It makes no sense to do this if we are not acting on a crm.lead record => We check the resModel before proceeding opw-4101752 Forward-Port-Of: odoo/odoo#183375
As this pr is [merged] (https://github.com/odoo/odoo/pull/152709) so due to this ``float_round`` behaviour is bit changed due to that here is test case is failing in upgrade that checks the qty_available with product their is difference come. [Here](https://github.com/odoo/odoo/blob/251ef3edcc7e0894683acb7c69bfa437a024110f/addons/stock/models/product.py#L207) before product record ``qty_avaliable`` (it non stored field and compute) to come like this ``'qty_available': 0.7000000000000001 `` after
Original PR description
As this pr is [merged] (https://github.com/odoo/odoo/pull/152709) so due to this ``float_round`` behaviour is bit changed due to that here is test case is failing in upgrade that checks the…
As this pr is [merged] (https://github.com/odoo/odoo/pull/152709) so due to this ``float_round`` behaviour is bit changed due to that here is test case is failing in upgrade that checks the qty_available with product their is difference come. [Here](https://github.com/odoo/odoo/blob/251ef3edcc7e0894683acb7c69bfa437a024110f/addons/stock/models/product.py#L207) before product record ``qty_avaliable`` (it non stored field and compute) to come like this ``'qty_available': 0.7000000000000001 `` after new changes in ``float_round`` after this [pr](https://github.com/odoo/odoo/pull/152709) in 17.4 value is ``'qty_available': 0.7`` coming like this and after dividing [here](https://github.com/odoo/odoo/blob/913c081a8687d0f2aa6c40faeee9013fa10865db/addons/mrp/models/product.py#L280) with 0.1(qty per kit) becomes like ```py before 0.7000000000000001/0.1 7.0 after 0.7/0.1 6.999999999999999 ``` while taking quotent [here](https://github.com/odoo/odoo/blob/b3d61b372a8cd315f9063b6add634ad194f3341b/addons/mrp/models/product.py#L264) it taking 6 instead of 7 so this difference come and test case failed ``` AssertionError: Lists differ: [[142[456 chars]63, '7'], [14264, '0.7'], [14265, '-30'], [142[12426 chars]-2']] != [[142[456 chars]63, '6'], [14264, '0.7'], [14265, '-30'], [142[12426 chars]-2']] First differing element 27: [14263, '7'] [14263, '6'] Diff is 15569 characters long. Set self.maxDiff to None to see it. : Invariant check fail ``` for correcting this as discussed here https://github.com/odoo/odoo/pull/152709#issuecomment-2383006955 this fixed is proposed. 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#182265
- Have access to multiple companies (A and B for instance); - Be connected to only one company (company A); - In the profile, have notifications handled in Odoo; - Open Discuss; - Got to History; - Click on the origin of a thread, it should be a record from the second company (company B in this case); Before this commit, we will connect to the second company (as expected), but the record will not be open. This issue happens because we open the record through a doAction. Before the f
Original PR description
- Have access to multiple companies (A and B for instance); - Be connected to only one company (company A); - In the profile, have notifications handled in Odoo; - Open Discuss; - Got to History; -…
- Have access to multiple companies (A and B for instance); - Be connected to only one company (company A); - In the profile, have notifications handled in Odoo; - Open Discuss; - Got to History; - Click on the origin of a thread, it should be a record from the second company (company B in this case); Before this commit, we will connect to the second company (as expected), but the record will not be open. This issue happens because we open the record through a doAction. Before the form view is mounted, an AccessError is raised and the correct company is added to the cookies (see [1]). As the form view is not already mounted, the action service didn't push the new state into the URL. When reloading (after adding the company into the cookies), the state loaded will not contain the action to open the record. Now, we will connect to the second company, and the record will be open. opw-4240778 [1]: https://github.com/odoo/odoo/commit/6213c40932236101b529b82f0ea9fce1829c8c24 Forward-Port-Of: odoo/odoo#182974
Since [1] the meta tag 'default_title' was double-escaped due to improper handling of dynamic content within the template, leading to HTML entities being escaping twice. For example, `"` was incorrectly transformed into `&34;` Steps to reproduce: - Open a product and modify its name by adding a special character, such as a single quote. - Open the "Optimize SEO" dialog. Issue: The default title displays `'` instead of the single quote. This commit resolves this issue and
Original PR description
Since [1] the meta tag 'default_title' was double-escaped due to improper handling of dynamic content within the template, leading to HTML entities being escaping twice. For example, `"` was incorrectly transformed into `&34;` Steps to reproduce: - Open a product and modify its name by adding a special character, such as a single quote. - Open the "Optimize SEO" dialog. Issue: The default title displays `'` instead of the single quote. This commit resolves this issue and at the same time gets rid of the trailing spaces. [1] https://github.com/odoo/odoo/commit/7c54acaebe38e47cad25d8a1bbdb430e5bad265d task-3974334 Forward-Port-Of: odoo/odoo#183806 Forward-Port-Of: odoo/odoo#179739
*: test_website Since [1], the code responsible for resetting broken view failed to consider that during a "hard" reset, the 'arch_updated' field should be set to False. Steps to reproduce (on a local server): - Activate the developer mode - Navigate to Website and click on "Go to Website" - Click on the menu "Pages" > "Manage Pages" - At the /contactus line, click on the "bug" button to access the view - Click on "Edit" to be able to change the architecture - Add something that
Original PR description
*: test_website Since [1], the code responsible for resetting broken view failed to consider that during a "hard" reset, the 'arch_updated' field should be set to False. Steps to reproduce (on a…
*: test_website Since [1], the code responsible for resetting broken view failed to consider that during a "hard" reset, the 'arch_updated' field should be set to False. Steps to reproduce (on a local server): - Activate the developer mode - Navigate to Website and click on "Go to Website" - Click on the menu "Pages" > "Manage Pages" - At the /contactus line, click on the "bug" button to access the view - Click on "Edit" to be able to change the architecture - Add something that breaks the view in the template (i.e : ```<p t-field="no_field.exists"></p>```) - Click on "Save" and after "Go to Page Manager" - Click on the /contactus url link - An internal server error page appears with the possibility to restore the previous version of the view (soft reset) or to reset to initial version (hard reset). Click on "Hard Reset" - With your DB manager, search in the table ir.ui.view, the record with the key website.contactus. Observe that the field arch_updated is still True while the view is reset and shouldn't be in an updated state. This commit ensures consistent updating of this field. A "Hard" reset of a broken view will remove its previous architecture used for "Soft" reset, since there is no real usage where a "Previous" reset is needed after a "Hard" one. [1]: https://github.com/odoo/odoo/commit/479585140caca9fdc758709f043da500297e8046 task-3743850 Forward-Port-Of: odoo/odoo#164929
Versions -------- - 17.0+ Steps ----- 1. Have an SO selling a timesheet-based service; 2. have at least some hours delivered via timesheets; 3. click on "Create Invoice"; 4. select a date for "Timesheets Period". Issue ----- It first shows a datepicker for only the start date, only after closing it can you select a second date. Cause ----- The `daterange` widget doesn't actually default to a range, unless the date field is marked as required. As seen in the `isRange` funct
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have an SO selling a timesheet-based service; 2. have at least some hours delivered via timesheets; 3. click on "Create Invoice"; 4. select a date for "Timesheets Period". Issue ----- It first shows a datepicker for only the start date, only after closing it can you select a second date. Cause ----- The `daterange` widget doesn't actually default to a range, unless the date field is marked as required. As seen in the `isRange` function, it opens a range picker when there are two values present, the field is required, or the `alwaysRange` property is `true`: https://github.com/odoo/odoo/blob/39029710bbce55889c6b951fc423c1254e05ff22/addons/web/static/src/views/fields/datetime/datetime_field.js#L215-L224 Solution -------- Force the range picker on the `daterange` widget by setting the `always_range` option. opw-4049959 Forward-Port-Of: odoo/odoo#181079
Steps to reproduce: 1. Assign a product to category A and category B. 2. Make category A the parent of category B. 3. Put category A as restricted category of the pos.config. 4. Open the pos.config. 5. [ISSUE] click category A. The app crashes because of duplicate key. This is because we are rendering 2 product cards with the same product coming from category A (the parent) and category B (the child). To rectify, this commit proposes to remove the duplicates in the return value of `
Original PR description
Steps to reproduce: 1. Assign a product to category A and category B. 2. Make category A the parent of category B. 3. Put category A as restricted category of the pos.config. 4. Open the pos.config. 5. [ISSUE] click category A. The app crashes because of duplicate key. This is because we are rendering 2 product cards with the same product coming from category A (the parent) and category B (the child). To rectify, this commit proposes to remove the duplicates in the return value of `getProductsByCategory`. Forward-Port-Of: odoo/odoo#183794
Steps to reproduce: - Install Timesheet - Delete all tasks - Run server actions to create tasks with the following scripts https://gist.github.com/mattismegevand/5db26ee9d1e7756e7fe4600897244c1e - Go to Project -> Tasks -> All tasks - Switch to calendar view and go to june 2024 Issues: A traceback appears, the cause is an infinite recursion caused by the computation of the intersection. Since two events are next to each other their intersection is null but fullcalendar try to compute it
Original PR description
Steps to reproduce: - Install Timesheet - Delete all tasks - Run server actions to create tasks with the following scripts https://gist.github.com/mattismegevand/5db26ee9d1e7756e7fe4600897244c1e - Go to Project -> Tasks -> All tasks - Switch to calendar view and go to june 2024 Issues: A traceback appears, the cause is an infinite recursion caused by the computation of the intersection. Since two events are next to each other their intersection is null but fullcalendar try to compute it anyway which leads to the intersection span being null which causes a traceback. I suspect that the fix is https://github.com/fullcalendar/fullcalendar/commit/362a37345a4b7cb65d16f345e8555f727f1c8450 However for good measure and to fix preemptively other bug from fullcalendar an update seems like the best decision. opw-3997810 Forward-Port-Of: odoo/odoo#183151
When we try to add any product for order in the first browser with ``Mitchell Admin`` as the user and simultaneously close the session in the second browser with ``Marc Demo`` as the user, the error will occur in the first browser when we click on order. Steps to reproduce: --- - Install the ``pos_online_payment_self_order`` module - Open the Bar, copy the URL, and Open a POS session on 2 different browsers with different user on both browser - Now go to the second browser and then close
Original PR description
When we try to add any product for order in the first browser with ``Mitchell Admin`` as the user and simultaneously close the session in the second browser with ``Marc Demo`` as the user, the error…
When we try to add any product for order in the first browser with ``Mitchell Admin`` as the user and simultaneously close the session in the second browser with ``Marc Demo`` as the user, the error will occur in the first browser when we click on order. Steps to reproduce: --- - Install the ``pos_online_payment_self_order`` module - Open the Bar, copy the URL, and Open a POS session on 2 different browsers with different user on both browser - Now go to the second browser and then close the session there - Now come to the first browser and add any product - Click on Order Traceback: --- ``ValueError: Expected singleton: pos.config()`` Previous Behaviour: --- This error occurred after this commit https://github.com/odoo/odoo/pull/179382/commits/a351107ade64a0ef67b28283a38b7add0cef689e because when a session is open in two different browsers and one browser is closed, at point [1], we delete the session, and after the deleted session, the orders are not linked to any session. After FIX Behaviour: --- After the deletion of the session from one browser if the orders are not completed then those orders are transferred to the rescue session(recuse session will be created). [1]- https://github.com/odoo/odoo/blob/462acc6853dfdc1418b790e99a0611c5ef5e17e2/addons/point_of_sale/static/src/app/store/pos_store.js#L1048-L1053 sentry-5699019259 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182033
When unlinking too many records, the memory can be reached when browsing too many records, which prevents the gc to work properly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183908 Forward-Port-Of: odoo/odoo#183321
Original PR description
When unlinking too many records, the memory can be reached when browsing too many records, which prevents the gc to work properly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183908 Forward-Port-Of: odoo/odoo#183321
When doing a groupby on a non-relational field (e.g. a char), if the field contains NULL values in DB, they appear as `None` in the keys of the `group_lines_by_keys` dict. If the comparison operator is not implemented between the field type and `NoneType`, `sorted` will fail with a traceback. Solution: sort on keys `(k is None, k)`. if k is None, then `k is None = True`. Because `True > False`, these values are pushed to the end by the sorting. task-none Forward-Port-Of: odoo/enterpri
Original PR description
When doing a groupby on a non-relational field (e.g. a char), if the field contains NULL values in DB, they appear as `None` in the keys of the `group_lines_by_keys` dict. If the comparison operator is not implemented between the field type and `NoneType`, `sorted` will fail with a traceback. Solution: sort on keys `(k is None, k)`. if k is None, then `k is None = True`. Because `True > False`, these values are pushed to the end by the sorting. task-none Forward-Port-Of: odoo/enterprise#72008
This commit addresses the issue of applying incorrect exchange rates for foreign currency transactions. Previously, we were using the rate from the last closing date instead of the rate applicable to the transaction day. Moving forward, the correct exchange rate will be used based on the day to which the quote applies, as outlined in the official guidelines for foreign currency operations by the Dirección General Impositiva (DGI). For reference: https://www.gub.uy/direccion-general-impositiva/
Original PR description
This commit addresses the issue of applying incorrect exchange rates for foreign currency transactions. Previously, we were using the rate from the last closing date instead of the rate applicable to the transaction day. Moving forward, the correct exchange rate will be used based on the day to which the quote applies, as outlined in the official guidelines for foreign currency operations by the Dirección General Impositiva (DGI). For reference: https://www.gub.uy/direccion-general-impositiva/comunicacion/publicaciones/operaciones-moneda-extranjera. latam-task: 1264 adhoc-side-task: 43762 Forward-Port-Of: odoo/enterprise#70335
When a MO consumes components that have a MPS record, the MPS does not take the consumption moves into account for the starting quantity of the MPS record. This PR removes that condition to make sure the starting inventory is correctly computed. Forward-Port-Of: odoo/enterprise#69412
Original PR description
When a MO consumes components that have a MPS record, the MPS does not take the consumption moves into account for the starting quantity of the MPS record. This PR removes that condition to make sure the starting inventory is correctly computed. Forward-Port-Of: odoo/enterprise#69412
This avoids a manual operation when testing DIAN's webservice for support documents. no task Forward-Port-Of: odoo/enterprise#72166
Original PR description
This avoids a manual operation when testing DIAN's webservice for support documents. no task Forward-Port-Of: odoo/enterprise#72166
It’s too easy to forget to set the right group opw-4206894 Forward-Port-Of: odoo/enterprise#72050 Forward-Port-Of: odoo/enterprise#70894
Original PR description
It’s too easy to forget to set the right group opw-4206894 Forward-Port-Of: odoo/enterprise#72050 Forward-Port-Of: odoo/enterprise#70894
In the deferred computations, we always assume that both the start and end date are inclusive E.g: 1st January -> 31st December is *exactly* 1 year = 12 months However, the user may instead put 1st January -> 1st January of next year which is then 12 months + 1/30 month = 12.03 months which may result in odd amounts when deferrals are created For this reason, we now alert the user if we detect such a case with a warning banner and yellow highlight in the abnormal dates. Other cases were the num
Original PR description
In the deferred computations, we always assume that both the start and end date are inclusive E.g: 1st January -> 31st December is *exactly* 1 year = 12 months However, the user may instead put 1st January -> 1st January of next year which is then 12 months + 1/30 month = 12.03 months which may result in odd amounts when deferrals are created For this reason, we now alert the user if we detect such a case with a warning banner and yellow highlight in the abnormal dates. Other cases were the number of months is not round should not be handled. task-id: none Forward-Port-Of: odoo/enterprise#71423
When the user presses `Ctrl` + `p` to print an article, the page appears blank because the assets for print media queries are only loaded after the user clicks the "Export" button. To ensure that the print-specific styles are loaded, we will move the `knowledge_print.scss` file to the `web.assets_web_print` asset bundle. The generated stylesheet will then be linked to the page using a `link` tag with the `media="print"` attribute. The browser will then be able to load the stylesheet when the
Original PR description
When the user presses `Ctrl` + `p` to print an article, the page appears blank because the assets for print media queries are only loaded after the user clicks the "Export" button. To ensure that the print-specific styles are loaded, we will move the `knowledge_print.scss` file to the `web.assets_web_print` asset bundle. The generated stylesheet will then be linked to the page using a `link` tag with the `media="print"` attribute. The browser will then be able to load the stylesheet when the user is printing the page or previewing it for print. Steps to reproduce the issue: 1. Go to the Knowledge app. 2. Open an article 3. Press `Ctrl` + `p` to print the article. => The print rules are not loaded and the page appears blank. TO BE: The print rules should be loaded. task-4191390 Forward-Port-Of: odoo/enterprise#70243
After [this commit], there was an issue for reports where we don't have accounts as the first column. It would offset the cell too far to the left, assuming there is an account code column. This commit fixes that, so reports like the partner ledger are exporting correctly again showing the partner names. [this commit]: https://github.com/odoo/enterprise/commit/a3d76fc2b39428b7ea7c41bf98b2ecbe741a67fb Forward-Port-Of: odoo/enterprise#72038 Forward-Port-Of: odoo/enterprise#72010
Original PR description
After [this commit], there was an issue for reports where we don't have accounts as the first column. It would offset the cell too far to the left, assuming there is an account code column. This commit fixes that, so reports like the partner ledger are exporting correctly again showing the partner names. [this commit]: https://github.com/odoo/enterprise/commit/a3d76fc2b39428b7ea7c41bf98b2ecbe741a67fb Forward-Port-Of: odoo/enterprise#72038 Forward-Port-Of: odoo/enterprise#72010
Currently, an error was generated when the user tries to filter `Customer/Saleperson` in the subscription dashboard. error: `Invalid field sale.subscription.report.message_partner_ids in leaf ('message_partner_ids', 'in', [3])` This is because we have used fields 'message_partner_ids' and 'activity_user_id' to filter out records, but this field is not available in the model. This commit will fix the above issue by using fielels 'partner_id' and 'user_id' to fielter records. sentry-56
Original PR description
Currently, an error was generated when the user tries to filter `Customer/Saleperson` in the subscription dashboard.
error: `Invalid field sale.subscription.report.message_partner_ids in leaf ('message_partner_ids', 'in', [3])`
This is because we have used fields 'message_partner_ids' and 'activity_user_id' to filter out records, but this field is not available in the model.
This commit will fix the above issue by using fielels 'partner_id' and 'user_id' to fielter records.
sentry-5657224204
Forward-Port-Of: odoo/enterprise#71360Problem: The `is_available` flag was used to check both product availability and conflicts with other rentals. However, the UI message was misleading, stating "Other rental(s) in conflict" even when the product was simply not available. Steps to reproduce: - Create a rental product with a quantity of 0. - Add a rental order for that product. - In the Schedule Gantt view, hover over the order. - A warning appears stating "Other rental(s) in conflict," even though no other rentals exist
Original PR description
Problem: The `is_available` flag was used to check both product availability and conflicts with other rentals. However, the UI message was misleading, stating "Other rental(s) in conflict" even when the product was simply not available. Steps to reproduce: - Create a rental product with a quantity of 0. - Add a rental order for that product. - In the Schedule Gantt view, hover over the order. - A warning appears stating "Other rental(s) in conflict," even though no other rentals exist on the same date; the actual issue is that the product is not available. opw-4085496 Forward-Port-Of: odoo/enterprise#69783
Before this commit, when installing the account_reports and l10n_ae modules, the l10n_ae_reports and corporate_tax_report modules were not installed, even though they depended on these modules. This caused an issue during an account report test, as the necessary field was not created, leading to an "Invalid field" error: ('l10n_ae_tax_report_liabilities_account' on model 'res.company') By removing the countries field from the manifest, the modules now auto-install as expected, and the test
Original PR description
Before this commit, when installing the account_reports and l10n_ae modules, the l10n_ae_reports and corporate_tax_report modules were not installed, even though they depended on these modules. This caused an issue during an account report test, as the necessary field was not created, leading to an "Invalid field" error: ('l10n_ae_tax_report_liabilities_account' on model 'res.company')
By removing the countries field from the manifest, the modules now auto-install as expected, and the test no longer fails. But why? If a module depends on another module that has the countries attribute, there’s no need to include it back; the auto-installation will only be triggered if there is a company that belongs to that country.
Forward-Port-Of: odoo/enterprise#72132Problem: In version 17.0, the `partner_id` doesnt exist, and instead, the correct field to use is `partner`. This mismatch causes a traceback when processing invoices in the PoS. Steps to Reproduce: - Install the Chilean localization module (`l10n_cl`). - Go to PoS > Order > Invoice > Pay. - A traceback appears in the console due to the incorrect field reference. opw-4204528 Forward-Port-Of: odoo/enterprise#71737
Original PR description
Problem: In version 17.0, the `partner_id` doesnt exist, and instead, the correct field to use is `partner`. This mismatch causes a traceback when processing invoices in the PoS. Steps to Reproduce: - Install the Chilean localization module (`l10n_cl`). - Go to PoS > Order > Invoice > Pay. - A traceback appears in the console due to the incorrect field reference. opw-4204528 Forward-Port-Of: odoo/enterprise#71737
Steps to reproduce: - Insert a pivot view of timesheet - Insert a list view of project - Add a new global filter based on project => you actually cannot select id for the list view of project, but we should be able to filter the list view based on the project id. This commit adds the id field to the allowed fields for the relation global filters. Task: 4228916 Forward-Port-Of: odoo/enterprise#71856 Forward-Port-Of: odoo/enterprise#71365
Original PR description
Steps to reproduce: - Insert a pivot view of timesheet - Insert a list view of project - Add a new global filter based on project => you actually cannot select id for the list view of project, but we should be able to filter the list view based on the project id. This commit adds the id field to the allowed fields for the relation global filters. Task: 4228916 Forward-Port-Of: odoo/enterprise#71856 Forward-Port-Of: odoo/enterprise#71365
Before this commit, the data given to the spreadsheet init callback in the case of inserting a pivot view was not used. This could lead to an error if the data was too big to be stored in the browser's session storage. This commit removes the useless data given to the spreadsheet init. Note that it's not necessary to write a new test for this, as the existing tests already cover this case. Task: 4255049 Forward-Port-Of: odoo/enterprise#71847
Original PR description
Before this commit, the data given to the spreadsheet init callback in the case of inserting a pivot view was not used. This could lead to an error if the data was too big to be stored in the browser's session storage. This commit removes the useless data given to the spreadsheet init. Note that it's not necessary to write a new test for this, as the existing tests already cover this case. Task: 4255049 Forward-Port-Of: odoo/enterprise#71847
2 changes
Resolved issues and error corrections
This update ensures that the Documents field in projects displays a consistent label across all installations. Previously, the label would vary depending on which modules were installed, which could cause confusion. Now it will always show "Documents" for clarity and consistency.
Original PR description
Before this commit, when documents_project module is installed on a fresh DB the label of `Use Documents` and when documents_fsm module is installed the label is updated to be `Documents`. This commit makes sure the label of that field will always be `Documents` in all cases. task-4250848 Forward-Port-Of: odoo/enterprise#71741
This update corrects and cleans up translations in German localization modules for account follow-up and field service management. These improvements ensure that German-speaking users see accurate and consistent text throughout the application, enhancing the overall user experience.
Original PR description
*l10n_din5008_account_followup, l10n_din5008_industry_fsm Related to: https://github.com/odoo/odoo/pull/183268 Forward-Port-Of: odoo/enterprise#71710