Daily updates from Odoo
Friday, December 6, 2024
75 changes · master
Enhancements to existing features
Grid views now validate date range settings more strictly, so only supported time periods can be used. This helps prevent configuration mistakes that could lead to incorrect grid displays or data loading issues.
Original PR description
Before this commit, `range` tag can be defined as child of field, that range is used if the parent field is a column and a Date/Datetime field to know the number of grid columns to display and how to fetch data to fill in those columns. However, the content of `span` and `step` attributes defined in the `range` xml tag is not really checked during the xml validation of the grid view. This commit makes sure `span` attribute only contains `day`, `week`, `month` or `year` and `step` attribute is either `day` or `month`. task-4373526
Shift times in the Planning kanban view now hide unnecessary seconds, making schedules easier to read at a glance. Single-day shifts show the date once with start and end times, while multi-day shifts show both full dates and times for clarity.
Original PR description
Removed seconds from the planned date display for shifts in the kanban view, it will improves readability and provides a cleaner display of shift times in the kanban view - for multiple days it will show the full date and time e.g., '10/10/2024 8:00 - 10/12/2024 17:00'. - For the single day it will show only the start date with start time and end time '10/10/2024 8:00 - 17:00'.. task- 4247327
Subscription renewals now update the contract end date only once instead of briefly setting it to today first. This avoids temporary date inconsistencies that could disrupt custom business processes during renewals.
Original PR description
Before this commit, the end_date in set_close was always set to today. During a renewal, it was later updated. Unfortunately, it could break customization when the parent end_date was set to today during a shrt amount of time. During that time, it would be earlier than the start_date and this could lead to issues on some customizations. This change aimes to avoid setting the end_date twice and have single update of the end_date during the renewal process.
This update adds automated test coverage for expanding resources in the Planning app. It helps ensure this scheduling behavior remains reliable in future updates, reducing the risk of regressions for users who manage resource planning.
Original PR description
In this commit: planning expand resource is tested task-4367703
The interview scheduling email template was updated to use a simpler layout that improves alignment. This helps recruitment-related appointment emails look cleaner and more consistent for candidates and recruiters.
Original PR description
- Remove the table structure from "Recruitment: Schedule interview" email template and go for just div to fix the alignment Task: 4363968
Website editors can now choose Appointments and Knowledge Articles directly in the search bar building block's search scope options. This makes the visible choices match what is already searched under "Everything" and uses a clearer book icon for knowledge articles to avoid confusion with forums.
Original PR description
 
