Daily updates from Odoo
Navigate
Branch
Thursday, May 23, 2024
105 changes
44 changes
New functionality added to Odoo
This update adds payroll localization for Pakistan, including salary structures, rules, payroll parameters, and accounting integration. It helps businesses in Pakistan run payroll more accurately in Odoo and aligns payroll processing with local requirements; it also removes an unused Saudi payroll contract field.
Enhancements to existing features
Users can now choose a marketing campaign template directly when creating a new campaign, or start from scratch if preferred. This makes existing templates easier to discover and use, while also allowing standard marketing users to create campaigns from templates without admin help.
Original PR description
Add a template selection dialog modal:
Marketing campaign templates had been added, but they were inaccessible
once a campaign had been created.
This commit adds a dialog modal that replaces the usual behavior when
trying to create a new campaign with the "New" buttons.
The modal allows choosing a template from a list, including a "Start
from scratch" (empty campaign) option.
The old helper is simplified: it no longer displays marketing campaign
templates.
New files are created to accomodate the new Controller classes used to
display the modal in all Kanban, List and Form views.
The files created by the precedent commit would clog up the main JS
folder, and are therefore moved to dedicated subfolders.
Rectify SVG template icons:
The SVG files for each FontAwesome icon used in the template picker
helper were either too wide or too narrow.
This corrects these icons; the missing FA license mentions have also
been added.
task-3603400VoIP users can now place an active call on hold and resume it directly from the softphone. The mute control has also been clarified so it now mutes the user's microphone, making call handling more intuitive.
Original PR description
We finally have a button to hold/unhold during a call. Also, since we can now hold a call, the Mute button now will now mute your microphone instead of muting your speaker. Task-3670392
Search screens in several Odoo apps now use updated date filter options and improved filtering behavior. This makes reports and operational views more consistent and easier to use across areas such as Helpdesk, Payroll, Planning, Rentals, Stock, and Knowledge.
Original PR description
This PR updates various search views following the change to date filters in the community counterpart. It also brings some changes in search views using the new features brought by those changes. Community: https://github.com/odoo/odoo/pull/156746 Task-3692123
Knowledge search now helps users find articles based on the text inside documents, not only by title. This makes it faster for teams to locate information in large or poorly organized knowledge bases and reduces time spent opening multiple articles manually.
Original PR description
Knowledge is a wonderful tool for collecting, organising and sharing documents with colleagues. However, Knowledge lacks an effective search feature allowing people to search within the content of…
Knowledge is a wonderful tool for collecting, organising and sharing documents with colleagues. However, Knowledge lacks an effective search feature allowing people to search within the content of their documents. The existing search feature only searches for documents with a specific title. If the users don't know which document contains the information they need, they can waste time reading a bunch of articles before finding what they want. This can be time consuming and frustrating when there are a lot of documents in the knowledge base and when the articles are not well organised. To help people to quickly find the information they need in the knowledge base, we will improves the command palette search algorithm. The search algorithm will now be able to find documents containing the search terms inputted by the user. Technical --- The new search algorithm uses the PostgreSQL's built-in full-text search feature. This feature will do all the heavy lifting for us: It will be able to strip the html tags from a document, quickly find article matching with the given search terms, highlight the matching terms in the document, etc. To index the documents, we will define a custom text configuration that is independent of the user's language: It will not discard any words and will not apply any stemming methods to the documents and the search query. It will also ignore the HTML tags stored in the article body. To reduce the query runtime, the search algorithm limits the number of candidates to consider (see: the "cut_off" parameter) and pre-selects relevant candidates incrementally: The algorithm first selects articles matching with the title and the body of the article. If there are not enough matches, the algorithm will select articles matching with the title only. If there are still not enough matches, the algorithm will select the articles matching with the body only. After that, the algorithm ranks the selected articles using a scoring function and returns the most relevant ones. This should ensure that the results we get are relevant and that the query response time is acceptable. Benchmark --- To evaluate the efficiency of the new search algorithm, we loaded in Knowledge 100, 1000 and 10 000 articles coming from an online encyclopaedia using a populate script. The script will nest these articles under one another to form a tree with a branching factor of 5. The articles will be written in English and will be placed in the workspace of Knowledge. We then randomly selected 100 different words from the loaded articles and we searched them using the new search algorithm. We then measure the query response time and we calculate the average, the standard deviation, the minimum and the maximum response time. Response time: - Admin user: | N | AVG | Std Dev | Minimum | Maximum | |-------|-----------|---------|----------|-----------| | 100 | 188.92ms | 172.5 | 18.4ms | 540.31ms | | 1000 | 406.56ms | 316.31 | 28.54ms | 1236.47ms | | 10000 | 1467.31ms | 901.12 | 138.56ms | 3670.40ms | - Demo user: | N | AVG | Std Dev | Minimum | Maximum | |-------|-----------|---------|----------|-----------| | 100 | 184ms | 165.41 | 25.86ms | 571.79ms | | 1000 | 457.69ms | 275.76 | 76.02ms | 1456.63ms | | 10000 | 1504.90ms | 662.64 | 600.57ms | 3199.80ms | **Observation**: The response time can vary greatly depending on the number of times the search terms appear in the documents. The more often the search term is used, the more results there will be and the slower the query will be. - The minimal response time observed is when the search term appears in the body of a single article. - The maximal response time observed is when the search term appears in the body of many article but does not appear frequently in the titles. Index disk usage: | N | Index name | Size | |-------|-------------------------------|--------| | 100 | knowledge_article__name_index | 229kB | | 100 | knowledge_article__body_index | 2318kB | | 1000 | knowledge_article__name_index | 1458kB | | 1000 | knowledge_article__body_index | 8536kB | | 10000 | knowledge_article__name_index | 5447kB | | 10000 | knowledge_article__body_index | 32MB | Column disk usage: | N | Column name | Size | |-------|-------------|--------| | 100 | body | 855kB | | 1000 | body | 6799kB | | 10000 | body | 71MB | Legend: - N: Number of articles stored in the database Reference: PostgreSQL documentation: https://www.postgresql.org/docs/15/textsearch.html task-3071299
Restaurant staff can now manage table bookings directly from the point of sale interface. This reduces the need to switch to the back office, helping teams handle reservations faster during service.
Original PR description
In this commit we introduce the ability to book tables directly from the pos ui, by opening the gantt view of `appointments` in a dialog. This means that users will no longer need to navigate to the backoffice to manage appointments. Task: 3861885
New Point of Sale users can now quickly start with ready-made business scenarios such as Furniture, Bakery, Clothing, Bar, and Restaurant. This improves first-time setup by creating relevant sample configurations and data, while demo installations automatically include all scenarios for easier evaluation.
Original PR description
The goal of this task is to improve onboarding experience of new users. The idea is that when a user start an odoo instance without demo and installed the point_of_sale module, the user is welcomed…
The goal of this task is to improve onboarding experience of new users. The idea is that when a user start an odoo instance without demo and installed the point_of_sale module, the user is welcomed with options to create configuration and data sets from different predefined scenarios, namely Furnitures, Bakery, Clothing, Bar and Restaurant. The original sets of demo data are now categorized in the Furnitures and Restaurant scenarios and the other scenarios are added with new data sets. As for the installation of pos modules in demo mode, we automatically load the scenarios, so now, there will be 5 configurations when both point_of_sale and pos_restaurant are installed. The demo products (and related records) are put in .xml files. These files are loaded using `convert` module on demand -- based on what scenario the user selected. This is the reason we have exposed few methods that will be called from the backend interface. When in demo mode, we pretend that all scenarios are selected and we call the action that loads the scenarios. Small fixes and improvements are also included in this commit: - Fix styles and layouts in the components related to opening and closing dialogs. - Resize of selection pills during product configuration. - Reduce the size of the anchor to resize tables in the floor screen during edit mode. - Remove CancelConfirmationDialog as it doesn't serve so much purpose. We just use the normal confirmation dialog when asking users about the closing amount difference. TASK-ID: 3598952 Linked PR: https://github.com/odoo/odoo/pull/154995
Users can now choose custom date ranges in Gantt views instead of being limited to fixed day, week, month, or year views. The update also adds new scale options, sorting controls, dense/sparse display switching, and performance safeguards for very large schedules.
Original PR description
The main goal of this task is to allow the user to work on a chosen time range via two date pickers. This will ease the edition of records by making possible to move, resize, create, edit records on…
The main goal of this task is to allow the user to work on a chosen time range via two date pickers. This will ease the edition of records by making possible to move, resize, create, edit records on time periods that are not arbitrarily fixed to a given day, week, month, or year. Two new scales are also available: week_2 and month_3. The principal effect of scales is now to determine the duration of the gantt columns ("hour", "day", "month") and their widths. The scale can be chosen via a slider.
We also have added some new buttons:
- two buttons for sorting the rows by the time their first pill occur (i.e. groups can be sorted by date_start:min asc or desc)
- a button to change the display mode ("dense"/"sparse") introduced in https://github.com/odoo/enterprise/pull/58338
Note that for performance reason, we do not allow time range bigger than 10 years. We also forbid to load more than 1000 records. In case that limit is reached a notification is displayed. This has been done in order to keep the number of rows/columns in the css grid within the bounds allowed by Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=1336679). Note that we do not render all loaded records. The gantt view is now also virtualized in the horizontal direction and we only add to the css grid the rows/columns effectively needed to display the visible elements.
In mobile mode, the date selection is done in a dialog instead of a popover. We plan to extend that behavior everywhere.
Task ID: `3601456`
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Julien Carion <juca@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Romeo Fragomeli <rfr@odoo.com>
Co-authored-by: Pierre Pulinckx <pipu@odoo.com>
Co-authored-by: Luca Vitali <luvi@odoo.com>
https://github.com/odoo/odoo/pull/162017The appointment module’s automated tests were updated to reflect a calendar list view change. This helps ensure the “All calendars” filter continues to be checked correctly during development, reducing the risk of regressions for appointment scheduling.
Original PR description
This commit adapts the tests with mock RPC routes to add the route to get the "All calendars" filter from the calendar's list view. related: odoo/odoo#149192 task-3790206
Moroccan invoice templates now include the ICE business identification number for companies and partners when available. This helps invoices meet local administrative and legal requirements in Morocco.
Original PR description
[IMP] l10n_ma_report: Add ice number Adding ice number to morocco's companies' and partners' invoices template as part of the address Reason: The ICE (Identifiant Commun de l'Entreprise) is an identification number assigned to businesses and legal entities for various administrative and legal purposes in Morocco. If the partner has one, it must be indicated on the invoice. Task-3877546 Community-pr: https://github.com/odoo/odoo/pull/162669
The product form has been reorganized to make key settings easier to understand and find. Labels and filters were clarified for rentals and subscriptions, while product details such as pricing, versions, and categories now appear in more relevant places.
Original PR description
This commit do following changes: - Hide category field for combo products. - Update tour steps according to community changes. - Move version field to inventory module. - Move pricer section to POS page. - Change rent_ok field to `Rental` instead of `Can Be Rented`. - Change can be `Can Be Recurring` filter to `Subscriptions`. task-3526304
Employees with an appraisal already in progress now see “Ongoing” where the next appraisal date appears, instead of a blank value. This makes appraisal status clearer for managers and employees reviewing employee profiles.
Original PR description
Before the next appraisal date displayed nothing when there was an ongoing appraisal but now it will display "Ongoing". task-3890332
Product and appointment-related flows were simplified by removing the special booking fee product type and updating related sales, payment, and website appointment behavior. This should make product setup clearer and reduce unnecessary complexity for teams managing appointments and online sales.
Original PR description
The following changes have been made in this commit: - In the product form, several strings have been renamed. - The stat buttons are reordered. - Remove SLA policy from helpdesk - Removing the All Category and making a flat hierarchy. **Target version**: master **Task**: 3526304
The Master Production Schedule has been reworked to make planning clearer and more automated. Users get a cleaner interface, better demand calculations with production lead times, optional maximum replenishment limits, and new controls for automatic or blocked replenishment.
Original PR description
Rework of mrp_mps task 3416609
The barcode app’s operation list now highlights useful context, including operation descriptions and batch counts, so warehouse teams can identify the right workflow faster. It also defaults to showing favorite barcode operations, reducing clutter and helping users focus on their most-used tasks.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/150360
New automated tests verify that Balance Sheet reports remain balanced across supported accounting setups. This helps catch localization or configuration issues earlier, reducing the risk of inaccurate financial reports reaching users.
Original PR description
This commit introduces a l10n test over the Balance Sheet reports. For each CoA, a company is set-up, and all the available Balance Sheet reports for the company are tested. The test generates a…
This commit introduces a l10n test over the Balance Sheet reports. For each CoA, a company is set-up, and all the available Balance Sheet reports for the company are tested. The test generates a journal entry with a line in every account that is not `off_balance` and not in the NON_TESTED_ACCOUNTS global at the head of the file (useful for accounts that are forced to be generated, but should never be used, like 999999 in Belgium). It then checks whether the Balance Sheet is balanced. The test does this both for debits and for credits. To work, the test needs to know, for each Balance Sheet report: - the XMLID of the Total Assets line - the XMLID of the Total Liabilities line - the XMLID of the Total Equity line (if separate from Liabilities) - the column name containing the balance (if different from 'balance') These are specified in the REPORT_CONFIG global at the head of the file. The test will hard-fail if an available Balance Sheet report is not configured in the REPORT_CONFIG global. This makes it mandatory for new Balance Sheets to add their config there. Setting the global IDENTIFY_INCORRECT_ACCOUNTS to True switches the behaviour of the test: it identifies the accounts that cause the imbalance using a binary search. This is off by default for runbot. Task: 3060790
This update removes outdated configuration left over from an earlier redesign of the import screen controls. It does not change user-facing behavior, but helps keep the accounting import interface easier to maintain and less prone to future layout issues.
Original PR description
During the "Milk" redesign [1], ControlPanel's layout was changed, impacting the `display` prop used to control which parts are displayed or not.
This commit cleans up some remnants of the old layout (i.e. `{top,bottom}-{left,right}`) that are now unused.
task-3336242
[1]: https://github.com/odoo/odoo/pull/116641Manufacturing teams can now open related shop floor work directly from a manufacturing order and add or edit shared log notes for manufacturing and work orders. Product analysis also gains expected unit cost figures for components, work centers, employees, and totals, helping compare planned costs with average costs.
Payroll users can now generate payment reports as CSV files from individual payslips or payroll batches. The change also standardizes the reporting flow so future payment formats can use the same buttons and wizard, reducing training and operational friction.
Original PR description
* = hr_payroll_account_sepa With this, we can generate a payment report for any payslip/batch as a .csv. Also make it so that when new modules introduce other payment report formats, they are handled with the same buttons and wizards. Task: 3880728
The Amounts to Settle view now includes a reconcile button, making it easier for accounting users to handle outstanding items directly from that screen. This supports the expanded view, which now covers more move types such as sales, purchases, incoming, and outgoing entries.
Original PR description
This commit improves the Amounts to Settle view by adding a reconcile button on it. This behavior is now desired because the view shows all types of moves (out, in, sale, purchase) which it did not before so this button is needed. --- Community PR: https://github.com/odoo/odoo/pull/158014 Upgrade PR: https://github.com/odoo/upgrade/pull/6036 task-3640027
The Documents app interface has been refined to make everyday document work clearer and faster. Users get cleaner document cards, simpler search filters, clearer inspector actions, improved configuration menus, and more control over tag category colors.
Original PR description
This commit performs the following changes in the view of documents module: - Reshuffle the star icon and the owner avatar in kanban title. - Increase the visibility of the document record selector…
This commit performs the following changes in the view of documents module: - Reshuffle the star icon and the owner avatar in kanban title. - Increase the visibility of the document record selector icon in kanban view. - Rename and reorganizes some search filters and remove activity-related filters section. - Merge the functionality of "Documents" and "File Extension" search filters under one single search filter that goes by the name "Name/Extension". - Make the labels of actions in documents inspector clickable and remove the preceding play icon. - Remove icons that precedes the field labels in documents inspector. (i.e. 'Workspace', 'Model Name', 'Tags', 'Actions' and 'History') - Simplify list view of 'documents.folder' model by displaying only the `Name` field by default all others are optional. - Change the 'Content Helper' message of the 'Trash' folder. - Add a placeholder for the 'Message' field in the 'Request File' wizard. - Change the position of lock icon in the kanban title. Add bootstrap classes to properly display the document name. - Restructure the list view of 'Workflow Rules' (Actions). This commit also allows the user to manually change tags group color by using a color picker. And it finally change the structure of the configuration menu. Task-3874977
The rental shopping experience is refined with clearer date pickers, better mobile filter spacing, and more visible guidance messages. Rental snippets and product pages now follow a more consistent layout, making it easier for customers to choose rental dates and understand pricing.
Original PR description
### 1. Adapt spacing in mobile filters Prior to this PR, there was a spacing issue between the date picker and the title in the offcanvas menu for filters. This PR fixes this issue. ### 2. Rental…
### 1. Adapt spacing in mobile filters Prior to this PR, there was a spacing issue between the date picker and the title in the offcanvas menu for filters. This PR fixes this issue. ### 2. Rental datepicker adaptations This PR reviews the design of the datepicker to make it easier to use. ### 3. Display disclaimer in tooltip Prior to this PR, there was a disclaimer as a title attribute in the rental filter. But this message is too important to be displayed as a regular title attribute. This PR highlights this message by displaying it in a tooltip available when hovering an "info" icon. ### 4. Rental snippet adaptations **Design adaptations:** Since the adaptations made to the design of the rental datepicker, this PR reviews the design of the rental snippet to maintain a consistent layout. **Generate unique ids for rental snippet:** We now use the calendar icon next to the input as a label. To be clickable, this label must be linked to the corresponding input by an id. To avoid duplicate ids when several snippets are in the page, this PR generates unique ids for each input. ### 5. Refine the product page layout This PR moves the price to the same place and style as the other product types to maintain a consistent layout. It also adapts the style of "Pricing" title for the same reason. --- Requires: - https://github.com/odoo/odoo/pull/153374 task-3637980 --- | Before | After | |--------|--------| |  |  | |  |  | |  |  | |  |  | |  |  | |  |  | |  |  |
HR teams can now choose how many people need to sign an employee contract and specify exactly which users should sign. This gives businesses more control over contract approval workflows and better supports company-specific signing policies.
Original PR description
Allow to change the number and the users of signatories in hr_contract task-id: 3332971
Resolved issues and error corrections
This update makes minor corrections to the manufacturing planning setup. It removes an unwanted default forecast value, clarifies a form label, and prevents an error when adding products without an enabled route to the master production schedule.
Original PR description
- remove the default setting from 'To Forecast' field - change the label for field `is_indirect` on form view
This fixes an intermittent automated test failure in financial reporting by making the test wait for the correct sorted report lines. It helps keep quality checks stable without changing how users interact with reports.
Original PR description
issue: when the account_reports tour test is run it sometimes fails with some report line not containing the correct value. The root cause of this issue is that the triggers for 2 of the test steps check the content of lines that are excluded from sorting. This could result in the test step triggering before sorting of the report is completed, which will in turn fail the testcase. fix: while testing the sorting mechanism only trigger on lines that are included in the sort. This ensures the next test step is triggered after sorting is completed.
Code cleanup and technical improvements
This update modernizes internal accounting report query handling by replacing older query-building logic with a newer, safer SQL object approach. It should not change day-to-day user workflows, but it improves maintainability and consistency across accounting, tax, asset, and localization reports.
Original PR description
Gist: - Rename `_get_table_expression` to `_get_sql_table_expression` This clarifies that the function returns an SQL expression and not a `account.report.expression`. - Remove `_query_get`: use `_get_sql_table_expression` instead. This makes use of the new `odoo.tools.SQL` object. - Some related functions / queries were adapted to use the new SQL object too: I.e. `_get_query_tax_details` and `_get_query_currency_table` (see related community PR) community PR: https://github.com/odoo/odoo/pull/158880 task-3791228
Miscellaneous changes
The field NumCta in the SAT XML is parsed from the lines in the trial balance report. The name of the line is the code for the account concatenated with the name of the account. The existing implementation assumes the code has 3 sets of digits separated by two dots, and that the account name has no dots. This is true for the default chart of accounts for Mexico, but is not necessarily the case if additional accounts are added by the user. As a result, invalid NumCta values were generated, whi
Original PR description
The field NumCta in the SAT XML is parsed from the lines in the trial balance report. The name of the line is the code for the account concatenated with the name of the account. The existing…
The field NumCta in the SAT XML is parsed from the lines in the trial balance report. The name of the line is the code for the account concatenated with the name of the account. The existing implementation assumes the code has 3 sets of digits separated by two dots, and that the account name has no dots. This is true for the default chart of accounts for Mexico, but is not necessarily the case if additional accounts are added by the user. As a result, invalid NumCta values were generated, which would include parts of the account name if dots were present in it, or the value would be too long if the code had more than two dots. Subdividing the code into further levels is allowed, they'll get aggregated into the allowed SAT code (of the form XXX or XXX.YY). Dots in account names shouldn't matter. This fix makes the parsing of the NumCta value more strict so it supports the above use cases. In case the prefix doesn't match the expected pattern, an error is shown to the user. Normally this shouldn't happen, since the line would have been filtered out if it didn't match a valid prefix from the upper levels. It was added to make the code more robust against refactoring and customization, and to prevent an uncaught traceback in that case. opw-3878763 Forward-Port-Of: odoo/enterprise#62920 Forward-Port-Of: odoo/enterprise#62113
Since we don't create anymore a contract by default, we don't need to change the values of the contract on the newly created bike. More over, if there is a customization of the creation of vehicle it will scratch it Forward-Port-Of: odoo/enterprise#62455
Original PR description
Since we don't create anymore a contract by default, we don't need to change the values of the contract on the newly created bike. More over, if there is a customization of the creation of vehicle it will scratch it Forward-Port-Of: odoo/enterprise#62455
Steps to reproduce: - Install l10n_es_reports - Switch to a Spanish company (e.g. ES Company) - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Check that a Spanish Tax Report is selected (i.e. Mod 111/115/303/347/349) - Click on "Save" - Select "BOE" for "Export To" option - Export Issue: A traceback is raised: "KeyError: 'res_id'" Cause: In previous versions, "open_boe_wizard" method was creating the wizard and returning its "id". It's not the case anymore.
Original PR description
Steps to reproduce: - Install l10n_es_reports - Switch to a Spanish company (e.g. ES Company) - Go to "Accounting / Reporting / Statement Reports / Tax Report" - Check that a Spanish Tax Report is selected (i.e. Mod 111/115/303/347/349) - Click on "Save" - Select "BOE" for "Export To" option - Export Issue: A traceback is raised: "KeyError: 'res_id'" Cause: In previous versions, "open_boe_wizard" method was creating the wizard and returning its "id". It's not the case anymore. Complement of https://github.com/odoo/enterprise/commit/e8d5582a773d7f31669fa8be576569681ed3f110 opw-3856749 Forward-Port-Of: odoo/enterprise#62841
**Steps to reproduce:** - Install account_reports - Install a RTL language (e.g. Arabic) - Set the RTL language on the current user - Set the currency of the company to SR - Go to "Accounting / Reporting / Partner Ledger" - Make sure there are some partners with long name (but less than 50 chars) - Print PDF **Issue:** In RTL, the partner column overflows outside of the page width. **Cause:** The break-word is only activated when the name has more than 50 characters. In RTL, the
Original PR description
**Steps to reproduce:** - Install account_reports - Install a RTL language (e.g. Arabic) - Set the RTL language on the current user - Set the currency of the company to SR - Go to "Accounting / Reporting / Partner Ledger" - Make sure there are some partners with long name (but less than 50 chars) - Print PDF **Issue:** In RTL, the partner column overflows outside of the page width. **Cause:** The break-word is only activated when the name has more than 50 characters. In RTL, the cell to display the partner is smaller. **Solution:** Do not use a minimum length of 50 characters to activate "break-word" in RTL. opw-3888122 Forward-Port-Of: odoo/enterprise#62626
In the view when `email_from` precomputation isn't triggered because one of its dependencies `mail_server_id` isn't present in the view, because of that `email_from` stays NULL which raises an error since it's a required field. task-3901450 Forward-Port-Of: odoo/enterprise#62860 Forward-Port-Of: odoo/enterprise#62164
Original PR description
In the view when `email_from` precomputation isn't triggered because one of its dependencies `mail_server_id` isn't present in the view, because of that `email_from` stays NULL which raises an error since it's a required field. task-3901450 Forward-Port-Of: odoo/enterprise#62860 Forward-Port-Of: odoo/enterprise#62164
Steps ----- 1. Install accounting and mrp_workorder_hr, activate analytic accounting in settings. 2. Select a work center and check "Requires Log In" 3. Create a manufacturing order and add a work order using the work center from the previous step. On the miscellaneous tab, add an analytic account. 4. Confirm the MO. 5. On the Work Orders tab, change the Real Duration to 60:00 6. Analytic account smart button > the gross margin is correctly set. 7. Either change the real duration to 0:
Original PR description
Steps ----- 1. Install accounting and mrp_workorder_hr, activate analytic accounting in settings. 2. Select a work center and check "Requires Log In" 3. Create a manufacturing order and add a work…
Steps ----- 1. Install accounting and mrp_workorder_hr, activate analytic accounting in settings. 2. Select a work center and check "Requires Log In" 3. Create a manufacturing order and add a work order using the work center from the previous step. On the miscellaneous tab, add an analytic account. 4. Confirm the MO. 5. On the Work Orders tab, change the Real Duration to 60:00 6. Analytic account smart button > the gross margin is correctly set. 7. Either change the real duration to 0:00 or open the work order and delete a line from the Time Tracking tab. Note: decreasing the Real Duration on the Manufacturing Order page will not lead to an issue as long as no time record is deleted on the work order (typically, when decreasing the time by a small amount). Issue ----- The gross margin still takes into account the employee's cost for the deleted time. Note that the workcenter's cost is removed from the gross margin as expected. Either by _create_or_update_analytic_entry in case the time of the work order is modified, or unlink if the work order is deleted. https://github.com/odoo/odoo/blob/16.0/addons/mrp_account/models/mrp_workorder.py Fix ----- When deleting a time record, modify the analytic account accordingly. We create an analytic entry with a previous_duration equal to the double of the time that is deleted. https://github.com/odoo/enterprise/blob/a992a3ae345478a148e536103c1585a4caa86113/mrp_workorder_hr_account/models/mrp_workorder.py#L16 That way, we create an analytic entry with a duration equal to the negative of the deleted time. This will add a positive amount to the analytic account. https://github.com/odoo/enterprise/blob/a992a3ae345478a148e536103c1585a4caa86113/mrp_workorder_hr_account/models/mrp_workorder.py#L21-L22 This makes the analytic account's gross margin consistent with the time worked. **opw-3759144** Forward-Port-Of: odoo/enterprise#61881 Forward-Port-Of: odoo/enterprise#58760
Before this commit: Only the first two `/` were removed from reference_id of picking. creating wrong shipping request url for reference_id with more than two `/`. After this commit: All the slashes are removed from reference_id. opw-3853123 Forward-Port-Of: odoo/enterprise#60652
Original PR description
Before this commit: Only the first two `/` were removed from reference_id of picking. creating wrong shipping request url for reference_id with more than two `/`. After this commit: All the slashes are removed from reference_id. opw-3853123 Forward-Port-Of: odoo/enterprise#60652
Before this commit: request timeout was 15 seconds, which was too short for sendcloud request when requesting large ammount of data. After this commit: request timeout increased to 60 seconds. opw-3890386 Forward-Port-Of: odoo/enterprise#62043
Original PR description
Before this commit: request timeout was 15 seconds, which was too short for sendcloud request when requesting large ammount of data. After this commit: request timeout increased to 60 seconds. opw-3890386 Forward-Port-Of: odoo/enterprise#62043
When the team_id of a ticket is set to False in its form view, a traceback occurs. This is an invalid value anyway, but the user should only be notified of that fact when he tries to save his change, not with traceback. Step to reproduce: - Open helpdesk - open the 'all tickets' menu - open any ticket form - set the team_id to false - save changes or click anywhere else to leave the edit field => a traceback occurs Source of the issue: When a new team is set on a ticket, a new stage
Original PR description
When the team_id of a ticket is set to False in its form view, a traceback occurs. This is an invalid value anyway, but the user should only be notified of that fact when he tries to save his change,…
When the team_id of a ticket is set to False in its form view, a traceback occurs. This is an invalid value anyway, but the user should only be notified of that fact when he tries to save his change, not with traceback. Step to reproduce: - Open helpdesk - open the 'all tickets' menu - open any ticket form - set the team_id to false - save changes or click anywhere else to leave the edit field => a traceback occurs Source of the issue: When a new team is set on a ticket, a new stage is set on it, as well as new sla_status. The issue is that inside the _compute_sla_deadline method, the calendar of the team is used. But since there are no teams, there are also no calendar. And the ensure_one() fails later on in the stack because of that. Solution: Prevent the computation of those values for ticket without team_id. Since this is an invalid value, the changes would be rolled back anyway, or overwrite once the user put a valid value for the team. version 16.0 - master task - 3895303 Forward-Port-Of: odoo/enterprise#61563
This issue arises after having visited the "General Ledger" at least once. When clicking on the "General Ledger" part of the "The current balance in the General Ledger didn't match the balance of your last bank statement, leading to an unexplained difference of [...]" message in "Bank Reconciliation", options such as the currency unit weren't properly transferred. Steps to reproduce original issue: - Install `account_reports` - Go to: Accounting > Reporting > Audit Reports > General Le
Original PR description
This issue arises after having visited the "General Ledger" at least once. When clicking on the "General Ledger" part of the "The current balance in the General Ledger didn't match the balance of your last bank statement, leading to an unexplained difference of [...]" message in "Bank Reconciliation", options such as the currency unit weren't properly transferred. Steps to reproduce original issue: - Install `account_reports` - Go to: Accounting > Reporting > Audit Reports > General Ledger - Go back - Create, confirm & reconcile an invoice - Reset invoice to draft - In "Accounting", go to "Dashboard" - Click on the 3 vertical dots to the right of the "Bank" card - Click on "Reconciliation Report" - In "Options: Posted Entries Only", select "Include Draft Entries" - Click on "General Ledger" in the first yellow warning - Draft entries won't be included task-3928454 Forward-Port-Of: odoo/enterprise#62940 Forward-Port-Of: odoo/enterprise#62655
Steps to reproduce: - Configure Starshipit - Create a stock picking - Choose Starshipit as carrier - Validate the picking - Try multiple times to reproduce the error Current behaviour: - KeyError exception raised Expected behaviour: - Should not have any KeyError Explanation: Starshipit API sometimes will not return the total_shipping_price, therefore the carrier price become 0 and cannot proceed. To handle this case, we put the order detail fetching in background as wel
Original PR description
Steps to reproduce: - Configure Starshipit - Create a stock picking - Choose Starshipit as carrier - Validate the picking - Try multiple times to reproduce the error Current behaviour: - KeyError exception raised Expected behaviour: - Should not have any KeyError Explanation: Starshipit API sometimes will not return the total_shipping_price, therefore the carrier price become 0 and cannot proceed. To handle this case, we put the order detail fetching in background as welljust in case the API didn't return the total_shipping_price again. task-3887386 Forward-Port-Of: odoo/enterprise#61286
The compute function _compute_sending_conditions needs date_from and date_to fields as its dependencies to compute whether or not to show the "Send" button on the ICP report SBR wizard. Without them, the field does not get properly recomptued, and the button isn't shown, unless the "Is Test" checkbox gets ticked by the user. Forward-Port-Of: odoo/enterprise#62876
Original PR description
The compute function _compute_sending_conditions needs date_from and date_to fields as its dependencies to compute whether or not to show the "Send" button on the ICP report SBR wizard. Without them, the field does not get properly recomptued, and the button isn't shown, unless the "Is Test" checkbox gets ticked by the user. Forward-Port-Of: odoo/enterprise#62876
…ec widget Steps to reproduce: - Create an invoice with a foreign currency of rate 1:3: 120 EUR = 40 USD - Create a statement line with a foreign currency of rate 1:2: 120 EUR = 60 USD - Reconcile them both using the bank reco widget: An exchange diff of 20 USD will be created. At this point, the invoice and the statement line are reconciled all together. The exchange difference is reconciled with the statement line (lowest rate). The point is both account.partial.reconcile are linke
Original PR description
…ec widget Steps to reproduce: - Create an invoice with a foreign currency of rate 1:3: 120 EUR = 40 USD - Create a statement line with a foreign currency of rate 1:2: 120 EUR = 60 USD - Reconcile…
…ec widget Steps to reproduce: - Create an invoice with a foreign currency of rate 1:3: 120 EUR = 40 USD - Create a statement line with a foreign currency of rate 1:2: 120 EUR = 60 USD - Reconcile them both using the bank reco widget: An exchange diff of 20 USD will be created. At this point, the invoice and the statement line are reconciled all together. The exchange difference is reconciled with the statement line (lowest rate). The point is both account.partial.reconcile are linked to the exchange diff. That's what will cause the problem describe below. When the invoice is reset to draft: 'button_draft' removes the reconciliation so the partial linking the invoice with the statement line is deleted. Since an exchange diff is attached to the account.partial.reconcile through the exchange_move_id field, we create a reversal for the exchange diff to neutralize its accounting items. During the creation of the reversal, we remove the reconciliation so the partial linking the exchange difference with the statement line is deleted. Since the exchange diff is wrongly attached to this partial too, again, the code tries to reverse the exchange difference. At the end, a double reversal of the exchange diff has been created. opw: 3869770 Forward-Port-Of: odoo/enterprise#62773 Forward-Port-Of: odoo/enterprise#62717
**Steps to reproduce:** - Install Accounting and l10n_mx_edi - Switch to a Mexican company (e.g. ESCUALA KEMPER URGATE) - Activate another currency (e.g. USD) - In Accounting settings, run the "Automatic Currency Rates" feature ([MX] Bank of Mexico) - Add a different currency rate for USD for yesterday - Create an invoice: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) * Currency: [USD] * Invoice Date: [yesterday] * Invoice Lines: - Product: [any product with UNS
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_mx_edi - Switch to a Mexican company (e.g. ESCUALA KEMPER URGATE) - Activate another currency (e.g. USD) - In Accounting settings, run the…
**Steps to reproduce:**
- Install Accounting and l10n_mx_edi
- Switch to a Mexican company (e.g. ESCUALA KEMPER URGATE)
- Activate another currency (e.g. USD)
- In Accounting settings, run the "Automatic Currency Rates" feature ([MX] Bank of Mexico)
- Add a different currency rate for USD for yesterday
- Create an invoice:
* Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA)
* Currency: [USD]
* Invoice Date: [yesterday]
* Invoice Lines:
- Product: [any product with UNSPSC Category set]
- Price: [any] - Taxes: [any]
- Confirm the invoice
- Generate CFDI via "Send & Print" button
- Request Cancel:
* Reason: 01- Invoice issued with errors (with related document)
- Create Replacement Invoice
**Issue:**
A UserError is raised while checking the balance of the replacement invoice because the total of debits and the total of credits are different.
**Cause:**
The lines for the replacement invoice are just copied, keeping the values of the original invoice lines for many fields (such as "balance", "discount_balance" and "tax_base_amount").
Product-type lines do not have "balance" set in the copied data. In this case, "balance" is computed by using the current currency rate when the replacement invoice is created, which is correct.
The other lines are populated with the copied "balances" that correspond to the previous currency rate, which is not correct.
This leads to a mix of balances linked to different currency rates.
These fields are in the invoice currency and should be computed with the current currency rate as the replacement invoice is created with the present day as invoice date.
**Solution:**
Remove non product-type lines from the copied data to force them to recompute with the current currency rate.
opw-3863010
opw-3902683
Forward-Port-Of: odoo/enterprise#62373Steps to reproduce: ------------------- - create a project; - create a new planning slot for the project with a resource (user); - go to the project and create a task; - record timesheet in the planning slot time range in the task; - go to the planning slot view (via list view) Issue: ------ The times recorded are not updated (in the smart button). Despite the fact that `_compute_effective_hours` depends on `timesheet_ids`. Cause: ------ The `effective_hours` field will be recomp
Original PR description
Steps to reproduce: ------------------- - create a project; - create a new planning slot for the project with a resource (user); - go to the project and create a task; - record timesheet in the planning slot time range in the task; - go to the planning slot view (via list view) Issue: ------ The times recorded are not updated (in the smart button). Despite the fact that `_compute_effective_hours` depends on `timesheet_ids`. Cause: ------ The `effective_hours` field will be recomputed if one of its dependencies changes (in this case, `timesheet_ids`). For `timesheet_ids` to be marked for compute, one of its dependencies must change. `project_id.analytic_account_id.line_ids` is different from `project_id.timesheet_ids`. As a result, the method which computes `effective_hours` is not triggered. Solution: --------- Add `project_id.timesheet_ids` in dependencies. opw-3891624 Forward-Port-Of: odoo/enterprise#61668
Issue --> The fetchall call made after the querying the dataset in `_saft_fill_report_general_ledger_values` runs into a memory error if there is a large number of rows. Solution --> Use a `while True` loop to use `dictfetchmany` to return rows in batches to optimize memory usage. `dictfetchmany` returns None if no rows are returned, which is the exit condition of the loop. opw-3859206 Forward-Port-Of: odoo/enterprise#62571 Forward-Port-Of: odoo/enterprise#61272
Original PR description
Issue --> The fetchall call made after the querying the dataset in `_saft_fill_report_general_ledger_values` runs into a memory error if there is a large number of rows. Solution --> Use a `while True` loop to use `dictfetchmany` to return rows in batches to optimize memory usage. `dictfetchmany` returns None if no rows are returned, which is the exit condition of the loop. opw-3859206 Forward-Port-Of: odoo/enterprise#62571 Forward-Port-Of: odoo/enterprise#61272
How to reproduce: - Enable "Storage Locations"; - Create a receipt with WH/Stock/Shelf 2 as the Destination Location; - Add a product with a barcode in this receipt and mark it as todo; - Open the created receipt in the Barcode app; - Scan the product; - Scan WH/Stock/Shelf 1 barcode. -> Current behavior: the product will be moved in Shelf 1, which is not a sublocation of Shelf 2 (the receipt's destination.) -> Expected behavior: a product cannot be moved in a destination who is not
Original PR description
How to reproduce: - Enable "Storage Locations"; - Create a receipt with WH/Stock/Shelf 2 as the Destination Location; - Add a product with a barcode in this receipt and mark it as todo; - Open the created receipt in the Barcode app; - Scan the product; - Scan WH/Stock/Shelf 1 barcode. -> Current behavior: the product will be moved in Shelf 1, which is not a sublocation of Shelf 2 (the receipt's destination.) -> Expected behavior: a product cannot be moved in a destination who is not (a part of) the picking's destination. [OPW-3895328](https://www.odoo.com/web#id=3895328&cids=1&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#62546 Forward-Port-Of: odoo/enterprise#61560
The link from 'Balance Sheet (abridged)' to 'Profit & Loss (abridged)' raises an error. ### Steps to reproduce : - Install the l10n_lu_reports module - Change the company to a Luxembourgian company - Go to Accounting > Reporting > Statement Reports > Balance Sheet - Change the report to 'Balance Sheet (abridged) (LU)' - In the report, click on the link 'VI. Profit or loss for the financial year' ### Cause: The action triggered by this link has not the right formatted context. It shou
Original PR description
The link from 'Balance Sheet (abridged)' to 'Profit & Loss (abridged)' raises an error. ### Steps to reproduce : - Install the l10n_lu_reports module - Change the company to a Luxembourgian company - Go to Accounting > Reporting > Statement Reports > Balance Sheet - Change the report to 'Balance Sheet (abridged) (LU)' - In the report, click on the link 'VI. Profit or loss for the financial year' ### Cause: The action triggered by this link has not the right formatted context. It should have the value 'report_id' but has 'model' and 'id' instead. This raises an error in execute_action when trying to read 'report_id' on this action. ### Solution: Remove 'model' in the context and rename 'id' to 'report_id'. opw-3912348 Forward-Port-Of: odoo/enterprise#62715
56 changes
New functionality added to Odoo
This update adds automated testing for the Point of Sale IoT device printer functionality. Previously, when IoT devices were connected to the POS system and invoice reports, errors would occur because required services weren't available during testing. This fix ensures the feature works reliably by adding comprehensive test coverage.
Original PR description
Current behavior: When an iot device is linked to the PoS and invoice report, you had an error because action service and iot_websocket service where not available. Steps to reproduce: - Install pos_iot - Set an iot_device printer on the pos session - Set an iot_device on the report of the invoice - Open session, make an order and invoice it - You get an error opw-3792576
This update enhances the mail_enterprise module to store code line count (cloc) results in Odoo's internal configuration parameters (ICP). This change improves system monitoring and reporting capabilities by automatically capturing code metrics during updates, enabling better tracking of codebase size and complexity over time.
Original PR description
Task-id: 3631712 Forward-Port-Of: odoo/enterprise#62751 Forward-Port-Of: odoo/enterprise#52348
Enhancements to existing features
This update enhances the testing framework for Mexican electronic invoicing (CFDI) by adding tools to easily validate test files with current dates and switch between test and production modes. This allows the system to send XML files directly to Mexico's SAT (tax authority) for real validation, ensuring the generated documents meet official requirements.
Original PR description
Add a setup allowing you to easily create xmls at today date and switch from external to standard mode. That way, in external mode, the XMLs are really send to the SAT in order to ensure their validity. community PR: https://github.com/odoo/odoo/pull/163938 Forward-Port-Of: odoo/enterprise#61741
This update improves the image editing experience in the web editor by allowing users to press the Escape key to quickly exit image transformation mode. Additionally, it prevents accidental image deletion when users are actively resizing or transforming images, making the editing interface more intuitive and user-friendly.
Original PR description
Desired behavior after PR is merged: I. This PR implements a functionality where pressing the `Escape` key removes the transform widget from the image. II. Also it ensures that pressing any character key does not result in the removal of the image when the transform widget is active. task-3839151
This update simplifies how the system retrieves shopping cart quantities for products, particularly those available for backorder. Previously, the cart quantity method would always return zero for out-of-stock items, limiting its usefulness. Now it provides accurate cart quantities for all products, making the system more flexible and reducing code duplication across the platform.
Original PR description
Description of the issue/feature this PR addresses: Improve versatility of `_get_cart_qty` method for 'product.product' model. As of now, this method automatically returns zero, for all products that…
Description of the issue/feature this PR addresses: Improve versatility of `_get_cart_qty` method for 'product.product' model. As of now, this method automatically returns zero, for all products that allow ordering when out-of-stock. This bit of logic is only necessary in one place (to generate combination info to display in `website_sale_stock.product_availability` view), making the method effectively useless in other places, like community modules. This commit simplifies the `_get_cart_qty` method logic, to make it more usable, and delegates the removed check only to the `_get_additionnal_combination_info` override. This also allows the method to be used in `_get_cart_and_free_qty`, to avoid needing to override cart quantity acquisition logic in multiple places. Current behavior before PR: The `_get_cart_qty` method, automatically returns zero, for all products, that allow ordering out-of-stock, preventing acquisition of cart quantity using this method, for these products. Desired behavior after PR is merged: Being able to get the current cart quantity for all products, using this method. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When users upload files in Odoo, the system now sends the activity ID along with the file. This prevents duplicate documents from being created when a file is uploaded as part of an existing activity, improving the user experience and data organization.
Original PR description
When uploading a file, the activity ID is now sent to the server. This will help (for example) to avoid creating a second document if the file is uploaded in the context of an existing activity. ENT PR: https://github.com/odoo/enterprise/pull/59796 opw-3458850 Forward-Port-Of: odoo/odoo#164964 Forward-Port-Of: odoo/odoo#159943
This update improves the Spanish electronic invoice (Factura-E) export functionality by adding two important fields: FileReference and FileDate. These fields are now included in the exported invoice documents, ensuring compliance with Spanish electronic invoicing requirements and improving the completeness of exported financial records.
Original PR description
FileReference and FileDate fields are added to the Factura-E export. task-3864452 Forward-Port-Of: odoo/odoo#162791
Resolved issues and error corrections
This fix resolves a bug in the barcode scanning system where scanning a lot number that exists for multiple products would incorrectly add the wrong product to a delivery order. The issue occurred because the system's cache was not properly distinguishing between identical lot numbers across different products. The fix improves the caching mechanism to use more precise keys based on search filters, ensuring the correct product is always selected when scanning.
Original PR description
Steps to reproduce: - Install `stock_barcode` - Create two product "aaa" and "bbb" with both of them being tracked by lots with the same lot number "123" - Open the Inventory app and go to…
Steps to reproduce: - Install `stock_barcode` - Create two product "aaa" and "bbb" with both of them being tracked by lots with the same lot number "123" - Open the Inventory app and go to Configuration > Operation Types > Delivery Orders - Enable Product in the Barcode App - Go to the barcode app > Operations > Delivery Orders and click on New - Scan 123 - Scan aaa (or bbb it probably depends on order of creation of product) - Scan 123 Issues: bbb has been added even though we never scanned it. The reason for this bug is that when we scan 123 we don't have it in the cache as such we make an RPC and store 123 in `missCache`. https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L184-L185 After this when we scan aaa we retrieve the record, and add the line as intended. The problem arise when we scan 123, since it's already in our cache. https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L130 However that record is not right since this lot is linked to the wrong product bbb. https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L135-L138 We will try to retrieve again the right record, however we will once again get a hit on the cache. As such no RPC call will be made to retrieve the lot we're looking for. We will go in the function once again, where we will have the same problem this time in the `if (model)` condition. https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/lazy_barcode_cache.js#L112-L115 Later in the execution we will get to this line where we call the function without a filters which will allow the wrong record to be added. https://github.com/odoo/enterprise/blob/ed30bde4af5d77261f3a44ba4235fd435153c7ce/stock_barcode/static/src/models/barcode_model.js#L943 The root of this problem lies in the way we set the key to the cache, since two product can share the same barcode we need a more precise cache key to differentiate them. The proposed solutions is to cache result based on the provided arguments to the function. This means fewer hit if we retrieve the same record with different filter for example, however it's safer as when we hit we are sure to get the right record. opw-3862263
This fix resolves an issue where uploading a file to a document activity would create two documents instead of one, causing an access error. The system now prevents duplicate document creation by checking if a document already exists for the activity before creating a new one during file upload.
Original PR description
**Steps to reproduce:** - Install `documents_project` module (for test purposes) - Create a new activity type with: - `action`: `Upload Document` - `folder_id`: `Internal` - `model_id`: `Task` - Go…
**Steps to reproduce:** - Install `documents_project` module (for test purposes) - Create a new activity type with: - `action`: `Upload Document` - `folder_id`: `Internal` - `model_id`: `Task` - Go to settings and enable `Centralize files attached to projects and tasks` (from 16.0, set a default folder on the project) - Go to any task and add a new activity with the new activity type - Click on `Upload Document` and select a file **Issue:** Access right error message. **Cause:** Simple explanation: 2 documents are created (one on the activity creation and one on the attachment upload) and the attachment is linked to the second document. When trying to fisrt unlink the second document and then link the attachment to the first document, the attachment is already unlinked. Detailed explanation: When creating the activity, if a folder_id is set on the activity, an empty document is first created with the request_activity_id. https://github.com/odoo/enterprise/blob/a23a18681bddc5995c5dac8cacfb074c06fc5ea8/documents/models/mail_activity.py#L46 When uploading the file, if the related record model is an inherit of `documents.mixin` model and the documents settings (in this case `Document Project Settings`) are activated, it will create the document with the attachment. https://github.com/odoo/enterprise/blob/2df654e8cb08d528976d5f1d24397574798a5cad/documents/models/ir_attachment.py#L63 Then, in the action done, we will unlink the last document record created and try to link it's attachment (already unlinked) to the first document record (with the `request_activity_id`). https://github.com/odoo/enterprise/blob/2df654e8cb08d528976d5f1d24397574798a5cad/documents/models/mail_activity.py#L33 Since the following commit, when unlinking a document, it unlink also it's attachment: https://github.com/odoo/enterprise/commit/a999f2c32ab542ca7aa44cf34970dc7cca4fdaf8 **Solution:** Override the upload route (`/mail/attachment/upload`) so that it skip the creation of the second document (by adding `no_document` to the context) if an activity ID is available and that a document with a `request_activity_id` with the same activity ID already exists. COM PR: https://github.com/odoo/odoo/pull/159943 opw-3458850 Forward-Port-Of: odoo/enterprise#62209 Forward-Port-Of: odoo/enterprise#59796
This update resolves an issue where users creating immediate transfers in the Barcode app were unable to scan certain warehouse locations due to overly restrictive validation rules. The fix allows users to scan any relevant location when creating transfers on-the-fly, since they cannot pre-set source and destination locations. Additionally, a minor bug is corrected where location names containing the default location's name were not displayed correctly on barcode lines.
Original PR description
The commit 0c84f2d86b982d1b244622f2d86ca474f0ba496b fixes the fact than users could scan any locations as the source, even if the scanned location is not related to the picking's source location. But…
The commit 0c84f2d86b982d1b244622f2d86ca474f0ba496b fixes the fact than users could scan any locations as the source, even if the scanned location is not related to the picking's source location. But for immediate transfer, it is not very wise to limited which location the user can scan because they have no way to set source or destination for picking created on the fly from the Barcode app. This commit fixes this issue. How to reproduce: - Inventory -> Settings -> Enable "Multi-Step Routes"; - Go to your warehouse and choose 3 steps for incoming and/or outgoing shipments; - Go to the Barcode App > Operations > Internal Transfers > New; - In the newly created transfer, try to scan who is not a sublocation of WH/Stock (WH/input for example, barcode: WH-INPUT) - :arrow_right: An error message is displayed because you are not allowed to scan this location. The exact same issue happens for destination too since 61d378b0a49ba734cff84a39aa2693fe4226225d. Also, fix a minor unrelated bug where locations on the barcode line are not correctly written when there name include the picking's defaut location's name (eg.: WH/Stock 2 when the default location is WH/Stock.) [OPW-3843358](https://www.odoo.com/web#id=3843358&cids=1&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#62550 Forward-Port-Of: odoo/enterprise#62480
This fix corrects a typo in the Mexican EDI payment complement feature that was preventing bank account information from appearing on payment receipt PDFs. The update also improves how the system retrieves payment data to handle cases where not all information is always available, making the payment receipts more reliable and complete.
Original PR description
Fixed typo for `cdfi` that not generates the section for bank accounts on the PDF for payment complement, and with this fix was improved the way to get the values from the dict, because not in all the cases are assigned all the values. https://github.com/odoo/enterprise/blob/17.0/l10n_mx_edi/models/account_move.py#L392
This update adjusts the employment bonus calculations in the Belgian payroll system to reflect the latest government regulations through May 2024. The changes ensure that employee bonuses are calculated correctly according to current Belgian labor law, which is important for accurate payroll processing and compliance.
Original PR description
TaskID: 3942303
This fix resolves an issue where the "Send" button was not appearing in the Dutch ICP report wizard unless users manually checked the "Is Test" checkbox. The problem was caused by missing date fields that the system needs to properly determine when to show the button. By adding these invisible fields to the form, the button now displays correctly based on the selected dates.
Original PR description
The compute function _compute_sending_conditions needs date_from and date_to fields as its dependencies to compute whether or not to show the "Send" button on the ICP report SBR wizard. Without them, the field does not get properly recomptued, and the button isn't shown, unless the "Is Test" checkbox gets ticked by the user. Forward-Port-Of: odoo/enterprise#62876
This update fixes how account codes are extracted from trial balance reports for Mexican tax filing (SAT XML). Previously, the system incorrectly parsed account codes when users added custom accounts with dots in their names or codes with more than the standard format. The fix now correctly handles these variations while maintaining compatibility with standard accounts, ensuring accurate tax report generation.
Original PR description
The field NumCta in the SAT XML is parsed from the lines in the trial balance report. The name of the line is the code for the account concatenated with the name of the account. The existing…
The field NumCta in the SAT XML is parsed from the lines in the trial balance report. The name of the line is the code for the account concatenated with the name of the account. The existing implementation assumes the code has 3 sets of digits separated by two dots, and that the account name has no dots. This is true for the default chart of accounts for Mexico, but is not necessarily the case if additional accounts are added by the user. As a result, invalid NumCta values were generated, which would include parts of the account name if dots were present in it, or the value would be too long if the code had more than two dots. Subdividing the code into further levels is allowed, they'll get aggregated into the allowed SAT code (of the form XXX or XXX.YY). Dots in account names shouldn't matter. This fix makes the parsing of the NumCta value more strict so it supports the above use cases. In case the prefix doesn't match the expected pattern, an error is shown to the user. Normally this shouldn't happen, since the line would have been filtered out if it didn't match a valid prefix from the upper levels. It was added to make the code more robust against refactoring and customization, and to prevent an uncaught traceback in that case. opw-3878763 Forward-Port-Of: odoo/enterprise#62885 Forward-Port-Of: odoo/enterprise#62113
This update fixes a memory issue that occurred when generating SAFT financial reports with large amounts of data. The system now processes data in smaller batches instead of loading everything at once, preventing crashes and allowing the report to complete successfully even with extensive transaction histories.
Original PR description
Issue --> The fetchall call made after the querying the dataset in `_saft_fill_report_general_ledger_values` runs into a memory error if there is a large number of rows. Solution --> Use a `while True` loop to use `dictfetchmany` to return rows in batches to optimize memory usage. `dictfetchmany` returns None if no rows are returned, which is the exit condition of the loop. opw-3859206 Forward-Port-Of: odoo/enterprise#62571 Forward-Port-Of: odoo/enterprise#61272
This fix resolves a performance issue in batch payment creation where an editable payment method code field was triggering unnecessary recalculations across all related payments. By making this field read-only, the system no longer performs these redundant calculations, improving database performance especially for organizations processing large volumes of batch payments.
Original PR description
payment_method_code was in the view for the batch payment creation view. However, when you create batch payment the check printing module has a compute that was being triggered on all payments with the same payment method because the payment method's code was being written by the payment_method_code on this view. This would cause performance issues on some databases. Setting this to readonly causes the create to no longer use this payment_method_code value and subsquently no longer triggers the recompute. opw-3848817 Forward-Port-Of: odoo/enterprise#62431 Forward-Port-Of: odoo/enterprise#61908
Customers who receive a link to a helpdesk ticket with an attached field service task were getting an error (403 access denied) when clicking the link while not logged in. This fix prevents the Tasks link from appearing to users who don't have permission to access it, ensuring a better customer experience.
Original PR description
**Steps** - Install Field Service and Helpdesk - Create a ticket for a customer. Add a field service task. A link will be sent to the customer via mail (visible in chatter). ** 403 for the customer if not logged in when clicking the link ** **Issue** Access rights issue here https://github.com/odoo/enterprise/blob/4f44fcf5761ca5499ede148e2e49363e3c8f80bc/helpdesk_fsm/controllers/portal.py#L34 **Fix** Don't show the "Tasks" link if the user doesn't have access rights to them. opw-3911444 Forward-Port-Of: odoo/enterprise#62087
A testing component was moved from the CRM Enterprise module to the correct location, enabling community users to run related quality assurance tests. This fix resolves an issue where certain tests were inaccessible to users without the enterprise version.
Original PR description
This was currently defined in `crm_enterprise` which made impossible to run QUnit tests dependent on this model in community. runbot-65889 https://github.com/odoo/odoo/pull/166475
This update fixes a display issue in the Partner Ledger report where grouped partner lines were incorrectly showing "0.0" in text columns instead of remaining blank. The fix ensures that non-numeric columns display properly when partners are grouped by prefix, improving report readability and accuracy across all accounting reports that use this grouping feature.
Original PR description
To reproduce the issue, on a runbot with the demo data: 1) Setup a prefix group threshold of 2 on the Partner Ledger 2) Open the Partner Ledger ==> The lines created for the prefix groups show "0.0" in the columns supposed to contain non-number values. Instead, these columns should contain empty values on those lines. The bug originates in the common helper called to generate the prefix group lines, so it does not only impact the Partner Ledger. We fix it and modify the test a little bit to check that behavior as well. Forward-Port-Of: odoo/enterprise#62740
Fixed a technical error that occurred when users attempted to clear the team assignment on a helpdesk ticket. Previously, the system would crash with an error message instead of properly validating the input. Now users will only see a validation message if they try to save without assigning a team, providing a better user experience.
Original PR description
When the team_id of a ticket is set to False in its form view, a traceback occurs. This is an invalid value anyway, but the user should only be notified of that fact when he tries to save his change,…
When the team_id of a ticket is set to False in its form view, a traceback occurs. This is an invalid value anyway, but the user should only be notified of that fact when he tries to save his change, not with traceback. Step to reproduce: - Open helpdesk - open the 'all tickets' menu - open any ticket form - set the team_id to false - save changes or click anywhere else to leave the edit field => a traceback occurs Source of the issue: When a new team is set on a ticket, a new stage is set on it, as well as new sla_status. The issue is that inside the _compute_sla_deadline method, the calendar of the team is used. But since there are no teams, there are also no calendar. And the ensure_one() fails later on in the stack because of that. Solution: Prevent the computation of those values for ticket without team_id. Since this is an invalid value, the changes would be rolled back anyway, or overwrite once the user put a valid value for the team. version 16.0 - master task - 3895303 Forward-Port-Of: odoo/enterprise#61563
This fix corrects how shipping reference IDs are processed when sending delivery requests to bpost. Previously, only the first two forward slashes were being removed from reference IDs, which caused incorrect shipping request URLs when references contained more than two slashes. Now all slashes are properly removed, ensuring accurate shipping requests.
Original PR description
Before this commit: Only the first two `/` were removed from reference_id of picking. creating wrong shipping request url for reference_id with more than two `/`. After this commit: All the slashes are removed from reference_id. opw-3853123 Forward-Port-Of: odoo/enterprise#60652
This update increases the timeout for Sendcloud delivery requests from 15 seconds to 60 seconds. The previous timeout was too short when processing large amounts of shipping data, causing requests to fail. This change ensures that large delivery requests complete successfully without timing out.
Original PR description
Before this commit: request timeout was 15 seconds, which was too short for sendcloud request when requesting large ammount of data. After this commit: request timeout increased to 60 seconds. opw-3890386 Forward-Port-Of: odoo/enterprise#62043
Fixed an issue where lines with zero values were still appearing in exported PDF and Excel reports even when the "Hide lines at 0" option was enabled. Now when users toggle this setting, zero-value lines are properly hidden in both the on-screen view and printed documents, ensuring consistency between what they see and what they export.
Original PR description
0 lines are still included in exported report when Hide lines at 0 is toggled Steps to reproduce: - Open a report, e.g. Balance Sheet (Accounting > Reporting > Balance Sheet) - In options, toggle 'Hide lines at 0' - Click in PDF to export a PDF version of the report - 0 lines are included in the PDF file When "Hide lines at 0" is toggled, lines at 0 are still included in the PDF/XLSX report, despite being hidden in the report view. This leads to a difference between what the user sees and what is printed. Another reason to hide lines at 0 from the printed report is that lines with Hide if Zero checked does impact the PDF. This means the two options (Hide lines at 0 and Hide if Zero) have similar impacts in the user view but different behavior in printed reports. This commit implements the function _filter_out_0_lines to remove lines at 0 from printed report if "Hide lines at 0" is toggled, and adds a test. task-3888290
This update fixes an issue with the kitchen display system's main menu visibility in the Point of Sale module. The fix prevents unnecessary software installations from occurring during system upgrades, ensuring a smoother and more efficient update process for restaurant operations.
Original PR description
Backport of fix from master to 17.0 to avoid unnecessary installation during upgrades: https://github.com/odoo/enterprise/pull/56794 task-3725031
This update corrects how base amounts are calculated in accounting tax reports when they are grouped by account and tax. Previously, only tax amounts were properly summed while base amounts were duplicated, causing inaccurate tax reporting. The fix ensures both base and tax amounts are correctly aggregated in grouped tax reports.
Original PR description
Before this commit: The sum of base amounts and tax amounts for accounting reports in 16 is inaccurate. When collecting taxes, implementation was included in 16 to create multiple nodes based off whether the node was a refund, it's tax_id, sale/purchase, and it's account_id. This logic was done to prevent duplicates from being added to the report. However, the base amount was the only value that did this sum with a check, and the tax amount was added regardless. This results in multiple databases with improper tax information generated on the tax reports that are sorted by "Account >> Tax" or "Tax >> Account". Including the addition of base_amount in the computations that check for duplicates will create the right sum for the grouped tax report templates. opw-3890736 opw-3793820
This fix corrects how payment reference information is extracted from CAMT bank statement files. Previously, the system was looking for reference information in the wrong location within the file structure, causing it to display "/" instead of the actual payment details. Now it correctly retrieves the additional entry information that serves as a fallback when primary reference data is unavailable.
Original PR description
Currently, when importing a CAMT file, the system fails to use `<AddtlNtryInf>` as a fallback for the payment reference. ### Steps to Reproduce 1. Install `account_bank_statement_import_camt`. 2. Import a CAMT file with a statement that includes `<TxDtls>` but no `<RmtInf>`, and has `<AddtlNtryInf>` defined. (You can use the one provided in the tests) **Expected Result:** The imported statement's payment reference should contain the value of `<AddtlNtryInf>`. **Actual Result:** The imported statement's payment reference contains `/` instead. ### Cause The system attempts to use `<AddtlNtryInf>` as a fallback for `payment_ref`. However, it looks in the wrong place. It searches inside `<TxDtls>`, whereas `<AddtlNtryInf>` is actually a child of `<Ntry>`. opw-3878785 Forward-Port-Of: odoo/enterprise#62703
This fix resolves a system error that occurred when users tried to delete toppings from lunch vendors. Previously, deleting a topping would cause the system to crash with an error message. Now users can successfully delete toppings without encountering this issue.
Original PR description
When the user tries to delete the toppings, a traceback appears. Steps to reproduce the error: - Go to Lunch > Configuration > Vendors > Open any vendor - Now add extra 2 (topping 2) > Save - Delete…
When the user tries to delete the toppings,
a traceback appears.
Steps to reproduce the error:
- Go to Lunch > Configuration > Vendors > Open any vendor
- Now add extra 2 (topping 2) > Save
- Delete that extra 2 (topping 2) > Save
Traceback:
```
IndexError: list index out of range
File "odoo/http.py", line 2251, in __call__
response = request._serve_db()
File "odoo/http.py", line 1827, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1847, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1825, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1832, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2057, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 739, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 71, in web_save
self.write(vals)
File "addons/lunch/models/lunch_supplier.py", line 193, in write
topping_values = topping[2]
```
https://github.com/odoo/odoo/blob/07f6d71e4dd3fac7b4cacc545819430aa48823cd/addons/lunch/models/lunch_supplier.py#L192-L193 Here when the user deletes the extra 2 (topping 2),
"topping" will be [2,2] instead of [2,2,False].
So when it tries to access topping[2],
It will lead to the above traceback.
sentry-5203693767
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes two display problems with mobile menus on websites. First, when users click to close and reopen a mobile menu, the menu backdrop now displays correctly instead of breaking the page layout. Second, when a header is set to display "Over The Content," it now properly remains transparent when the mobile menu opens, instead of incorrectly showing a colored background. These fixes improve the mobile browsing experience for website visitors.
Original PR description
**[FIX] website: fix close offcanvas on page click** Steps to reproduce the bug: - In "Website" edtit mode. - Drop some snippets. - Select a Hamburger menu header template or resize the screen at MD…
**[FIX] website: fix close offcanvas on page click** Steps to reproduce the bug: - In "Website" edtit mode. - Drop some snippets. - Select a Hamburger menu header template or resize the screen at MD to have the mobile menu. - Open the menu => the offcanvas backdrop is transparent and we see the snippets behind it. - Click on the page to close it and then reopen it. => The offcanvas is not transparent anymore and the layout looks broken. This is due to the fact that the code handles the hint preview for the "Powerbox" considers that it must insert the hint in a "<div>" if it's empty. See the "_makeHint()" function in this commit [1]. In this commit, we fix this by preventing selection on the backdrop. There's probably a better way to fix it. But until the problem is solved more generally, we simply fix it in CSS for the "Backdrop". [1]: https://github.com/odoo/odoo/commit/4600086e7a2831664cc104a143e1014870874427 task-3853573 ----------------------------- **[FIX] website: fix overlay header when mobile menu is open** Steps to reproduce the bug: - Open a page in Website edit mode. - Click on the header. - Select a red color for the background option of the header. - Choose "Over The Content" for the "Header Position" option. - Resize the screen to MD to have the mobile menu. - Click on the "hamburger button". => Bug: The header is red instead of transparent. The bug arises because since this commit [2], the transparent background of the "Over The Content" header is removed when the mobile menu is open. [2]: https://github.com/odoo/odoo/commit/e10913daf7025accb3b93808ae12ce4a50db1510 task-3853573
This fix resolves an issue where creating multiple down-payments on the same sales order would generate extra unwanted down-payment lines. The system now correctly filters out previously created down-payment lines when calculating new ones, ensuring only product-based lines are considered. This prevents confusion and errors in invoice generation.
Original PR description
Issue:
======
Extra down-payment line is creating
Steps to reproduce the issue:
=============================
- create an SO, then create downpayment with 30% percent, remove the tax in generated INV and post the invoice.
- go back to SO create another downpayment with 30%
Solution:
=========
Typically, when calculating the value of down-payment lines,
we only consider sales order lines for products, not down-payment lines.
This is because, according to the Odoo workflow,
down-payment lines are created based on product lines in the sales order,
not on down-payment lines themselves. Therefore, I am filtering out those lines here.
closes odoo/odoo#163699
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes a critical issue where setting the repeat interval to zero in recurring maintenance requests causes the system to crash when accessing the maintenance calendar. A validation check has been added to prevent users from saving invalid repeat interval values, ensuring the maintenance calendar functions properly.
Original PR description
If you have "repeat interval" set to "0" in the Maintenance request, and if you go to the Maintenance calendar, then the system crashes. Adding a validationError to avoid the crash. To Reproduce on Runbot: 1. Go to Maintenance Request 2. Make a new request with Maintenance type as Preventive, Recurrent checked, and Repeat Every to 0. 3. Save it 4. Go to Maintenance Calendar 5. The system crashes opw-3859966 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue in the e-learning app where the word "false" was incorrectly displayed when a quiz had no description. The problem occurred because the code wasn't properly handling empty description values, causing them to be converted to the text string "false" instead of remaining blank. Users will no longer see this unwanted text when viewing quizzes without descriptions.
Original PR description
Inside our `_fetchQuiz` we pass the markup() to the quiz description to check that the description we have introduced is safe to be converted into html, the problem is that this markup() is not handling properly when the value of `quiz_data.slide_description` is false, so instead of not displaying anything we are sending a string of 'false'. Steps to reproduce: 1. Create quiz-type content inside a course in the e-learning app. 2. Do not add a description to the quiz. 3. Go to the website page of the course. 4. Open the quiz in fullscreen. 5. A "false" message is displayed on the top-left corner. opw-3887445
This fix resolves a problem where employees couldn't reorder rows in two-week work schedules. When users tried to drag and reorder schedule rows, they would reset to their original positions. The issue has been corrected so that reordering now works as expected, and new schedule rows now appear in a more intuitive location in the interface.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Ensure debug mode is off; 2. go to Employees / Configuration / Employee / Working Schedules; 3. select a schedule and switch it to a 2 week calendar; 4. try…
Versions -------- - 17.0+ Steps ----- 1. Ensure debug mode is off; 2. go to Employees / Configuration / Employee / Working Schedules; 3. select a schedule and switch it to a 2 week calendar; 4. try to reorder one of the rows. Issue ----- Row resets to original place. Cause ----- Commit a9b804b1ad6c added a `default_order` to the view, its values get passed to the `_sort` function of `StaticList`, which then compares them to the `activeFields` of the loaded model. One of the fields given to `default_order` is `week_type`, which isn't included in the `activeFields` of the loaded model unless you're in developer mode. This is a consequence of being assigned to the group `base.group_no_one`. Because of this mismatch, it assumes the model isn't loaded yet, and creates a new one with the `week_type` field in order to sort them, leaving the original records (the ones in view) unchanged. Solution -------- Remove the `groups` attribute from `week_type`, and make it an optional field. Also switch `editable` from `top` to `bottom` to make the line appear right above the `Add a line` line. opw-3773432
This fix corrects a problem where changing the unit of measurement on an expense would incorrectly update the unit price. The issue occurred because the system was recalculating prices in situations where it shouldn't. The fix ensures that price recalculation only happens when using the OCR (document scanning) feature, preventing unintended price changes when users manually adjust units.
Original PR description
Steps to reproduce: - Create an expense - Add a product (with units) - Save - Add an attachement - Change the units Issue: The price unit will change to match the total Cause: We wanted to avoid using the _price_compute in case of the OCR Solution: We are making sure that the price unit is only recomputed when using the OCR enterprise: https://github.com/odoo/enterprise/pull/62425 opw-3869104
This fix corrects how byproduct quantities are displayed in manufacturing order overviews. Previously, the system was showing the planned quantity instead of the actual quantity produced, which could confuse users about what was actually manufactured. Now byproducts display the same accurate quantity information as components.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1” with BoM:
- Component: 1 unit of C1
- By-product: 1 unit of C2
- Create a manufacturing order to produce 2 unit of P1
- Confirm the MO
- Set the qty producing to 1 unit and mark it as done
Problem:
The quantity displayed for the byproduct is the quantity to produce (product_uom_qty) instead of the quantity produced (Quantity)
https://github.com/odoo/odoo/blob/a94f3f4dcb24e08cd4db7fd50ea704e9a065fd83/addons/mrp/report/mrp_report_mo_overview.py#L434
opw-3903182This fix ensures that when restaurant staff select a table and view the product selection screen, the table number is now displayed in the navigation bar. Previously, staff had no visual reminder of which table was selected, which could lead to orders being placed for the wrong table. This improvement helps prevent order mistakes in restaurant operations.
Original PR description
For version 17.0 only Problem: In restaurant, in the product page, we don't have anything to remind which table is selected Steps to reproduce: - Install "Point of Sale" app and "pos_restaurant" module - Open a restaurant session - Click on a table, the product page is loaded and we don't see the table number in the navbar Note: Solution copied from version 17.1 opw-3929069 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves how the accounting system retrieves product information by ensuring it properly considers the company context. When no specific company is provided, the system now automatically uses the current company from the environment, and prioritizes products that are explicitly linked to that company. This ensures consistent and accurate product data retrieval across different company setups.
Original PR description
When company is not passed as parameter, take the company from the environment by consistency with 'retrieve_partner'. Also, search for a product explicitely linked to the company in priority. enterprise PR: https://github.com/odoo/enterprise/pull/61741 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163938
This fix resolves errors that occurred when using IoT devices (like printers) with the Point of Sale system and invoice reports. The issue was caused by missing required service files in the system configuration. After this fix, businesses can now successfully use IoT-connected printers and devices in their POS operations without encountering errors.
Original PR description
Current behavior: When an iot device is linked to the PoS and invoice report, you had an error because action service and iot_websocket service where not available. Steps to reproduce: - Install pos_iot - Set an iot_device printer on the pos session - Set an iot_device on the report of the invoice - Open session, make an order and invoice it - You get an error opw-3792576 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes two issues in the subcontracting workflow. First, it prevents the subcontracting button from appearing prematurely on stock moves before any quantity has been delivered. Second, it corrects the details button to properly display subcontracting information instead of redirecting to the wrong view. These fixes ensure users see the correct interface at the right time when managing subcontracted manufacturing orders.
Original PR description
### Steps to reproduce: - Enable subcontracting in the settings - Create a finished product FP tracked by lot using the buy route - Create a component product CP tracked by unique serial numbers and…
### Steps to reproduce: - Enable subcontracting in the settings - Create a finished product FP tracked by lot using the buy route - Create a component product CP tracked by unique serial numbers and using the routes: - Buy - Resupply Subcontractor on Order - Create a BOM for FP of type subcontracting and consuming 1 x CP - Create and confirm a purchase order for 2 x CP, assign serial numbers on the receipt, receive products and validate - Create and confirm a purchase order for your subcontractor for 2 x FP - Go to the resupply picking, assign the stock moves related to your components and validate - Go to receipt #### Two issues reported by the PO (mgm): 1) The subcontracting button is visible on the move even though no qty was delivered yet. 2) The `fa-list` button on the move redirects to stock move lines of the move rather than to the "action_show_details". ### Cause issue 1: The `show_subcontracting_details_visible` computed field determine if the button should be visible. Prior to the `quantitypocalypse` this field relied on the `quantity_done` to determine if the button should appear: https://github.com/odoo/odoo/blob/c68b17e944079f0718a1bef74b941dcb18b841e3/addons/mrp_subcontracting/models/stock_move.py#L30-L37 As this field does not exist in 17.0 anymore, the new condition relies on the `quantity` field: https://github.com/odoo/odoo/blob/3dc2e25f30a411f49f895568b4689265152f153d/addons/mrp_subcontracting/models/stock_move.py#L30-L36 However, this field only represents the same thing as the quantity_done when the move is `picked`. ### Cause of issue 2: The `fa-list` button referring to the `action_show_details` in 16.0: https://github.com/odoo/odoo/blob/d1bdcde5160d1a320396f0703103a50e8636e96f/addons/stock/views/stock_picking_views.xml#L302-L303 (that is overriden in `mrp_subcontracting`) has been replaced in 17.0 on the `stock.picking` form view by the one2Many record stock.move widget: https://github.com/odoo/odoo/blob/b4ae1ed7382dcb9c91c06ba0055974994dcdf54c/addons/stock/static/src/views/picking_form/stock_move_one2many.xml#L3-L8 see commit 4da8c6e for more details. opw-3871634 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
This fix prevents customers from completing purchases when shipping information contains errors (such as invalid addresses or unsupported delivery locations). Previously, the "Pay Now" button remained active even when shipping costs were incorrectly calculated as zero due to carrier validation failures. Now the payment button is properly disabled when shipping errors are detected, protecting both customers and the business from incorrect orders.
Original PR description
## Issue: - When a customer places an order on the website and there are errors in the shipping informations, such as an invalid address format, the shipping costs drop to 0€ if only one shipping…
## Issue:
- When a customer places an order on the website and there are errors in the shipping informations, such as an invalid address format, the shipping costs drop to 0€ if only one shipping method is available.
- Despite these errors, Odoo does not block the "Pay now" button, allowing the customer to proceed and pay 0€ for shipping.
## Steps To Reproduce:
- Install UPS US on your db and publish it.
- unpublish the other shipping methods.
- Go to /shop and purchase any product as a customer
- During the checkout process, add an address that has more than 35 characters
- Notice you'll be allowed to pay and your order will be confirmed.
In an other scenario:
- Install Fedex US on your db and publish it.
- Set Fedex service type to STANDARD_OVERNIGHT
- unpublish the other shipping methods.
- Go to /shop and purchase any product as a customer
- During the checkout process, set Hawaii in state/Povince
- Notice you'll be allowed to pay and your order will be confirmed even though Hawaii doesn't support STANDARD_OVERNIGHT shipping.
## Explanation and Solution:
- The first issue arises when there is only one shipping provider available; it gets selected by default. After this selection, the `start` method of `websiteSaleDelivery` is triggered, which attempts to force-click the already checked shipping carrier. Consequently, it returns without completing the logic because the click event handler `_onCarrierClick` dismisses with the following condition:
`if (radio.checked && !this._shouldDisplayPickupLocations(ev)) {return;}`
- The second problem occurs because the `start` method is triggered as soon as the `websiteSaleDelivery` public widget is rendered, which does not allow enough time for the `PaymentButton` to be rendered. This delay causes the `_disablePayButton` method to fail.
- To address the first issue, I added a flag `refreshclick` to indicate that the shipping carrier was set by default.
- To address the second issue, I modified the `_enableButton` method to actively disable the button if the status is false. This change ensures that the `PaymentButton` widget has sufficient time to render since `_enableButton` is called within `_handleCarrierUpdateResult` after awaiting the response from an RPC call.
opw-3844214
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#165267
Forward-Port-Of: odoo/odoo#161704Event tickets were displaying dates in UTC instead of the user's local timezone, causing the date to appear one day off when the event was scheduled in a timezone west of UTC. This fix ensures that event dates on downloaded ticket PDFs now display correctly in the user's timezone, improving the accuracy of event information provided to attendees.
Original PR description
The date on an event ticket can be wrong. To reproduce, create an event with a date_begin datetime that falls on the next UTC day. For example, specifying 2024-05-23 18:30 with the user's timezone as America/Los_Angeles results in a stored UTC time of 2024-05-24 01:30:00 (next day). Make sure the timezone of the public user is unset for simplicity's sake (it will fall back on that timezone), and then register for the event in an incognito window through the website. After registering, click "Download Tickets". The ticket PDF will display the UTC date. The event_registration_report_template_full_page_ticket wrapper sets the timezone in context: <t t-set="event" t-value="attendee.event_id._set_tz_context()"/> But ir.qweb.field.datetime doesn't use the record with attached context and only looks directly at the value. To make it work, tz_name must be specified explicitly. This is already done for the time part of date_begin below. opw-3930916
This fix prevents partners without active user accounts from appearing in the chat command palette when using the @ mention feature. Previously, any partner who was a member of a channel (like WhatsApp) would show up as a chat option, even if they couldn't actually receive messages. Now only partners with valid user accounts will be suggested, improving the user experience and preventing failed chat attempts.
Original PR description
**Current behavior before PR:** if a partner is a member of any channel (eg, whatsapp channel) it will be displayed in the command palette even if he does not have any associated user.which will cause issues as you can not chat with partner who do not have any dedicated user. **Desired behavior after PR is merged:** partners with no dedicated users will not be displayed in the command palette to chat with when you enter @. Task-3815150 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165960 Forward-Port-Of: odoo/odoo#159239
This update fixes a critical bug where the system crashes when calculating how much a customer can still invoice, and improves the speed of these calculations. The fix prevents errors from invalid data and makes the system more efficient by letting the database handle calculations instead of processing large amounts of data in the application.
Original PR description
Currently there are 2 issues with the function used to compute `credit_to_invoice` on model 'res.partner' (`_compute_credit_to_invoice`): 1) On 17.0 a traceback has been reported. There were…
Currently there are 2 issues with the function used to compute `credit_to_invoice` on model 'res.partner' (`_compute_credit_to_invoice`): 1) On 17.0 a traceback has been reported. There were instances in which the `amount_to_invoice` was `None` and not `0` (to be looked at in a separate fix). In such a case the `None` value is passed to the `float` function and causes a traceback. 2) From a performance perspective it is unnecessary to aggregate all the `amount_to_invoice` values into an array and then postprocess them in python. Effectively the only thing we do in the postprocess is sum all the values but ignore all non-postive values. Thus we can just ignore sales orders with `amount_to_invoice <= 0` and let the SQL / the database handle the summing. This way we avoid the overhead from passing around the array(s) (size proportional to the number of sales orders) and just pass around a single value. This commit introduces the changes mentioned in (2). These changes also solve (1): The additional condition in the domain leads to sales orders where `amount_to_invoice` is `None` being ignored. (SQL / the DB handles (1) for us now.) related PR introducing the changed lines of code: https://github.com/odoo/odoo/pull/162770 a comment about the issue in 17.0: https://github.com/odoo/odoo/commit/b5d02cc72543b36c7e5e620a3a579f15c88baed6#r141990142 Forward-Port-Of: odoo/odoo#166175 Forward-Port-Of: odoo/odoo#166087
This update fixes a crash that occurred when users tried to select multiple tables at once using their mouse in the web editor. The fix prevents the application from throwing an error by properly handling cases where the selection doesn't contain a valid table element.
Original PR description
**Current behaviour before PR:** Selecting multiple tables using mouse throws traceback. This happens because in _selectTableCells method, range has no table as closest element of commonAncestorContainer which gives traceback later. This method needs a table as closest element to be worked. **Desired behaviour after PR:** There should be no traceback. This can be handled by returning the method if we don't find the closest table. task-3922517 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165234
This fix prevents multiple duplicate dialog windows from opening when users click the same action multiple times while waiting for it to load on slow internet connections. Now only the last requested action will open, providing a cleaner and less confusing user experience.
Original PR description
Current Behaviour: - Currently, if the internet is slow and the user tries to open any action, which action target='new,' it takes time to open the action form in the browser, if the user clicks multiple times during this loading process, multiple instances of the same action will be displayed to the user. Steps to produce: - Open CRM and navigate to the activity view of CRM. - Select throttling as 'Slow 3G' in your browser network setting. - Now click multiple times on any scheduled activity to open an action. Expected Behaviour: - Only open the dialog for the last action requested when there are multiple actions requested with target='new'. Task-3750720 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165940 Forward-Port-Of: odoo/odoo#159236
Fixed a bug where design changes made to email templates (colors, formatting, sizing) were not appearing in test emails. The system was using outdated styling rules instead of the updated ones. This fix ensures that when users customize the design of their marketing emails and send a test, the changes are properly reflected in the preview.
Original PR description
Issue: ====== Email doesn't have applied design changes (format , color ..) Steps to reproduce the issue: ============================= - Go to Email marketing - Create a new one - Add a subject,…
Issue: ====== Email doesn't have applied design changes (format , color ..) Steps to reproduce the issue: ============================= - Go to Email marketing - Create a new one - Add a subject, mailing list, and choose any template that have some blocks - Go to design tab in editor and change any color or size of something - Click save and test sending the email - The email doesn't have the changes applied Origin of the issue: ==================== When first rendering , CssRules are calculated using the first version of the template and styles. When we update the design so the css rules, they are not applied in the inlineHtml since it uses the old cssRules. Solution: ========== We only use `_rulesCache` defined in `wysiwyg` and we already handle everything in `toInline` from calculating the `cssRules` to saving them in the cache, so we just pass `undefined` as cssRules and let it take care of everything. task-3289131 Forward-Port-Of: odoo/odoo#166246 Forward-Port-Of: odoo/odoo#153180
This update implements new Indonesian tax authority rules for E-faktur invoicing where NPWP (tax ID) and NIK (national ID) now work together as complementary fields. Users must now provide either a valid NPWP, NIK, or both—the system will no longer auto-fill NPWP with zeros. This ensures compliance with the latest e-invoice regulations and improves data accuracy for Indonesian businesses.
Original PR description
Due to recent rule changes for E-faktur, now NIK and NPWP are complement to each other. Which means now, when the person is filling in 000000000000000, e-faktur should be taking the NIK as NPWP column in e-Faktur 3815006 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166182 Forward-Port-Of: odoo/odoo#163707
This update fixes how date filters work in spreadsheets when dealing with datetime fields across different timezones. Previously, the system was comparing dates incorrectly, which could cause filters to show wrong data because a date in one timezone might actually be a different date in UTC. The fix ensures that date and time comparisons are done properly regardless of the user's timezone.
Original PR description
Steps to reproduce: - add a pivot in a spreadsheet - create a From/To global filter - match the filter with a datetime field of the pivot - set some values in the filter => the domain contains dates, but they should compare the values with datetimes, because a date in a given timezone might start the previous day in UTC time. opw-3805775 Task:3853821 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the web interface from getting stuck in an endless reload cycle when the server connection is lost while viewing records. Previously, if a user tried to open a record while the server was down, the system would repeatedly attempt to reload the list view indefinitely. The fix restores a check that detects when an error occurs in a view that's already displayed, and shows the error message instead of continuing to reload.
Original PR description
Shut down the server to simulate a connection lost when being in a multi record view. Click on a record to open it in form view. As the server is down, the web_read rpc will fail. The error will be…
Shut down the server to simulate a connection lost when being in a multi record view. Click on a record to open it in form view. As the server is down, the web_read rpc will fail. The error will be caught by the onError in the action service, which will try to restore the previous controller (the multi record view). The server being down, requests for that controller will fail as well, and we'll end up again in the same onError callback. Since [1], we'll indefinitely try to reload the multi record view, because we removed the check detecting that the error occurs in the controller that is already in the DOM. If that controller fails, there's no point trying to restore it again, instead, we just show the error. This commit simply restores that part of the code as it was before [1]. [1] odoo/odoo@9c954de94148ab6f3b8d02e6a4713a87fe233a28 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects how timesheet entries are displayed in the customer project portal. When timesheets are configured to use days as the unit of measurement, the portal was incorrectly showing hours instead. The fix ensures the correct unit (days or hours) is passed to the portal view so customers see accurate timesheet information.
Original PR description
Steps to reproduce: - Install Project and Timesheet modules - In Timesheets, navigate to Configurations and choose 'Days / Half-Days' as the Encoding Method. - Create a new project. Then, create a…
Steps to reproduce: - Install Project and Timesheet modules - In Timesheets, navigate to Configurations and choose 'Days / Half-Days' as the Encoding Method. - Create a new project. Then, create a task within the project and assign a Timesheet entry to it for 1 Day. - Share the project and copy the link provided. - When opening the link, the task previously recorded as 1 Day in the Timesheet now appears as 1.0 Hour Spent in the customer's portal Current behavior before PR: We are not passing the 'is_uom_day' value in the project portal view. So in XML when it checks this variable it will get undefined. so, always will go with the else condition. https://github.com/odoo/odoo/blob/16.0/addons/hr_timesheet/views/project_portal_templates.xml#L50:L53 Desired behavior after PR is merged: We are now passing this value to check if the timesheet unit is days so it will be shown as 'Days spent' instead of 'Hours spent' opw-3925368 Forward-Port-Of: odoo/odoo#166164 Forward-Port-Of: odoo/odoo#165737
This fix prevents users from accidentally modifying critical manufacturing-related warehouse settings in debug mode. Previously, these special location and picking type fields could be edited, unlike similar fields in other modules. Now they are locked as read-only to maintain system consistency and prevent misconfigurations.
Original PR description
In debug mode, the special locations and picking types are shown on the warehouse 'Technical Information' tab. All the values shown there are readonly, with the exception of the mrp-related fields. This was likely forgotten at the time, and can lead to misconfigurations, so we make it consistent with the other location and picking types introduced in stock and other modules. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164162
This update fixes a technical issue in the automation system that was causing errors when comparing dates and times. The system was trying to compare two different types of time values (one with timezone information and one without), which was preventing time-based automated workflows from running properly. This fix ensures that automated tasks scheduled by time will execute correctly.
Original PR description
Fine-tunning of 447ac7fb97b5373ce8623461dc89ab78eade7121 Forward-Port-Of: odoo/odoo#166147
Fixed a bug that prevented users from checking refund amounts for multiple payments at once. The system was incorrectly searching for payment records, causing errors when trying to retrieve refund availability information. This fix ensures the refund calculation works properly whether checking one payment or multiple payments together.
Original PR description
If you try to retrieve the `amout_available_for_refund` of a recordset of `account.payment`, it raises a traceback because the search domain includes `self.id` where it should be on the record `payment`. Fixes #165537 Forward-Port-Of: odoo/odoo#165945
This fix resolves a crash that occurred when translating website pages with invisible elements like the Cookies Bar enabled. The issue was caused by a previous update that prevented the system from properly handling invisible snippets during translation. The fix ensures invisible elements are correctly processed and prevents them from being accidentally activated when users interact with the sidebar.
Original PR description
[FIX] web_editor: fix the translation of invisible elements Steps to reproduce: - Add a second language and enable the "Cookies Bar" in your website settings. - Go to a website page (in translation…
[FIX] web_editor: fix the translation of invisible elements Steps to reproduce: - Add a second language and enable the "Cookies Bar" in your website settings. - Go to a website page (in translation mode) > Traceback. The implementation from [1] allowed to use text options (text animations & text highlights) in the translation mode by only creating snippet editors if the target is a text option snippet. This code unintentionally prevented editor creation for invisible snippets, which was required to correctly add entries for every invisible snippet in the sidebar box (see [2] and [3]). The goal of this commit is to fix this behavior by forcing the editor's creation to consider "invisible" elements. A small adaptation of the `_activateSnippet()` method is also required to prevent activating invisible snippets when their related sidebar buttons are clicked. [1]: https://github.com/odoo/odoo/commit/3a149e36f7e6deaf156a7ee35e654aad61cf2e5d [2]: https://github.com/odoo/odoo/commit/e9096a3844459b271cecbcc5e50df4a18c4c3d2a [3]: https://github.com/odoo/odoo/commit/f45a6ea38553566ff35cde3eceb2e4220075205d opw-3941516 (main one) Marked as similar: opw-3936669 opw-3939855 opw-3940168 opw-3940210 opw-3940218 opw-3940224 opw-3940407 opw-3940776 opw-3940845 opw-3940982 opw-3941047 opw-3941333 opw-3941377 opw-3941986 opw-3942480 opw-3944506 opw-3944641 opw-3944862 opw-3944893 opw-3945094 opw-3945589
This update fixes a bug where inventory routes were being duplicated unnecessarily in the manufacturing and purchasing workflows. The system now properly prevents route duplication by refining how routes are searched and created, ensuring cleaner data and more reliable inventory operations.
Original PR description
Few improvements for commit [1]: \- Before [1], `_find_global_route`, was not supposed to create any route. Let's keep it like that \- `_find_global_route` is sometimes calls with an empty `self` \- The name of the copied route should not contain "(Copy)" \- When looking for a route, we should skip the `active` criteria [1] https://github.com/odoo/odoo/commit/961ac2d70e897fb235d2d581db3a91b7c4163a41 OPW-3889889 OPW-3888885 Forward-Port-Of: odoo/odoo#165949 Forward-Port-Of: odoo/odoo#165728
This fix resolves a problem where WebSocket connections were hanging and becoming unresponsive when using Werkzeug version 2.3.x or newer. The issue occurred because Werkzeug was discarding socket data after sending responses, which prevented WebSocket frames from being processed. The fix ensures WebSocket connections remain active and responsive by using alternative data streams.
Original PR description
Since [1], Werkzeug discards any remaining data in the read socket after sending the response. In the case of WebSocket connections, the socket is not closed, and data keeps coming. As a result, WebSocket connections to the threaded server hang indefinitely in this discarding phase and never reach the processing phase. Thus, frames sent to the server are never processed. To solve this issue, rfile and wfile are replaced by dummy byte streams to ensure that our socket remains intact. [1]: https://github.com/pallets/werkzeug/commit/4f7048e7a31752142f18eefeccd49acc42a89e31 Forward-Port-Of: odoo/odoo#166231
Documentation and clarification updates
This update records that contributor tisho99 has signed Odoo's Contributor License Agreement (CLA). The CLA signature is a legal requirement that allows Odoo to use and distribute contributions from community members. This is a routine administrative update with no impact on product functionality.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165942