Friday, October 25, 2024
56 changes · 18.0
Enhancements to existing features
The Knowledge editor no longer uses an extra internal command for each individual collaborative editing step. This simplifies processing for embedded content and should reduce unnecessary background work without changing the user experience.
Original PR description
This command's purpose was to dispatch the event at each individual external step, but it was only used for embedded components, and `onExternalHistorySteps` resource (which handles every batch of collaborative steps) is enough for embedded components, and it is called less often. This commit therefore removes `ADD_EXTERNAL_STEP` command. task-4281356
This update adds automated checks for the WhatsApp functionality in marketing automation. It helps reduce the risk of regressions and supports a more reliable experience for teams using WhatsApp campaigns.
Original PR description
The commit intends to add tests to newly introduced functionality of marketing automation where we added whatsapp.
Resolved issues and error corrections
This update restores outstanding accounts in the Ecuador chart of accounts that were available in earlier versions. It helps Ecuadorian companies keep expected payment and receipt flows correctly represented in their accounting setup.
Original PR description
Add the Outstanding Accounts we had in V17.4 and earlier versions --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Using composer in the mass mail mode is allowed on non `mail.thread` models. This fix covers the case where one of the required methods isn't available on the model that we try to send mail on. Reproduce --- - install website_slides - "Add Context Action" on the "Elearning: Add Attendees to Course" template - open an eLearning course -> Attendees list view, select one, click on Send Mail action - fill required replyto -> send -> BUG: traceback opw-4062613 Forward-Port-Of: odoo/odoo
Original PR description
Using composer in the mass mail mode is allowed on non `mail.thread` models. This fix covers the case where one of the required methods isn't available on the model that we try to send mail on. Reproduce --- - install website_slides - "Add Context Action" on the "Elearning: Add Attendees to Course" template - open an eLearning course -> Attendees list view, select one, click on Send Mail action - fill required replyto -> send -> BUG: traceback opw-4062613 Forward-Port-Of: odoo/odoo#185153 Forward-Port-Of: odoo/odoo#178999
This fix prevents errors when users navigate to client actions that include a record in the URL breadcrumb. Invalid breadcrumb entries are now handled cleanly and removed, improving navigation reliability without changing user workflows.
Original PR description
In the case of a client action with a record id on the breadcrumb part of the url (`myClient/22` for instance). The controller should return the display name for the combination action + record id. And for the action alone (a multi-record if it was the case of a window action), the controller should return an error, to be removed from the breadcrumb. This is because client actions don't have multi-records views. Before this commit, the controller avoids returning anything, and an error raised. Now, the controller returns correctly an error, and it's correctly removed from the breadcrumb.
This fix moves shared VAT reference data into the Accounting module so Accounting can operate correctly even when the separate VAT validation module is not installed. It prevents setup issues for businesses that use Accounting without that optional module.
Original PR description
In #180744, we used the `_ref_vat` dictionary in the `account` module in order to provide a placeholder for the company and partner VAT. However, `_ref_vat` was defined only in `base_vat` which depends on `account`, not the other way around. As such, some users might want to use `account` without `base_vat`. We therefore move `_ref_vat` to `account` to allow this. task-none
Fixed a visual issue in Manufacturing where hovering over sample data in the Work Center Overview graph could show an unwanted black spot. This keeps the dashboard cleaner and avoids confusion when reviewing work center information.
Original PR description
In the Work Center Overview, when sample data is present on graph overview, a black spot appears on hover. This PR fixes the issue by preventing it.
This update fixes how text color is chosen inside website cards so it better matches the card background and surrounding page. It helps prevent hard-to-read or inconsistent text when cards inherit different background styles.
Original PR description
Bootstrap sets up background-color using `var(--card-bg)` but forces a color using `var(--body-color)`. It relies on `var(--card-color)` being used on the card-body... but there does not seem to be a…
Bootstrap sets up background-color using `var(--card-bg)` but forces a
color using `var(--body-color)`. It relies on `var(--card-color)` being
used on the card-body... but there does not seem to be a valid reason
to force the body one on the card above. Given the fact that card-color
is actually null by default, we end up with an inconsistent body-color
forced on the card whatever the value of `card-bg`. In the website case,
we often set up `card-bg` to inherit by default, which means the text
color would only work if the card was over the body background color.
By forcing card-color we enforce something consistent and controllable,
which by default will result as the card text color just following the
parent environment one (as `card-color` is null by default). We assume
that if `card-bg` is set, then `card-color` should be too.
Note: doing `color: var(--card-color)` would prevent overriding
--body-color in the card context (which is a bit weird) but it does not
work: it would override the color given by bg-xxx in the .card.bg-xxx
case, which is not what we want.Fixes an issue where undoing an icon size change removed the icon instead of restoring its previous size. This makes editing website content more predictable and reduces accidental content loss.
Original PR description
**Behaviour before PR:** Steps to reproduce: - Add an icon. - Change it's size from 1x to 2x or whatever. - Try to undo. Icon is removed at all instead of resizing to 1x. **Behaviour after PR:** Now undo works properly after changing icon's size. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes automated guided flows behave correctly when pop-up windows are present, ensuring steps target the active window or close it when needed. This improves reliability of website, point of sale, eLearning, and asset validation tests without changing day-to-day user features.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: https://github.com/odoo/enterprise/pull/72756 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a visual issue where status bar arrows could appear broken or separated from their labels on touchscreen devices. It improves the appearance and usability of status indicators in form views, such as CRM leads, without changing business workflows.
Original PR description
On touchscreen, the interactive elements' padding is extended to make them easier to target with fingers. This commit fixes a glitch in the StatusBarField's arrow where the said arrow doesn't touch the bottom of its element. Further more, it reworks the shape to avoid having a small (but visible) gap between the "arrow" part and the "label" one (in addition to weird background, appearing border occasional glitches). Steps to reproduce (on touchscreen): - Open CRM app - Open a lead (form view) => check the statusbar field arrow is "broken" at the bottom and a gap between the arrow and the label task-4212908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Sign app’s automated test was made more stable by ensuring it uses the correct signing template and by allowing more time for the test to complete. This reduces false test failures in the development pipeline without changing customer-facing features.
Original PR description
The shared_sign_request_tour, attempts to open some template and then click on some sign item. However it fails when it tries to click on the sign item, because it's not found. This happened because the tour sometimes open the wrong sign template (one with no items). This commit aims to fix the issue by archiving other sign templates when testing this flow. fixes runbot-98036
The Planning test data now gives Aaron's calendar a full-time hours value, so the expected workload indicator appears during automated checks. This helps keep the Planning schedule view reliable after changes to flexible working hours.
Original PR description
Before this commit, since the `full_time_required_hours` field is unset on the calendar of Aaron employee, the test `/planning:TestUi.test_01_ui` fails because no progressbar is displayed for that employee in the gantt view of `planning.slot` model, meaning the employee is not supposed to work. This commit sets `full_time_required_hours` on the calendar of `Aaron` employee to display the progressbar for that employee as it was expected before the rework of flexible hours for resources. runbot-99111
Non-timesheet analytic entries can now be edited without incorrectly triggering the timesheet-specific unit amount limit. This prevents unnecessary errors when business data uses larger values outside timesheets.
Original PR description
Before this commit, when the user alters the unit_amount field of an analytic account line which is not a timesheet and the amount has more than 6 digits then the user will get a user error saying he cannot encode a number with more than 6 digits for the unit amount field. This commit makes sure the check made on the unit amount is only made when the analytic line altered is a timesheet.
A Studio approval test was corrected so it targets the right button instead of accidentally triggering an app installation. This prevents crashes during automated checks and helps keep Studio validation reliable.
Original PR description
Before this commit, in single app mode (only studio is installed), a tour failed because we added approvals on a button on the Form View of Apps without specifying which. At the end of the day, a module got actually installed which triggered a lot of crashes, including the tour itself and a few low-level cursor-related functions. After this commit, we precisely specify in the tour on which button and function we make approvals for. The tour succeeds and there is no crash.
The quality measurement screen no longer shows a “Take measure” prompt when no scale or device is connected. This avoids confusing operators because they need to enter the measurement manually in that case.
Original PR description
When real time measure is not linked to a device (scale), no need to add the 'Take measure' label as the user must input a value
Automated product walkthroughs now close any open pop-up window when the next item to interact with is hidden behind it. This helps internal testing flows run more consistently for areas such as Helpdesk timesheets and point-of-sale account settlement.
Original PR description
In this commit, we close active modals when the focussed element of a step (trigger) is below the modal. https://github.com/odoo/odoo/pull/185231
Spreadsheet side panel headings now use a shared bold style, making the interface more visually consistent across filters, lists, pivots, and related panels. A related test was also added to help ensure pivot autocomplete behavior remains reliable.
Original PR description
The font weight of this side panel was previously inconsistent with other side panels. This commit introduces a constant for the side panel title font weight to ensure consistency and replaces Bootstrap classes with custom class o-fw-bold. Task: 4194259
The issue: When setting an automation rule to trigger 'On Save' onto a model with a settable non-stored compute field it will sometimes cause an error. For example, the boolean_favortie widget on project.project, clicking the widget while there is an automation rule set to trigger "on save" will not properly update the view. This is because the initial write call to `is_favorite` triggers its inverse function, which also attempts to write to project.project.favorite_user_ids which retriggers th
Original PR description
The issue: When setting an automation rule to trigger 'On Save' onto a model with a settable non-stored compute field it will sometimes cause an error. For example, the boolean_favortie widget on…
The issue: When setting an automation rule to trigger 'On Save' onto a model with a settable non-stored compute field it will sometimes cause an error. For example, the boolean_favortie widget on project.project, clicking the widget while there is an automation rule set to trigger "on save" will not properly update the view. This is because the initial write call to `is_favorite` triggers its inverse function, which also attempts to write to project.project.favorite_user_ids which retriggers the automation rule again. During this retrigger, the `old_values` are populated which attempts to fetch the field values from project.project, causing is_favorite to be recomputed BEFORE the inverse function finishes writing the inverse data, causing this inconsistency. The Fix: Filter out non-stored values when memoizing old_values. This will avoid the issue entirely. It also does not make sense for non-stored field values to be "stored" in this way when they could be dynamically recomputed from the stored field values that will still be passed into the context. OPW: 4106799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180965
- Some are out of date since the last batch export - Some were incorrectly manually modified - Also some cleanup of the `code` comments --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
- Some are out of date since the last batch export - Some were incorrectly manually modified - Also some cleanup of the `code` comments --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Item description node in UBL is merged to one line in the XML by replacing the new line with ', '. This commit improves on it by using single spacebar without the comma. opw-4213014 Forward-Port-Of: odoo/odoo#183935
Original PR description
Item description node in UBL is merged to one line in the XML by replacing the new line with ', '. This commit improves on it by using single spacebar without the comma. opw-4213014 Forward-Port-Of: odoo/odoo#183935
Steps to reproduce: - Create a Sale Order for a storable product and confirm it - Create another user with the following permissions: - Sales > User: Own Documents Only - Inventory > User - With that user, create a new Sale Order for the same product and confirm it. - Click the forecast icon and open the report. Issue: An AccessError will be triggered, as that user doesn't have the rights to access the SO lines of the first SO since it wasn't created by them. While it's correct
Original PR description
Steps to reproduce: - Create a Sale Order for a storable product and confirm it - Create another user with the following permissions: - Sales > User: Own Documents Only - Inventory > User - With that user, create a new Sale Order for the same product and confirm it. - Click the forecast icon and open the report. Issue: An AccessError will be triggered, as that user doesn't have the rights to access the SO lines of the first SO since it wasn't created by them. While it's correct that this user shouldn't be able to access the sale order, we still want them to be able to access the forecast report and see their use, even though they can't click on them and see the SO content. Same thing should apply for draft SO, as they indicate potential future state of the stock as well. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185125 Forward-Port-Of: odoo/odoo#182914
Description of the issue/feature this PR addresses: Do not try install auto installable modules that are not installable Current behavior before PR: If you have an auto_installable module (auto_install = True) that is not installable (installable = False) odoo is trying to install it and displaying warnings on the log Desired behavior after PR is merged: Avoid trying to install modules that are auto_install = True and installable = False --- I confirm I have signed the CLA and
Original PR description
Description of the issue/feature this PR addresses: Do not try install auto installable modules that are not installable Current behavior before PR: If you have an auto_installable module (auto_install = True) that is not installable (installable = False) odoo is trying to install it and displaying warnings on the log Desired behavior after PR is merged: Avoid trying to install modules that are auto_install = True and installable = False --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#141938
Correctly set the flag `install_demo` in demo data for some localisation, they were triggering some warnings otherwise. RunbotError: 103691 Forward-Port-Of: odoo/odoo#185226
Original PR description
Correctly set the flag `install_demo` in demo data for some localisation, they were triggering some warnings otherwise. RunbotError: 103691 Forward-Port-Of: odoo/odoo#185226
This reverts commit bcaf8cb859dc2f7e975d180ba0fc49da20204557 as we were forcing values and it did not reflect the settings of fiscal positions. opw-4270399 Forward-Port-Of: odoo/odoo#185212 Forward-Port-Of: odoo/odoo#185101
Original PR description
This reverts commit bcaf8cb859dc2f7e975d180ba0fc49da20204557 as we were forcing values and it did not reflect the settings of fiscal positions. opw-4270399 Forward-Port-Of: odoo/odoo#185212 Forward-Port-Of: odoo/odoo#185101
Some payment request are failing when sent to viva wallet. Steps to reproduce: ------------------- * Configure viva wallet payment for shop session * Configure one product to have a price unit of 5.1 and na taxes * Open shop session * Add that product to order (only once) * Select **Payment** * Select viva wallet payment method that you configured * Select **Send** > Observation: Error. There are some issues betwees us and Viva Wallet, try again later. [{'type': 'int_from_float', 'lo
Original PR description
Some payment request are failing when sent to viva wallet.
Steps to reproduce:
-------------------
* Configure viva wallet payment for shop session
* Configure one product to have a price unit of 5.1 and na taxes
* Open shop session
* Add that product to order (only once)
* Select **Payment**
* Select viva wallet payment method that you configured
* Select **Send**
> Observation: Error. There are some issues betwees us and Viva Wallet, try again later. [{'type': 'int_from_float', 'loc': ['body', 'amount'], 'msg': 'Input should be a valid integer, got a number with fractional part', 'input': 510.00000000000006, 'url': '...'}]
Why the fix:
------------
Just a floating point precision issue. `3.1 * 100 = 310` but `5.1 * 100 = 510.00000000000006`, explaining why the issue does not always happen.
opw-4076168
Forward-Port-Of: odoo/odoo#184855
Forward-Port-Of: odoo/odoo#184048The issue: When trying to update the stage field of multiple maintenance request there was an error. How to reproduce the issue: -Navigate to the Maintenance app -Click the Maintenance menu item and select Maintenance Requests from the drop-down menu -Click the List view -Select more than one request -Click the Stage field on the list view and select a different stage -Confirm the stage move -> Traceback Explanation: In the write method of the maintenance.request model, the fields mai
Original PR description
The issue: When trying to update the stage field of multiple maintenance request there was an error. How to reproduce the issue: -Navigate to the Maintenance app -Click the Maintenance menu item and select Maintenance Requests from the drop-down menu -Click the List view -Select more than one request -Click the Stage field on the list view and select a different stage -Confirm the stage move -> Traceback Explanation: In the write method of the maintenance.request model, the fields maintenance_type and recurring_maintenance were directly accessed on a recordset instead of a single record. This caused an error in the __get__ method of field.py because it expects a single record. opw-4213560 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#183154
* Module maintenance worksheet is from enterprise, we should add widget upgrade_boolean for it to avoid misunderstanding from customer 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#185020
Original PR description
* Module maintenance worksheet is from enterprise, we should add widget upgrade_boolean for it to avoid misunderstanding from customer 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#185020
Steps to reproduce: - Install `snailmail_account` and `contacts` - Add a company as a contact, this company should be a german one add address and street 2 - Create an invoice for that contact - Confirm invoice - Send invoice using post only - With debug mode go to snailmail letters - Click on send - Check pdf document Issue: The format is not respected, for german letter we should have a '//' preceeding the supplementary notes, as such pingen flag the document as invalid. http
Original PR description
Steps to reproduce: - Install `snailmail_account` and `contacts` - Add a company as a contact, this company should be a german one add address and street 2 - Create an invoice for that contact - Confirm invoice - Send invoice using post only - With debug mode go to snailmail letters - Click on send - Check pdf document Issue: The format is not respected, for german letter we should have a '//' preceeding the supplementary notes, as such pingen flag the document as invalid. https://help.pingen.com/en/faq-post/adressanforderungen-deutsche-post opw-4160129 Forward-Port-Of: odoo/odoo#182292
In line with the approach outlined in [1], where element accessibility was improved by providing explicit names for easier selection and inheritance, this commit applies the same logic to the account portal invoices. By adding column header names, we ensure that these elements can be safely referenced without relying on positional selectors, thus avoiding potential issues when the element structure changes. [1] https://github.com/odoo/enterprise/pull/63957 --- I confirm I have signed the
Original PR description
In line with the approach outlined in [1], where element accessibility was improved by providing explicit names for easier selection and inheritance, this commit applies the same logic to the account portal invoices. By adding column header names, we ensure that these elements can be safely referenced without relying on positional selectors, thus avoiding potential issues when the element structure changes. [1] https://github.com/odoo/enterprise/pull/63957 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180259
Issue: ------ During pdf generation, wkhtmltopdf creates device logs via a request. The user agent of this request is: ``` Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) wkhtmltopdf Safari/534.34. ``` The result is that a `Linux - Safari` device log is created. Solution: --------- This must be prevented using the `_disable_trace` server-side mechanism of the session object. However, we don't want to add this flag to the session currently used by the user in
Original PR description
Issue: ------ During pdf generation, wkhtmltopdf creates device logs via a request. The user agent of this request is: ``` Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.34 (KHTML, like Gecko) wkhtmltopdf Safari/534.34. ``` The result is that a `Linux - Safari` device log is created. Solution: --------- This must be prevented using the `_disable_trace` server-side mechanism of the session object. However, we don't want to add this flag to the session currently used by the user in order to continue generating logs even during report generation for activities performed in parallel. The possibility of creating a temporary session on the filesystem which is a copy of the current session with the `_trace_disable` flag is a good solution. Forward-Port-Of: odoo/odoo#180262
Before this commit, product variants not initially loaded but fetched during the processing of product attributes would remain visible, leading to duplicate product displays. opw-4246879 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184200
Original PR description
Before this commit, product variants not initially loaded but fetched during the processing of product attributes would remain visible, leading to duplicate product displays. opw-4246879 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184200
Description of the issue/feature this PR addresses: - Rremove redundant call to `addPendingOrder`. Current behavior before PR: - Currently, `addPendingOrder` is invoked once by the `point_of_sale` module, and immediately again by `pos_restaurant` [when](https://github.com/odoo/odoo/blob/875ea840b913fd31ef73df9e10e4426df6195bfc/addons/pos_restaurant/static/src/overrides/components/product_screen/product_screen.js#L16-L18) the ProductScreen component mounts. Desired behavior after PR i
Original PR description
Description of the issue/feature this PR addresses: - Rremove redundant call to `addPendingOrder`. Current behavior before PR: - Currently, `addPendingOrder` is invoked once by the `point_of_sale` module, and immediately again by `pos_restaurant` [when](https://github.com/odoo/odoo/blob/875ea840b913fd31ef73df9e10e4426df6195bfc/addons/pos_restaurant/static/src/overrides/components/product_screen/product_screen.js#L16-L18) the ProductScreen component mounts. Desired behavior after PR is merged: - Following the fix for #182495, the 'addPendingOrder' call in pos_restaurant becomes redundant and is no longer necessary. - As now we call the same function in root component. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184266
Steps to reproduce: - install project module. - open form view of any task - create new task and set value of deadline - deadline is getting text-decoration even if deadline is not passed. Sol: - Condition ensures date_deadline is not None and strictly less than current_date - This change improves the robustness of the condition by handling undefined date_deadline values. task: 3970136 Forward-Port-Of: odoo/odoo#173850
Original PR description
Steps to reproduce: - install project module. - open form view of any task - create new task and set value of deadline - deadline is getting text-decoration even if deadline is not passed. Sol: - Condition ensures date_deadline is not None and strictly less than current_date - This change improves the robustness of the condition by handling undefined date_deadline values. task: 3970136 Forward-Port-Of: odoo/odoo#173850
Remove Dependency on hr_contract model as it does exist in the dependent apps for base_automation which would allow tests to fail if the module was not installed. To solve this, the test was compared against a base field instead. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184335 Forward-Port-Of: odoo/odoo#183573
Original PR description
Remove Dependency on hr_contract model as it does exist in the dependent apps for base_automation which would allow tests to fail if the module was not installed. To solve this, the test was compared against a base field instead. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184335 Forward-Port-Of: odoo/odoo#183573
How to reproduce: 1. install l10n_pe_edi_pos 2. run `test_pos_js` The following traceback is obtained: ``` Error received after termination: QUnit test failed: point_of_sale > Chrome > test unsynch data error filtering : message: "Promise rejected during "test unsynch data error filtering": Cannot read properties of undefined (reading 'code')" ``` Adding demo data fixes the error. runbot-73446 Forward-Port-Of: odoo/odoo#184751
Original PR description
How to reproduce: 1. install l10n_pe_edi_pos 2. run `test_pos_js` The following traceback is obtained: ``` Error received after termination: QUnit test failed: point_of_sale > Chrome > test unsynch data error filtering : message: "Promise rejected during "test unsynch data error filtering": Cannot read properties of undefined (reading 'code')" ``` Adding demo data fixes the error. runbot-73446 Forward-Port-Of: odoo/odoo#184751
Fixed onboarding CRM tour which is not working properly. Task-4210376 Forward-Port-Of: odoo/odoo#181846
Original PR description
Fixed onboarding CRM tour which is not working properly. Task-4210376 Forward-Port-Of: odoo/odoo#181846
The event is create with a date_begin and date_end calling datetime.now consecutively. This can lead to a situation where the date_end is before the date_begin in verry rare case (not monotonic). This commit fix this by calling datetime.now only once and using the same value for both date_begin and date_end. runbot error [56986](https://runbot.odoo.com/web#id=56986&cids=1&menu_id=424&action=573&model=runbot.build.error&view_type=form) Forward-Port-Of: odoo/odoo#185067 Forward-Port-Of: odoo/
Original PR description
The event is create with a date_begin and date_end calling datetime.now consecutively. This can lead to a situation where the date_end is before the date_begin in verry rare case (not monotonic). This commit fix this by calling datetime.now only once and using the same value for both date_begin and date_end. runbot error [56986](https://runbot.odoo.com/web#id=56986&cids=1&menu_id=424&action=573&model=runbot.build.error&view_type=form) Forward-Port-Of: odoo/odoo#185067 Forward-Port-Of: odoo/odoo#184990
The test_sync_recorder was breaking for strange reason because of extra elements in the stack A first attempt was made trying to remove last elements but in some case a `_remove` or `signal_handler` can appear in the middle. It looks to complex to adapt the test to work in all those cases. Moving it to a non standard test looks like the simplest solution for now. runbot error [73473](https://runbot.odoo.com/web#id=73473&cids=1&menu_id=424&action=573&model=runbot.build.error&view_type=form)
Original PR description
The test_sync_recorder was breaking for strange reason because of extra elements in the stack A first attempt was made trying to remove last elements but in some case a `_remove` or `signal_handler` can appear in the middle. It looks to complex to adapt the test to work in all those cases. Moving it to a non standard test looks like the simplest solution for now. runbot error [73473](https://runbot.odoo.com/web#id=73473&cids=1&menu_id=424&action=573&model=runbot.build.error&view_type=form) Forward-Port-Of: odoo/odoo#185065 Forward-Port-Of: odoo/odoo#185023
Discuss displays an unread counter for the user to keep track of unread messages. This counter is notably shown in the sidebar and in the unread messages banner. However, these counters sometimes have different values, which is inconsistent. Steps to reproduce: - Open two browsers (admin/demo). - Send enough messages from demo to admin to get a scrollbar. - Scroll to the top with admin, mark the first message as unread. - Focus the composer: only the banner remains. - Send another messag
Original PR description
Discuss displays an unread counter for the user to keep track of unread messages. This counter is notably shown in the sidebar and in the unread messages banner. However, these counters sometimes have different values, which is inconsistent. Steps to reproduce: - Open two browsers (admin/demo). - Send enough messages from demo to admin to get a scrollbar. - Scroll to the top with admin, mark the first message as unread. - Focus the composer: only the banner remains. - Send another message from demo. - The sidebar displays 1 unread message while the banner still shows the same value. To better indicate unread messages, the banner/indicator remains until the user returns to the thread. As a result, server and local values can sometimes become desynced. This PR ensures both counters account for this desync, adding the local counter to the server one when necessary. Forward-Port-Of: odoo/odoo#185044
While adding the `TDS` taxes on payment for receipt from vendor and payment to customer, the type of tax i.e purchase or sale should be dependent on partner type i.e supplier or customer. For the vendor tds taxes should be of purchase type and for the customer it should be of sale type. task-4262953 Forward-Port-Of: odoo/odoo#184823
Original PR description
While adding the `TDS` taxes on payment for receipt from vendor and payment to customer, the type of tax i.e purchase or sale should be dependent on partner type i.e supplier or customer. For the vendor tds taxes should be of purchase type and for the customer it should be of sale type. task-4262953 Forward-Port-Of: odoo/odoo#184823
- Some are out of date/module was added since the last batch export. - Some were incorrectly manually modified - Also some cleanup of the `code` comments
Original PR description
- Some are out of date/module was added since the last batch export. - Some were incorrectly manually modified - Also some cleanup of the `code` comments
Add a compound index on (`res_model`, `res_id`) to support domains searching documents based on those criteria, similarly to `ir_attachment_res_idx` on `ir.attachment`. Forward-Port-Of: odoo/enterprise#72426
Original PR description
Add a compound index on (`res_model`, `res_id`) to support domains searching documents based on those criteria, similarly to `ir_attachment_res_idx` on `ir.attachment`. Forward-Port-Of: odoo/enterprise#72426
The error occurs when we validate the quality worksheet template. Steps to reproduce: --- - Install the ``quality_mrp_workorder_worksheet`` module - Quality > Configuration > Quality Worksheet Templates - Click on ``Design Template`` - Click on ``Close`` - Click on ``Validate`` Traceback: --- ``ValueError: Expected singleton : quality.check()`` This error occurs at [1], where we are receiving ``self`` as empty. Previous behavior: --- When we try to design a template in the
Original PR description
The error occurs when we validate the quality worksheet template. Steps to reproduce: --- - Install the ``quality_mrp_workorder_worksheet`` module - Quality > Configuration > Quality Worksheet…
The error occurs when we validate the quality worksheet template. Steps to reproduce: --- - Install the ``quality_mrp_workorder_worksheet`` module - Quality > Configuration > Quality Worksheet Templates - Click on ``Design Template`` - Click on ``Close`` - Click on ``Validate`` Traceback: --- ``ValueError: Expected singleton : quality.check()`` This error occurs at [1], where we are receiving ``self`` as empty. Previous behavior: --- When we try to design a template in the ``Quality Worksheet Templates`` the studio opens as expected. However, if we close it without making any changes, we are redirected to the form view. In this view, we encounter strange behavior and are unable to perform any actions. After behavior: --- Now, when we click on ``Design Template`` from the list view and then close it, we are redirected to the form view of the ``Quality Worksheet Templates``. [1]- https://github.com/odoo/enterprise/blob/7eb1131b413afc2549382d2524ec83445803b682/quality_mrp_workorder_worksheet/models/quality.py#L12 sentry-5695518176 Forward-Port-Of: odoo/enterprise#68341
steps: -> populate the portal user's appointments with enough appointments to have multiple pages in the portal -> go on the portal, filter by "past" -> go to page 2 --> the filter by "past" is removed from the url opw-4236596 Forward-Port-Of: odoo/enterprise#71965
Original PR description
steps: -> populate the portal user's appointments with enough appointments to have multiple pages in the portal -> go on the portal, filter by "past" -> go to page 2 --> the filter by "past" is removed from the url opw-4236596 Forward-Port-Of: odoo/enterprise#71965
This reverts commit a0a5dea9178d7db7ef35d8241ad13f8bac406044 as we're reverting e3acf5937cd7a65087a0178fadd666dead2b99db opw-4270399 Forward-Port-Of: odoo/enterprise#72749
Original PR description
This reverts commit a0a5dea9178d7db7ef35d8241ad13f8bac406044 as we're reverting e3acf5937cd7a65087a0178fadd666dead2b99db opw-4270399 Forward-Port-Of: odoo/enterprise#72749
**Version:** - 17.0 **Current Behaviour:** - Whenever tags were added to the document, the saved notification would appear, which looked odd. - Adding multiple tags caused the field size to increase, which was inappropriate. **Updated Behaviour:** - The saved notification will only appear when exiting the document. - A CSS class has been added to maintain a fixed size when adding multiple tags. task-4164151 Forward-Port-Of: odoo/enterprise#72664 Forward-Port-Of: odoo/enterpris
Original PR description
**Version:** - 17.0 **Current Behaviour:** - Whenever tags were added to the document, the saved notification would appear, which looked odd. - Adding multiple tags caused the field size to increase, which was inappropriate. **Updated Behaviour:** - The saved notification will only appear when exiting the document. - A CSS class has been added to maintain a fixed size when adding multiple tags. task-4164151 Forward-Port-Of: odoo/enterprise#72664 Forward-Port-Of: odoo/enterprise#70195
The query count in single module build is higher than the one with all modules installed. - test_mail_enterprise   - test_mail_enterprise + documents_project    - test_mail_enterprise + documents_project   In summary, a one2many fields document_ids on document_projects triggers an [orm optimisation](https://github.com/odoo/odoo/pull/111651/files) leading to 10 less queries. In 16.0 the query count adapted in an all-enterprise build fails in single module In 17.0 a regression of performance was missed because a margin is added on a bunch of query count that didn't break in the all-enterprise build This pr proposes to add a field with the corresponding optimization in the test module in stable, to have reliable query counter. This field will be moved to the document module in master. RunbotError-65777 Forward-Port-Of: odoo/enterprise#72700 Forward-Port-Of: odoo/enterprise#72598
### Steps to reproduce: - Create and configure a Sendcloud shipping method - Create a Contact Bob - Create a subconcat of type delivery for Bob without setting any name > by default its display name will be "Bob, delivery address" - Create a sale order for Bob - Add a Sendcloud shipment method to that SO and confirm the SO - Go on the associated delivery and try to validate it ### Expected behavior: You should raise a user error telling you that you a pickup point was required fo
Original PR description
### Steps to reproduce: - Create and configure a Sendcloud shipping method - Create a Contact Bob - Create a subconcat of type delivery for Bob without setting any name > by default its display name…
### Steps to reproduce: - Create and configure a Sendcloud shipping method - Create a Contact Bob - Create a subconcat of type delivery for Bob without setting any name > by default its display name will be "Bob, delivery address" - Create a sale order for Bob - Add a Sendcloud shipment method to that SO and confirm the SO - Go on the associated delivery and try to validate it ### Expected behavior: You should raise a user error telling you that you a pickup point was required for the selected shipping method. ### Current behavior: You raise a traceback prior to that point. ### Cause of the issue: Since you did not set a name on your delivery partner the code will break as soon as you try to generate the parcels data because "False" is not iterable, see: https://github.com/odoo/enterprise/blob/37577535a4482eaa1250b41136b47b3613eb7693/delivery_sendcloud/models/sendcloud_service.py#L576-L577 ### Fix: If for some reason the name of the delivery partner has been removed or was unset (e.g. display name is of the form: Bob, Delivery address), the name of its parent should be used to generate the parcel data. Note: This fix should normally not be that relevant, because, if you were to select a pickup point, the partner used to generate the parcel would already be the parent partner and is guarranteed to have a name: https://github.com/odoo/enterprise/blob/37577535a4482eaa1250b41136b47b3613eb7693/delivery_sendcloud/models/sendcloud_service.py#L556-L561already However, now, if you proceed with this flow without any pickup point (which you can only select form the website) you will now raise a relevant user error: #### Invalid Operation: "A service point is required for the selected shipping method" opw-4118362 Forward-Port-Of: odoo/enterprise#72076
Due to a quirk in the JS framework, when a device form view is opened from the IoT box form view, it opens in a dialog box where it's `js_class` is not run. This causes updates to Display URL and Keyboard layout not to sync to the IoT box. This PR works around the issue by forcing the full device form view to open, rather than the dialog box. task-4141053 Forward-Port-Of: odoo/enterprise#72461 Forward-Port-Of: odoo/enterprise#72351
Original PR description
Due to a quirk in the JS framework, when a device form view is opened from the IoT box form view, it opens in a dialog box where it's `js_class` is not run. This causes updates to Display URL and Keyboard layout not to sync to the IoT box. This PR works around the issue by forcing the full device form view to open, rather than the dialog box. task-4141053 Forward-Port-Of: odoo/enterprise#72461 Forward-Port-Of: odoo/enterprise#72351
Fixed onboarding Social Marketing tour which is not working properly. Reason ====== We're not getting this `'textarea[name="message"]` for some reasons, & there is no `name` attribute in textarea. Also, we removed `extra_tringger` in later version, and we can use `run: 'edit` instead so removed that & used common classes that works on all version. Task-4210376 Forward-Port-Of: odoo/enterprise#72705 Forward-Port-Of: odoo/enterprise#71016
Original PR description
Fixed onboarding Social Marketing tour which is not working properly. Reason ====== We're not getting this `'textarea[name="message"]` for some reasons, & there is no `name` attribute in textarea. Also, we removed `extra_tringger` in later version, and we can use `run: 'edit` instead so removed that & used common classes that works on all version. Task-4210376 Forward-Port-Of: odoo/enterprise#72705 Forward-Port-Of: odoo/enterprise#71016
The field fetching status is used to check if we need to call the synchronization. In case there is an error during the synchronization, the user would be block with his connection. The solution is to reset the fetching status when fetching the transaction or use the new reset button on the list view of the online accounts. task:4262788 Forward-Port-Of: odoo/enterprise#72492
Original PR description
The field fetching status is used to check if we need to call the synchronization. In case there is an error during the synchronization, the user would be block with his connection. The solution is to reset the fetching status when fetching the transaction or use the new reset button on the list view of the online accounts. task:4262788 Forward-Port-Of: odoo/enterprise#72492
When deleting the measure on which the pivot is sorted, the side panel would crash. This commit fixes this issue by removing the sortedColumn from the pivot when the measure is deleted. Task: [4154831](https://www.odoo.com/web#id=4154831&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#69926
Original PR description
When deleting the measure on which the pivot is sorted, the side panel would crash. This commit fixes this issue by removing the sortedColumn from the pivot when the measure is deleted. Task: [4154831](https://www.odoo.com/web#id=4154831&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#69926
Steps to reproduce: - multi-currency - upload an expense with a differenct currency than the company - OCRize it Issue: The exchange rate is always 1:1 Cause: We don't fetch the echange rate with OCR and the compute's cannot fetch it since we cill never satisfy the condition https://github.com/odoo/odoo/blob/86b748dc91f7260b30c6944fd906a4d68ec1849b/addons/hr_expense/models/hr_expense.py#L251-L261 Solution: Fetch the exchange rate directly during the process of the extracted data.
Original PR description
Steps to reproduce: - multi-currency - upload an expense with a differenct currency than the company - OCRize it Issue: The exchange rate is always 1:1 Cause: We don't fetch the echange rate with OCR and the compute's cannot fetch it since we cill never satisfy the condition https://github.com/odoo/odoo/blob/86b748dc91f7260b30c6944fd906a4d68ec1849b/addons/hr_expense/models/hr_expense.py#L251-L261 Solution: Fetch the exchange rate directly during the process of the extracted data. I differed the write operation at the end to avoid unwanted computed that could overwrite what we need. opw-4151571 Forward-Port-Of: odoo/enterprise#72112
Steps to reproduce: - Sign app > Upload a PDF & Sign - Add a Date field > Sign Now > Sign Now - Click the date field The value 'undefined' fills the field instead of today's date. This was caused by an oversight when resolving a conflict in https://github.com/odoo/enterprise/pull/71864, the query selector should have grabbed the date from the HTML document but didn't. opw-4278391 Forward-Port-Of: odoo/enterprise#72574
Original PR description
Steps to reproduce: - Sign app > Upload a PDF & Sign - Add a Date field > Sign Now > Sign Now - Click the date field The value 'undefined' fills the field instead of today's date. This was caused by an oversight when resolving a conflict in https://github.com/odoo/enterprise/pull/71864, the query selector should have grabbed the date from the HTML document but didn't. opw-4278391 Forward-Port-Of: odoo/enterprise#72574
Currently, Odoo supports several currencies (USD, EUR, JPY, GBP) for Banxico data parsing, but CNY (Chinese Yuan) is missing. This commit adds support for CNY in the list of currencies retrieved from Banxico’s API (through iap proxy). related pr: https://github.com/odoo/iap-apps/pull/912 task-4205613 Forward-Port-Of: odoo/enterprise#72202
Original PR description
Currently, Odoo supports several currencies (USD, EUR, JPY, GBP) for Banxico data parsing, but CNY (Chinese Yuan) is missing. This commit adds support for CNY in the list of currencies retrieved from Banxico’s API (through iap proxy). related pr: https://github.com/odoo/iap-apps/pull/912 task-4205613 Forward-Port-Of: odoo/enterprise#72202