Thursday, March 27, 2025
19 changes · 17.0
New functionality added to Odoo
Introduces a new script intended to support printing point-of-sale receipts and kitchen order tickets on thermal printers. The current change appears to provide a placeholder structure, so business value depends on completing the actual printer integration logic.
Original PR description
In this script:ThermalPrinter class contains methods for printing POS receipts (print_pos_receipt) and KOTs (print_kot).Inside each method, you would include the actual code to format and send the print commands to the thermal printer using the xthermal driver. This may involve using libraries like escpos for generating ESC/POS commands.The if __name__ == "__main__": block demonstrates how you can use the ThermalPrinter class by creating an instance and calling its methods with sample data.Replace the placeholder code with actual logic to communicate with the xthermal driver and send print commands to your thermal printer.
Enhancements to existing features
The project README was refreshed to better follow markdown standards and make contribution information clearer. It also adds guidance for reporting security concerns, helping users and contributors find the right process more easily.
Original PR description
* follow markdown guidelines * add section for security reports --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix makes the automated sales product catalog walkthrough more precise so it is not disrupted by extra custom fields or interface changes. It also adds a dedicated customer record for the test, reducing inconsistent results when demo data is not available.
Original PR description
The tour was being broken by customizations adding elements to the Sale view. The trigger targets were too loose, they have to be more specific. Also added a new `res.partner` as one is required to open the product catalog. While there exists partners by default (eg admin), these seemed to lead to inconsistent behaviour without demo data. Follow-up of #197620
Miscellaneous changes
Steps to reproduce: - go to a blog post with several paragraph - edit translations Issue 1: - select several paragraph completely and use the translate tool - insert the translation => the translation are not inserted Issue 2: - select 3 paragraphs but don't start at the beginning or end of the text - insert translation - see that all translations is inserted at end of paragraph 1, paragraph 2 is emptied and paragraph 3 selected part is removed - save => paragraph 1 and 2 a
Original PR description
Steps to reproduce: - go to a blog post with several paragraph - edit translations Issue 1: - select several paragraph completely and use the translate tool - insert the translation => the…
Stripe checkout in Odoo no longer offers UPI because this payment method is not supported by the current integration. This prevents customers from selecting an option that would fail with a payment form error during checkout.
Original PR description
Steps to reproduce: - Configure stripe and enable UPI payment method. - In e-commerce, add a product to the cart. - Go to checkout and select UPI. Issue: On selecting UPI, we get `Cannot display the payment form` error. Cause: Our current integration with Stripe does not support UPI as a payment method. Our setup only supports payment methods activated in the Stripe account, and UPI is not listed there. As a result, the Stripe API does not recognize the `upi` code and throws an error. Fix: Remove the support for UPI as a payment method from the stripe. opw-4014898
Excel exports for account reports now avoid duplicate worksheet names when composite reports include sections with very similar long titles. This prevents export errors and makes downloaded financial reports more reliable for users.
Original PR description
This commit ensures that sheet names in exported excel files are unique. The names may not be unique in case a composite report contains multiple section reports all having the same very long prefix. An example to that could be found in l10n_fr_reports: 1) IMB - Intermediate management balances 2) IMB - Intermediate management balances (2024) task-4678129
Updates internal tests for Mexican reporting and closing reports after related account changes in the community edition. This helps ensure the Mexican localization remains reliable and aligned with the latest accounting setup, with no expected direct impact for end users.
Original PR description
#Description A total of 6 test were broken after changes(add/removal) in the accounts of the mexican localization in odoo community, the new expected values for the assesments were updated. Related PR #196852.
The subscription dashboard has been updated to show the intended sales subscription figures. This helps business users rely on the dashboard for more accurate subscription tracking and reporting.
Steps to reproduce: - go to a blog post with several paragraph - edit translations Issue 1: - select several paragraph completely and use the translate tool - insert the translation => the translation are not inserted Issue 2: - select 3 paragraphs but don't start at the beginning or end of the text - insert translation - see that all translations is inserted at end of paragraph 1, paragraph 2 is emptied and paragraph 3 selected part is removed - save => paragraph 1 and 2 are deleted (so we show original lang value), selected part of paragraph 3 is removed Why: In the blog post content, we are inside a "blog.post().content" editable field, this allows the editor to select several translations nodes which will work wrongly with the editor because translation mode only expect to change the content of translation nodes. The first paragraph translation is saved empty because the editor is cloning the node with the same "data-oe-translation-source-sha" because we are inserting several paragraphs inside it. Fix: in translation mode, make the editable node of html fields around translation nodes uneditable so we can't select several translation nodes thanks to how browser handle selection and content editable. Note: the added test step is very light, because in javascript it is programmatically possible to select 2 separate content editable. At the step that is added in the tour, with the fix it is not possible to select both the H1 and P nodes. opw-4221993 opw-4482717 pr note: opw-4221993 could possibly solved by this fix too (the video reproduction seemed to be about a bulleted list but I could not reproduce, and the original report video is deleted) Forward-Port-Of: odoo/odoo#197511
When viewing sale report for POS orders, the gross weight number will be off by a factor of how much larger/smaller the UOM ratio is compared to the base. For example, if we sell 1 qty of product with a weight of 25kg and a UOM of 25kg (25 * 1kg), the gross weight field will be 1 * 25kg * 25kg or 625kg instead of the expected 1 * 25kg or 25kg. This fix removes the UOM factor from being taken into account when calculating gross weight for POS orders. This is a valid solution because if we
Original PR description
When viewing sale report for POS orders, the gross weight number will be off by a factor of how much larger/smaller the UOM ratio is compared to the base. For example, if we sell 1 qty of product…
When viewing sale report for POS orders, the gross weight number will be off by a factor of how much larger/smaller the UOM ratio is compared to the base. For example, if we sell 1 qty of product with a weight of 25kg and a UOM of 25kg (25 * 1kg), the gross weight field will be 1 * 25kg * 25kg or 625kg instead of the expected 1 * 25kg or 25kg. This fix removes the UOM factor from being taken into account when calculating gross weight for POS orders. This is a valid solution because if we treat 'SUM(p.weight * l.product_uom_qty / u.factor * u2.factor)' as the ground truth from sale report for sale orders, the '/ u.factor * u2.factor' portion of the calculation will cancel out to 1 for POS orders. This is because the only time 'u2.factor/u.factor' is not 1 for sale orders is when the product template's UOM factor is different from the sale order line's UOM factor. Since we can not change the UOM of pos order lines, the pos order line's factor will always be the same as the product template's therefore 'u2.factor / u.factor' for pos orders will always be 1 and can be ignored. To reproduce error on blank DB: 1) For a product, change its UOM to a UOM with a ratio not equal to 1 2) For the same product, change its weight in the inventory tab to a number not equal to 0 3) In POS make a sale with this product and confirm the order 4) Check the gross weight of the product just sold through POS by going to sales->reporting->list view and adding gross weight to the view through studio opw-4452892 Forward-Port-Of: odoo/odoo#203144
Currently when the user upload an e-invoice in compatible format, accounting information will be extracted to automatically create the bill and associated records. While creating the parnter, however, only basic information is filled in (name, vat, email, phone, country), leaving out the address Steps to reproduce: - Import an xml bill with complete partner info Issue: Only some partner fields are imported opw-4488308 Forward-Port-Of: odoo/odoo#201760
Original PR description
Currently when the user upload an e-invoice in compatible format, accounting information will be extracted to automatically create the bill and associated records. While creating the parnter, however, only basic information is filled in (name, vat, email, phone, country), leaving out the address Steps to reproduce: - Import an xml bill with complete partner info Issue: Only some partner fields are imported opw-4488308 Forward-Port-Of: odoo/odoo#201760
**Current behavior before PR:** - Rotating a cropped image reset the cropper to cover the entire image. - When saving the record, all attributes not in the safe_attrs list were sanitized. As a result, if the record contained a cropped image, its crop-related attributes were also sanitized. Consequently, when the cropper was reopened, the container displayed the entire image instead of the cropped version. **Desired behavior after PR is merged:** - The cropper now retains
Original PR description
**Current behavior before PR:** - Rotating a cropped image reset the cropper to cover the entire image. - When saving the record, all attributes not in the safe_attrs list were sanitized. As a result, if the record contained a cropped image, its crop-related attributes were also sanitized. Consequently, when the cropper was reopened, the container displayed the entire image instead of the cropped version. **Desired behavior after PR is merged:** - The cropper now retains its size when rotating a cropped image, maintaining the original crop area. - Image attributes such as data-width, data-height, data-scale-x, data-scale-y, data-x, and data-y are no longer sanitized during the save process. This ensures that when the cropper is reopened for a cropped image, the container correctly displays only the cropped portion of the image, rather than the entire image. task-4290693 Forward-Port-Of: odoo/odoo#186864
- have a follower with a portal partner linked to a specific company "portal" user is important here because internal users don't have multi-company rule. - view the chatter with a user which has no access to that company - the chatter is currently locked by an ACL error The follower should be displayed instead. task-4648765 Forward-Port-Of: odoo/odoo#201864
Original PR description
- have a follower with a portal partner linked to a specific company "portal" user is important here because internal users don't have multi-company rule. - view the chatter with a user which has no access to that company - the chatter is currently locked by an ACL error The follower should be displayed instead. task-4648765 Forward-Port-Of: odoo/odoo#201864
These commits fix two issues: - If a block that has an image selected as background is given a border, its background image will fit awkwardly in the surrounding border, and similarly if the background image is positioned all the way to any edge, it does not cover all the block. - If a video is selected as background for a block, the video does not always fill the block. Steps to reproduce: Bug 1 - Add a masonry block/big boxes block - Add a background image to an element o
Original PR description
These commits fix two issues: - If a block that has an image selected as background is given a border, its background image will fit awkwardly in the surrounding border, and similarly if the…
These commits fix two issues: - If a block that has an image selected as background is given a border, its background image will fit awkwardly in the surrounding border, and similarly if the background image is positioned all the way to any edge, it does not cover all the block. - If a video is selected as background for a block, the video does not always fill the block. Steps to reproduce: Bug 1 - Add a masonry block/big boxes block - Add a background image to an element of the masonry/big boxes - Add a big border - Make the border translucent if it isn't already to better see the bug => The background image overflows on the border randomly - Change the background position by shifting the image all the way to the left => The image does not cover all the border-box Bug 2 - Add a masonry block/big boxes block - Add a video background => The video does not always fill the box, especially when the window gets resized After the changes the image/video background completely covers its block, even when resized or when a border is applied. task-4174638 Forward-Port-Of: odoo/odoo#201200
Steps to reproduce: - Access with the demo user - Open Timesheet dashboard - Switch to list view Issue: Access error will raise Since commit https://github.com/odoo/odoo/commit/0258a627addf678d2c9b66bd8ee6752905fbac8f Readonly account users have now read access to analytic account lines. However, when sale_timesheet is installed, in the lowest access right it is possible to see only the own timesheets, so the rule needed to be limited as it occurs with Billing users. Forward-
Original PR description
Steps to reproduce: - Access with the demo user - Open Timesheet dashboard - Switch to list view Issue: Access error will raise Since commit https://github.com/odoo/odoo/commit/0258a627addf678d2c9b66bd8ee6752905fbac8f Readonly account users have now read access to analytic account lines. However, when sale_timesheet is installed, in the lowest access right it is possible to see only the own timesheets, so the rule needed to be limited as it occurs with Billing users. Forward-Port-Of: odoo/odoo#203460
An incorrect date being represented (14/11/2007 is displayed as 20/07/1114) on the payment field. The date was parsed two times with the format of the user's language, while the first parse should be based on the current format of the database. To reproduce: - Change user language to Spanish or French. - Register a payment for an invoice with a payment date between October 1st and December 31st, from 2001 to 2012. - "Paid on 20/07/1114" appears. Ticket [link](https://www.odoo.com/odoo/
Original PR description
An incorrect date being represented (14/11/2007 is displayed as 20/07/1114) on the payment field. The date was parsed two times with the format of the user's language, while the first parse should be based on the current format of the database. To reproduce: - Change user language to Spanish or French. - Register a payment for an invoice with a payment date between October 1st and December 31st, from 2001 to 2012. - "Paid on 20/07/1114" appears. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4486653) opw-4486653 Forward-Port-Of: odoo/odoo#202258
…stribution" is ambiguous Steps to reproduce: - projects App - project update for a project having "invoices count" stat btn => psycopg2.errors.AmbiguousColumn: column reference "analytic_distribution" is ambiguous Source: - analytic_distribution exists in more than one table Fix: - table alias added task-4637044 Forward-Port-Of: odoo/odoo#201332
Original PR description
…stribution" is ambiguous Steps to reproduce: - projects App - project update for a project having "invoices count" stat btn => psycopg2.errors.AmbiguousColumn: column reference "analytic_distribution" is ambiguous Source: - analytic_distribution exists in more than one table Fix: - table alias added task-4637044 Forward-Port-Of: odoo/odoo#201332
Before this change, if a jsonrpc handler was successful but returned the value `None` the dispatcher would return a response object containing just the `jsonrpc` and `id` keys. This is an invalid response according to [JSON-RPC 2.0 Specification section 5 "Response Object"][jsonrpc-response]: > Either the result member or error member MUST be included [...] [jsonrpc-response]: https://www.jsonrpc.org/specification#response_object Forward-Port-Of: odoo/odoo#203270
Original PR description
Before this change, if a jsonrpc handler was successful but returned the value `None` the dispatcher would return a response object containing just the `jsonrpc` and `id` keys. This is an invalid response according to [JSON-RPC 2.0 Specification section 5 "Response Object"][jsonrpc-response]: > Either the result member or error member MUST be included [...] [jsonrpc-response]: https://www.jsonrpc.org/specification#response_object Forward-Port-Of: odoo/odoo#203270
### Steps to reproduce: - Accounting > Dashboard > Bank > Import Statement - Select a QIF file with a transaction having a total of 0 - Traceback ### Cause: The QIF file parser (`_parse_bank_statement_file`) does not return `unique_import_id` for transactions. In [`_create_bank_statements`](https://github.com/odoo/enterprise/blob/316b7bdc7781d5d72d91430f74de35fdafb0bf84/account_bank_statement_import/models/account_journal.py#L261-L269) when the amount is 0, the code tries to read `line_va
Original PR description
### Steps to reproduce: - Accounting > Dashboard > Bank > Import Statement - Select a QIF file with a transaction having a total of 0 - Traceback ### Cause: The QIF file parser (`_parse_bank_statement_file`) does not return `unique_import_id` for transactions. In [`_create_bank_statements`](https://github.com/odoo/enterprise/blob/316b7bdc7781d5d72d91430f74de35fdafb0bf84/account_bank_statement_import/models/account_journal.py#L261-L269) when the amount is 0, the code tries to read `line_vals['unique_import_id']` so an error is raised. ### Solution: The read is done to store the skipped lines in `ignored_statement_lines_import_ids`. This variable is then only used to get the number of skipped lines. https://github.com/odoo/enterprise/blob/316b7bdc7781d5d72d91430f74de35fdafb0bf84/account_bank_statement_import/models/account_journal.py#L291 The fix is to increment a counter instead of storing the lines. opw-4656142 Forward-Port-Of: odoo/enterprise#81944
… is ambiguous Steps to reproduce: - projects App - project update for a project having "invoices count" stat btn => psycopg2.errors.AmbiguousColumn: column reference "analytic_distribution" is ambiguous Source: - analytic_distribution exists in more than one table Fix: - table alias added task-4637044 Forward-Port-Of: odoo/enterprise#81220
Original PR description
… is ambiguous Steps to reproduce: - projects App - project update for a project having "invoices count" stat btn => psycopg2.errors.AmbiguousColumn: column reference "analytic_distribution" is ambiguous Source: - analytic_distribution exists in more than one table Fix: - table alias added task-4637044 Forward-Port-Of: odoo/enterprise#81220