Tuesday, November 19, 2024
78 changes · 18.0
Enhancements to existing features
Adds documentation guidance for the GSTIN status feature in the India localization settings. This helps users understand where to find official information and how the feature supports GST compliance workflows.
Original PR description
task-4143187 Related PR - https://github.com/odoo/documentation/pull/11324 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The editor’s insert option now uses the clearer name “Media” instead of “Image,” matching the media selection dialog and better reflecting that it can handle more than images. Users can still find it by searching for image or icon, while video insertion remains available through the media dialog where enabled.
Original PR description
This commit:
- renames the Image command to Media to better reflect its broader functionality and match the dialog's title ("Select a media").
- adds search keywords so that both "image" and "icon" are aliases to the Media command, improving discoverability.
- removed the Video command as it is currently not used in html_field (it is still available as a tab in the media dialog when the "disableVideo" option is set to false, effectively merging the Video command into the Media command).
task-4264248This update marks the mail mailbox route as read-only, helping the system handle mailbox-related requests more efficiently. It is a behind-the-scenes improvement that can reduce unnecessary database overhead without changing the user experience.
Attendance Gantt and list views now hide archived employees by default. This keeps workforce planning screens focused on current staff and reduces clutter for managers reviewing attendance schedules.
Original PR description
With this commit, by default, The gantt view and list view don't dispayed archived employees. task-4208052
Resolved issues and error corrections
The test mock server now correctly supports property-related fields, helping automated tests better reflect real application behavior. This reduces the risk of unnoticed issues in features that rely on those fields, without changing the end-user experience.
Original PR description
This commit allows the mock server to properly handle 'property' and 'property_definition' fields in tests. Enterprise: https://github.com/odoo/enterprise/pull/73851 Task: [4058174](https://www.odoo.com/odoo/project.task/4058174) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
This change removes a duplicated internal component used by automated website tours and relies on the existing shared version instead. It reduces maintenance complexity without changing the expected user experience.
Original PR description
In this commit, we remove the MacroEngine class which duplicates the Macro class.
Miscellaneous changes
Currently, if an order has a downpayment made from the POS, when we invoice it, the unit price of the downpayment becomes 0 on the sale order. The same flow using only sale will correctly show the downpayment price. Steps to reproduce: ------------------- * Create a quotation in the **Sale** app * In the **Point of Sale** app, open shop session * Create a downpayment for the order * Go back in the **Sale** app * Open sale order > Observation: The downpayment line has a price unit set
Original PR description
Currently, if an order has a downpayment made from the POS, when we invoice it, the unit price of the downpayment becomes 0 on the sale order. The same flow using only sale will correctly show the…
The attendance schedule now hides archived employees by default, keeping views focused on active staff. Users can still include archived employees by selecting them directly or searching for their name when needed.
Original PR description
With this task, by default archived employees will not be displayed. If the user want to see them, he can select archived employees or write their name in the searchbar. task-4208052 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 update fixes several unstable automated test tours across point of sale, project, website, and eLearning areas. It helps prevent false test failures by making checks more reliable without changing user-facing features.
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
The Certifications search view no longer shows an option to filter for non-certifications, because that option could never return results in this area. This reduces confusion and makes the search experience clearer for users managing certifications.
Original PR description
Problem: Surveys can be filtered by whether or not they are also Certifications, based on the boolean field `certification` on the `survey.survey` record. There is a separate menu item to display Certifications only, which uses a Window Action domain filtering for this field being True. In the inherited search view for Certifications, we already hide the filter for Certifications (since they are). But we still display the filter for non-Certifications, which is pointless given the domain. Purpose: Hide the additional filter for `Is not a Certification` since it will never return results via the Certification views after the domain filters them out. opw-4167285
This fixes a point-of-sale issue where sessions could not be closed if some orders did not have an assigned employee. It helps businesses using kiosks or self-ordering avoid blocked session closures and end-of-day disruptions.
Original PR description
Before this commit, it was not possible to close the session if an order was missing the employee_id field. This situation can occur when an order comes from a kiosk or self-order. opw-4325334 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where activity searches based on status could use an outdated user timezone. Business users should see more accurate activity filtering, especially around due dates across time zones.
Original PR description
The user timezone is not flushed and used in the SQL to search by `activity_state` in the activity mixin. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The recruitment job position screen now displays today’s activities and overdue activities on separate lines. This makes the activity information easier to read and helps recruiters quickly distinguish urgent follow-ups.
Original PR description
With this commit, today activities and late activities are not on the same line. task-4270265 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 fixes an incorrect text label used in a Mail activity filter. Users will see the right filter wording, reducing confusion when finding or organizing activities.
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
This change removes an unused internal service reference in the Mail app. It helps keep the codebase cleaner and reduces the chance of maintenance issues, with no expected change for users.
The test environment now better understands configurable property fields used across Odoo apps. This helps teams catch issues earlier and improves confidence in updates for Documents, planning views, and map-based features.
Original PR description
This commit allows the mock server to properly handle 'property' and 'property_definition' fields in tests. Community: https://github.com/odoo/odoo/pull/187269 Task: [4058174](https://www.odoo.com/odoo/project.task/4058174)
This update adds a missing safeguard for the UK HMRC integration so demo or test environments do not accidentally keep live-style configuration. It helps ensure the module behaves safely when databases are prepared for non-production use.
Original PR description
This commit adds the missing neutralization necessary for the l10n_uk_hmrc module introduced in [1]. [1]: https://github.com/odoo/enterprise/pull/66766
Invoice PDFs for Mexico localization now show the Predial Account column only when invoice lines include rental products with a predial account. This keeps most signed invoices cleaner by removing an unnecessary empty column.
Original PR description
The "Predial Account" column appeared in all signed invoices, regardless of whether the invoice lines included rental products with a predial account. This resulted in a non-organized layout with an empty column for most invoices. Steps to reproduce: 1. Install the l10n_mx_edi module. 2. Create and sign an invoice with any product and customer. Expected behavior: The "Predial Account" column should only be displayed when the invoice contains products with a predial account. Actual behavior: The "Predial Account" column is displayed in all invoices, even when it's empty. opw-4233358
The Chilean point-of-sale invoice checkbox now reflects the actual invoice selection instead of appearing checked all the time. This reduces cashier confusion and helps users see whether an invoice option is truly selected before completing payment.
Original PR description
Issue: In the Chilean POS localization, the checkbox contained in the invoice button is always checked. This is confusing, since it seems the option is selected even when it isn't. Cause: By default, the checkbox depends on the order's "is_to_invoice" return value. In the Chilean POS, the "to_invoice" value is set to true by default and never updated, so "is_to_invoice" always returns true. Clicking on the invoice button only updates the value of the "invoice_type" field. Solution: Replace the checkbox with one that uses the "invoice_type" field through the "isFactura" function. Ticket: opw-4298996
This fix keeps subscription product pricing aligned with recent platform changes so the correct discount comparison price can be shown. It helps customers see accurate strikethrough prices when configuring subscription products.
Original PR description
The pricelist rule is now returned by the configurator methods, to be able to deduce the right strikethrough price. See also odoo/odoo#187436
This update simplifies an automated check that confirms users in read-only mode do not see add buttons in Knowledge articles. It helps keep the Knowledge app's access behavior reliable without changing the user experience.
Original PR description
In this commit, we simplify steps of the tour that check there are no add buttons in readonly mode.
Opening or refreshing a shared Documents link now shows the intended selected document, even when default filters would normally hide it. This prevents users from landing in an empty or filtered view and makes copied document URLs more reliable.
Original PR description
Reproduce: 1. Configure a default filter on Documents so that not all documents are visible 2. Select a document that does not match this default filter 3. Copy the url of this document (copy url when it is selected) 4. Paste in navigation bar / refresh page 5. You do not end up on the document because the default filter still applied This commit prevents loading default filters when we come from such URLs, not otherwise (refresh the page after deselecting the document in the folder). Task-4342960
A restaurant preparation display test was adjusted to prevent an unrelated printing failure pop-up from interrupting it. This helps keep automated checks reliable so future updates can be validated with fewer false failures.
Original PR description
Fix tour test_03_preparation_display_skip_change by unlink printer config to avoid the appear of modal "printing failed".
This update removes a duplicate internal component used to manage web tour macros, reducing maintenance complexity. Business users should not see any change in day-to-day behavior, but the cleanup helps keep the product easier to maintain and evolve.
Original PR description
[REF] web_tour: remove MacroEngine class In this commit, we remove the MacroEngine class which duplicates the Macro class.
Currently, if an order has a downpayment made from the POS, when we invoice it, the unit price of the downpayment becomes 0 on the sale order. The same flow using only sale will correctly show the downpayment price. Steps to reproduce: ------------------- * Create a quotation in the **Sale** app * In the **Point of Sale** app, open shop session * Create a downpayment for the order * Go back in the **Sale** app * Open sale order > Observation: The downpayment line has a price unit set * If needed, deliver the items * Create an invoice (regular invoice) * Confirm the invoice * Go back to the sale order > Observation: The downpayment line has a price unit of 0.0 Why the fix: ------------ The difference between the two flows (pos/sale) mainly resides in those few lines: https://github.com/odoo/odoo/blob/b3b1fe6a78f9e5b6f1d993b5aa2fed11e33c793e/addons/sale/models/account_move.py#L75-L85 `dpl.invoice_lines` will include 2 items when using the sale flow whereas only one when making the downpayment in pos. Downpayments from pos are not automatically invoiced and even if they are, the model `pos.order.line` does not have the field `invoice_lines`. However each downpayment **sale order line** that comes from the POS is linked to its downpayment **pos order line** with the field `pos_order_line_ids`. The only element left in `dpl.invoice_lines` will not be counted as it is included in `real_invoice` (the current invoice). The idea of the fix is to include the price unit of the downpayment made in pos in this sum. opw-4160111 Forward-Port-Of: odoo/odoo#187198 Forward-Port-Of: odoo/odoo#185788
Some users are using custom domains in their loyalty programs. This include using fields that are not loaded in the PoS. This will fix the specific usecase of one client. But this could be improved and fields should be loaded dynamically based on the needed fields. opw-4262960 Forward-Port-Of: odoo/odoo#187230 Forward-Port-Of: odoo/odoo#186804
Original PR description
Some users are using custom domains in their loyalty programs. This include using fields that are not loaded in the PoS. This will fix the specific usecase of one client. But this could be improved and fields should be loaded dynamically based on the needed fields. opw-4262960 Forward-Port-Of: odoo/odoo#187230 Forward-Port-Of: odoo/odoo#186804
Current behaviour: --- On Knowledge, when multiple people are looking at the same page, if one of them deletes the end of a sentence, the others have a traceback. Steps to reproduce: --- 1. Install knowledge 2. On one browser tab, connect admin 3. On another, connect demo 4. With admin, go to knowledge 5. Create a page in workspace 6. In Share, change visibility to everyone 7. With demo, join the page 8. With admin, write a long word 9. Place both cursors at the end of the word
Original PR description
Current behaviour: --- On Knowledge, when multiple people are looking at the same page, if one of them deletes the end of a sentence, the others have a traceback. Steps to reproduce: --- 1. Install knowledge 2. On one browser tab, connect admin 3. On another, connect demo 4. With admin, go to knowledge 5. Create a page in workspace 6. In Share, change visibility to everyone 7. With demo, join the page 8. With admin, write a long word 9. Place both cursors at the end of the word 10. With admin, select a few letters at the end of the word 11. Delete those letters 12. Demo should have a traceback Cause of the issue: --- In `getDeepestPosition` > `closestBlock` > `findNode` `findNode` can return `null` opw-4072333 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177964
Versions -------- - 16.0+ Steps (17.0+) ------------- 1. Create a Sale Order for a new contact without phone number; 2. disable online signature; 3. add a deliverable product to the SO; 4. hit "Send by Email"; 5. open the sent mail (e.g. via Mailhog); 6. copy the payment link; 7. open in Safari on iOS; 8. pay the sales order. Issue ----- > ``` >TypeError: Attempted to assign to readonly property. > extractFilteredSchemaValuesFromMicroData@https... > extractSchemaValuesF
Original PR description
Versions -------- - 16.0+ Steps (17.0+) ------------- 1. Create a Sale Order for a new contact without phone number; 2. disable online signature; 3. add a deliverable product to the SO; 4. hit "Send…
Versions -------- - 16.0+ Steps (17.0+) ------------- 1. Create a Sale Order for a new contact without phone number; 2. disable online signature; 3. add a deliverable product to the SO; 4. hit "Send by Email"; 5. open the sent mail (e.g. via Mailhog); 6. copy the payment link; 7. open in Safari on iOS; 8. pay the sales order. Issue ----- > ``` >TypeError: Attempted to assign to readonly property. > extractFilteredSchemaValuesFromMicroData@https... > extractSchemaValuesFromSchemaOrg@https... > global code@https... > ``` Cause ----- `extractFilteredSchemaValuesFromMicroData` is a function internal to iOS Safari. It is bugged in that it tries to reassign a `const` in some scenarios where no elements with `itemprop="telephone"` attributes are found. More details in this comment: https://github.com/odoo/odoo/pull/187143#issuecomment-2475934797 Solution -------- If the contact doesn't have a mobile or phone number, add an empty `div` with `itemprop="telephone"`. > [!note] > I've also reported the bug to Apple, but who knows when/if they'll fix it. Related issue: https://github.com/odoo/odoo/issues/162145 opw-4072838 Forward-Port-Of: odoo/odoo#187380 Forward-Port-Of: odoo/odoo#187143
Updated the regex of the youtube videos to accept some of the latest links as shorts and lives, following the same behavior as in web_editor. Specifically the links generated using the share button. Steps to reproduce: 1. Install eLearning and create a course. 2. Add a new content as video. 3. Take the Youtube livestream url from share > copy. 4. Use this link for the video slide in the course. opw-4278811 I confirm I have signed the CLA and read the PR guidelines at www.odoo.co
Original PR description
Updated the regex of the youtube videos to accept some of the latest links as shorts and lives, following the same behavior as in web_editor. Specifically the links generated using the share button. Steps to reproduce: 1. Install eLearning and create a course. 2. Add a new content as video. 3. Take the Youtube livestream url from share > copy. 4. Use this link for the video slide in the course. opw-4278811 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187139 Forward-Port-Of: odoo/odoo#185518
Issue: when we import a data only module with unknown dependencies we allow it to be installed, and in the process we add wrong data to the dependencies table. Example manifest: ``` {'data': ['foo.xml'], 'depends': ['base', 'bar', 'baz']} ``` Will end up with: ``` test_17=> select id,name,latest_version,state from ir_module_module where name in ('base','foo', 'bar', 'baz') +------+------+----------------+-----------+ | id | name | latest_version | state | |------+------+-----
Original PR description
Issue: when we import a data only module with unknown dependencies we allow it to be installed, and in the process we add wrong data to the dependencies table. Example manifest: ``` {'data':…
Issue: when we import a data only module with unknown dependencies we
allow it to be installed, and in the process we add wrong data to the
dependencies table.
Example manifest:
```
{'data': ['foo.xml'], 'depends': ['base', 'bar', 'baz']}
```
Will end up with:
```
test_17=> select id,name,latest_version,state from ir_module_module where name in ('base','foo', 'bar', 'baz')
+------+------+----------------+-----------+
| id | name | latest_version | state |
|------+------+----------------+-----------|
| 84 | base | 17.0.1.3 | installed |
| 1148 | foo | <null> | installed |
+------+------+----------------+-----------+
test_17=> select * from ir_module_module_dependency where module_id=1148
+------+------+-----------+-----------------------+
| id | name | module_id | auto_install_required |
|------+------+-----------+-----------------------|
| 2468 | bar | 1148 | False |
| 2469 | baz | 1148 | False |
| 2470 | base | 1148 | False |
+------+------+-----------+-----------------------+
```
This later causes issues during the upgrade of the DB.
In this patch we reinstate the check for missing dependencies taking
into account only those that cannot be installed --i.e those that are
truly unknown to the ORM. The installation of such data modules with
wrong dependencies will now be blocked with a UserError.
See: odoo/odoo@234590f3
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#187626
Forward-Port-Of: odoo/odoo#187531**Issue:** An employee can't modify a `Payment Method` (other than "Manual" on a new payment entry). **Expected:** An employee should be able to change the payment provider to register a customer payment. **Steps to reproduce:** - Activate Accounting app and go to Configuration > Online Payments > Payment Providers; - Install any of these providers, configure it, activate the test mode and publish it; - Go to Customers Payments > Payments; - Open or create a payement record; - Try t
Original PR description
**Issue:** An employee can't modify a `Payment Method` (other than "Manual" on a new payment entry). **Expected:** An employee should be able to change the payment provider to register a customer payment. **Steps to reproduce:** - Activate Accounting app and go to Configuration > Online Payments > Payment Providers; - Install any of these providers, configure it, activate the test mode and publish it; - Go to Customers Payments > Payments; - Open or create a payement record; - Try to change the Payment Method field for . **Cause:** No rights have been given to users on the payment provider data lookup. https://github.com/odoo/odoo/blob/18.0/addons/payment/security/ir.model.access.csv **Fix:** Give temporary rights on payment provider token lookup. opw-4270781 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186890
Steps to reproduce: 1. Go to website --> forum 2. Click on "New Post," add a title/description, and post the question. 3. A pop-up appears --> close the pop-up. 4. Enter edit mode, resulting in a traceback. Before this fix, the `publicWidget` responsible for attaching the modal in DOM was bound to the `body` element, which led to the removal of the `body` on `widget_stop_request` when trying to open the editor. This commit addresses the issue by creating a dummy element to bind the `Fo
Original PR description
Steps to reproduce: 1. Go to website --> forum 2. Click on "New Post," add a title/description, and post the question. 3. A pop-up appears --> close the pop-up. 4. Enter edit mode, resulting in a traceback. Before this fix, the `publicWidget` responsible for attaching the modal in DOM was bound to the `body` element, which led to the removal of the `body` on `widget_stop_request` when trying to open the editor. This commit addresses the issue by creating a dummy element to bind the `ForumShare` publicWidget instead of the `body`, preventing its removal. Additionally, an event listener has been added to remove the modal from the DOM after it's closed, ensuring no further issues during the editor opening process. task-3834378 Forward-Port-Of: odoo/odoo#187577 Forward-Port-Of: odoo/odoo#181643
The function _validate_accounting_entries is notorious for not using proper batching which results in a lot of SQL queries. Originally, it had to iterate individual svls and invoke functions in an unbatched way, even when all svls belonged to the same product. The changes here are to use as much batching as possible and enforcing the use of prefetch_ids to lower the total number of queries. Benchmarks: |no. queries before| no. queries after | total time before | total time after| |-----|-
Original PR description
The function _validate_accounting_entries is notorious for not using proper batching which results in a lot of SQL queries. Originally, it had to iterate individual svls and invoke functions in an unbatched way, even when all svls belonged to the same product. The changes here are to use as much batching as possible and enforcing the use of prefetch_ids to lower the total number of queries. Benchmarks: |no. queries before| no. queries after | total time before | total time after| |-----|-----|------|-----| |95991|83352|1.59 min|1.48 min| opw-4283347 opw-4096108 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186434
Versions -------- - 17.4+ Steps ----- 1. Create a discount code with a free shipping reward with a max amount; 3. Create one or more shipping methods with a price higher than the max amount previously set; 4. in eCommerce, add a product to the cart, and go to checkout; 5. apply coupon; 6. open the express checkout form using Stripe 7. switch between shipping methods. Issue ----- The free shipping discount is not considered in the Express Checkout form. Cause ----- Commit 8e
Original PR description
Versions -------- - 17.4+ Steps ----- 1. Create a discount code with a free shipping reward with a max amount; 3. Create one or more shipping methods with a price higher than the max amount previously set; 4. in eCommerce, add a product to the cart, and go to checkout; 5. apply coupon; 6. open the express checkout form using Stripe 7. switch between shipping methods. Issue ----- The free shipping discount is not considered in the Express Checkout form. Cause ----- Commit 8e2b6ce accidentally removed `delivery_discount_minor_amount` from `_order_summary_values` (previously called `_update_website_sale_delivery_return`) introduced by commit c047cc8, preventing the express checkout to get the up to date value. Solution -------- Add `delivery_discount_minor_amount` back to `_order_summary_values`. opw-4204901 Forward-Port-Of: odoo/odoo#187450
Steps to reproduce the bug: - Create a storable product P1 - Go to the delivery method - Select the Standard delivery - Add this tracking link: “https://iel.co.th/tracking/?trackingNo=<shipmenttrackingnumber>” - Create a delivery for one unit of P1 - Go to the additional information: - carrier: Standard delivery - Tracking Reference: 1234 - Mark as todo - Click on the racking smartbutton Problem: The link is lowercase, so its become not valid (some URLs are CASE-s
Original PR description
Steps to reproduce the bug:
- Create a storable product P1
- Go to the delivery method
- Select the Standard delivery
- Add this tracking link: “https://iel.co.th/tracking/?trackingNo=<shipmenttrackingnumber>”
- Create a delivery for one unit of P1
- Go to the additional information:
- carrier: Standard delivery
- Tracking Reference: 1234
- Mark as todo
- Click on the racking smartbutton
Problem:
The link is lowercase, so its become not valid (some URLs are CASE-sensitiv)
opw-4296872
Forward-Port-Of: odoo/odoo#186818Partner was not created during import because `bank_details` was an iterator instead of a list/collection. So once it was consummed for the search, nothing was created. Moreover, this function is called in the context of a file import which may have a default journal_id which is not the same as the journal of the partner. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187583 Forward-Port-Of: odoo/odoo#187415
Original PR description
Partner was not created during import because `bank_details` was an iterator instead of a list/collection. So once it was consummed for the search, nothing was created. Moreover, this function is called in the context of a file import which may have a default journal_id which is not the same as the journal of the partner. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187583 Forward-Port-Of: odoo/odoo#187415
**Current behavior before PR:** When a user leaves a group chat from the Discuss sidebar, an `AccessError` occurs because `thread.delete()` is not called, allowing `thread.markAsFetched()` to run even though the user is no longer a member. **Desired behavior after PR is merged:** This commit resolves the issue by ensuring that no access error occurs when a non-admin user leaves a group chat. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Fo
Original PR description
**Current behavior before PR:** When a user leaves a group chat from the Discuss sidebar, an `AccessError` occurs because `thread.delete()` is not called, allowing `thread.markAsFetched()` to run even though the user is no longer a member. **Desired behavior after PR is merged:** This commit resolves the issue by ensuring that no access error occurs when a non-admin user leaves a group chat. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187170
Before this commit, a rtcSession was required to display the connection state. Which meant that the receiving end of a peer-to-peer offer was not displaying the connection state until the offer was received, which was hiding early connection issues (pre-offer) like missing bus messages. Forward-Port-Of: odoo/odoo#186788
Original PR description
Before this commit, a rtcSession was required to display the connection state. Which meant that the receiving end of a peer-to-peer offer was not displaying the connection state until the offer was received, which was hiding early connection issues (pre-offer) like missing bus messages. Forward-Port-Of: odoo/odoo#186788
**Steps:** - Create a new pricelist - Apply pricelist rules - For eg: Apply it on Acoustic Bloc Screen, with a fixed price of 20. - When seen on the shop page or product page, it shows a strikethrough price along with the original price - Same happens when we use formula instead of fixed price. **Changes:** Changed some test cases because currently, the pricelist had fixed price which was causing the strikethrough to not appear. But due to the code change, it will now not appear, hen
Original PR description
**Steps:** - Create a new pricelist - Apply pricelist rules - For eg: Apply it on Acoustic Bloc Screen, with a fixed price of 20. - When seen on the shop page or product page, it shows a…
**Steps:** - Create a new pricelist - Apply pricelist rules - For eg: Apply it on Acoustic Bloc Screen, with a fixed price of 20. - When seen on the shop page or product page, it shows a strikethrough price along with the original price - Same happens when we use formula instead of fixed price. **Changes:** Changed some test cases because currently, the pricelist had fixed price which was causing the strikethrough to not appear. But due to the code change, it will now not appear, hence giving the percentage price to the tour to run it smoothly. **Before this commit:** The strikethrough prices on the shop page were shown for all the pricelist rules **After this commit:** The strikethrough prices are now shown everywhere only if the pricelist rule is a 'discount'. Formula based discount rules strikethrough prices are also displayed on the shop/configurator and product pages, but not on the cart and subsequent steps of the checkout to allow customer to apply discounts while still keeping 'beautiful' prices. **Affected version:** saas-17.4~master opw-4181825 Forward-Port-Of: odoo/odoo#181014 Enterprise PR: odoo/enterprise#73993
The issue: Before this commit, the product was intended to be set as 'invoice on order', but this wasn't applied. The status was overridden due to the '_compute_invoice_policy' function override in the 'l10n_ke_edi_oscu_stock' module, which caused the test to fail on runbot when this module is installed. The fix: Put the product to 'invoice on order' before creating the sale order runbot-70731 Forward-Port-Of: odoo/odoo#187280
Original PR description
The issue: Before this commit, the product was intended to be set as 'invoice on order', but this wasn't applied. The status was overridden due to the '_compute_invoice_policy' function override in the 'l10n_ke_edi_oscu_stock' module, which caused the test to fail on runbot when this module is installed. The fix: Put the product to 'invoice on order' before creating the sale order runbot-70731 Forward-Port-Of: odoo/odoo#187280
In a previous commit: #151805, the goal was to add margin to the account invoice report. No negative margins were possible before because it didn't take the customer's credit notes. This is now fixed with this commit, that aims to add customer's credit note to margin calculations task-4167630 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186952 Forward-Port-Of: odoo/odoo#185498
Original PR description
In a previous commit: #151805, the goal was to add margin to the account invoice report. No negative margins were possible before because it didn't take the customer's credit notes. This is now fixed with this commit, that aims to add customer's credit note to margin calculations task-4167630 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186952 Forward-Port-Of: odoo/odoo#185498
### Issue: - When picking up a SO in POS, the discount on products sold with a non groupable UOM disappears. ### Steps to reproduce: - Create a SO in the sales app. - Include a product that has a UOM of which the uom category is not grouped in POS (g for example). - Add a discount to the product. - Pick up the order in POS. - Notice that the discount is not applied. ### Solution: - In `_onClickSaleOrder` I set the discount on the `splitted_line` before adding it to the orderline.
Original PR description
### Issue: - When picking up a SO in POS, the discount on products sold with a non groupable UOM disappears. ### Steps to reproduce: - Create a SO in the sales app. - Include a product that has a UOM of which the uom category is not grouped in POS (g for example). - Add a discount to the product. - Pick up the order in POS. - Notice that the discount is not applied. ### Solution: - In `_onClickSaleOrder` I set the discount on the `splitted_line` before adding it to the orderline. opw-4133659 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187441 Forward-Port-Of: odoo/odoo#185109
The dropdown selection for tracking/lot number is misaligned when the users has a rtl language. Steps to reproduce: ------------------- * Switch the current user to a rtl language (arabic for ex) * Open shop session * Select the drawer product > Observation: dropdown selection is misaligned Before vs after fix: ------------------------- RTL computer: * Before:  * After:  * After:  RTL mobile: * Before:  * After:  LTR computer: * Before:  * After:  LTR mobile * Before:  * After:  Also works if we move the popup around. opw-4187095 Forward-Port-Of: odoo/odoo#185878
Before this PR, query strings were added to the attachment of URL types. This is incorrect since those URLs can already have query strings, and the added query strings don't make sense for non-binary attachments. Forward-Port-Of: odoo/odoo#187580 Forward-Port-Of: odoo/odoo#187522
Original PR description
Before this PR, query strings were added to the attachment of URL types. This is incorrect since those URLs can already have query strings, and the added query strings don't make sense for non-binary attachments. Forward-Port-Of: odoo/odoo#187580 Forward-Port-Of: odoo/odoo#187522
Steps to reproduce: - Project app > Any project > ':' Menu > Burndown Chart - Add any custom filter > Click Add - Sticky Note 'Domain is invalid. Please corect it' The burndown chart view is dependent on groupby argument 'date', if you try to remove the groupby block from the search bar an error message will appear to stop you. This works properly when passing through `web_read_group` but here we take a slightly different path. When adding a custom domain to the search bar, we validate
Original PR description
Steps to reproduce: - Project app > Any project > ':' Menu > Burndown Chart - Add any custom filter > Click Add - Sticky Note 'Domain is invalid. Please corect it' The burndown chart view is…
Steps to reproduce: - Project app > Any project > ':' Menu > Burndown Chart - Add any custom filter > Click Add - Sticky Note 'Domain is invalid. Please corect it' The burndown chart view is dependent on groupby argument 'date', if you try to remove the groupby block from the search bar an error message will appear to stop you. This works properly when passing through `web_read_group` but here we take a slightly different path. When adding a custom domain to the search bar, we validate that domain by simulating an SQL query using said domain. This request is made independantly of `web_read_group` since it's not intended to be displayed, hence why we don't have the groupby argument. This causes the query building process to fail, so a default value is needed to restore the flow. Since we only want to validate the domain it does not matter what we put in so I used the default search value. opw-4300254 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186402
We have to await for `_initiatePaymentFlow()` completion to ensure we correctly got the result of the transaction route. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187618 Forward-Port-Of: odoo/odoo#187527
Original PR description
We have to await for `_initiatePaymentFlow()` completion to ensure we correctly got the result of the transaction route. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187618 Forward-Port-Of: odoo/odoo#187527
Step to reproduce. 1. Drag and drop a Contact Us Form 2. Select the form action as : " Apply for Job" 3. Select a field Type : "Activities" or "Kanban Stage" 4. Now on other field set visibility depending on this field 5. Now set the visibility options. -> Visibility value shows ID instead actual value/name. Prior to this commit, fields with conditional visibility showed the record's ID instead of its display name when the dependent field was a checkbox or radio button. This commit
Original PR description
Step to reproduce. 1. Drag and drop a Contact Us Form 2. Select the form action as : " Apply for Job" 3. Select a field Type : "Activities" or "Kanban Stage" 4. Now on other field set visibility depending on this field 5. Now set the visibility options. -> Visibility value shows ID instead actual value/name. Prior to this commit, fields with conditional visibility showed the record's ID instead of its display name when the dependent field was a checkbox or radio button. This commit fix the issue by displaying the displayName of the record instead ID. task-4267217 Forward-Port-Of: odoo/odoo#187030 Forward-Port-Of: odoo/odoo#184232
Problem: If the product image size is smaller than `$o-form-picture-size` or is an SVG without intrinsic size, it uses the original image size or displays as 0px in the case of SVGs without intrinsic size. The desired behavior is for the image to always display at `$o-form-picture-size`. Steps to reproduce: - Add a small or SVG image without intrinsic size to a product. - The image will not display correctly. opw-4119433 --- I confirm I have signed the CLA and read the PR guidelin
Original PR description
Problem: If the product image size is smaller than `$o-form-picture-size` or is an SVG without intrinsic size, it uses the original image size or displays as 0px in the case of SVGs without intrinsic size. The desired behavior is for the image to always display at `$o-form-picture-size`. Steps to reproduce: - Add a small or SVG image without intrinsic size to a product. - The image will not display correctly. opw-4119433 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178526
Currently, an exception was generated when the user tries to open their account details in the portal (url: my/account) error: `KeyError: 'partner_sudo'` This error was generated because when the user tries to open their account detail in the portal, we do not have 'partner_sudo'. Recentley refacto code with https://github.com/odoo/odoo/commit/453cfab758505ae15135703fb7be8bdb54981444 replaced `partner` with `partner_sudo` for the getting partner in the website sale address (`shop/addres
Original PR description
Currently, an exception was generated when the user tries to open their account details in the portal (url: my/account) error: `KeyError: 'partner_sudo'` This error was generated because when the…
Currently, an exception was generated when the user tries to open their account details in the portal (url: my/account) error: `KeyError: 'partner_sudo'` This error was generated because when the user tries to open their account detail in the portal, we do not have 'partner_sudo'. Recentley refacto code with https://github.com/odoo/odoo/commit/453cfab758505ae15135703fb7be8bdb54981444 replaced `partner` with `partner_sudo` for the getting partner in the website sale address (`shop/address`) and we have the new key because the template 'partner_info' called from template 'address' see [1] and `partner_sudo` set from [2] for address. But when we call the 'partner_info' from template 'portal_my_details_fields' at [3], we do not have `partner_sudo` This commit will fix the above issue by passing `partner_sudo` in the template at the time prepare value for opening account detail in portal. [1] - https://github.com/odoo/odoo/blob/3ea0c936c01a7c55ee8fa6ee64fd8e89b2a04f5f/addons/l10n_ar_website_sale/views/templates.xml#L60 [2] - https://github.com/odoo/odoo/blob/3ea0c936c01a7c55ee8fa6ee64fd8e89b2a04f5f/addons/website_sale/controllers/main.py#L1119 [3] - https://github.com/odoo/odoo/blob/3ea0c936c01a7c55ee8fa6ee64fd8e89b2a04f5f/addons/l10n_ar_website_sale/views/templates.xml#L68 sentry-5725856236 Forward-Port-Of: odoo/odoo#186872
Previously, the l10n_id_kode_transaksi field was invisible on the invoice form view. This is because the xpath was incorrectly done. This solution is inspired to what is already done in 18.0. Steps to reproduce: - Install l10n_id_efaktur - Select ID company - Create an Indonesian customer with a VAT number, and select boolean field PKP - Create an invoice, select this customer, and add a line with a tax -> the field below Customer has no display name, but the value is visible
Original PR description
Previously, the l10n_id_kode_transaksi field was invisible on the invoice form view. This is because the xpath was incorrectly done. This solution is inspired to what is already done in 18.0. Steps to reproduce: - Install l10n_id_efaktur - Select ID company - Create an Indonesian customer with a VAT number, and select boolean field PKP - Create an invoice, select this customer, and add a line with a tax -> the field below Customer has no display name, but the value is visible opw-4315901 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187294
Steps to reproduce: - In Website edit mode. - Drag and drop a "Text" block into the page. - Click on the first paragaph of the "Text" block. - click the "Insert media" button of the text toolbar. - A traceback occurs. The bug was introduced in commit [1], where we checked that "this.props.media" was not undefined before calling the "closest" function on it. However, this was incorrect because, in cases where "this.props.media" was false, the "closest" function was still called, causing
Original PR description
Steps to reproduce: - In Website edit mode. - Drag and drop a "Text" block into the page. - Click on the first paragaph of the "Text" block. - click the "Insert media" button of the text toolbar. - A…
Steps to reproduce: - In Website edit mode. - Drag and drop a "Text" block into the page. - Click on the first paragaph of the "Text" block. - click the "Insert media" button of the text toolbar. - A traceback occurs. The bug was introduced in commit [1], where we checked that "this.props.media" was not undefined before calling the "closest" function on it. However, this was incorrect because, in cases where "this.props.media" was false, the "closest" function was still called, causing the traceback. With this fix, the "closest" function is not called if "this.props.media" is false. [1]: https://github.com/odoo/odoo/commit/625c1aa71e17882848dd827f3be6162e49cbc8ca opw-4335833 opw-4328280 opw-4334279 opw-4328490 opw-4334012 opw-4332500 opw-4332028 opw-4332684 opw-4329687 opw-4331635 opw-4331371 opw-4331287 opw-4332437 opw-4331144 opw-4329646 opw-4328364 opw-4323197 opw-4325959 opw-4322945 Forward-Port-Of: odoo/odoo#187494 Forward-Port-Of: odoo/odoo#187406
Change field calling convention to support dynamic localization and language formatting. Currently, all fields are called with `t-out` instead of `t-field`, making them non-language or locale-sensitive, which results in a uniform format regardless of user preferences. Steps to produce: 1: installed l10n_din5008_sale 2: create a Quotation 3: Send it by email 4: Select DIN5008 in the template selector opw-4189869 Forward-Port-Of: odoo/odoo#181116
Original PR description
Change field calling convention to support dynamic localization and language formatting. Currently, all fields are called with `t-out` instead of `t-field`, making them non-language or locale-sensitive, which results in a uniform format regardless of user preferences. Steps to produce: 1: installed l10n_din5008_sale 2: create a Quotation 3: Send it by email 4: Select DIN5008 in the template selector opw-4189869 Forward-Port-Of: odoo/odoo#181116
Steps to reproduce: Install the app l10n_de and switch to a German company Create an invoice Send & Print the Invoice with XRechnung PDF and XML versions are stored as attachments in the record (Chatter). Try to delete them form the chatter. When deleting them, the unlink function only removes the link to account.move fields and saves the attachment with a new name: "document detached by user on date". This works fine for the PDF version but not for XML one. This is because `ir_attachmen
Original PR description
Steps to reproduce: Install the app l10n_de and switch to a German company Create an invoice Send & Print the Invoice with XRechnung PDF and XML versions are stored as attachments in the record (Chatter). Try to delete them form the chatter. When deleting them, the unlink function only removes the link to account.move fields and saves the attachment with a new name: "document detached by user on date". This works fine for the PDF version but not for XML one. This is because `ir_attachment.res_field` is set to `ubl_cii_xml_file` for XML version of the attachment, but when filtering to detach them the filter looks for `ir_attachment.res_field` that are set to `ubl_cii_xml_id`. opw-4273836 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186603
## Issue: After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we are able to submit the sign even before drawing anything, which will allow us to send the document "unsigned", since there will not be any sign. ## Steps to reproduce: 1. Get Sign module. 2. Upload any document to sign. 3. Add sign box and go to sign the document. 4. Now change from Auto to Dr
Original PR description
## Issue: After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we…
## Issue: After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we are able to submit the sign even before drawing anything, which will allow us to send the document "unsigned", since there will not be any sign. ## Steps to reproduce: 1. Get Sign module. 2. Upload any document to sign. 3. Add sign box and go to sign the document. 4. Now change from Auto to Draw. ## Solution: We should take into account that it makes sense that everytime we update if our signature is empty, we update the state of the buttons accordingly avoiding this way to be able to sign without an actual sing. The solution address a similar approach at what was already being done with the onChangeName, we move this logic to be handled by a specific function for this buttons 'handleButtonStateChange'. The fix is part of > [#61981](https://github.com/odoo/enterprise/pull/61981) opw-3874034 Forward-Port-Of: odoo/odoo#180103 Forward-Port-Of: odoo/odoo#164410
We've added tracking on some fields that are used to compute the cost of cars and also the serial number to know if it has been manually changed. When the value or the cost of the car change, we want to know who modified it and when it has been done. TASK-ID: 4306184 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187032
Original PR description
We've added tracking on some fields that are used to compute the cost of cars and also the serial number to know if it has been manually changed. When the value or the cost of the car change, we want to know who modified it and when it has been done. TASK-ID: 4306184 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187032
Problem: When creating a new e-commerce category, the breadcrumb displays "Unnamed" instead of the actual category name. This happens because the `parents_and_self` field is not recomputed when `parent_path` changes, despite the former depending on the latter. Solution: Ensure that `parents_and_self` is recomputed whenever `parent_path` is updated, so that the correct name is reflected in the breadcrumb. Steps to reproduce: - Open the form to create a new e-commerce category. - After s
Original PR description
Problem: When creating a new e-commerce category, the breadcrumb displays "Unnamed" instead of the actual category name. This happens because the `parents_and_self` field is not recomputed when `parent_path` changes, despite the former depending on the latter. Solution: Ensure that `parents_and_self` is recomputed whenever `parent_path` is updated, so that the correct name is reflected in the breadcrumb. Steps to reproduce: - Open the form to create a new e-commerce category. - After saving, the breadcrumb displays "Unnamed" instead of the actual category name. opw-4267144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186929 Forward-Port-Of: odoo/odoo#184423
Before this commit, a user was able to double click on check-in/check-out. To avoid that the pop-up will be automatically closed when the button will be clicked. task-4316077 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#186565
Original PR description
Before this commit, a user was able to double click on check-in/check-out. To avoid that the pop-up will be automatically closed when the button will be clicked. task-4316077 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#186565
As so_reference_type can be left empty on the payment.provider, we need to handle the case in the back end and effectively allow an empty payment reference. With no payment reference defined on the sale.order (field reference), we have the possibility to let the invoice define the payment reference itself (field payment_reference) which allows an easier reconciliation of payments and invoices. opw-4282903 Forward-Port-Of: odoo/odoo#187205
Original PR description
As so_reference_type can be left empty on the payment.provider, we need to handle the case in the back end and effectively allow an empty payment reference. With no payment reference defined on the sale.order (field reference), we have the possibility to let the invoice define the payment reference itself (field payment_reference) which allows an easier reconciliation of payments and invoices. opw-4282903 Forward-Port-Of: odoo/odoo#187205
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#187125 Forward-Port-Of: odoo/odoo#186755
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187125 Forward-Port-Of: odoo/odoo#186755
To reproduce: Go to Accounting/Invoicing, Customers and create a new Customer. Delete it. You get an error talking about audit trail while you don't have it activated. The issue is that we block based on customer/supplier rank when there is no company on the partner. We now check if we should block the deletion of a message of a partner if this partner has at least one journal entry with a company that has audit trail activated. --- I confirm I have signed the CLA and read the
Original PR description
To reproduce: Go to Accounting/Invoicing, Customers and create a new Customer. Delete it. You get an error talking about audit trail while you don't have it activated. The issue is that we block based on customer/supplier rank when there is no company on the partner. We now check if we should block the deletion of a message of a partner if this partner has at least one journal entry with a company that has audit trail activated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187151 Forward-Port-Of: odoo/odoo#181891
We have new coders --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186749
Original PR description
We have new coders --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186749
Product images are lazy-loaded on the cart page, causing them to be displayed later than the rest of the page. As a result, some parts of the page were shifted once the image was loaded (since the image had no size before loading). This change wraps the image in a fixed-size container to avoid the layout shift. Incidentally, this change also fixes some alignment issues when the cart contains images with various aspect ratios. opw-4029017 Forward-Port-Of: odoo/odoo#187297
Original PR description
Product images are lazy-loaded on the cart page, causing them to be displayed later than the rest of the page. As a result, some parts of the page were shifted once the image was loaded (since the image had no size before loading). This change wraps the image in a fixed-size container to avoid the layout shift. Incidentally, this change also fixes some alignment issues when the cart contains images with various aspect ratios. opw-4029017 Forward-Port-Of: odoo/odoo#187297
Steps to reproduce: - Sign app > Upload PDF > Add a 'Signature' field > Send > Cancel - In mailhog open the email > Click 'Sign Document' - Redirected to 404 as expected - Traceback '$(...).zoomOdoo is not a function' Original PR: https://github.com/odoo/odoo/pull/186241 JQuery is loaded twice, from `web.assets_frontend asset` (With zoomOdoo) and from `web.assets_frontend_lazy` (Without zoomOdoo). When redirecting to website 404 through a cancelled sign request we attempt to use zoomOd
Original PR description
Steps to reproduce: - Sign app > Upload PDF > Add a 'Signature' field > Send > Cancel - In mailhog open the email > Click 'Sign Document' - Redirected to 404 as expected - Traceback '$(...).zoomOdoo is not a function' Original PR: https://github.com/odoo/odoo/pull/186241 JQuery is loaded twice, from `web.assets_frontend asset` (With zoomOdoo) and from `web.assets_frontend_lazy` (Without zoomOdoo). When redirecting to website 404 through a cancelled sign request we attempt to use zoomOdoo with the latter causing this error. The option to cancel sign requests is available in saas-17.4 and above only. opw-4261794 Forward-Port-Of: odoo/enterprise#73375
Currently, An error occurs while opening a 'Production Analysis' report, and the module name `mrp_workorder` is not installed. Steps To Reproduced: - Install ```mrp_account_enterprise```. - Uninstall ```mrp_workorder```. - Open Manufacturing / Reporting / Production Analysis and an error is generated. ``` UndefinedColumn: column wc.employee_costs_hour does not exist LINE 248: * wc.employee_costs_hour * op.employee_ratio ``` An error occurs when the system tries to access fields
Original PR description
Currently, An error occurs while opening a 'Production Analysis' report, and the module name `mrp_workorder` is not installed. Steps To Reproduced: - Install ```mrp_account_enterprise```. - Uninstall…
Currently, An error occurs while opening a 'Production Analysis' report, and the module name `mrp_workorder` is not installed. Steps To Reproduced: - Install ```mrp_account_enterprise```. - Uninstall ```mrp_workorder```. - Open Manufacturing / Reporting / Production Analysis and an error is generated. ``` UndefinedColumn: column wc.employee_costs_hour does not exist LINE 248: * wc.employee_costs_hour * op.employee_ratio ``` An error occurs when the system tries to access fields like `employee_cost`, and `employee_costs_hour` at [1]. but it is unavailable as the module `mrp_workorder` has not been installed. These fields are defined in it. Link [1]: https://github.com/odoo/enterprise/blob/baba978bca701c589eb0d45527275b6275eec5c5/mrp_account_enterprise/reports/mrp_report.py#L206 To resolve this issue, Move the `_join_expected_component_cost_unit` method into bridge module `mrp_workorder_hr_account`, Additionally, Create dummy methods to provide a default value for fields([2]) that are not working and override these methods in the bridge module to return the correct values. Link [2]: https://github.com/odoo/enterprise/blob/baba978bca701c589eb0d45527275b6275eec5c5/mrp_account_enterprise/reports/mrp_report.py#L64-L78 Sentry-5794503324 Forward-Port-Of: odoo/enterprise#69559
Add `Bonus` input type to `United States Regular Pay Salary Structure`. Use `Expenses` and `Bonus` input types in the computation of payslips. * Expenses: * Allows users to include expenses (added automatically from the Expenses app) into the salary calculation when using the Structure Type "United States: Regular Pay". The rule is placed post taxes in the structure. * Bonus: * Add an Input type in "hr.payslip.input.type" called `Bonus`. * "Bonus" allows users to add an e
Original PR description
Add `Bonus` input type to `United States Regular Pay Salary Structure`.
Use `Expenses` and `Bonus` input types in the computation of payslips.
* Expenses:
* Allows users to include expenses (added automatically from the Expenses app) into the salary calculation when using the Structure Type "United States: Regular Pay". The rule is placed post taxes in the structure.
* Bonus:
* Add an Input type in "hr.payslip.input.type" called `Bonus`.
* "Bonus" allows users to add an extra source of income for employees that have associated the "United States: Regular Pay" Structure type in their payslip. The rule is placed pre-taxes in the structure, it is a taxable amount.
task-4097635
Forward-Port-Of: odoo/enterprise#68530task-4246523 Forward-Port-Of: odoo/enterprise#72701
Original PR description
task-4246523 Forward-Port-Of: odoo/enterprise#72701
This was forgotten in this bugfix : https://github.com/odoo/enterprise/commit/4d548d2240c85eebe004595cd65e0fbb6a76a39b We don't fix it before 17.4 because of this revert https://github.com/odoo/enterprise/pull/73495 Forward-Port-Of: odoo/enterprise#73496
Original PR description
This was forgotten in this bugfix : https://github.com/odoo/enterprise/commit/4d548d2240c85eebe004595cd65e0fbb6a76a39b We don't fix it before 17.4 because of this revert https://github.com/odoo/enterprise/pull/73495 Forward-Port-Of: odoo/enterprise#73496
Before this commit, amount_to_invoice was computed in the cron when the invoice was created as it depends on qty_invoiced. Unfortunately, the compute would be triggered and the ORM would try to write on the sale.order record at the same time than the cron would continue his job. it would end up with concurrent updates. This commit ensure that the compute method is inhibited during the cron and is triggered at the end of it. task 4216148 Forward-Port-Of: odoo/enterprise#708
Original PR description
Before this commit, amount_to_invoice was computed in the cron when the invoice was created as it depends on qty_invoiced. Unfortunately, the compute would be triggered and the ORM would try to write on the sale.order record at the same time than the cron would continue his job. it would end up with concurrent updates. This commit ensure that the compute method is inhibited during the cron and is triggered at the end of it. task 4216148 Forward-Port-Of: odoo/enterprise#70878
test_sync_pickings depends on street value, which does not exist in no-demo mode, thus breaking tests. This commit fixes the issue. [broken test](https://runbot.odoo.com/web#id=73283&view_type=form&model=runbot.build.error&menu_id=405&cids=1) Forward-Port-Of: odoo/enterprise#73041
Original PR description
test_sync_pickings depends on street value, which does not exist in no-demo mode, thus breaking tests. This commit fixes the issue. [broken test](https://runbot.odoo.com/web#id=73283&view_type=form&model=runbot.build.error&menu_id=405&cids=1) Forward-Port-Of: odoo/enterprise#73041
Forward-Port-Of: odoo/enterprise#73901
Original PR description
Forward-Port-Of: odoo/enterprise#73901
We have to await for `_initiatePaymentFlow()` completion to ensure we correctly got the result of the transaction route. Forward-Port-Of: odoo/enterprise#74023 Forward-Port-Of: odoo/enterprise#73974
Original PR description
We have to await for `_initiatePaymentFlow()` completion to ensure we correctly got the result of the transaction route. Forward-Port-Of: odoo/enterprise#74023 Forward-Port-Of: odoo/enterprise#73974
This commit uses the res.company env to check the value of the sign_invoice field instead of checking it directly through the related field. When uninstalling a module through res.config settings (i.e. unchecking the Partner Autocomplete box), this line will thrown an error if the uninstalled module had any fields on res.company. When using the related field, it tries to access a cached copy of the res.company record with field values that may have been modified, as opposed to browsing for the r
Original PR description
This commit uses the res.company env to check the value of the sign_invoice field instead of checking it directly through the related field. When uninstalling a module through res.config settings (i.e. unchecking the Partner Autocomplete box), this line will thrown an error if the uninstalled module had any fields on res.company. When using the related field, it tries to access a cached copy of the res.company record with field values that may have been modified, as opposed to browsing for the record directly which will be properly updated. Task-ID: 4107361 Forward-Port-Of: odoo/enterprise#68336
This commit fix some missing translations for the modelo349 tax report in spain. no-task Forward-Port-Of: odoo/enterprise#73850
Original PR description
This commit fix some missing translations for the modelo349 tax report in spain. no-task Forward-Port-Of: odoo/enterprise#73850
## Issue: After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we are able to submit the sign even before drawing anything, which will allow us to send the document "unsigned", since there will not be any sign. ## Steps to reproduce: 1. Get Sign module. 2. Upload any document to sign. 3. Add sign box and go to sign the document. 4. Now change from Auto to Dr
Original PR description
## Issue: After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we…
## Issue: After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we are able to submit the sign even before drawing anything, which will allow us to send the document "unsigned", since there will not be any sign. ## Steps to reproduce: 1. Get Sign module. 2. Upload any document to sign. 3. Add sign box and go to sign the document. 4. Now change from Auto to Draw. ## Solution: We should take into account that it makes sense that everytime we update if our signature is empty, we update the state of the buttons accordingly avoiding this way to be able to sign without an actual sing. The solution address a similar approach at what was already being done with the onChangeName, we move this logic to be handled by a specific function for this buttons 'handleButtonStateChange'. The fix is part of > [#164410](https://github.com/odoo/odoo/pull/164410) opw-3874034 Forward-Port-Of: odoo/enterprise#69975 Forward-Port-Of: odoo/enterprise#61981
The medical assistance work entry should be behaving like the credit-time and should have the same DMFA code. Task: 4247631 Forward-Port-Of: odoo/enterprise#73674 Forward-Port-Of: odoo/enterprise#71872
Original PR description
The medical assistance work entry should be behaving like the credit-time and should have the same DMFA code. Task: 4247631 Forward-Port-Of: odoo/enterprise#73674 Forward-Port-Of: odoo/enterprise#71872
We've added tracking on some fields that are used to compute the cost of cars to know if it has been manually changed. When the value or the cost of the car change, we want to know who modified it and when it has been done. TASK-ID: 4306184 Forward-Port-Of: odoo/enterprise#73718
Original PR description
We've added tracking on some fields that are used to compute the cost of cars to know if it has been manually changed. When the value or the cost of the car change, we want to know who modified it and when it has been done. TASK-ID: 4306184 Forward-Port-Of: odoo/enterprise#73718
To reproduce: - Enable card provider (ex. "Demo" provider from `payment_demo`) - Go to website /shop - Add a subscription product to the cart - To go cart and click on "Checkout" - On the payment, chose the card payment method and check the option: "Automate payments for the linked subscriptions" - Click on "Pay Now" Here a request is made to /shop/undefined instead of the expect transaction route This commit ensure we only overwrite the default transation route by the sub
Original PR description
To reproduce: - Enable card provider (ex. "Demo" provider from `payment_demo`) - Go to website /shop - Add a subscription product to the cart - To go cart and click on "Checkout" - On the payment, chose the card payment method and check the option: "Automate payments for the linked subscriptions" - Click on "Pay Now" Here a request is made to /shop/undefined instead of the expect transaction route This commit ensure we only overwrite the default transation route by the subscription one only if it's set (from invoice portal controller) Forward-Port-Of: odoo/enterprise#73887
We only need to shown MX EDI fields for move/invoices related to a company where fiscal country is Mexico, hide it for other companies. Forward-Port-Of: odoo/enterprise#73848 Forward-Port-Of: odoo/enterprise#73623
Original PR description
We only need to shown MX EDI fields for move/invoices related to a company where fiscal country is Mexico, hide it for other companies. Forward-Port-Of: odoo/enterprise#73848 Forward-Port-Of: odoo/enterprise#73623
When uploading a CFDI XML invoice containing the `InformacionGlobal` element, the system fails to parse the document correctly and displays an error message. ### Steps to Reproduce 1. Install the `l10n_mx_edi` module. 2. Create a blank invoice. 3. Add a CFDI XML file containing an `InformacionGlobal` as an attachment to the invoice. (You can use the file `enterprise/l10n_mx_edi/tests/test_files/test_global_invoice_year_month_format.xml` for testing.) The chatter displays the following
Original PR description
When uploading a CFDI XML invoice containing the `InformacionGlobal` element, the system fails to parse the document correctly and displays an error message. ### Steps to Reproduce 1. Install the…
When uploading a CFDI XML invoice containing the `InformacionGlobal` element, the system fails to parse the document correctly and displays an error message. ### Steps to Reproduce 1. Install the `l10n_mx_edi` module. 2. Create a blank invoice. 3. Add a CFDI XML file containing an `InformacionGlobal` as an attachment to the invoice. (You can use the file `enterprise/l10n_mx_edi/tests/test_files/test_global_invoice_year_month_format.xml` for testing.) The chatter displays the following error: Error importing attachment 'xml_file_name.xml' as invoice (decoder=_l10n_mx_edi_import_cfdi_invoice) ### Cause The `InformacionGlobal` element in the XML requires an `Año` attribute (note the special character `ñ`). Correct encoding is crucial here to handle special characters accurately. When the XML file is first uploaded, it is parsed with the correct encoding. However, during processing, the XML is converted back to a string, losing its original encoding in the process. This causes issues with special characters like `ñ`, which can no longer be read correctly by the system, resulting in a parsing error. opw-4226968 Forward-Port-Of: odoo/enterprise#73726