Tuesday, February 11, 2025
58 changes
Enhancements to existing features
The attendance kiosk screen no longer shows an unnecessary inner scrollbar. This makes the kiosk interface cleaner and easier for employees to use when checking in or out.
Original PR description
The innerscrollbar of the attendance kiosk is not needed. removed the scrollbar task-4456820
Resolved issues and error corrections
This fixes a timing issue that could prevent the link popover from opening correctly when users trigger it from Odoo's shortcut bar. The change makes the editor behavior more consistent and reduces small interruptions while editing content.
Original PR description
Fix a race condition between two different event that can affect the opening of the link popover when triggered via the odoo shortcut bar. backport of #197287 runbot-115558 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Before this commit here was a discrepancy between getting a report from the Web interface in debug=assets and in debug=0 In debug=assets, some parts of the report were invisible, namely the footer. Following efforts made by 7c4e591d58dd2b882f0c237d52490b2756c94203, this commit forces the PDF rendering in debug=0 mode Some behaviors are left mysterious though. The web.minimal_layout has a <base /> node to make sure every resources is fetched by wkhtml from that origin. It seems that wkhtml
Original PR description
Before this commit here was a discrepancy between getting a report from the Web interface in debug=assets and in debug=0 In debug=assets, some parts of the report were invisible, namely the footer.…
This fixes an unreliable automated test for restaurant preparation receipts by checking the receipt content directly instead of relying on a temporary print area. It helps reduce random test failures without changing point of sale behavior for users.
Original PR description
The `PreparationPrinterContent` test was checking if the preparation receipt was containing a specific string. But the check was performed on the `.render-container` which is generated for printing and erased just after. That was causing a random error in the test. Now we call internal `pos_store` method that generate the receipt content and we check if the string is present in the content. runbot error id: 114884
This fixes an intermittent issue in HTML editor tests where a link popover could steal focus at the wrong time on slower systems. The test now waits for the popover before refocusing the editor, making automated checks more stable without changing user-facing behavior.
Original PR description
Some tests end with the selection in a link, leading the link popover to open, which blurs the editable element. To prevent that, we would focus the editable by force, then wait a tick. But when the CPU is slow, sometimes the focus into the link popover happens too late to redirect it. This waits for the popover to open before focusing the editable. runbot-112609 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Long product packaging names now display more cleanly on sales-related reports instead of wrapping awkwardly into a narrow space. This makes printed or generated sales documents easier to read and more professional for customers and staff.
Original PR description
step to reporduce: 1. createdb with sale and inventory in 18.0 and activate product packaging 2. Create product or demo product can be used add the product packaging in inventory tab. 3. if packaging name is have more text then it description data will auto wrap in small portion which don't look good. before fix:  after fix:  upg-2452360 opw-4527424 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where non-admin users could see an error when opening Invoicing with only a branch company selected. Bank logo information can now be retrieved correctly in this setup, improving reliability for multi-company branch users.
Original PR description
**[FIX] account_online_synchronization: branch company failing to fetch bank's logos.** When a branch company is selected alone with a non admin user, the function `fetch_online_sync_favorite_institutions` fails due to an access error, when trying to access the original companies country code (which is not selected). To reproduce the issue: - Create a branch for a company with a bank journal that hasn't been set up. - Create new internal user with access to the new branch company as well as the parent (origin of the journal) - Login with the non admin user - Choose soley the newly created branch in company selector - Open invoicing opw-4524368
The Partner Ledger report no longer shows the Send button twice when using a duplicated child report. This prevents confusion for accounting users and keeps report actions clear and consistent.
Original PR description
### Steps to reproduce the issue: 1. Using debug mode, in _Accounting > Configuration > Management > Accounting Reports_, duplicate Partner Ledger 2. Set Partner Ledger as Root Report of the copy 3. In _Accounting > Reporting > Partner Reports > Partner Ledger_ use the copy report 4. The Send button is displayed twice ### Explanation: When using a child report, `_custom_options_initializer` will be called both for the report and its `root_report_id`. https://github.com/odoo/enterprise/blob/92a47d5fb28449c32b632446d983a42d3df77547/account_reports/models/account_report.py#L7174-L7177 The Partner Ledger override of this method includes the addition of a button, but we don't check its presence, and the method being called twice makes the button being added twice to the options object. ### Fix reasoning: Checking that a button sending to the same action is already in the options avoids multiple buttons with the same purpose from being added in the options. opw-4506968
Before this commit here was a discrepancy between getting a report from the Web interface in debug=assets and in debug=0 In debug=assets, some parts of the report were invisible, namely the footer. Following efforts made by 7c4e591d58dd2b882f0c237d52490b2756c94203, this commit forces the PDF rendering in debug=0 mode Some behaviors are left mysterious though. The web.minimal_layout has a <base /> node to make sure every resources is fetched by wkhtml from that origin. It seems that wkhtmltopdf actually makes a fetch request to that raw url with unspecified debug mode. The session being open, ir_qweb is in debug mode anyway, which makes that rpc rendering the main page in debug=assets. For some reason, probably time and memory, that call is responsible for hiding some parts of the report in PDF. 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#196138
Tremol USD device issues can be hard to investigate since we don't have access to all messages exchanged between the device and Odoo drivers. This PR adds logs for request and responses when the debug flag is enable on the proxy server installed on the user computer. opw-4453505 Forward-Port-Of: odoo/odoo#197218
Original PR description
Tremol USD device issues can be hard to investigate since we don't have access to all messages exchanged between the device and Odoo drivers. This PR adds logs for request and responses when the debug flag is enable on the proxy server installed on the user computer. opw-4453505 Forward-Port-Of: odoo/odoo#197218
hen email provider rewrites message_id of odoo generated emails we lose trace of original message and/or trace in Odoo. Crafting references as already containing the original message_id ensure to keep a trace even if message_id is rewritten. Continuation of https://github.com/odoo/odoo/pull/81901 but this time for mailing generated mail records. Task-3927616 Forward-Port-Of: odoo/odoo#196983 Forward-Port-Of: odoo/odoo#189195
Original PR description
hen email provider rewrites message_id of odoo generated emails we lose trace of original message and/or trace in Odoo. Crafting references as already containing the original message_id ensure to keep a trace even if message_id is rewritten. Continuation of https://github.com/odoo/odoo/pull/81901 but this time for mailing generated mail records. Task-3927616 Forward-Port-Of: odoo/odoo#196983 Forward-Port-Of: odoo/odoo#189195
…sively The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled. Instead, this commit introduces a new context key: 'no_exchange_difference_no_recursive'. task-id:
Original PR description
…sively The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled. Instead, this commit introduces a new context key: 'no_exchange_difference_no_recursive'. task-id: 4531511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196074 Forward-Port-Of: odoo/odoo#195814
Steps to reproduce : -open settings/technical/views -search "product.template.form.inherit" -select the view with external id "point_of_sale.product_template_form_inherit" -A Yellow Warning Message should appear indicating an Access Rights Inconsistency Problem: In the product_view.xml file of the point_of_sale module, in the view named product.template.form.inherit for the field "color", the invisible condition was invisible="true". This caused an accessed right inconsistency because
Original PR description
Steps to reproduce : -open settings/technical/views -search "product.template.form.inherit" -select the view with external id "point_of_sale.product_template_form_inherit" -A Yellow Warning Message should appear indicating an Access Rights Inconsistency Problem: In the product_view.xml file of the point_of_sale module, in the view named product.template.form.inherit for the field "color", the invisible condition was invisible="true". This caused an accessed right inconsistency because the python code did not recognize true as a Boolean but looked for a field named "true" in the product.template model and didn't find any. https://github.com/odoo/odoo/blob/abf0b5f102a0bad3ed0feb8b8e967f5e3c8d2288/addons/point_of_sale/views/product_view.xml#L69 opw-4520474 Forward-Port-Of: odoo/odoo#196807
When the vendor price is set in a different currency than main one in product's form, the PO triggered by the procurement is created in main currency. Steps to reproduce: - Activate foreign currency - Activate Route MTO - Have a product [PROD] configured with - [General Info tab] Product Type: Storable Product - [Purchase tab] Set a Vendor, a price, and foreign currency - [Inventory Tab] Routes Buy, MTO - Create a Sales Order with [PROD] and confirm it - Open the created Purchas
Original PR description
When the vendor price is set in a different currency than main one in product's form, the PO triggered by the procurement is created in main currency. Steps to reproduce: - Activate foreign currency - Activate Route MTO - Have a product [PROD] configured with - [General Info tab] Product Type: Storable Product - [Purchase tab] Set a Vendor, a price, and foreign currency - [Inventory Tab] Routes Buy, MTO - Create a Sales Order with [PROD] and confirm it - Open the created Purchase order Issue: currency is in company currency and not the currency set in the product configuration opw-4398597 Forward-Port-Of: odoo/odoo#193005
Steps to Reproduce: -> Drag and Drop the Facebook Snippet. -> Click on the snippet. -> Enter any random text. -> The snippet's content is editable. Solution: By adding the `o_not_editable` class to the Facebook Snippet, it prevent user's input from affecting the snippet. This PR ensures that the Facebook Snippet does not accept any user input. task-4517743 Forward-Port-Of: odoo/odoo#197195 Forward-Port-Of: odoo/odoo#195549
Original PR description
Steps to Reproduce: -> Drag and Drop the Facebook Snippet. -> Click on the snippet. -> Enter any random text. -> The snippet's content is editable. Solution: By adding the `o_not_editable` class to the Facebook Snippet, it prevent user's input from affecting the snippet. This PR ensures that the Facebook Snippet does not accept any user input. task-4517743 Forward-Port-Of: odoo/odoo#197195 Forward-Port-Of: odoo/odoo#195549
Currently, when closing the session, you would encounter an issue if the a refund payment was done using bank payment method and on the journal, the SEPA Credit Transfer is positionned first in the sequence. Steps to reproduce: ------------------- * Install `l10n_fr`, `point_of_sale`, and `account_sepa` * Switch to the `FR Company` * In the **Invoicing** app, select **Configuration** > **Journals** * Select the `Bank` journal * Set proper IBAN account * In **Outgoing Payments**, move `
Original PR description
Currently, when closing the session, you would encounter an issue if the a refund payment was done using bank payment method and on the journal, the SEPA Credit Transfer is positionned first in the…
Currently, when closing the session, you would encounter an issue if the a refund payment was done using bank payment method and on the journal, the SEPA Credit Transfer is positionned first in the sequence. Steps to reproduce: ------------------- * Install `l10n_fr`, `point_of_sale`, and `account_sepa` * Switch to the `FR Company` * In the **Invoicing** app, select **Configuration** > **Journals** * Select the `Bank` journal * Set proper IBAN account * In **Outgoing Payments**, move `SEPA Credit Transfer` to the top * In **Point of sale**, open pos shop * Select any product, change the price or qty to be negative (or make a refund for an order with no customer) * Select `Bank` payment method * Validate * Try closing session > Observation: Closing session error: An error has occurred when trying to close the sesion. You will be redirected to the back-end to manually close the session. * In the backend, try to close the session > Observation: To record payments with False, the recipient bank account must be manually validated. You should go on the partner bank account in order to validate it. Why the fix: ------------ The first payment_method_line will be used among the available payment method lines: https://github.com/odoo/odoo/blob/ae4c01ea7c9a5709a5f5ebcaded06fd91bdabae3/addons/account/models/account_payment.py#L461-L465 https://github.com/odoo/odoo/blob/ae4c01ea7c9a5709a5f5ebcaded06fd91bdabae3/addons/account/models/account_payment.py#L470-L475 In the context of the point of sale, using SEPA CT in the context of refunds does not make too much sense. Indeed, in the pos a refund can be done on an order which is not related to a client. By definition, when using SEPA your are supposed to know the client and it bank account number. We exclude the possibility of using SEPA CT when creating refund account payments coming from the Pos. opw-4310781 Forward-Port-Of: odoo/odoo#196292 Forward-Port-Of: odoo/odoo#195784
*: http_routing Since [1], the tel:// format was preferred over tel: due to reasons stated in [2]. However, the change in [2] was a workaround for a bug in the Python library used to parse URLs. According to the relevant RFC, the tel: protocol should not include double slashes. When clicking on a link like `tel://+112351221233` in a browser, a popup may appear attempting to handle the communication using `http://tel//+112351221233` as the browser does not recognize the tel protocol when do
Original PR description
*: http_routing Since [1], the tel:// format was preferred over tel: due to reasons stated in [2]. However, the change in [2] was a workaround for a bug in the Python library used to parse URLs.…
*: http_routing Since [1], the tel:// format was preferred over tel: due to reasons stated in [2]. However, the change in [2] was a workaround for a bug in the Python library used to parse URLs. According to the relevant RFC, the tel: protocol should not include double slashes. When clicking on a link like `tel://+112351221233` in a browser, a popup may appear attempting to handle the communication using `http://tel//+112351221233` as the browser does not recognize the tel protocol when double slashes are included.   This commit removes the unnecessary double slashes to comply with RFC recommendations [1]: https://github.com/odoo/odoo/commit/6d4a3b3ab5c0f3361d1d681d05b974e295dcbabe [2]: https://github.com/odoo/odoo/commit/56ce29e71f75a657d4b518d86c1d7084891e898e task-4331070 Forward-Port-Of: odoo/odoo#190860
__Current behavior before commit:__ If an unexpected error that has no body is thrown inside `printHtml`, the popup shows "undefinedDo you want to print using the web printer?" and nothing is written in the console, making it impossible to troubleshoot. __Description of the fix:__ Don't print "undefined" in the popup if the error has no body but write the error in the console. opw-4322339 Forward-Port-Of: odoo/odoo#197130 Forward-Port-Of: odoo/odoo#194985
Original PR description
__Current behavior before commit:__ If an unexpected error that has no body is thrown inside `printHtml`, the popup shows "undefinedDo you want to print using the web printer?" and nothing is written in the console, making it impossible to troubleshoot. __Description of the fix:__ Don't print "undefined" in the popup if the error has no body but write the error in the console. opw-4322339 Forward-Port-Of: odoo/odoo#197130 Forward-Port-Of: odoo/odoo#194985
## Description of the issue/feature this PR addresses Unable to reach Kiosk mode while in debug mode due to props validation ``` Error: Invalid props for component 'kioskAttendanceApp': unknown key 'token', unknown key 'companyId', unknown key 'companyName', unknown key 'employees', unknown key 'departments', unknown key 'kioskMode', unknown key 'barcodeSource' ``` ### Steps to reproduce - Install `hr_attendance` - Open Kiosk Mode - Enable debug mode => Blank screen ## Current b
Original PR description
## Description of the issue/feature this PR addresses Unable to reach Kiosk mode while in debug mode due to props validation ``` Error: Invalid props for component 'kioskAttendanceApp': unknown key…
## Description of the issue/feature this PR addresses Unable to reach Kiosk mode while in debug mode due to props validation ``` Error: Invalid props for component 'kioskAttendanceApp': unknown key 'token', unknown key 'companyId', unknown key 'companyName', unknown key 'employees', unknown key 'departments', unknown key 'kioskMode', unknown key 'barcodeSource' ``` ### Steps to reproduce - Install `hr_attendance` - Open Kiosk Mode - Enable debug mode => Blank screen ## Current behavior before PR Before this commit, when we were in debug mode, we couldn't access Kiosk mode (white screen with message in console). This was because the props were not fully declared, and, in debug mode, we validated the props here : https://github.com/odoo/odoo/blob/c3e7ee585a58fc07c11d07677d1d64dbd357d6b7/addons/web/static/lib/owl/owl.js#L5715-L5717 As the components are only used in one place each, I've updated the props declaration to match the usage. Forward-Port-Of: odoo/odoo#195831 Forward-Port-Of: odoo/odoo#189412
Those tests were too long and sometimes triggered a timeout when the runbot happened to be too slow. This commit separates each test into its own async function so that the timeout is applied on each test separately, thus significantly decreasing the likelihood of a timeout to occur in any of them. runbot-112694 runbot-112819 Forward-Port-Of: odoo/odoo#196986
Original PR description
Those tests were too long and sometimes triggered a timeout when the runbot happened to be too slow. This commit separates each test into its own async function so that the timeout is applied on each test separately, thus significantly decreasing the likelihood of a timeout to occur in any of them. runbot-112694 runbot-112819 Forward-Port-Of: odoo/odoo#196986
When creating a SOL on the fly from a project or a ticket, we try to match an existing product from what was typed in the field. However, we should be excluding recurring services Task-4354482 Forward-Port-Of: odoo/odoo#188309
Original PR description
When creating a SOL on the fly from a project or a ticket, we try to match an existing product from what was typed in the field. However, we should be excluding recurring services Task-4354482 Forward-Port-Of: odoo/odoo#188309
A sales team should be assigned only to sales type moves (invoices, credit notes, ...). Currently, it is possible that some Bills get a sales team assigned. This is not ok as it will distort the reports if users analyze by sales team. It occurs when `_compute_team_id` is called on a recordset containing sales moves and other moves. Even if sales moves are correctly filtered a `self.concat` is used to set the `team_id` and it will return the concatenation of `self` with the arguments, s
Original PR description
A sales team should be assigned only to sales type moves (invoices, credit notes, ...). Currently, it is possible that some Bills get a sales team assigned. This is not ok as it will distort the reports if users analyze by sales team. It occurs when `_compute_team_id` is called on a recordset containing sales moves and other moves. Even if sales moves are correctly filtered a `self.concat` is used to set the `team_id` and it will return the concatenation of `self` with the arguments, so also the non sales moves will have the team assigned opw-4422292 Forward-Port-Of: odoo/odoo#196332 Forward-Port-Of: odoo/odoo#195645
if they use import export or any automated action that write same journal then it's take new number. here assume that journal_id is only change on draft and if posted then it's raise error but not consider what is same journal_id come to write. 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#19
Original PR description
if they use import export or any automated action that write same journal then it's take new number. here assume that journal_id is only change on draft and if posted then it's raise error but not consider what is same journal_id come to write. 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#196777
GLN is the default that many people want to use, but that should not be the default for everybody. Instead use the real Peppol Endpoint when it's filled. We only take care of those that the schematron allows and where we know the correspondence. For the others and if the peppol fields are not filled, we still fallback on the VAT opw-4502607 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194551
Original PR description
GLN is the default that many people want to use, but that should not be the default for everybody. Instead use the real Peppol Endpoint when it's filled. We only take care of those that the schematron allows and where we know the correspondence. For the others and if the peppol fields are not filled, we still fallback on the VAT opw-4502607 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194551
Versions -------- - 16.0+ Steps ----- 1. Enable Stripe Express Checkout; 2. go to eCommerce as Public User; 3. pay via express checkout for a deliverable item; 4. in Stripe, set shipping address to somewhere in California; 5. finish payment. Issue ----- The new partner is created with its state set to Cadiz instead of California. Cause ----- When searching for a state using its code, it fetches the first matching item. The problem is that unlike country codes, state codes ar
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Enable Stripe Express Checkout; 2. go to eCommerce as Public User; 3. pay via express checkout for a deliverable item; 4. in Stripe, set shipping address to somewhere in California; 5. finish payment. Issue ----- The new partner is created with its state set to Cadiz instead of California. Cause ----- When searching for a state using its code, it fetches the first matching item. The problem is that unlike country codes, state codes aren't unique, e.g. there are 4 states that match the 'CA' code (only one of them being in the United States). Solution -------- Add `country_id` to the search domain to ensure the fetched state belongs to the relevant country. opw-4396024 Forward-Port-Of: odoo/odoo#197073 Forward-Port-Of: odoo/odoo#196428
before this commit, opening sessions menu raising a single ton error. * navigate to point of sale app * click on orders -> session * traceback is shown self.env['pos.payment']._read_group(self._get_captured_payments_domain(), ['session_id'], ['amount:sum']) File "/home/dev/Git/17.0/git/odoo/addons/point_of_sale/models/pos_session.py", line 1504, in _get_captured_payments_domain return [('session_id', '=', self.id), ('pos_order_id.state', 'in', ['paid', 'invoiced'])] File "/hom
Original PR description
before this commit, opening sessions menu raising a single ton error. * navigate to point of sale app * click on orders -> session * traceback is shown…
before this commit, opening sessions menu raising a single ton error.
* navigate to point of sale app
* click on orders -> session
* traceback is shown
self.env['pos.payment']._read_group(self._get_captured_payments_domain(), ['session_id'], ['amount:sum'])
File "/home/dev/Git/17.0/git/odoo/addons/point_of_sale/models/pos_session.py", line 1504, in _get_captured_payments_domain
return [('session_id', '=', self.id), ('pos_order_id.state', 'in', ['paid', 'invoiced'])]
File "/home/dev/Git/17.0/git/odoo/odoo/fields.py", line 5159, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: pos.session(1562, 1561, 1560, 1559, 1558, 1557, 1506, 1505, 1504, 1503, 1502, 1501, 1498, 1497, 1496,
introduced in: https://github.com/odoo/odoo/commit/0ee6d2881150c04631efc9f38f0e098b0a10dee9
after this commit, without any issues, the sessions
will opened.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#197138