Monday, May 19, 2025
52 changes · 18.0
Enhancements to existing features
Payment status updates will now be recorded in the activity history, making it easier for users to see when a payment moves between states. This improves transparency and auditability for accounting teams without changing the payment workflow.
Original PR description
Add a tracking flag to the payments state to be logged into the chatter. task-4531618 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Calendar attendee processing has been optimized to handle large calendar syncs much faster. This can significantly reduce setup or synchronization time for services like Google Calendar, improving the user experience for calendars with many events.
Original PR description
This change uses python set subtraction over recordset \_\_sub\_\_ on calendar.attendees. Before this change, when doing a large calendar synchronization such as setting up Google Calendar, notified_attendees could be a large recordset of calendar.attendees. When performing a recordset subtraction in _notify_attendees, this uses \_\_sub\_\_ and browse multiple times. Synchronizing around 5000 events took about ~350 seconds (on my own calendar data), where _notify_attendees took ~313 seconds (83%). After this change, _notify_attendees takes ~1 second operating on the same synchronization. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Shipping and invoicing addresses now have clearer spacing when shown together on several business reports. This makes printed and shared documents easier to read and helps avoid confusion between delivery and billing details.
Original PR description
*: account,l10n_hu_edi,l10n_sa,purchase,purchase_stock,sale When a Shipping Address is displayed inside the `information_block` there is no spacing to differentiate it from the Invoicing Address, making it harder to read. The `:` character is inconsistent with other reports, but will be removed in the master forward port to avoid overriding stable translation. task-4730464 Enterprise PR: https://github.com/odoo/enterprise/pull/84281 | Issue solved in this PR | |--------| | | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
When using shiplater in PoS and creating a backorder from the original picking, the COGS would be duplicated when validating the backorder. Steps to reproduce: ------------------- * Create 2 products, one with a cost of 20 and one with a cost of 0 * Create a PoS order with 2 lines, one for each product * Validate the order using the shiplater option * Close the session and go to the picking created * Validate the delivery only for the product with a cost of 20 and make a backorder for t
Original PR description
When using shiplater in PoS and creating a backorder from the original picking, the COGS would be duplicated when validating the backorder. Steps to reproduce: ------------------- * Create 2…
When using shiplater in PoS and creating a backorder from the original picking, the COGS would be duplicated when validating the backorder. Steps to reproduce: ------------------- * Create 2 products, one with a cost of 20 and one with a cost of 0 * Create a PoS order with 2 lines, one for each product * Validate the order using the shiplater option * Close the session and go to the picking created * Validate the delivery only for the product with a cost of 20 and make a backorder for the product with a cost of 0 * Go to the session accounting entries and check the COGS entries, you should see one entry for the product we just processed * Validate the backorder > Observation: A second COGS entry is created for the product with a cost of 20 Why the fix: ------------ Instead of creating the COGS entries based on the PoS order lines, we now create them based on the stock move lines. This way, we only create the COGS entries for the stock move lines that are actually processed. We also avoid creating COGS entries for the stock move lines that have no cost. opw-4597430 Forward-Port-Of: odoo/odoo#209961 Forward-Port-Of: odoo/odoo#207075
This fix restores access to the Attendance app for users who can manage employee records but are not attendance administrators. It corrects a missing permission update so attendance officers can perform their expected work without being blocked.
Original PR description
Attendance module was inaccessible for users that had access to employee records, but were not attendance admins. This was due to [this](https://github.com/odoo/odoo/pull/205031/commits/ef423640c4e2402509eafc6aa8696e33dacf51ea) backported change that did not also backport the access right change for the attendance_manager_id field. opw-4750765
The online shop checkout flow was adjusted so customers are always sent to the main checkout step first, even when extra invoicing information may be needed. This prevents routing issues caused by related Enterprise changes and keeps the purchase process consistent.
Original PR description
- Remove _get_extra_billing_info_route method, as it is unnecessary. The user should always be redirected to the checkout step first, regardless of the existence of an invoicing info step. Enterprise PR: https://github.com/odoo/enterprise/pull/85094 opw-4738797 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in Time Off reporting where selecting a leave record could incorrectly open an allocation record instead. The report now keeps leave and allocation data aligned, helping users review time off details accurately.
Original PR description
### Steps to reproduce: - Navigate to Time off app -> Reporting -> By type - Access any leave record - Notice it will open an allocation record form ### Cause: This is happening as the query we are using to fetch hr.leave.report is not ordered correctly when it comes to fetching the columns. https://github.com/odoo/odoo/blob/c0f3bff835cc8dbe63d5369de43c76e83ca0018e/addons/hr_holidays/report/hr_leave_report.py#L51-L53 https://github.com/odoo/odoo/blob/c0f3bff835cc8dbe63d5369de43c76e83ca0018e/addons/hr_holidays/report/hr_leave_report.py#L68-L70 in those two sub-queries the order of fetching the allocation_id and leave_id is not the same which cause that leave_id column will be always null and every id value -either leave_id or allocation_id- will be stored in allocation_id column. ### Fix: Since columns' order matter when fetching sub-queries we unified the order in both queries. opw-4723952
This fixes an issue where generated foreign VAT taxes could miss required transition accounts in multi-VAT company setups. It helps ensure cash basis taxes are created consistently, company settings are updated correctly, and related accounts can be reconciled for smoother accounting operations.
Original PR description
To reproduce the issue: 1) Create a Belgian company, with CoA installed 2) Make a foreign VAT fiscal position in France for this company 3) Click on the button in the fiscal position's banner to…
To reproduce the issue: 1) Create a Belgian company, with CoA installed 2) Make a foreign VAT fiscal position in France for this company 3) Click on the button in the fiscal position's banner to generate the French taxes => Some of the generated taxes are cash basis. All of them should have a transition account, but it's not the case (some have, some haven't). This is due to the fact 0% cash basis taxes exist in France, and they are treated before some other taxes due to the order we declare them in in the csv. When creating those 0% taxes, the transition account had to be mapped. Since Belgium does not have any cash basis taxe, we relied on the first account used in the tax repartition of the tax to convert. However, those 0% taxes obviously had no account there (since they're 0% anyway), so we ended up not entering this condition https://github.com/odoo/odoo/blob/18.0/addons/account/models/chart_template.py#L970 and mapping the transition account to None. Because of that, we did not create any equivalent for that account, for any of the taxes using it. This commit solves that by sorting the tax templates to first treat those with accounts in their tax repartition. We also fix here the fact that instantiating such cash basis taxes did not enable the "cash basis" setting on the company ; which didn't make any sense, and caused an error message when trying to edit the settings afterwards.
Automatic checkout now accounts for scheduled lunch breaks when determining the end of a workday. This prevents employees from being checked out too early and helps recorded hours match expected schedule hours, including two-week calendar setups.
Original PR description
**Issue** For example, in the case of a working schedule from 8:00 to 17:00 with a 1 hour lunch period, 8 hours of work are expected. By taking the lunch interval into account, the auto check out will happen at 17:00 if the company's tolerance in the attendance's setting is set at 0. Previously, it would happen at 16:00, resulting in only 7 worked hours for the attendance while the user may expect the attendance's worked hours to match the expected working hours of the schedule. **Solution** - include lunch attendances (not taken into account by `duration_hours`) in the total time that needs to be exceeded before an `hr.attendance` is automatically checked out. Note that this solution manages the case where `hr.attendance` are outside lunch periods (e.g. 8-12 and 13-17, but no attendance between 12-13). Though in that case, the automatic check out will be delayed by at least 1h. Note: a change was also made to account for 2 weeks calendars. opw-4402321
This fixes an issue where pasting text in the HTML editor could make the page scroll unexpectedly, even when the cursor was already visible. The editor now better detects the selected area and only scrolls when needed, improving editing comfort for users working with long content.
Original PR description
Problem:
In case of programmatic selection change (e.g., on paste), the selection may be set on an invisible range, like:
`setSelection({anchorNode: <div>, anchorOffset: 1});` This case was not properly handled by the `scrollToSelection` function.
Solution:
When encountering an invisible collapsed range, use the `anchorNode`'s closest element to calculate offset and perform scrolling. This prevents unnecessary scrolling when the selection is already inside the viewport and within an element.
Steps to reproduce:
1. Add enough text to make the editable area scrollable.
2. Insert a list (any type).
3. Copy some text and paste it into the last list element. → Even if the selection is in the viewport, it still scrolls
incorrectly.
opw-4745939
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prA bug in Point of Sale local storage prevented updates to existing records from being saved properly. This fix ensures changes made while using the local database are retained, improving reliability for store operations.
Original PR description
After commit https://github.com/odoo/odoo/commit/692992a25dc8f583ef70517088ec963a8d30802b, updates to existing records in indexedDB were not properly saved due to incorrect logic. As a result, changes to records were not persisted in the local database. This commit corrects the update logic to ensure that modifications to existing records are correctly saved in indexedDB. opw-4802025 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue in the HTML editor where selecting all content inside a table cell with the mouse did not select the cell itself. This makes table editing more predictable and reduces frustration when working with complex cell content.
Original PR description
### Approach: - When the entire content of a single table cell is selected, store the `ev.clientX` value once the cell content is fully selected. Afterward, if the mouse moves in the direction of the selection (left or right) by a sensitivity threshold of 5px, the entire cell is selected. ### Steps to Reproduce: - Create a table (e.g., using /table). - Add multiple blocks with varying text lengths inside a cell. - Try selecting all the content inside the cell using the mouse. - Observe that the cell does not get selected. ### Description of the issue/feature this PR addresses: - The cell does not get selected when all content inside the cell is selected with the mouse. ### Desired behavior after PR is merged: - The entire cell is selected when the content is fully selected. task-4743170 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue on the online shop page where the add-to-cart confirmation pop-up could appear off-screen after a customer scrolled down. Customers now see the confirmation immediately, reducing confusion during shopping.
Original PR description
The issue is only reproducible from version 18.0 onwards, even if the `position-absolute` class still exists in earlier versions because the regression was introduced by…
The issue is only reproducible from version 18.0 onwards, even if the `position-absolute` class still exists in earlier versions because the regression was introduced by [[1]](https://github.com/odoo/odoo/commit/189a7c96e6e26825dc05c0c6466576fe63aa091e), where the scroll handling was moved out of `div#wrapwrap`, which inadvertently affected the positioning of notifications. Steps to Reproduce: - Install `website_sale` and enable the 'Add to Cart' button from the website editor on the `/shop` page - Navigate to the shop page and scroll to the last product - Add the last product to the cart - The pop-up does not appear unless you scroll back up Issue: - The add to cart pop-up is not visible when the user is scrolled down on the page Root cause: - The CSS class `position-absolute` restricts the pop-up to a specific location in the scrollable content Fix: - Replace `position-absolute` with `position-fixed` to keep the pop-up visible regardless of scroll position opw-4686886 Affected version - 18.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Attendance officers without manager access were incorrectly blocked from opening the Attendance app. This fix updates the access setup so officers can enter the app while still only seeing the employee records they are allowed to manage.
Original PR description
**Problem** Users in the `hr_attendance.group_hr_attendance_officer` group are blocked from opening the Attendance app when they lack the manager role. **Steps to reproduce** - Remove…
**Problem** Users in the `hr_attendance.group_hr_attendance_officer` group are blocked from opening the Attendance app when they lack the manager role. **Steps to reproduce** - Remove `hr_attendance.group_hr_attendance_manager` from your user. - Add `hr_attendance.group_hr_attendance_officer`. - Open the Attendance app: access is denied. **Cause** The method [read_group_employee_id](https://github.com/odoo/odoo/blob/cd428bd75b63f96c67942be5457d0afdb00d29b0/addons/hr_attendance/models/hr_attendance.py#L672) applies a domain on attendance_manager_id, which incorrectly prevents officers from passing the check. **Solution** Switch the group on the attendance_manager_id field in hr_employee.py so that officers aren’t inadvertently blocked. Officers will still be restricted from reading records they don’t manage. 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 HTML editor color picker now remembers the custom color a user just applied when they move between tabs. This avoids confusion and helps users continue formatting content consistently without reselecting the same color.
Original PR description
**Current behaviour before PR:** Steps to reproduce: - Select a text, open color selector. - Switch to custom tab. - Apply any custom color. - Switch to any other tab without closing color selector. - Switch back to the custom color tab. - Selected default color in colorpicker is old one rather than applied one. **Desired behaviour after PR is merged:** Applied custom color should be selected by default when switching back to custom tab. task-4737027 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The portal invitation email template now uses the contact’s partner details instead of relying on incomplete portal user information. This prevents an error when previewing the invite email and ensures the recipient name displays properly.
Original PR description
[FIX] portal: display template for portal invite Steps to reproduce: ---- - Install portal module - Grant a portal access to a contact - Go to the email template (Portal: User Invite) for the contact - Click on Preview -> Traceback Issue: --- The display was based on the user itself referencing to a partner. And there was no name for the portal users. Fix: --- Changed the view so now the different values are based on the partner.Also added the name to this function based on the partner name. opw-4444729
The web code editor can now reopen with the cursor placed where editing previously started. This helps users continue work smoothly after saving or reloading edited content, reducing friction in workflows that require the editor to restart.
Original PR description
Before this commit it was not possible to start the Ace editor (via its owl wrapper codeEditor) with an initial cursor position. After this commit it is now possible to do just that. This comes handy in the use case where: - one makes modification on the edited resource. - saves the result. This could mean that the codeEditor must be restarted from scratch (reloading all the data) - functionally stay on the saved resource at the right position. Note that the onChange call back now received the position at which the edition *started*. 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
Website forms that create project tasks no longer fail when the optional Full Name field is removed and the submitted email is not already known. This prevents errors for visitors using simplified contact forms and helps teams continue receiving task requests reliably.
Original PR description
Scenario: - add a form with studio - change its action to "Create a Task" - delete the field "Full Name" - send the form with an unknown email Result: an error happens Cause: if the email does not find a user, the code expects the partner_name to always be present, even if it is an optional field. Fix: make the code work without partner_name field. opw-4773357
This fix prevents an error when users open accrued expense entries from purchase orders that include down payments. Down payment lines are now handled correctly, so accounting workflows can continue without a traceback.
Original PR description
When user tries to open accrued expense entry in purchase order, A traceback will appear. Steps to reproduce the error: - Install ``accountant`` and ``purchase`` module - Create a new Bill > Add a line > Don't add a product > Save > Purchase matching > Select your bill > Add to PO > Add Down Payment > New PO will be created - Actions > Accrued Expense Entry Traceback: ``` AssertionError: precision_rounding must be positive, got 0.0 ``` https://github.com/odoo/odoo/blob/834eff6e770280e911bb99e2abab4ea42d4ca8ff/addons/account/wizard/accrued_orders.py#L170 Here, when ``is_purchase`` is true, ``is_downpayment`` will not be evaluated. As a result, down payment lines in purchase orders are not excluded. Since down payment lines do not have a ``product_uom``. so ``rounding`` will be 0.0 So, it will lead to the above traceback. sentry-6576645089 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a test setup issue in the Indonesian Point of Sale module by using the right user permissions when creating POS records. It helps keep automated nightly checks stable without changing day-to-day business behavior.
Original PR description
- creating pos config and payment method requires pos admin (or sudo) - creating a pos order requires pos user Blows up during nightly single app tests. https://runbot.odoo.com/odoo/error/223001
Cypriot companies invoicing EU businesses with a valid VAT number will now automatically apply a 0% tax rate instead of 19%. This helps invoices comply with EU VAT rules and reduces the need for manual tax corrections.
Original PR description
Current behavior before PR: - When a Cyprian company invoiced another EU company with a valid VAT number, the 19% EU code was applied. But legally, as Cyprus is in the EU, the applicable tax rate should be 0%. Desired behavior after PR is merged: - The tax rate is now automatically 0% when invoicing a EU company Link to task: - https://www.odoo.com/odoo/project/967/tasks/4488340 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers can now confirm eCommerce orders from the portal when online payment is disabled but online signature is enabled. This restores a missing confirmation path while still preventing signatures from bypassing required online payments.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Go to Sales settings; 2. ensure Online Signature is enabled; 3. disable Online Payment; 4. create an order via eCommerce; 5. go to portal preview. Issue ----- No sign and/or pay button that would allow the customer to confirm their order. Cause ----- Commit 880cd7a516147 disabled signatures for all eCommerce orders, as it could lead to customers getting an email to sign the quote, confirming the order, and triggering delivery without payment. As a consequence, with online payment disabled, there's no longer a way for customers to confirm their order. Solution -------- Disable signatures for eCommerce orders if online payment is enabled. opw-4739013
Guest shoppers using Mexican or Chilean e-invoicing checkout flows are now sent to the normal checkout step after submitting their address. This prevents them from being pushed directly to invoicing details too early, making checkout clearer and less likely to cause confusion or abandonment.
Original PR description
*= mx/cl Steps to reproduce: 1.Set the website's company to Mexico or Chile. 2.As a guest user, add any deliverable product to the cart. 3.In the address form, select Mexico or Chile as the country. 4.Submit the address form. Issue: - The user is redirected directly to the invoicing info step, skipping the checkout step. Cause: - When submitting the address form, if the address type is 'billing' and the invoicing info step is available, the flow redirects there immediately. Fix: - Removed the _get_extra_billing_info_route method, as it is unnecessary. The user should always be redirected to the checkout step first, regardless of the existence of an invoicing info step. See also: - https://github.com/odoo/odoo/pull/209221 opw-4738797
Batch payments now show clearer status information, only validate payments that are actually in process, and record when payments are added to or removed from a batch. SEPA mandate collection and paid invoice counters now include the right payments and hide empty buttons, helping users avoid misleading totals and errors.
Original PR description
* Hide smart buttons when there are no elements and include `in process` payments to the collections smart button. * Consider all payments linked to a mandate as Collections not only the ones have journal entries * Log in the payment chatter the inclusion/exclusion of the payment in a batch. * Validate only in process payments task-4531618
Rental order reports now add clearer spacing between invoicing and shipping addresses. This makes printed or shared reports easier to read when both addresses are shown.
Original PR description
Follow the changes made in community commit. When a Shipping Address is displayed inside the `information_block` there is no spacing to differentiate it from the Invoicing Address, making it harder to read. Note: there are leftovers `:` characters that will be removed on master forwardport to avoid wiping existing translation on stable (not worth) task-4730464 Community PR: https://github.com/odoo/odoo/pull/207725
The loan accounting app now handles missing demo data more safely during installation. This prevents an installation crash in cases where accounting demo data is present but loan demo data cannot be loaded, improving setup reliability.
Original PR description
Prior to this change, if the demo data were loaded for account but couldn't be for account_loans, its installation would simply crash trying to reference an unknown xml_id 'account_loans_loan_demo1'. opw-4790398 upg-2793930
This fixes an automated field service test that could fail when customer search suggestions loaded too slowly or in the wrong order. The change helps keep validation runs reliable, reducing false failures during quality checks without changing normal user behavior.
Original PR description
The tours fails because when we edit the value in the input field of customer it clicks on the field and then fills out the value and then a change event is propagated and text based autocomplete results are shown (and m2o fields with partner autocomplete wizard are a tad bit slower), after that tours moves to next step and the new result dropdown menu is not loaded and it gets its reference from older menu which got closed in between and tries click it and no change is reflected but the new menu is not closed and tour continues to industry_fsm_report where we create a worksheet from a many2one field using create and edit so we click on the m2o input and wait for options but as partner field loaded dropdown is loaded it clicks on click and edit trying to create a new partner and opening thus fails the tour. Fix: - After entering the text to instantly load the dropdown by clicking on it and give time for loading of menu. task-4800194
The web_studio report editor now keeps the user's cursor near their last edit after saving and reloading XML content. This avoids sending users back to the top of the editor, making repeated edits less disruptive.
Original PR description
…ve and reload sources In the reportEditor edit the xml, modify a view's arch and save. Before this commit, the cursor position in the XMLEditor was reset to [0,0]. After this commit, we restore the position of the cursor according to the start position of the last edition. opw-4745895
Before this commit, resizing columns in list views when being in right-to-left didn't work as expected: when resizing a column, the column was resized in the opposite direction. This commit makes it work. opw~4782197 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#210516 Forward-Port-Of: odo
Original PR description
Before this commit, resizing columns in list views when being in right-to-left didn't work as expected: when resizing a column, the column was resized in the opposite direction. This commit makes it work. opw~4782197 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#210516 Forward-Port-Of: odoo/odoo#210290
This commit adds translations for Luxembourg VAT report in the official languages of Luxembourg. The translation is added for languages Luxembourgish, German, and French. task-4717339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208673
Original PR description
This commit adds translations for Luxembourg VAT report in the official languages of Luxembourg. The translation is added for languages Luxembourgish, German, and French. task-4717339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208673
In list views, we have a custom logic for column widths which aims at optimizing as much as possible the available space, and freezing the table such that it doesn't flicker upon user interaction (like editing, adding records, browsing through pages...). This logic defines, for some field types, the exact width that values need to be properly displayed, especially for dates and datetimes for which we know upfront the format, i.e. the length of values. However, before this commit, the logic
Original PR description
In list views, we have a custom logic for column widths which aims at optimizing as much as possible the available space, and freezing the table such that it doesn't flicker upon user interaction…
In list views, we have a custom logic for column widths which aims at optimizing as much as possible the available space, and freezing the table such that it doesn't flicker upon user interaction (like editing, adding records, browsing through pages...). This logic defines, for some field types, the exact width that values need to be properly displayed, especially for dates and datetimes for which we know upfront the format, i.e. the length of values. However, before this commit, the logic was incorrect. It didn't take into the account the fact that date and time formats are language dependant. It assumed that the required space for the english formats (+ a bit of security margin) was enough. Moreover, the fonts may obviously has an impact as well (some fonts requiring more space to display the same text, than others). As a consequence, on macos and, for instance, in deutch, date and datetime values were trimmed, which is something we never want: dates and datetimes should always be fully displayed. This is even worse in some languages, like arabic, basque or chinese, in which the month and/or the day of week is displayed in letters. This commit comes with a more elaborated solution to deal with those variable date and time formats + fonts. We no longer hardcode the ideal widths of dates and datetimes, but instead compute it (lazily) once, by rendering values in the DOM. This commit also improves the datetime and daterange cases with option "show_time" set to false: in that case, we know those fields only require the width of date values, not datetime, so we can shrink their columns. Task~4801116 Forward-Port-Of: odoo/odoo#210300
1. Install `l10n_it_stock_ddt` (Accounting, Sales, Italian localization, Italian delivery slip) 2. Create an invoice with one or more products 3. Set the quantity on the order lines to a relatively high value, like 200 4. Set the unit price to include decimal values so that rounding becomes relevant 5. Confirm the invoice. 6. Click on the delivery smart button. 7. Click on Validate > Print. The total for each product line and the overall total should be correctly calculated as the unit
Original PR description
1. Install `l10n_it_stock_ddt` (Accounting, Sales, Italian localization, Italian delivery slip) 2. Create an invoice with one or more products 3. Set the quantity on the order lines to a relatively high value, like 200 4. Set the unit price to include decimal values so that rounding becomes relevant 5. Confirm the invoice. 6. Click on the delivery smart button. 7. Click on Validate > Print. The total for each product line and the overall total should be correctly calculated as the unit price multiplied by the quantity, then the tax must be added. Doing this in incorrect order, can result in discrepancies per unit due to the rounding being done before applying the tax, and that becomes significant when a large number of items is sold. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4666634) opw-4666634 Forward-Port-Of: odoo/odoo#204531
When sending a combo to a preparation printer, the combo items where not indented correctly. This was leading to a preparation ticket that made it look like all items were normal items, instead of being part of a combo. Steps to reproduce: ------------------- * Create a combo product A * Setup a kitchen printer in the PoS * Open PoS and add the combo product A * Send the order to the kitchen printer > Observation: The preparation ticket does not show the combo items > indented correctl
Original PR description
When sending a combo to a preparation printer, the combo items where not indented correctly. This was leading to a preparation ticket that made it look like all items were normal items, instead of being part of a combo. Steps to reproduce: ------------------- * Create a combo product A * Setup a kitchen printer in the PoS * Open PoS and add the combo product A * Send the order to the kitchen printer > Observation: The preparation ticket does not show the combo items > indented correctly Why the fix: ------------ We add a new fields in the `changes` that state if the line is part of a combo. If it is part of a combo, we add a css class that will indent the line accordingly. opw-4459211 Forward-Port-Of: odoo/odoo#207277 Forward-Port-Of: odoo/odoo#196397
Versions -------- - 17.0+ Steps ----- 1. Have a company partner with a credit limit; 2. add an employee partner to the company; 3. create a sales order for the employee; 4. have the total amount exceed the credit limit; 5. confirm order; 6. create a copy. Issue ----- The credit warning isn't updated with the new order's amount. Cause ----- The `credit` field gets computed on the `commercial_partner_id` while `credit_to_invoice` gets computed on the current partner. Solut
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a company partner with a credit limit; 2. add an employee partner to the company; 3. create a sales order for the employee; 4. have the total amount exceed the credit limit; 5. confirm order; 6. create a copy. Issue ----- The credit warning isn't updated with the new order's amount. Cause ----- The `credit` field gets computed on the `commercial_partner_id` while `credit_to_invoice` gets computed on the current partner. Solution -------- Compute the `credit_to_invoice` on the `commercial_partner_id`. Also, search sales orders on `partner_invoice_id` instead of `partner_id` to compute `credit_to_invoice`. opw-4654476 Forward-Port-Of: odoo/odoo#210177
Scheduling a custom activity plan on a single record should do a `soft_reload` of the current view in order to avoid breadcrumbs pollution. The most frequent use case for that action is scheduling a plan from the chatter of the form view of a record, and retriggering an unnamed default form act_window would only restrict possible operations for the user. After this commit, the current view will be reloaded and the user will most probably be able to see its enabled plan in the chatter. t
Original PR description
Scheduling a custom activity plan on a single record should do a `soft_reload` of the current view in order to avoid breadcrumbs pollution. The most frequent use case for that action is scheduling a plan from the chatter of the form view of a record, and retriggering an unnamed default form act_window would only restrict possible operations for the user. After this commit, the current view will be reloaded and the user will most probably be able to see its enabled plan in the chatter. task-4525830 Forward-Port-Of: odoo/odoo#210168
Steps to reproduce: - Install accounting, Sales apps - Setup two companies for the current user with two diff currencies - In company A, make a SO on a product and create an invoice - Validate and confirm the invoice. - Go to accounting, reporting, invoice analysis, and add group for the product - Select the report of that specific invoice posted - Observe the values untaxed_total, avg_price, inventory_value and price_margin - Switch to company B, and add a currency rate between both cur
Original PR description
Steps to reproduce: - Install accounting, Sales apps - Setup two companies for the current user with two diff currencies - In company A, make a SO on a product and create an invoice - Validate and…
Steps to reproduce: - Install accounting, Sales apps - Setup two companies for the current user with two diff currencies - In company A, make a SO on a product and create an invoice - Validate and confirm the invoice. - Go to accounting, reporting, invoice analysis, and add group for the product - Select the report of that specific invoice posted - Observe the values untaxed_total, avg_price, inventory_value and price_margin - Switch to company B, and add a currency rate between both currencies to observe a difference - Make sure that you are selecting both companies, but B as the main company - Go again to the report of the same Invoice. - Observe the values again. Issue: When changing the currency, the fields untaxed_total and price_avg are updated using the currency rate of the current main company. However, inventory_value is not updated. This inconsistency affects the calculation of price_margin, which relies on both untaxed_total and inventory_value. As a result, price_margin is computed incorrectly. opw-4582973 Forward-Port-Of: odoo/odoo#206582
Step to reproduce: - install accounting - in the dashboard searchbar, add a `Group By` with value `type` - go to vendor bills view from the dashboard - upload any file Error: Wrong value for `ir.attachment.type`: 'purchase' Expected: The upload process should go on without any error Explanation: in the `onFileUploaded` hook for vendor bills AccountFileUploader JS component, we included all context when we are creating the `ir.attachment` object. The group-by we added earl
Original PR description
Step to reproduce: - install accounting - in the dashboard searchbar, add a `Group By` with value `type` - go to vendor bills view from the dashboard - upload any file Error: Wrong value for…
Step to reproduce: - install accounting - in the dashboard searchbar, add a `Group By` with value `type` - go to vendor bills view from the dashboard - upload any file Error: Wrong value for `ir.attachment.type`: 'purchase' Expected: The upload process should go on without any error Explanation: in the `onFileUploaded` hook for vendor bills AccountFileUploader JS component, we included all context when we are creating the `ir.attachment` object. The group-by we added earlier are thus also added as `default_type` in the context. But when creating a record, the ORM checks for all `default_*` key in the context and try to use it as additional values for the created record. Since the key-value combination `type` and `purchase` is not valid in an `ir.attachment` record, it throws this error. Solution: Before passing the context, we have to make sure to clean all the `default_*` contexts to avoid these kind of behaviors. In python, usually we use `clean_context` method before calling `create`. But since this is in JS, we manually filter all key-value item that starts with "default_" in the context object. opw-4512697 Forward-Port-Of: odoo/odoo#201628
Steps to print the check: 1. Ensure l10n_us_check_printing is installed 2. Set the check layout to Print Check (Middle) - US 3. Create a PO and a bill from it. 4. Create a payment for the bill using checks as your payment method 5. Click Print Check on the payment Current behavior before PR: The checks would print the vendor's name in the stubs, and the date alignment in the (middle) format was overlapping with the check number. Description of the issue/feature this PR addresses: Th
Original PR description
Steps to print the check: 1. Ensure l10n_us_check_printing is installed 2. Set the check layout to Print Check (Middle) - US 3. Create a PO and a bill from it. 4. Create a payment for the bill using…
Steps to print the check: 1. Ensure l10n_us_check_printing is installed 2. Set the check layout to Print Check (Middle) - US 3. Create a PO and a bill from it. 4. Create a payment for the bill using checks as your payment method 5. Click Print Check on the payment Current behavior before PR: The checks would print the vendor's name in the stubs, and the date alignment in the (middle) format was overlapping with the check number. Description of the issue/feature this PR addresses: The checks are aligned with the expected format and conditionally render the correct fields in the document's intended areas. Desired behavior after PR is merged: The printed check will now match the format and alignment of the templates used here: https://checkdepot.net/collections/odoo-checks/products/odoo-checks-top- format. Additionally, the check will now avoid printing the issuing company name on the stubs when the manual numbering setting on the bank journal is switched off. This assumes that the checks are preprinted with the company name and check number. opw-4557006 opw-4738359 Enterprise PR: https://github.com/odoo/enterprise/pull/84644 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210074 Forward-Port-Of: odoo/odoo#208357
Steps: - Create a partner and it's parent partner and set different salesperson on each. - Login with child partner and add product to cart. - Go to backend and open related quotation. Issue: - Salesperson set on quotation is customer's parent partner's salesperson even though salesperson set on customer. While in backend it first check customer's salesperson and if customer does not have salesperson then it set parent's salesperson. Cause: - In eCommerce we gave parent's salesperson
Original PR description
Steps: - Create a partner and it's parent partner and set different salesperson on each. - Login with child partner and add product to cart. - Go to backend and open related quotation. Issue: - Salesperson set on quotation is customer's parent partner's salesperson even though salesperson set on customer. While in backend it first check customer's salesperson and if customer does not have salesperson then it set parent's salesperson. Cause: - In eCommerce we gave parent's salesperson first priority then customer's salesperson. Fix: - Swap priority to set first customer's salesperson opw-4757042 Forward-Port-Of: odoo/odoo#210439 Forward-Port-Of: odoo/odoo#209062
…count value Steps to reproduce: 1. Create an invoice with a product 2. Set quantity to 3, price to 11.34 3. Confirm & get the invoice PDF 4. Upload the PDF in accounting app 5. Check the "discount" value Issue: Visually the result is correct, but the stored value (in db) is not -2.220446049250313e-14 != 0.0 Cause: ``` >>> 3 * 11.34 34.019999999999996 ``` Creating a slight error of -0.0000000000002 opw-4675079 Forward-Port-Of: odoo/odoo#208446 Forward-Port-Of: odoo/odoo
Original PR description
…count value Steps to reproduce: 1. Create an invoice with a product 2. Set quantity to 3, price to 11.34 3. Confirm & get the invoice PDF 4. Upload the PDF in accounting app 5. Check the "discount" value Issue: Visually the result is correct, but the stored value (in db) is not -2.220446049250313e-14 != 0.0 Cause: ``` >>> 3 * 11.34 34.019999999999996 ``` Creating a slight error of -0.0000000000002 opw-4675079 Forward-Port-Of: odoo/odoo#208446 Forward-Port-Of: odoo/odoo#206107
- Configure a payment method (e.g. `"demo"`) with an outstanding receipt account in the bank journal used by the website (automatic invoicing enabled). Enable Automatic Invoice for online payment. - Create a partner on the website using an incognito window. In the backend change their default property_account_receivable_id. Assign them a fiscal position where the receivable account is mapped to another account. - Make a purchase using the `"demo"` payment method with the new partner. The ge
Original PR description
- Configure a payment method (e.g. `"demo"`) with an outstanding receipt account in the bank journal used by the website (automatic invoicing enabled). Enable Automatic Invoice for online payment. -…
- Configure a payment method (e.g. `"demo"`) with an outstanding receipt account in the bank journal used by the website (automatic invoicing enabled). Enable Automatic Invoice for online payment. - Create a partner on the website using an incognito window. In the backend change their default property_account_receivable_id. Assign them a fiscal position where the receivable account is mapped to another account. - Make a purchase using the `"demo"` payment method with the new partner. The generated invoice and its corresponding journal entry do not share the same `account_id` (Account Receivable). The invoice uses the `account_id` computed in `_compute_account_id` of `account.move.line`, which is not necessarily the same as the `account_id` set on the partner. After this commit, the payment uses the same `account_id` as the related invoice, (same as _create_payment_vals_from_wizard) avoiding any discrepancy. opw-4669927 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#208790 Forward-Port-Of: odoo/odoo#204489
Description: --- The action to update Taxes and Accounts when changing the fiscal pos on invoice isn't considering the change in price_unit for lines with price included taxes. Steps to Reproduce: --- 1- Create a 21% tax and another 6% tax, both are included in price 2- Create a fiscal position that will map the 21% tax by the 6% tax 3- Create a product with Price = 121€, and Tax = 21% 4- Create an invoice with this product. 5- On the (Other info) tab, set the Fiscal Position to the o
Original PR description
Description: --- The action to update Taxes and Accounts when changing the fiscal pos on invoice isn't considering the change in price_unit for lines with price included taxes. Steps to Reproduce:…
Description: --- The action to update Taxes and Accounts when changing the fiscal pos on invoice isn't considering the change in price_unit for lines with price included taxes. Steps to Reproduce: --- 1- Create a 21% tax and another 6% tax, both are included in price 2- Create a fiscal position that will map the 21% tax by the 6% tax 3- Create a product with Price = 121€, and Tax = 21% 4- Create an invoice with this product. 5- On the (Other info) tab, set the Fiscal Position to the one created (from 21 to 6). 6- Click on update taxes and accounts: The price will still be 121 while the taxes will change to 6%, and total = 121. 7- Then if you added a new line with the product now after setting the fiscal pos , you will get price= 106, tax=6%, total = 106. which are the right values. Cause: --- The action created for updating taxes and accounts didn't consider price changes for price included taxes. Fix: --- Add call to _compute_price_unit() opw-4672466 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208780
This reverts commit 7ce1ba9f29f9b1edd5f2507492e45ef92d9ba868. Before the commit (1) We would iterate through the possible items and see if the partner has the field. As the partner in the test setup does not have `company_registry`, it will iterate on the second value, `vat`, which is set on the partner https://github.com/odoo/odoo/blob/037fabd81efc28c12359700ee8e21e0454e0535e/addons/l10n_dk/models/res_partner.py#L7-L18 which will be the key `0198` For this key, we have mocked the respons
Original PR description
This reverts commit 7ce1ba9f29f9b1edd5f2507492e45ef92d9ba868. Before the commit (1) We would iterate through the possible items and see if the partner has the field. As the partner in the test setup…
This reverts commit 7ce1ba9f29f9b1edd5f2507492e45ef92d9ba868. Before the commit (1) We would iterate through the possible items and see if the partner has the field. As the partner in the test setup does not have `company_registry`, it will iterate on the second value, `vat`, which is set on the partner https://github.com/odoo/odoo/blob/037fabd81efc28c12359700ee8e21e0454e0535e/addons/l10n_dk/models/res_partner.py#L7-L18 which will be the key `0198` For this key, we have mocked the response: https://github.com/odoo/odoo/blob/e62a86939b0b327e2c16a82b0829dac80ef1ff32/addons/account_peppol/tests/test_peppol_messages.py#L153-L155 After the commit (1), we stop at the first iteration since `vat` is defined on the partner's fields. The key is `0184` -> we don't have any mocked response for this key, we we wazt to load the response's body which does not exist -> kaboom I'm not sure that we wanted to change this value in the first place as from Julien, we wanted the company registry https://github.com/odoo/odoo/commit/ad37ebefb9fb7cb3c9593730f174dd6f1d73a31e https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/DK-R-014/ + the company registry == the vat for the danish localisation https://github.com/odoo/odoo/blob/037fabd81efc28c12359700ee8e21e0454e0535e/addons/l10n_dk/models/res_partner.py#L7-L18 --- commit (1) https://github.com/odoo/odoo/commit/7ce1ba9f29f9 runbot-163142 Forward-Port-Of: odoo/odoo#209498
When posting the vendor bill before validating the receipt, and the currency rate changed between the bill and receipt: - An Exchange diff account move would be created, and the Stock Input Account would not be balanced This is because the balance of the receipt would perfectly match the balance of the vendor bill, but not the Amount in currency. So, when we try to reconcile the 2 lines, because they are in the same currency, we are reconciling the Amount in Currency. Hence, the exchange rat
Original PR description
When posting the vendor bill before validating the receipt, and the currency rate changed between the bill and receipt: - An Exchange diff account move would be created, and the Stock Input Account…
When posting the vendor bill before validating the receipt, and the currency rate changed between the bill and receipt:
- An Exchange diff account move would be created, and the Stock Input Account would not be balanced
This is because the balance of the receipt would perfectly match the balance of the vendor bill, but not the Amount in currency. So, when we try to reconcile the 2 lines, because they are in the same currency, we are reconciling the Amount in Currency. Hence, the exchange rate journal entry is created, and a discrepancy in the Stock Input Account balance is introduced.
When the bill is posted before the receipt is validated, we want the receipt to have the value of the bill, and there is no reason to have only the balance or the amount in currency from the bill, so we can take both of them.
https://github.com/user-attachments/assets/c6dc5e72-8f5b-4c0f-99fa-c5e98a9574ff
## How to reproduce:
- Install stock_account,purchase
- Create product P:
* Valued in AVCO automated.
* Control Policy to 'On ordered quantities'
- Add currency rates for the EUR currency:
* 2.0 on the 2025-01-01
* 2.1 today
- Create and Confirm a new purchase for 1 unit of P and a price of 100 Euros
- Create the Bill:
* Set the bill's accounting date & bill date to the 2025-01-01
* Confirm the bill
=> Amount in Currency: 100 Euros - Balance: $50 USD - Rate used: 2.0
- Go back to the PO and receive the product.
=> Amount in Currency: 105 Euros - Balance: $50 USD - Rate used: 2.1
- Check the created Journal Entries:
=> Currency exchange rate difference: $2.38
=> (105 - 100) / 2.1
OPW-4631348
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#209667
Forward-Port-Of: odoo/odoo#209118Currently an error occurs during post-processing of a payment transaction. Steps to Reproduce: - Install the `website_sale` module. - Open `Reports > Quotation / Order` and enable the Invoice report option. - Go to the Website, place an order using the Wire Transfer payment provider. - Open `Scheduled Actions`. - Find and manually run the `Payment: Post-process transactions action`. `MissingError: Record does not exist or has been deleted. (Record: account.move(22,), User: 1)
Original PR description
Currently an error occurs during post-processing of a payment transaction. Steps to Reproduce: - Install the `website_sale` module. - Open `Reports > Quotation / Order` and enable the Invoice report…
Currently an error occurs during post-processing of a payment transaction. Steps to Reproduce: - Install the `website_sale` module. - Open `Reports > Quotation / Order` and enable the Invoice report option. - Go to the Website, place an order using the Wire Transfer payment provider. - Open `Scheduled Actions`. - Find and manually run the `Payment: Post-process transactions action`. `MissingError: Record does not exist or has been deleted. (Record: account.move(22,), User: 1)` This issue was generated because the user clicked on the invoice report option on the report Quotation / Order as a result, when we try to print qutation /order it tries to browse the sale.order with id 22 as an account.move. This commit ensures that the is_invoice_report field is only visible when the model is account.move. Additionally, the_is_invoice_report method has been modified to return True only when the model is account.move, thereby preventing a MissingError during scheduled actions. Sentry-6563415103 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207635
In the Italian balance sheet, the section for “d-bis. Other enterprises” is not added to the calculation for the section “1. Holdings in:”. As a result, it is not included in the calculation for assets in the balance sheet. This commit adds the section “d-bis. Other enterprises” to the calculation of “1. Holdings in”. This specification is based on Article 2424(1) of the Italian Civil Code: https://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:regio.decreto:1942-03-16;262 Steps to Repro
Original PR description
In the Italian balance sheet, the section for “d-bis. Other enterprises” is not added to the calculation for the section “1. Holdings in:”. As a result, it is not included in the calculation for assets in the balance sheet. This commit adds the section “d-bis. Other enterprises” to the calculation of “1. Holdings in”. This specification is based on Article 2424(1) of the Italian Civil Code: https://www.normattiva.it/uri-res/N2Ls?urn:nir:stato:regio.decreto:1942-03-16;262 Steps to Reproduce on Runbot: 1. Install l10n_it_reports 2. Create an account starting with 1306 3. Create a journal entry using account 1306 as the debit line and balance it with a credit line 4. Check the Italian balance sheet and notice that “d-bis. Other enterprises” is not included in the calculation for assets in the Italian balance sheet Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4763868) opw-4763868 Forward-Port-Of: odoo/enterprise#84586
Setting widget="date" on a datetime field doesn't have the wanted effect: the time is still displayed, but worse, the column widths logic of the list view considers the field as being a date, so not enough space is allocated to the column, meaning that the date is even fully displayed as it is trimmed. This commit fixes this by apply the adequate option on the field. Forward-Port-Of: odoo/enterprise#85707
Original PR description
Setting widget="date" on a datetime field doesn't have the wanted effect: the time is still displayed, but worse, the column widths logic of the list view considers the field as being a date, so not enough space is allocated to the column, meaning that the date is even fully displayed as it is trimmed. This commit fixes this by apply the adequate option on the field. Forward-Port-Of: odoo/enterprise#85707
Currently you are able to select the button to settle customer account/ deposit money even though the config does not have access to a paylater payment method. This will never settle the customer account. Steps to reproduce: ------------------- * Remove the customer account payment method from the config * Open the pos session * Find a customer that has an amount due * Select "Settle due accounts" * Process > Observation: The customer account is never settled. Why the fix: --------
Original PR description
Currently you are able to select the button to settle customer account/ deposit money even though the config does not have access to a paylater payment method. This will never settle the customer account. Steps to reproduce: ------------------- * Remove the customer account payment method from the config * Open the pos session * Find a customer that has an amount due * Select "Settle due accounts" * Process > Observation: The customer account is never settled. Why the fix: ------------ If there is no payment method of type "pay_later" we should not show the button whose purpose is to use such payment method. opw-4488571 Forward-Port-Of: odoo/enterprise#84695 Forward-Port-Of: odoo/enterprise#83995
Steps to print the check: 1. Ensure l10n_us_check_printing is installed 2. Set the check layout to Print Check (Middle) - US in the settings 3. Create a PO and a bill from it. 4. Create a payment for the bill using checks as your payment method 5. Click Print Check on the payment The printed check will now match the format and alignment of the templates used [here](https://checkdepot.net/collections/odoo-checks?_pos=1&_psq=odoo&_ss=e&_v=1.0). Additionally, the check will now avoid printi
Original PR description
Steps to print the check: 1. Ensure l10n_us_check_printing is installed 2. Set the check layout to Print Check (Middle) - US in the settings 3. Create a PO and a bill from it. 4. Create a payment for…
Steps to print the check: 1. Ensure l10n_us_check_printing is installed 2. Set the check layout to Print Check (Middle) - US in the settings 3. Create a PO and a bill from it. 4. Create a payment for the bill using checks as your payment method 5. Click Print Check on the payment The printed check will now match the format and alignment of the templates used [here](https://checkdepot.net/collections/odoo-checks?_pos=1&_psq=odoo&_ss=e&_v=1.0). Additionally, the check will now avoid printing the issuing company name on the stubs when the manual numbering setting on the bank journal is switched off. This assumes that the checks are preprinted with the company name and check number. Before the fix, the checks printed the vendor's name in the stubs, and the date alignment in the (middle) format overlapped with the check number. After the fix, the checks are aligned with the expected format and conditionally render the correct fields in the document's intended areas. opw-4557006 opw-4738359 odoo PR: https://github.com/odoo/odoo/pull/208357 Forward-Port-Of: odoo/enterprise#85578 Forward-Port-Of: odoo/enterprise#84644
In this commit: https://github.com/odoo/enterprise/pull/84728/commits/d3b3de47ca3f174e97eb598187b32e31077a2ddb since the transaction details field was in fact a string in version lower than 18.2 the get would traceback no task id Forward-Port-Of: odoo/enterprise#85848
Original PR description
In this commit: https://github.com/odoo/enterprise/pull/84728/commits/d3b3de47ca3f174e97eb598187b32e31077a2ddb since the transaction details field was in fact a string in version lower than 18.2 the get would traceback no task id Forward-Port-Of: odoo/enterprise#85848
**Steps to reproduce** - Install website_sale_subscription - On the website page of a product, enter the editor and enable the "Tax Indication" setting for the product page. - The tax indication information doesn't appear for subscription products.  **Cause** Issue since commit 7d160198be779095660e7f6fb68ae231e4621972 which hides default pricing information from `website_sale` for subscription produc
Original PR description
**Steps to reproduce** - Install website_sale_subscription - On the website page of a product, enter the editor and enable the "Tax Indication" setting for the product page. - The tax indication information doesn't appear for subscription products.  **Cause** Issue since commit 7d160198be779095660e7f6fb68ae231e4621972 which hides default pricing information from `website_sale` for subscription products, including the tax indication. opw-4637308 Forward-Port-Of: odoo/enterprise#84669
This reverts commit e4111ac8f817f97b3d6128453659a1014b6db00f. This fix was decided after https://github.com/odoo/enterprise/pull/74127 that was trying to prevent invoicing users to see accounting features, when it seemed to be unwanted to have the two property accounts fields required while having no CoA installed. The issue is, now when having Accounting installed, we can create a user without having CoA as these two fields are not required anymore, but we end up with a error message when cre
Original PR description
This reverts commit e4111ac8f817f97b3d6128453659a1014b6db00f. This fix was decided after https://github.com/odoo/enterprise/pull/74127 that was trying to prevent invoicing users to see accounting…
This reverts commit e4111ac8f817f97b3d6128453659a1014b6db00f.
This fix was decided after https://github.com/odoo/enterprise/pull/74127
that was trying to prevent invoicing users to see accounting features,
when it seemed to be unwanted to have the two property accounts fields
required while having no CoA installed.
The issue is, now when having Accounting installed, we can create a user
without having CoA as these two fields are not required anymore, but
we end up with a error message when creating an invoice ('no CoA
installed') although we could be have added accounts manually instead
of installing a CoAi (which is not possible for invoicing user).
In this situation, we should be able to create a contact, and having these
fields required will force the user to create them.
Finally, it is ok to revert the full chain, as the original issue is
fixed by this commit https://github.com/odoo/enterprise/commit/68f6c1f9fd3ff6762c98e1a405ade035129efce0
Forward-Port-Of: odoo/enterprise#85736
Forward-Port-Of: odoo/enterprise#85446