Specification:
- Add new objects in 'search within' option of s_searchbar
snippet.
- The list must contain all objects that are searched when
"Everything" is selected in "search within" toggler.
- Change the 'knowledge article' icon to "fa-book" from "fa-comment-o".
Before this commit:
- In search building block options, there were missing
`knowledge articles` and `Appointments` objects in
`search within` options.
After this commit:
- Added two new searchable objects "knowledge articles" and
"Appointments" in "search within" option.
- Icon for knowledge article is changed to fa-book to avoid
confusion with forums because both has same icons.
task-3060611The Indian GST reporting module now uses a standard Odoo grouping method instead of custom grouping logic. This cleanup should improve performance and maintainability without changing how users work with the reports.
Original PR description
Before this commit: We created a manual method to group by the journal items After this commit: We cleanup the manual created method and use the orm `grouped` method for better performance
Rental-related website pages are now marked so they can be served by read-only database replicas where appropriate. This helps distribute traffic more efficiently and can improve scalability without changing the customer-facing shopping experience.
Original PR description
Mark readonly routes/methods so that those requests can be handled by readonly database replicas. task-4167831 See also: odoo/odoo#187616
Planning screens are easier to read with cleaner list labels, less visual noise in Gantt progress bars, and more relevant calendar filters. This helps users find planned work and their resources faster during scheduling.
Original PR description
Planning Slots: List view: - Hide resources' job title. - Rename `Start Date` column label to `Planned Date`. Gantt view: - Remove the warning in the progress bar. Calendar view: - Display the resources of the current user on top of the filter panel. task-3823383
The old mobile testing setup has been removed because those tests now run through the newer testing system. This is an internal cleanup that helps keep the codebase simpler and does not change how users work with Odoo.
Original PR description
Because all mobile tests are now converted to hoot. We decided to remove the `web.qunit_mobile_suite` QUnit suite. task-4028335
Restaurant kitchen preparation cards now remain unchanged when an order is merged from one table into another. This prevents previously sent items from being incorrectly cancelled after merging or unmerging tables, reducing kitchen confusion and order mistakes.
Original PR description
Before this commit: ==================== - When items were ordered on Table 1 and then merged into Table 2, the preparation card for Table 1 was cancelled, and a new card was created for Table 2. After this commit: ================== - The preparation card for Table 1 remains intact even after merging its order with another table. - Upon unmerging, order lines from Table 1 are not automatically canceled and will remain intact when the order, along with any new lines, is sent back to the kitchen display for processing. Task- 4224207 Related Community PR: https://github.com/odoo/odoo/pull/188183
This update streamlines how Odoo loads and filters application menus, reducing unnecessary database checks and improving performance when menu data is cached. It also updates related tests and enterprise menu customizations to align with the improved behavior, with no expected change to day-to-day user workflows.
Original PR description
See https://github.com/odoo/odoo/pull/188278 ### [IMP] web: improve test_web_icon For the commit in community, it is important to have a realistic behavior and avoid patching the `search` method without calling the original one, because the current implementation only works with the override of `search_fetch`. ### [REF] base: refactor ir.ui.menu search_fetch Get rid of the 'ir.ui.menu.full_list' context. See community PR. ### [IMP] base: improve perf of _visible_menu_ids Improve the performance of _visible_menu_ids() to speed up load_menus() when the orm is cached. Avoid using ref because it always makes a SQL query for check the existence of the attached record. In this case, we don't care. task-4360403
Users can now copy a selected sign item and paste it elsewhere in a document using keyboard shortcuts. This makes preparing signature templates faster and reduces repetitive setup work.
Original PR description
This commit aims to add the ability of copying sign items using ctrl+c and ctrl+v. The user can: 1. click on sign item 2. hit ctrl+c 3. navigate to the desired position on any page and do a mouse click 4. hit ctrl+v and a new copy appears! task: 4069487
Gantt items now show their start and end dates only when those dates are not visible within the current timeline view. This makes schedules easier to read with dynamic date ranges and year views, while avoiding unnecessary date text when the timeline already shows the information.
Original PR description
In the past, there used to be just "static" scales (day, week, month, year) in the gantt view. For a given scale, we displayed the start and end dates of a record when it spanned across several units of that scale, because then, you couldn't see both limits at once. For example, when the scale is in weeks and the current focus is this week, we display the dates of a record if it starts this week and ends on next week, because you can't see the end of it. Now that it is possible to set the start and end date of the period that is displayed more dynamically, we want to keep this rationale "we display the dates if you can't see them graphically". So we display the start and end dates of the record if it starts before the start of the period or ends after the end of the period, no matter the "scale". task-3974394
Planning, Project, and Field Service Gantt views now display a progress bar on total rows, including selected grouped planning views. This helps managers quickly understand overall workload progress without opening individual items.
The Point of Sale Pricer module now includes its own app icon. This makes the module easier to recognize in Odoo’s app list and improves the overall presentation for users.
Original PR description
added pricer icon to module. 
Payslips can no longer be generated for employees who do not have a valid contract covering the payslip period. This helps prevent incorrect payroll processing and reduces the risk of paying employees outside approved employment terms.
Original PR description
Before this commit, a payslip was generated for employees even if they didn't have a valid contract for the payslip duration. This commit brings a restriction on payslip generation, preventing it if the employee doesn't have a valid contract for the payslip duration. task-3810418
The Timesheets settings action now opens employees in a list that shows the billable time target fields directly. This makes it clearer what managers need to fill in and allows faster bulk updates across employees.
Original PR description
Before this commit, when the user would like to set billable time targets to his employees and clicks on `Set Employee Billable Time Targets` action displayed in `Timesheets > Configuration > Settings` when `Billing Rate Indicators` is enabled. The user will be redirected to the kanban view of employees but he does not really know which field he has to set if he tries the feature, and he has to go to the form view and find the field and set it for each employee using timesheets app. This commit reviews the action loaded in that button to directly show the list view with the fields needed. By doing that, the user will directly see the field to set for his employees and he will be able to mass edit thanks to the list view. task-4179246
Resolved issues and error corrections
Manufacturing work orders now use the Google Slides viewer for embedded documents, replacing the previous viewer setup. This improves consistency with the wider platform change and helps operators view related instructions more reliably.
Original PR description
Following odoo/odoo#189309, clean the previous 'embed_viewer'.
Belgian payroll payslips now count half-day work entries as 0.5 days instead of a full day. This improves payroll accuracy and helps employees and payroll teams see the correct worked time on payslips.
Original PR description
half-day work entries should appear on the payslip as being 0.5 days instead of 1 task-4269240
Field service reports now include the time and materials section even when custom worksheets are turned off. This ensures customers and teams can still see added products in sent or downloaded reports, avoiding incomplete service documentation.
Original PR description
Steps: - Open Field Service - Open any task - Add products then go to task - Send report or download report Issue: - In field service report there is no 'time and material' section visible when 'custom worksheets' feature disabled in settings. Cause: - worksheet_custom_report_template is in industry_fsm_sale_report so when we disable 'custom worksheets' feature in settings the industry_fsm_sale_report is uninstalled so that the 'time & material' section is not visible Fix: - Add worksheet_custom_report_template in industry_fsm_sale so that it always visible when add the product. task-3484413
Features or functions removed from Odoo
The Belgian salary package configuration was cleaned up by removing an old field that is no longer used. This reduces maintenance overhead without changing the employee-facing salary offer process.
Original PR description
Since the field new_car is now used as show_new_car was, the field show_new_car is not used anymore and can be removed.
Code cleanup and technical improvements
The timer app's automated tests were converted to a newer testing approach, helping maintain reliability without changing how users work. This supports smoother future updates for timer and timesheet-related features by keeping internal quality checks current.
Original PR description
In this commit Quint test cases are converted into hoot test cases task-4354271 Note: `timer/static/tests/timer_start_field_tests.js` has already been done in PR https://github.com/odoo/enterprise/pull/68780
Payroll accounting test utilities were reorganized so tests can better handle records created during each test run. This is an internal maintenance change that improves test reliability and readability without changing payroll behavior for users.
Original PR description
The methods _generate_leave and _add_other_inputs could be improved to allow for records created in the test itself. Also made the code prettier. Task: 4374060
This update adjusts several Point of Sale-related modules to follow a newly introduced code style rule. It is an internal cleanup that helps keep the codebase consistent and easier to maintain, with no expected change to user-facing behavior.
Original PR description
In the corresponding community commit we add the eslint rule `"arrow-body-style": ["error", "as-needed"]`. In this commit we adapt the code to respect this new rule. https://github.com/odoo/odoo/pull/188818
Miscellaneous changes
This commit improves the UX of the Lock Dates Wizard with the following changes: - Reworded the tooltips of all 5 lock date fields - Change label for "Lock Everyone" to "Lock Everything" - Move the Exception to the bottom and highlight it in an alert - Make it so that the relevant field of the exceptions are highlighted with an info class (using `decoration-info`) In addition, it also changes the help and string of other related invisible fields (even though it's not needed) to keep it
Original PR description
This commit improves the UX of the Lock Dates Wizard with the following changes: - Reworded the tooltips of all 5 lock date fields - Change label for "Lock Everyone" to "Lock Everything" - Move the Exception to the bottom and highlight it in an alert - Make it so that the relevant field of the exceptions are highlighted with an info class (using `decoration-info`) In addition, it also changes the help and string of other related invisible fields (even though it's not needed) to keep it the same everywhere in the code. related community-PR: https://github.com/odoo/odoo/pull/188017 task-id: 4297145 Forward-Port-Of: odoo/enterprise#74262
The Profit&Loss and Balance Sheet have now a "Note" column, that contains a code that will help cross reference the Note Report (currently not implemented in odoo). Also, "Gross" and "Depreciation" columns are added to the Balance Sheet. Community PR: https://github.com/odoo/odoo/pull/163380 task-3848455 Forward-Port-Of: odoo/enterprise#75087 Forward-Port-Of: odoo/enterprise#61473
Original PR description
The Profit&Loss and Balance Sheet have now a "Note" column, that contains a code that will help cross reference the Note Report (currently not implemented in odoo). Also, "Gross" and "Depreciation" columns are added to the Balance Sheet. Community PR: https://github.com/odoo/odoo/pull/163380 task-3848455 Forward-Port-Of: odoo/enterprise#75087 Forward-Port-Of: odoo/enterprise#61473
Versions -------- - 17.0+ Steps ----- 1. Create an appointment type with availability base on resources; 2. have multiple resources to select from; 3. copy share URL; 4. open URL; 5. select a different resource. Issue ----- The resource name in the right column doesn't update to the selected resource. Cause ----- There's no logic in place to update it after selecting a different resource. Solution -------- For user-based appointments, this part isn't shown as long as th
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create an appointment type with availability base on resources; 2. have multiple resources to select from; 3. copy share URL; 4. open URL; 5. select a different resource. Issue ----- The resource name in the right column doesn't update to the selected resource. Cause ----- There's no logic in place to update it after selecting a different resource. Solution -------- For user-based appointments, this part isn't shown as long as there's multiple options available. Expand this logic to also work for resource-based appointments. Also modify it to now show details on date selection step unless there's only one option to select from (instead of unless pictures should be shown). With `website_appointment`, this is also the case when a separate selection screen was shown beforehand. opw-4355438 Forward-Port-Of: odoo/enterprise#75247 Forward-Port-Of: odoo/enterprise#75006
Reverts 9ae263696efff17a872e848b03a7b08ba84cdca2 Community PR: odoo/odoo#189440 task-3977961 Forward-Port-Of: odoo/enterprise#75054
Original PR description
Reverts 9ae263696efff17a872e848b03a7b08ba84cdca2 Community PR: odoo/odoo#189440 task-3977961 Forward-Port-Of: odoo/enterprise#75054
[FIX] account_reports, l10n_*_reports: add explicit ORDER BY to report engines for consistent LIMIT and OFFSET behavior As stated here https://www.postgresql.org/docs/current/queries-limit.html , postgresql requires an explicit ORDER by within the query for LIMIT and OFFSET to work properly and consistently between query executions. We hence add one to each engine not having one already. ======================================= [FIX] account_reports: properly handle groupby in account_co
Original PR description
[FIX] account_reports, l10n_*_reports: add explicit ORDER BY to report engines for consistent LIMIT and OFFSET behavior As stated here https://www.postgresql.org/docs/current/queries-limit.html ,…
[FIX] account_reports, l10n_*_reports: add explicit ORDER BY to report engines for consistent LIMIT and OFFSET behavior
As stated here https://www.postgresql.org/docs/current/queries-limit.html , postgresql requires an explicit ORDER by within the query for LIMIT and OFFSET to work properly and consistently between query executions. We hence add one to each engine not having one already.
=======================================
[FIX] account_reports: properly handle groupby in account_codes engine for grouping keys used with multiple accounts
// TO REPRODUCE
1) Create a report with a single line, whose computation uses the account_codes engine, with formula "1". Set "partner_id" as the groupby value for that line. Setup a "load more limit" of 2 on your report.
2) Create 3 accounts, with codes 11, 12, 13
3) Create 3 partners: A, B, and C
4) Create journal entries, with the following lines (all balancing lines must use other accounts as the ones defined in 2) ), in that order:
- on account 11, with partner A, debit=10
- on account 11, with partner A, debit=20
- on account 12, with partner A, debit=25
- on account 11, without partner, debit=30
- on account 11, without partner, debit=40
- on account 12, with partner B, debit=50
- on account 13, with partner C, debit=60
5) Open the report for a period covering all the created journal entries, and have a look at the sublines generated for the groupby.
=> With the limit being 2, you'd expect to see "A", "B", and a "Load more..." line allowing to visualize the rest (namely a line for "C", and "Unknown"). Instead of that, you see no "Load more ...", and line "A"'s amount is wrong.
// EXPLANATION
The SQL query of the account_codes engine is grouping not only by groupby key (here, partner_id), but also by account_id, to be able to process the "C" and "D" suffixes of the formula later on. Because of that, the LIMIT passed by the load_more_limit is applied on that grouping.
With a load_more_limit of 2, we try to load 3 lines. If we manage to load 3, we only display 2, but know we need to display the "Load more..." line. Else, we know there are no more results, so no need for that additional line.
So, with our example, the query runs with a LIMIT of 3, returning
- 30 for A on account 11
- 25 for A on account 12
- 70 for no partner on account 11
Then, another issue happens:
The results returned by the SQL query (hence, by the engine) contain two times the same partner_id. From an engine perspective, the grouping key is only partner_id, not account_id (which is only used for an inner computation, with the SQL query). So that means the same grouping key has two different values. This is not legit, and causes one of them to shadow the other.
The report computation then receives 1 result for A, and 1 for "Unknown", so it renders them, and since there is no third result, it does not display the "Load more ...".
Forward-Port-Of: odoo/enterprise#75168
Forward-Port-Of: odoo/enterprise#74784The second level already configured in demo has been moved in data because having only one follow-up level in a new database is a bit weird. Not only does it look weird, but in practice it also leads to a weird situation that by default the invoices will only be reminded once and never after. + we're failing to convey the usefuleness of the feature of building gradually harded reminders for the partner. Also added forcecreate="False" in snailmail demo data, because we don't waznt to recreate
Original PR description
The second level already configured in demo has been moved in data because having only one follow-up level in a new database is a bit weird. Not only does it look weird, but in practice it also leads to a weird situation that by default the invoices will only be reminded once and never after. + we're failing to convey the usefuleness of the feature of building gradually harded reminders for the partner. Also added forcecreate="False" in snailmail demo data, because we don't waznt to recreate the missing xml ids (if people deleted it) in every module's update. task-4334758 Forward-Port-Of: odoo/enterprise#74236
**Steps to reproduce the bug:** - Create a storable product: - "Finished Product" with the following BoM: - Component: 1 unit of "C1" - Byproducts: - 1 unit of "By-product 1" - 1 unit of "By-product 2" - Create a manufacturing order to produce 5 units of the finished product. - Confirm the MO. - Set the quantity produced to 5 units. - Set the quantity of byproducts to: - By-product 1: 4 units - By-product 2: 3 units - Validate the MO. - Print
Original PR description
**Steps to reproduce the bug:**
- Create a storable product:
- "Finished Product" with the following BoM:
- Component: 1 unit of "C1"
- Byproducts:
- 1 unit of "By-product 1"
- 1 unit of "By-product 2"
- Create a manufacturing order to produce 5 units of the finished product.
- Confirm the MO.
- Set the quantity produced to 5 units.
- Set the quantity of byproducts to:
- By-product 1: 4 units
- By-product 2: 3 units
- Validate the MO.
- Print the cost analysis.
**Problem:**
The reported quantity does not show the actual quantity produced but
instead shows the "to produce" quantity.
opw-4312292
Forward-Port-Of: odoo/enterprise#75020
Forward-Port-Of: odoo/enterprise#73666Issue ===== When tracked product setting was disabled, the "Group by products" barcode setting for operation type was ignored. How to reproduce ================ - Install `stock_barcode_picking_batch`; - Ensure "Lots & Serial Numbers" is disabled, to be sure, go in Inventory > Configuration > Settings; - Now, go in Configuration > Operation Type > Receipts > Barcode App, and check "Group batch lines"; - Create a receipt for a product and confirm it; - Duplicate this receipt and co
Original PR description
Issue ===== When tracked product setting was disabled, the "Group by products" barcode setting for operation type was ignored. How to reproduce ================ - Install `stock_barcode_picking_batch`; - Ensure "Lots & Serial Numbers" is disabled, to be sure, go in Inventory > Configuration > Settings; - Now, go in Configuration > Operation Type > Receipts > Barcode App, and check "Group batch lines"; - Create a receipt for a product and confirm it; - Duplicate this receipt and confirm it aswell; - Add these two pickings in a batch and open it in the Barcode app -> You can see the lines for the same product are not grouped. Cause ===== The issue was, in the `BarcodeModel` code, we skip the method who group the lines if tracking is disabled. [task-4291149](https://www.odoo.com/odoo/project.task/4353554) Forward-Port-Of: odoo/enterprise#74821 Forward-Port-Of: odoo/enterprise#74696
### Before this PR: If you create new internal transfer with src location WH/Stock and than you scan a package that is on a sublocation of WH/Stock , the source location on the line is not set as the location of the package so when you validate in this situation an error pops because Odoo try to take the package from a different location of the package ### After this PR: The right location id is taken from the stock.quant and put on the line created Forward-Port-Of: odoo/enterprise#75212 F
Original PR description
### Before this PR: If you create new internal transfer with src location WH/Stock and than you scan a package that is on a sublocation of WH/Stock , the source location on the line is not set as the location of the package so when you validate in this situation an error pops because Odoo try to take the package from a different location of the package ### After this PR: The right location id is taken from the stock.quant and put on the line created Forward-Port-Of: odoo/enterprise#75212 Forward-Port-Of: odoo/enterprise#74704
*: web_grid, web_map This commit contains the enterprise adaptations, using the new props 'toggler' for the SearchBar component. This will make the component automatically be focused on mobile devices. task-4269494 Forward-Port-Of: odoo/enterprise#75173
Original PR description
*: web_grid, web_map This commit contains the enterprise adaptations, using the new props 'toggler' for the SearchBar component. This will make the component automatically be focused on mobile devices. task-4269494 Forward-Port-Of: odoo/enterprise#75173
steps to reproduce: - Install documents_account - In Settings -> File centralization -> Activate "Accounting" - Then click on Journals below - Then add Jounal: Vendor Bill, Workspace: Finance - Then upload a file in the app Documents, in the workspace Finance - Select that file and update the partner to Azure Interior - Click on the action "Create Vendor Bill" The partner "Azure Interior" is not set on the created account move while it should. For fixing this adding ``partner_id`` o
Original PR description
steps to reproduce: - Install documents_account - In Settings -> File centralization -> Activate "Accounting" - Then click on Journals below - Then add Jounal: Vendor Bill, Workspace: Finance - Then…
steps to reproduce: - Install documents_account - In Settings -> File centralization -> Activate "Accounting" - Then click on Journals below - Then add Jounal: Vendor Bill, Workspace: Finance - Then upload a file in the app Documents, in the workspace Finance - Select that file and update the partner to Azure Interior - Click on the action "Create Vendor Bill" The partner "Azure Interior" is not set on the created account move while it should. For fixing this adding ``partner_id`` of document if present. Now question may arise why account.move having null partner_id. because it being [set](https://github.com/odoo/enterprise/blob/64fc38a80520cfeeb81c0bb329c6b24c3e9454e1/documents_account/models/documents_workflow_rule.py#L77) after creating [attachment](https://github.com/odoo/enterprise/blob/64fc38a80520cfeeb81c0bb329c6b24c3e9454e1/documents_account/models/documents_workflow_rule.py#L76) and during create attachment ``document.partner_id`` is set to null and issue is raised. opw-4077356 Forward-Port-Of: odoo/enterprise#75240 Forward-Port-Of: odoo/enterprise#74875
Since `xlrd >= 2.0` dropped XLSX support, we use `openpyxl` to open XLSX files if the `xlrd >= 2.0` is installed.[^1] However, the tests in `account_base_import` are skipped unless `xlrd.xlsx` can be imported. As a result, they are not run on runbot, where `xlrd >= 2.0` is installed. We therefore need to avoid skipping them if openpyxl is installed. runbot-108001 [^1]: https://github.com/odoo/odoo/pull/169245 Forward-Port-Of: odoo/enterprise#74790 Forward-Port-Of: odoo/enterprise#74
Original PR description
Since `xlrd >= 2.0` dropped XLSX support, we use `openpyxl` to open XLSX files if the `xlrd >= 2.0` is installed.[^1] However, the tests in `account_base_import` are skipped unless `xlrd.xlsx` can be imported. As a result, they are not run on runbot, where `xlrd >= 2.0` is installed. We therefore need to avoid skipping them if openpyxl is installed. runbot-108001 [^1]: https://github.com/odoo/odoo/pull/169245 Forward-Port-Of: odoo/enterprise#74790 Forward-Port-Of: odoo/enterprise#74608
Add basic support for South Korean financial reports: - Profit and Loss - Balance Sheet Task ID: 4018370 Forward-Port-Of: odoo/enterprise#74143
Original PR description
Add basic support for South Korean financial reports: - Profit and Loss - Balance Sheet Task ID: 4018370 Forward-Port-Of: odoo/enterprise#74143
In a production setup: - Create an invoice and sign it - Ask for a cancellation rejected by the customer => an invoice_request_cancel document is created - Ask for another cancellation request => another invoice_request_cancel document is created - Trigger the SAT to approve the second cancellation request => The first invoice_request_cancel document is unlink. Forward-Port-Of: odoo/enterprise#74753
Original PR description
In a production setup: - Create an invoice and sign it - Ask for a cancellation rejected by the customer => an invoice_request_cancel document is created - Ask for another cancellation request => another invoice_request_cancel document is created - Trigger the SAT to approve the second cancellation request => The first invoice_request_cancel document is unlink. Forward-Port-Of: odoo/enterprise#74753
LNE Certification (scales certification) requires not to be able to reboot the IoT Box with a simple button. We removed it from the IoT Box form view. Community PR: [https://github.com/odoo/odoo/pull/189467](https://github.com/odoo/odoo/pull/189467) Task: 4345731 Forward-Port-Of: odoo/enterprise#75161 Forward-Port-Of: odoo/enterprise#75074
Original PR description
LNE Certification (scales certification) requires not to be able to reboot the IoT Box with a simple button. We removed it from the IoT Box form view. Community PR: [https://github.com/odoo/odoo/pull/189467](https://github.com/odoo/odoo/pull/189467) Task: 4345731 Forward-Port-Of: odoo/enterprise#75161 Forward-Port-Of: odoo/enterprise#75074
Since [1], the export wizard default export data domain has changed but it was not at all in the scope of the faulty commit. This leads to a validation error when a new wizard is created if there is multiple 'ir.model.data' records created in the context of Studio and pointing to the same records. This is often the case for instance for 'ir.model.inherit' records. This commit reintroduces the missing domain part, while adding a test. [1]: https://github.com/odoo/enterprise/commit/99f35
Original PR description
Since [1], the export wizard default export data domain has changed but it was not at all in the scope of the faulty commit. This leads to a validation error when a new wizard is created if there is multiple 'ir.model.data' records created in the context of Studio and pointing to the same records. This is often the case for instance for 'ir.model.inherit' records. This commit reintroduces the missing domain part, while adding a test. [1]: https://github.com/odoo/enterprise/commit/99f3591316891e1c2373ed0b3b7e786c0a6b8457 Forward-Port-Of: odoo/enterprise#75078
In this commit, we fix knowledge_article_commands_tour by adapting the steps that concern the odoo editor in order to reactivate this tour. Forward-Port-Of: odoo/enterprise#75174
Original PR description
In this commit, we fix knowledge_article_commands_tour by adapting the steps that concern the odoo editor in order to reactivate this tour. Forward-Port-Of: odoo/enterprise#75174
Steps: - Create a new helpdesk team. - Open tickets of that team. - Delete all ticket stages Issue: - If all the stages are deleted then the blank screen appears instead of shadow data. Cause: - Only `helpdesk.ticket` was being validated, but `helpdesk.stage.delete.wizard` was not included in the check. Fix: - The issue has been fixed by replacing active_model with default_team_id. task-4290529 Forward-Port-Of: odoo/enterprise#75251 Forward-Port-Of: odoo/enterprise#72954
Original PR description
Steps: - Create a new helpdesk team. - Open tickets of that team. - Delete all ticket stages Issue: - If all the stages are deleted then the blank screen appears instead of shadow data. Cause: - Only `helpdesk.ticket` was being validated, but `helpdesk.stage.delete.wizard` was not included in the check. Fix: - The issue has been fixed by replacing active_model with default_team_id. task-4290529 Forward-Port-Of: odoo/enterprise#75251 Forward-Port-Of: odoo/enterprise#72954
Withholding tax information is missing when printing report 'Delivery Guide SII DTE 52 (CL)' from a delivery Steps to reproduce: - With a CL Company setup - Have a product with main 19% tax and a withholding tax - Create a SO with the product - Confirm - Open Delivery - Validate - Print menu > Delivery Guide SII DTE 52 (CL) Issue: Only VAT 19% tax is present in the report, withholding tax is missing (even if the total is correct) This occurs because the 'withholding' var is inside
Original PR description
Withholding tax information is missing when printing report 'Delivery Guide SII DTE 52 (CL)' from a delivery Steps to reproduce: - With a CL Company setup - Have a product with main 19% tax and a withholding tax - Create a SO with the product - Confirm - Open Delivery - Validate - Print menu > Delivery Guide SII DTE 52 (CL) Issue: Only VAT 19% tax is present in the report, withholding tax is missing (even if the total is correct) This occurs because the 'withholding' var is inside another dict Issue2: 'tax_name' is not present in the rendered data, so we need to add it Issue3: withholding amount will be shown without associated currency opw-4214377 Forward-Port-Of: odoo/enterprise#75196 Forward-Port-Of: odoo/enterprise#73926
[FIX] documents: fix error when creating vendor bill from split tool How to reproduce: - Install documents_account - In Document App, folder “Finance”, select 2 pdf - Click on Action -> Merge PDFs - Click on “Create Vendor Bill” You get an error “psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update” The error was caused by the update of the pdf preview during the execution of the action “Create Vendor Bill” (which both update the document). We so
Original PR description
[FIX] documents: fix error when creating vendor bill from split tool How to reproduce: - Install documents_account - In Document App, folder “Finance”, select 2 pdf - Click on Action -> Merge PDFs -…
[FIX] documents: fix error when creating vendor bill from split tool How to reproduce: - Install documents_account - In Document App, folder “Finance”, select 2 pdf - Click on Action -> Merge PDFs - Click on “Create Vendor Bill” You get an error “psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update” The error was caused by the update of the pdf preview during the execution of the action “Create Vendor Bill” (which both update the document). We solve the problem by waiting the execution of the action before executing the rest (especially the update of the preview). [FIX] documents: fix traceback after some action How to reproduce: - Install documents_account - In Document App, folder “Finance”, select 2 pdf - Click on Action -> Merge PDFs - Remove the scissors to merge the 2 documents - Click on “Create Vendor Bill” You get the error: Cannot read properties of null (reading "querySelectorAll"). This is the most reliable way to reproduce the problem but that problem occurs also in other circumstances, for example sometimes when moving to trash documents after some other actions. We solve the problem by returning an empty selection when there are no element. Task-4381458 Forward-Port-Of: odoo/enterprise#75142
Add check if date string is not equal to "000000" before parsing it, in record types that were missing this check. Some banks provide CODA files with the date set to "000000" which caused the `_parse_bank_statement_file` method to raise an exception and fail to parse such files. Using the `statement['date']` as a fallback in such case, as it is already used for `balance_start_date` and `transactionDate` fields. task-4348031 Forward-Port-Of: odoo/enterprise#74640
Original PR description
Add check if date string is not equal to "000000" before parsing it, in record types that were missing this check. Some banks provide CODA files with the date set to "000000" which caused the `_parse_bank_statement_file` method to raise an exception and fail to parse such files. Using the `statement['date']` as a fallback in such case, as it is already used for `balance_start_date` and `transactionDate` fields. task-4348031 Forward-Port-Of: odoo/enterprise#74640
To reproduce: ============= 1. Go to Documents app 2. Upload a PDF file (one of the attached on the opw) 3. Click on the file to open it 4. Click on the "Split" button the pages on the preview are not displayed correctly Problem: ======== these pdf files, the pages are rotated by 270 degrees so when splitting the pages, the rotation is not taken into account and set to 0 degrees Solution: ========= - set the rotation of the pages to the original rotation when splitting the pdf
Original PR description
To reproduce: ============= 1. Go to Documents app 2. Upload a PDF file (one of the attached on the opw) 3. Click on the file to open it 4. Click on the "Split" button the pages on the preview are not displayed correctly Problem: ======== these pdf files, the pages are rotated by 270 degrees so when splitting the pages, the rotation is not taken into account and set to 0 degrees Solution: ========= - set the rotation of the pages to the original rotation when splitting the pdf opw-4216158 Forward-Port-Of: odoo/enterprise#75011
Currently, a traceback occurs when the user tries to update the planning slot but has no recurrence. To reproduce this issue: 1) Install planning 2) Open any existing Open Shift planning slot 3) Enable the `repeat` and update the start and end date 4) Give the edit value as `All shifts` and make sure the resource be empty 5) Save the record. Error:- ``` IndexError: tuple index out of range ``` Here the `resource` is not required in planning slot. So, when the user tries to
Original PR description
Currently, a traceback occurs when the user tries to update the planning slot but has no recurrence. To reproduce this issue: 1) Install planning 2) Open any existing Open Shift planning slot 3)…
Currently, a traceback occurs when the user tries to update the planning slot but has no recurrence. To reproduce this issue: 1) Install planning 2) Open any existing Open Shift planning slot 3) Enable the `repeat` and update the start and end date 4) Give the edit value as `All shifts` and make sure the resource be empty 5) Save the record. Error:- ``` IndexError: tuple index out of range ``` Here the `resource` is not required in planning slot. So, when the user tries to update an open shift with the `repeat` enabled and `resource_update` as `all`, it leads to a traceback from the below line. https://github.com/odoo/enterprise/blob/64fc38a80520cfeeb81c0bb329c6b24c3e9454e1/planning/models/planning.py#L866-L871 This is because when there is no `recurrence_slots` in the slot, we get an empty recordset for the `recurrence_slots`, which leads to the above traceback when trying to extract a value from the recurrency_slots. We can resolve this issue by adding an extra check of `recurrence_slots` which makes the code more robust. sentry-6096445646 Forward-Port-Of: odoo/enterprise#75134 Forward-Port-Of: odoo/enterprise#74866
### Steps to reproduce: - In the settings: enable multi-steps route - Inventory > Configuration > Warehouse Management > Routes - Unarchive MTO - Create a storable prodcut with MTO, buy routes and a set vendor - Create and confirm a sale order for 3 units of your product - Confirm the purchase order and the associated reciept - Go to the barcode app on you delivery - set the quantity to 1/3 and leave the barcode app - Go back to the the delivery ### > only one line 1/1 appears ###
Original PR description
### Steps to reproduce: - In the settings: enable multi-steps route - Inventory > Configuration > Warehouse Management > Routes - Unarchive MTO - Create a storable prodcut with MTO, buy routes and a…
### Steps to reproduce: - In the settings: enable multi-steps route - Inventory > Configuration > Warehouse Management > Routes - Unarchive MTO - Create a storable prodcut with MTO, buy routes and a set vendor - Create and confirm a sale order for 3 units of your product - Confirm the purchase order and the associated reciept - Go to the barcode app on you delivery - set the quantity to 1/3 and leave the barcode app - Go back to the the delivery ### > only one line 1/1 appears ### Cause of the issue: The barcode app relies on stock move lines to work properly. These move lines are even in correspondance with the barcode lines. When you update a line in the barcode to be 1/3 and then leave the app, to keep track of the demand, the app split the moves in 2: https://github.com/odoo/enterprise/blob/69338098f5407a01b4ddcb8b18bc82cf9d7cb4d5/stock_barcode/models/stock_move.py#L9-L11 To create the new barcode lines, it is therefore expected that new move lines will be created by this call for the splitted move. which is the purpose of this line: https://github.com/odoo/enterprise/blob/69338098f5407a01b4ddcb8b18bc82cf9d7cb4d5/stock_barcode/models/stock_move.py#L37 However, this will only work for moves whose procure method is not MTO because mto moves are not confirmed but flaged as waiting and hence not assigned by the `_action_confirm`: https://github.com/odoo/odoo/blob/e7b269206fa125532c9e3ab6ed2b632198199cd8/addons/stock/models/stock_move.py#L1356-L1362 https://github.com/odoo/odoo/blob/e7b269206fa125532c9e3ab6ed2b632198199cd8/addons/stock/models/stock_move.py#L1380 https://github.com/odoo/odoo/blob/e7b269206fa125532c9e3ab6ed2b632198199cd8/addons/stock/models/stock_move.py#L1418-L1422 As a result no move line will be generated for these splitted mto moves and there will be no stock move line for the barcode to rely on. opw-4232106 --- Forward-Port-Of: odoo/enterprise#74874 Forward-Port-Of: odoo/enterprise#73773
### Steps to reproduce: - Create two storable product: Final Product (FP) and Component (COMP) - Create and confirm an MO for FP with a raw move: 1 x COMP > The move should be: "not available" since 0 unit of COMP are in Stock - Go to the barcode module > Operations > Manufacturing - Remove the MO Ready filter > Click on your MO and then exit barcode - Go back to the MO in the back end (mrp module) #### > The raw move has been reserved and is hence marked as available. ### Cause of the
Original PR description
### Steps to reproduce: - Create two storable product: Final Product (FP) and Component (COMP) - Create and confirm an MO for FP with a raw move: 1 x COMP > The move should be: "not available" since…
### Steps to reproduce: - Create two storable product: Final Product (FP) and Component (COMP) - Create and confirm an MO for FP with a raw move: 1 x COMP > The move should be: "not available" since 0 unit of COMP are in Stock - Go to the barcode module > Operations > Manufacturing - Remove the MO Ready filter > Click on your MO and then exit barcode - Go back to the MO in the back end (mrp module) #### > The raw move has been reserved and is hence marked as available. ### Cause of the issue: Exiting the barcode will launch an rpc call of the `split_uncompleted_moves` in order to split uncomplete moves in 2 if necessary (for the records to be appropriately set the next time you enter the barcode): https://github.com/odoo/enterprise/blob/71f979d5bdf88207cb94c83bd6a69633da649d1e/stock_barcode/static/src/models/barcode_picking_model.js#L1327-L1329 https://github.com/odoo/enterprise/blob/71f979d5bdf88207cb94c83bd6a69633da649d1e/stock_barcode/models/stock_move.py#L9-L11 Furthermore, since c29f61fdded2e80d0bb3c06199c6a196feac8076 in case of a production the component move are rather splitted on the move lines to avoid odd split of the component moves on the MO. However, in that case if a unassigned move is splitted, a move line will be generated and associated to that move, which makes it reserved and hence available. opw-4338827 --- Forward-Port-Of: odoo/enterprise#74244
Before this commit, the test fails due to the changes made in community to avoid having an access token if the project visibility is private. This commit makes sure the project visibility is `portal` to be able to set an access token as before. opw-4104804 task-4354145 Forward-Port-Of: odoo/enterprise#75115
Original PR description
Before this commit, the test fails due to the changes made in community to avoid having an access token if the project visibility is private. This commit makes sure the project visibility is `portal` to be able to set an access token as before. opw-4104804 task-4354145 Forward-Port-Of: odoo/enterprise#75115
For attendance based contract do not split generated work entries around lunch Steps --- * Create a running contract for some employee that uses a schedule with * `work_entry_source = 'attendance'` * Create an attendance overlapping lunch for the employee * (e.g 10:00 -> 20:00) * => 2 work entries are generated: * 10 - 12 * 13 - 20 * We want only one: 10 - 20 task-4252156 Forward-Port-Of: odoo/enterprise#71979
Original PR description
For attendance based contract do not split generated work entries around lunch Steps --- * Create a running contract for some employee that uses a schedule with * `work_entry_source = 'attendance'` * Create an attendance overlapping lunch for the employee * (e.g 10:00 -> 20:00) * => 2 work entries are generated: * 10 - 12 * 13 - 20 * We want only one: 10 - 20 task-4252156 Forward-Port-Of: odoo/enterprise#71979
Now we have an helper ensuring the consistency between the computation of the tax totals in both python & javascript, let's use it. task-id: 4280495 Related: https://github.com/odoo/odoo/pull/183299 Forward-Port-Of: odoo/enterprise#72597
Original PR description
Now we have an helper ensuring the consistency between the computation of the tax totals in both python & javascript, let's use it. task-id: 4280495 Related: https://github.com/odoo/odoo/pull/183299 Forward-Port-Of: odoo/enterprise#72597
server actions that use document tag should be noupdate as well because document tag records are noupdate, and they could be deleted by clients. possible steps to reproduce: 1) make a database 17.0 2) delete document tags 3) upgrade the database to 18.0 Document tags and server actions should be recreated in upgrade scripts when upgrading to 18.0 if they are missing. Setting the noupdate=1, makes sure that they are not recreated on subsequent updates or upgrades after reaching 18.0. o
Original PR description
server actions that use document tag should be noupdate as well because document tag records are noupdate, and they could be deleted by clients. possible steps to reproduce: 1) make a database 17.0 2) delete document tags 3) upgrade the database to 18.0 Document tags and server actions should be recreated in upgrade scripts when upgrading to 18.0 if they are missing. Setting the noupdate=1, makes sure that they are not recreated on subsequent updates or upgrades after reaching 18.0. odoo/upgrade#6803 Forward-Port-Of: odoo/enterprise#73108
Versions: - 18.0 Steps to Reproduce: - Go to Recurring Plan. - Click on the "Subscription Items" button. - Create a new item and save it. Issue: - An error occurs when saving a new subscription item. Cause: - create method of the sale.order.line model when ensure_one was called on an empty recordset. Solution: - Fixed a ValueError occurring in the create method of the sale.order.line model when ensure_one was called on an empty recordset. Added validation to prevent
Original PR description
Versions: - 18.0 Steps to Reproduce: - Go to Recurring Plan. - Click on the "Subscription Items" button. - Create a new item and save it. Issue: - An error occurs when saving a new subscription item. Cause: - create method of the sale.order.line model when ensure_one was called on an empty recordset. Solution: - Fixed a ValueError occurring in the create method of the sale.order.line model when ensure_one was called on an empty recordset. Added validation to prevent attempts to unpack values from an empty recordset, ensuring smoother operation during sales order line creation and preventing RPC errors in the frontend. Forward-Port-Of: odoo/enterprise#70525
## Issue: - The Cost Analysis report does not accurately reflect the quantity manufactured of a product or the correct cost per unit. ## Steps to reproduce: - Create a manufactured product and two components with costs and on hand quantities. - Confirm a manufacturing order for the product. - Adjust the manufactured quantity of the manufactured product. - Notice that the cost analysis report does not reflect the correct quantity manufactured or the correct cost per unit. ## Solution:
Original PR description
## Issue: - The Cost Analysis report does not accurately reflect the quantity manufactured of a product or the correct cost per unit. ## Steps to reproduce: - Create a manufactured product and two components with costs and on hand quantities. - Confirm a manufacturing order for the product. - Adjust the manufactured quantity of the manufactured product. - Notice that the cost analysis report does not reflect the correct quantity manufactured or the correct cost per unit. ## Solution: - Updated the calculation of `mo_qty` to sum the 'quantity' field instead of `product_qty`. opw-4118237 Forward-Port-Of: odoo/enterprise#74892 Forward-Port-Of: odoo/enterprise#70727
### Description When opening a report with a lot of data to display, getting some values can be very costly. In this case, for the depreciation schedule, we are retrieving the column expression and currency symbol each time if not found in `_build_column_dict`. To avoid retrieving a value that was already fetched, we can pass the currency and the expression directly. This reduces unnecessary `__get__` calls. ### Benchmark (made in 17.0) | N° of assets | Before | After | |------
Original PR description
### Description When opening a report with a lot of data to display, getting some values can be very costly. In this case, for the depreciation schedule, we are retrieving the column expression and currency symbol each time if not found in `_build_column_dict`. To avoid retrieving a value that was already fetched, we can pass the currency and the expression directly. This reduces unnecessary `__get__` calls. ### Benchmark (made in 17.0) | N° of assets | Before | After | |--------------|---------|--------| | 500 | 2 s | 1.55 s | | 7k | 20 s | 19 s | | 17k | 50 s | 41 s | ### Reference opw-4287192 Forward-Port-Of: odoo/enterprise#75170 Forward-Port-Of: odoo/enterprise#74085
Improve kanban cards: - Avoid having empty spaces and optimize space - Prevent displaying too much info by only displaying some on hover. The favorite toggle, the activities widget, the "only accessible by link" icon. - Prevent displaying large urls by hiding them behind icons. Improve list view UI: - Reorder fields - Add favorite field - Give a name to the type field in the tree view fields configurator. - When it is a shortcut, display the target document icon instead of the sho
Original PR description
Improve kanban cards: - Avoid having empty spaces and optimize space - Prevent displaying too much info by only displaying some on hover. The favorite toggle, the activities widget, the "only accessible by link" icon. - Prevent displaying large urls by hiding them behind icons. Improve list view UI: - Reorder fields - Add favorite field - Give a name to the type field in the tree view fields configurator. - When it is a shortcut, display the target document icon instead of the shortcut icon. Changing the keys: - Open a folder / preview a file: single click (previously double click) - Select a folder / file: ctrl+click (previously single click) - Make a selection range: shift+click (same as previously) => It wasn't natural for users to open a folder / preview a file by double clicking. It also required a lot of clicks to navigate. Task-4294457 Forward-Port-Of: odoo/enterprise#73078
Two flows are fixed and tested in this PR: A/ 1. Create a document outside a project's folder 2. Link the document to a project/task without moving it 3. The document's access_internal value is not synced with the privacy visibility as it would have if we had moved it inside the project's folder instead B/ 1. Create a document in a project's folder with privacy visibility 'employees' 2. Move the document outside the project's folder 3. Update the privacy_visibility to 'followers' 4.
Original PR description
Two flows are fixed and tested in this PR: A/ 1. Create a document outside a project's folder 2. Link the document to a project/task without moving it 3. The document's access_internal value is not synced with the privacy visibility as it would have if we had moved it inside the project's folder instead B/ 1. Create a document in a project's folder with privacy visibility 'employees' 2. Move the document outside the project's folder 3. Update the privacy_visibility to 'followers' 4. The document is still accessible to all internal users while it shouldn't Note: _add_missing_default_values was an unused remnant of a distant idea Task-4242299 Forward-Port-Of: odoo/enterprise#71485
Fixed a series of issues related to flexible and fully flexible resource introduced in task 3762895. In this PR, the following issues are fixed in the planning app: - In dark mode, the progress bar of resources working fully flexible hours had white background instead of transparent. Step to reproduce: 1. Open the gantt view, create a resource with fully flexible hours and assign it to a task. 2. The progress bar should not have a white background on dark mode. - Fully flexible e
Original PR description
Fixed a series of issues related to flexible and fully flexible resource introduced in task 3762895. In this PR, the following issues are fixed in the planning app: - In dark mode, the progress bar…
Fixed a series of issues related to flexible and fully flexible resource introduced in task 3762895. In this PR, the following issues are fixed in the planning app:
- In dark mode, the progress bar of resources working fully flexible hours had white background instead of transparent. Step to reproduce:
1. Open the gantt view, create a resource with fully flexible hours and assign it to a task.
2. The progress bar should not have a white background on dark mode.
- Fully flexible employee Suman Oza had no hourly cost set in demo data. Step to reproduce:
1. Go to the employees view and search for Suman Oza.
2. The hourly cost should be no longer be set to 0.
- Flexible employee should have the period outside of their contract grayed in the Gantt view Step to reproduce:
1. Create a resource with flexible hours.
2. Set a contract with a start and end date.
3. Open the gantt view in planning, and search for the resource.
4. The period outside of the contract should be grayed.
- In gantt view sparse mode view, the color of the progress bar (the thin line above each employee and each day) of resources working fully flexible hours should be always in purple color. Step to reproduce:
1. Create a resource with fully flexible hours.
2. Create some shifts for the resource.
3. Open the gantt view in sparse mode.
4. The progress bar should be in purple color.
- Recurring shifts for fully flexible employees are now assigned even if they generate conflicts with existing shifts. (test was added to ensure this behavior) Step to reproduce:
1. Create an employee working fully flexible hours.
2. Plan some shifts for the employee.
3. Create a recurring shift for the employee which ovelaps with the existing shifts.
4. The recurring shifts should be assigned to the employee even if they generate conflicts with existing shifts.
task-id: 4189386
Forward-Port-Of: odoo/enterprise#73477Versions -------- - 17.0+ Community: https://github.com/odoo/odoo/pull/188440 >[!important] >All functional changes are made in `sale`, this PR simply adds a test. Steps ----- 1. Have a confirmed subscription; 2. go to subscription management in portal; 3. set or change payment method. Issue ----- The following email is sent: > A payment [...] amounting $ 0.00 for [...] has been confirmed. Cause ----- The `_reconcile_after_done` override in `sale` sends a payment succe
Original PR description
Versions -------- - 17.0+ Community: https://github.com/odoo/odoo/pull/188440 >[!important] >All functional changes are made in `sale`, this PR simply adds a test. Steps ----- 1. Have a confirmed…
Versions -------- - 17.0+ Community: https://github.com/odoo/odoo/pull/188440 >[!important] >All functional changes are made in `sale`, this PR simply adds a test. Steps ----- 1. Have a confirmed subscription; 2. go to subscription management in portal; 3. set or change payment method. Issue ----- The following email is sent: > A payment [...] amounting $ 0.00 for [...] has been confirmed. Cause ----- The `_reconcile_after_done` override in `sale` sends a payment succeeded mail for any sale order linked to a transaction that wasn't confirmed by that transaction. It currently assumes all the transactions in `self` are actual payment operations, as any `validation` gets filtered out in `_finalize_post_processing`, before `_reconcile_after_done` is called[^1]. This assumption no longer holds with `sale_subscription` installed, which also calls `_reconcile_after_done` on validation transactions to manage payment tokens linked to subscriptions[^2]. Solution -------- Filter out `validation` transactions before calling `_send_payment_succeeded_for_order_mail` on linked orders. opw-4169491 [^1]: https://github.com/odoo/odoo/blob/12de68d342b/addons/payment/models/payment_transaction.py#L998-L1003 [^2]: https://github.com/odoo/enterprise/blob/bbd1be56538/sale_subscription/models/payment_transaction.py#L135-L144 Forward-Port-Of: odoo/enterprise#75046 Forward-Port-Of: odoo/enterprise#74626
Before this commit, if the user set a database with two preparation displays, both displaying the same products and orders, duplication of the order could happen. Steps to reproduce the issue: 1. configure a pos_restaurant 2. configure 2 kitchen displays (disp1 and disp2) 3. Open the restaurant and create and order with 3-4 items (items would belong to the same category, ideally) 4. on disp1, proceed to tick/mark as done 2 items 5. on disp1, press on the header of the order -> this will
Original PR description
Before this commit, if the user set a database with two preparation displays, both displaying the same products and orders, duplication of the order could happen. Steps to reproduce the issue: 1.…
Before this commit, if the user set a database with two preparation displays, both displaying the same products and orders, duplication of the order could happen. Steps to reproduce the issue: 1. configure a pos_restaurant 2. configure 2 kitchen displays (disp1 and disp2) 3. Open the restaurant and create and order with 3-4 items (items would belong to the same category, ideally) 4. on disp1, proceed to tick/mark as done 2 items 5. on disp1, press on the header of the order -> this will split the order, sending the done items to the next stage. 6. back in the POS, create a new order (any table) 7. on disp2, you will see a wrong duplication of the order the was split at the previous step number 5 The duplication would happen even if the order (and related split) are marked as done on both disp1 and disp2. What that means in the client flow is that you could have completely processed the order at both stations, and have it reappear at one of them. In practice, since inter-station communication is not always possible, it could lead to the staff preparing the same order multiple times. This in turn would incur losses because of the wasted orders and increased delays in processing other legitimate orders. After this commit, the other preparation displays (disp2 in my example above) get notified immediately of the change and update their respective statuses to reflect the order split. opw-4367937 Forward-Port-Of: odoo/enterprise#74816
**Steps to reproduce:** - Install Accounting - Create a Branch company without COA - Switch to the Branch company - Go to "Accounting / Accounting / Management / Assets" - Create an asset - Try to select an account for "Fixed Asset Account", "Depreciation Account" or "Expense Account" **Issue:** The list is empty. The accounts from the parent company should be proposed. opw-4368887 Forward-Port-Of: odoo/enterprise#75094 Forward-Port-Of: odoo/enterprise#75034
Original PR description
**Steps to reproduce:** - Install Accounting - Create a Branch company without COA - Switch to the Branch company - Go to "Accounting / Accounting / Management / Assets" - Create an asset - Try to select an account for "Fixed Asset Account", "Depreciation Account" or "Expense Account" **Issue:** The list is empty. The accounts from the parent company should be proposed. opw-4368887 Forward-Port-Of: odoo/enterprise#75094 Forward-Port-Of: odoo/enterprise#75034
Forward-Port-Of: odoo/enterprise#74926 Forward-Port-Of: odoo/enterprise#74889
Original PR description
Forward-Port-Of: odoo/enterprise#74926 Forward-Port-Of: odoo/enterprise#74889
Steps to reproduce: - create a spreadsheet - Freeze and Share this spreadsheet - go to a pivot view and hit "Insert in spreadsheet" => the frozen spreadsheet is included in the dialog Task: 4353076 Forward-Port-Of: odoo/enterprise#74337
Original PR description
Steps to reproduce: - create a spreadsheet - Freeze and Share this spreadsheet - go to a pivot view and hit "Insert in spreadsheet" => the frozen spreadsheet is included in the dialog Task: 4353076 Forward-Port-Of: odoo/enterprise#74337
The previous fix (odoo/enterprise#74860) was incomplete as out of range date also have the .o_date_item_cell class. Runbot Error 108371 Forward-Port-Of: odoo/enterprise#74956
Original PR description
The previous fix (odoo/enterprise#74860) was incomplete as out of range date also have the .o_date_item_cell class. Runbot Error 108371 Forward-Port-Of: odoo/enterprise#74956
Added the "identification_id" to all the "hr.employee" records to ba able to create the "DECSAL" report Task: 4334816 Forward-Port-Of: odoo/enterprise#74975
Original PR description
Added the "identification_id" to all the "hr.employee" records to ba able to create the "DECSAL" report Task: 4334816 Forward-Port-Of: odoo/enterprise#74975
To avoid everyone creating his own template and making noise in the official list. If a user want to use his own template he can have a dedicated and private knowledge sheet for that. task-4366949 Forward-Port-Of: odoo/enterprise#74771
Original PR description
To avoid everyone creating his own template and making noise in the official list. If a user want to use his own template he can have a dedicated and private knowledge sheet for that. task-4366949 Forward-Port-Of: odoo/enterprise#74771
Problem ---------- In th salary configurator, The display "group by category" for dropdown is broken in 18.0 due to framework task. Objective ---------- Make it works again like in 17.4. Group options by optgroup Solution ---------- add groups in the state and fill it with label of groups (attribute in optgroup) and all the choices (options inside optgroup) task-4350875 Forward-Port-Of: odoo/enterprise#74304
Original PR description
Problem ---------- In th salary configurator, The display "group by category" for dropdown is broken in 18.0 due to framework task. Objective ---------- Make it works again like in 17.4. Group options by optgroup Solution ---------- add groups in the state and fill it with label of groups (attribute in optgroup) and all the choices (options inside optgroup) task-4350875 Forward-Port-Of: odoo/enterprise#74304
To reproduce the issue: - Enable Avatax in Accounting settings - Go to the 'All' product category and set Avatax Category '[D0000000] Digital goods' - Create a subscription order and set Deco Addict as the customer (is exempt) - Set the Avatax fiscal position - Confirm the order - Preview in portal view - Notice the tax is not equal The subscription portal view was changed in #49963 to only display lines to be invoiced. So non-recurring lines were no longer shown. Because of this, th
Original PR description
To reproduce the issue: - Enable Avatax in Accounting settings - Go to the 'All' product category and set Avatax Category '[D0000000] Digital goods' - Create a subscription order and set Deco Addict…
To reproduce the issue: - Enable Avatax in Accounting settings - Go to the 'All' product category and set Avatax Category '[D0000000] Digital goods' - Create a subscription order and set Deco Addict as the customer (is exempt) - Set the Avatax fiscal position - Confirm the order - Preview in portal view - Notice the tax is not equal The subscription portal view was changed in #49963 to only display lines to be invoiced. So non-recurring lines were no longer shown. Because of this, the regular `tax_totals` field cannot be used in the portal anymore. Tax totals need to be recomputed for just those lines. This was done in a new method: `_next_billing_details()`. This method recomputes tax totals using account.tax records, which won't be correct in many cases when using an external tax calculator. The percentage field that we set on the tax is only informational, and won't take exemptions into account. Up to this point, the issue was only cosmetic. The customer was still charged the correct amount. This changed in #72120. Instead of charging `amount_to_invoice`, it now charges the amount calculated by `_next_billing_details()`. This, as stated above, won't always be correct. To resolve the problem we first override `_next_billing_details()` so that it returns `tax_totals` based on line amounts. Those fields are the authoritative amounts that we set during external tax calculation [1]. This solves the cosmetic issue described above in most cases. However, the wrong totals are still displayed right after paying a subscription. This happens because the payment changes the state of the subscription, which invalidates the line amounts and recomputes them from `account.tax` again. We already overrode the `/my/subscriptions` controller to insert an external calculation and avoid this, but it happened after `super()` which is too late. At that point `_next_billing_details()` is already evaluated, with the incorrect values already in `qcontext`. To solve that we move the call before `super()`. We also change `next_amount_invoice` to be the sum of invoicable lines, again basing this total on the authoritative amounts returned by the external tax calculator. We cannot use `amount_to_invoice` like before, because that breaks the "Anticipate payment" feature which was fixed in #72120. This solves the issue of charging the wrong amount. opw-4315535 opw-4363065 [1] https://github.com/odoo/enterprise/blob/84aa5e2fb064bc0366e952cbd4eaf3628ea24b73/sale_external_tax/models/sale_order.py#L43-L55 PR note: built on top of #73921 Forward-Port-Of: odoo/enterprise#75028
Forward-Port-Of: odoo/enterprise#74947 Forward-Port-Of: odoo/enterprise#74033
Original PR description
Forward-Port-Of: odoo/enterprise#74947 Forward-Port-Of: odoo/enterprise#74033
Since applicants are aggregated into a candidate and the field company_id is not related between these two models. If the company is modified on a records, it won't match the one of the other model and so will create access right issues. To avoid this to hapend, we synchronize the company id between these tow models when we modify one and we use/create a candidate with the same company of the applicant on creation We also propagate the company from the applicant to the candidate, when the
Original PR description
Since applicants are aggregated into a candidate and the field company_id is not related between these two models. If the company is modified on a records, it won't match the one of the other model and so will create access right issues. To avoid this to hapend, we synchronize the company id between these tow models when we modify one and we use/create a candidate with the same company of the applicant on creation We also propagate the company from the applicant to the candidate, when the candidate is manually created from the backend. task-4350838 Forward-Port-Of: odoo/enterprise#74674
Vestion: - 18.0 Steps to reproduce: - Create sale order and confirm it. - Invoice it. - Create renew order. Issue: - The "Cancel" button is not visible on the renewal quotation. Cause: - Condition to make button invisible is checking the invoice count should be greater than 1 but in renew order it is also considering invoice count of parent order and due to that it makes button invisible. Solution: - Remove the condition that checks the invoice count. The "Cancel" button will
Original PR description
Vestion: - 18.0 Steps to reproduce: - Create sale order and confirm it. - Invoice it. - Create renew order. Issue: - The "Cancel" button is not visible on the renewal quotation. Cause: - Condition to make button invisible is checking the invoice count should be greater than 1 but in renew order it is also considering invoice count of parent order and due to that it makes button invisible. Solution: - Remove the condition that checks the invoice count. The "Cancel" button will now be displayed even if an invoice exists. Since the system already prevents users from canceling subscriptions with invoices, this change will not lead to any functional issues. Forward-Port-Of: odoo/enterprise#74234
Before this commit, when customer anticipated payment on portl, it would fail if there were already some draft invoices. This commit ensure the draft invoices are canceled before. In master, we should not create the invoice at all. taskid: 4368057 Forward-Port-Of: odoo/enterprise#74811
Original PR description
Before this commit, when customer anticipated payment on portl, it would fail if there were already some draft invoices. This commit ensure the draft invoices are canceled before. In master, we should not create the invoice at all. taskid: 4368057 Forward-Port-Of: odoo/enterprise#74811
When you have a company with branches in a database, some reports only make sense when you have the main company with all its branches selected. Currently some report actions (buttons) were disabled if you didn't have your main company and its branches selected, without any information on why the buttons were disabled. This resulted in people creating tickets because they thought something was wrong. This change makes the buttons clickable again, but instead displays a message saying that
Original PR description
When you have a company with branches in a database, some reports only make sense when you have the main company with all its branches selected. Currently some report actions (buttons) were disabled if you didn't have your main company and its branches selected, without any information on why the buttons were disabled. This resulted in people creating tickets because they thought something was wrong. This change makes the buttons clickable again, but instead displays a message saying that the user should select the main company and its branches in order to save a sensible report. [task-4260501](https://www.odoo.com/odoo/all-tasks/4260501) Forward-Port-Of: odoo/enterprise#73018