Thursday, January 23, 2025
23 changes · 18.0
New functionality added to Odoo
Odoo spreadsheets can now calculate residual account amounts and partner balances directly with new formulas. This helps finance users analyze receivables, payables, and partner activity over selected periods without leaving the spreadsheet.
Original PR description
Problem --------- There is currently no formula to get the residual amount of accounts nor to get the balance of a partner in a given period of time in spreadsheets. Objective --------- Add the…
Problem --------- There is currently no formula to get the residual amount of accounts nor to get the balance of a partner in a given period of time in spreadsheets. Objective --------- Add the formula ODOO.RESIDUAL and ODOO.PARTNER.BALANCE that do just that ODOO.RESIDUAL should take the following parameters: - account_codes (mandatory)(can be more than one separate by ,): could be optional, in that case it could set the domain to all receivables/payables accounts - due_date_range or expected_date (optional): date range referred to due dates (not AML date) - offset (optional): adding the possibility of the offset to be not only “Year” but also, a specific date or other periods like Month, Quarter. - company_id (optional) - include_unposted (optional) (default: false) ODOO.PARTNER.BALANCE should take the following paramters: - partner_ids (mandatory) (can be more than one separate by ,) - accound_codes (optional) (the prefix of the account(s)) - date_range (optional) (21/12/2022,Q1 2022, 12/2022, 2022) - offset (optional) (default: 0) - company_id (optional) - include_unposted (optional) (default: false) Solution --------- 1. Define the spreadsheet function with the correct parameters in `accounting_function.js` 2. Hook it to the data source so that it can perform server calls 3. Craft that server python function to returns the list a residual amounts for the given list of parameters. 4. Adds some tests. Task-3679808 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A new customer statement report variant is available in accounting, making it easier to review a customer's outstanding balances and account activity. This helps finance teams share clearer account status information with customers and follow up on payments more efficiently.
Original PR description
task-4328333
Enhancements to existing features
The signing document viewer has been visually improved to reduce overlapping controls and make the signing flow easier to use. The side panel now appears on the right and selects the first option by default, helping users preview and complete documents more smoothly.
Original PR description
**Purpose ========** This PR handles overriding the default PDF.js viewer styling to enhance the user experience while signing documents. Specifically, it addresses the issue where overlapping…
**Purpose ========** This PR handles overriding the default PDF.js viewer styling to enhance the user experience while signing documents. Specifically, it addresses the issue where overlapping elements, such as the "Click to Start" prompt and the sign panel, create a visually unappealing interface. **Specification =========** 1. Moves the side panel to the right side of the viewer for improved accessibility. 2. Ensures the first option in the side panel is selected by default, simplifying the document preview process (refer to: https://link.excalidraw.com/l/65VNwvy7c4X/o1Mtd7yyXD). **Screenshots =========** #### Before:  #### After:  __________________________________________________________________________________________________________ I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) task-id: 4369079
Resolved issues and error corrections
Discount codes now calculate against the full tax-included price when products are priced with tax included. This prevents discounts from being limited to only the untaxed portion, so customers receive the intended discount amount.
Original PR description
If user had set to have tax included in their price and tried to apply discount code only the untaxed amount could be discounted even if discount code was higher than untaxed amount. opw-4486030 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
Check printouts now include the related bill information even when no accounting entry is created for the check payment. This helps users send complete checks in configurations where the check payment method has no outstanding payment account.
Original PR description
**Steps to reproduce:** - Install Accounting - Configure a Check Layout in Accounting settings - Go to Bank journal configuration - Make sure that "Checks" payment mehtod doesn't have an Outstanding Payment account - Create a bill - Register a Check payment for the bill - Print the check **Issue:** All the data about the bill are missing from the check. **Cause:** These data were retrieved from the journal entry linked to the check payment. As there is no journal entry in this case, they cannot be computed. **Solution:** Compute these data from the amount of the check and the linked bills. opw-4482589 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Combo product options now correctly show only choices customers can configure, while required single-choice options are preselected automatically. This helps prevent confusing product setup flows and reduces incorrect combo orders in Sales and eCommerce.
Original PR description
The combo configurator works with `product.product` records, so previously, we only allowed to configure `no_variant` PTALs. However, we should also allow to configure the `product.product`'s custom PTAVs (which can be `always` or `dynamic`). Moreover, we always allowed to configure `no_variant` PTALs, even if they weren't configurable (i.e. PTALs with a single, non-custom, non-multicheckbox PTAV). However, such PTAVs should be preselected and non-configurable in the combo configurator.
Sales orders can now accept discount coupons even when the Delivery module is not installed. This prevents an unexpected error during coupon application, making sales discount workflows more reliable for users.
Original PR description
Steps to reproduce: - Create SO and add a product. - Apply discount coupon to SO. Issue: - Traceback occurs when the delivery module is not installed. Cause: - The line.is_delivery attribute is not accessible when the delivery module is not installed, leading to an error. Fix: - Use the line._is_delivery() method to correctly check for delivery lines. opw-4509360 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix keeps lot-specific standard prices aligned when stock valuation entries are replenished. It prevents valuation discrepancies when lot-valued inventory is later reduced to zero, improving the accuracy of stock accounting.
Original PR description
## How to reproduce: - Create product P, tracked by lot, cost_method = 'standard', standard_price = 1 - Create quant with lot L1, 10 units on hand - Set L1 standard_price = 2 - Set lot_valuated to True => lot value_svl is $10 for 10 units (product.standard_price * quantity) - Set L1 quantity to 0 => lot value_svl is $-10 for 0 units ## Issue When the svl is replenished for the lot, the product.standard_price is used. However, the lot.standard_price is not updated; hence, when the stock is emptied, and the lot.standard_price is used, a discrepancy is created. ## Solution When the svl is replenished, we u se the product.standard_price and update the lot.standard_price --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Cancelled point of sale orders now remove related order lines cleanly, preventing leftover data from interfering with syncing new orders. This helps reduce synchronization errors and keeps checkout operations more reliable.
Original PR description
Before this commit, cancelling an order would result in keeping the removed orderlines in the unlink command, causing issues in different cases when trying to sync a new order. opw-4403100 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures the “Existing Third Party Checks” outgoing payment method is only added to the appropriate Argentine check journals, instead of all Argentine cash journals. It also lets users add the method back if it was accidentally removed from the Third Party Checks journal.
Original PR description
**Description of the issue/feature this PR addresses**: 1) It is necessay not to set "Existing Third Party Checks" outgoing payment method in all argentinean cash journals. It is only needed to be…
**Description of the issue/feature this PR addresses**: 1) It is necessay not to set "Existing Third Party Checks" outgoing payment method in all argentinean cash journals. It is only needed to be set on "Third Party Checks" and "Rejected Third Party Checks" Argentinean journals that are created when the module is installed or a new argentinean company is created. 2) Also when a user mistakenly remove the 'Existing Third Party Checks' payment method from the 'Third Party Checks' journal then is not able to add it back. This bug was introduced on this commit https://github.com/odoo/odoo/pull/188451/commits/0618fff9f9bb4716d22dc2ce8950cada824b90f4. **Current behavior before PR**: 1) "Existing Third Party Checks" outgoing payment method is set in all argentinean cash journals. 2) When a user mistakenly remove the 'Existing Third Party Checks' payment method from the 'Third Party Checks' journal then is not able to add it back. **Desired behavior after PR is merged**: 1) "Existing Third Party Checks" outgoing payment method is set only in "Third Party Checks" and "Rejected Third Party Checks" argentinean journals. 2) When a user mistakenly remove the 'Existing Third Party Checks' payment method from the 'Third Party Checks' journal then is able to add it back. _Ticket Adhoc side_: 83443 _Task Latam side_: 1309 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Flexible schedule reporting now correctly uses the planned daily hours even when an employee works less than expected. This prevents expected hours from being shown as equal to worked hours and improves overtime and attendance reporting accuracy.
Original PR description
Steps to reproduce: 1. Set a flexible working schedule with 40h / week and 8h / day for an employee 2. Record an attendance for the employee 3. Go to reporting, the expected hours is the same as the worked hours Expected behavior: The expected hours should be what was set in the schedule, which is 8 hours Explanation: The calculation of expected hours is based on the difference between overtime hours and worked hours. This is done to ensure the overtimes are always computed correctly. However if the overtime duration is negative, it is not taken into account in `_update_overtime`. This commit allows negative amounts for overtime hours. opw-4388707 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix improves how sales quote PDFs handle right-to-left languages such as Arabic or Hebrew. Businesses using these languages should see more readable, correctly presented quote documents for customers.
Original PR description
opw-4289424 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
Point of Sale now correctly considers available lot quantities when users select tracked products. This helps prevent staff from choosing unavailable or incorrect lots, improving checkout accuracy and inventory reliability.
Original PR description
Lots selection in POS was not working properly. It was not takin into account lot quantity when selecting it.
Fixes an issue where repeated email cleanup could incorrectly treat the whole message as a hidden quote or signature. This helps users see the actual message content reliably while still hiding genuine signatures and quoted sections as intended.
Original PR description
Since html_normalize is now run multiple times on the same body in mail it has become apparent that the heuristics for tag_quote are not suited to multiple passes on the same body. tag_quote is used…
Since html_normalize is now run multiple times on the same body in mail it has become apparent that the heuristics for tag_quote are not suited to multiple passes on the same body. tag_quote is used to detect and tag nodes in a document that are likely mail signatures. So that they may be hidden in the front-end. The detection of the signature using the "-- <br>" sets the parent of the element where is is detected to be a "quote container". However a quote container will set all of its children to be quotes too. If the signature is in the main div of the email, as is the case in most templates this means the whole content is marked as being inside a "quote container". Because the processing of the elements is done in order of their appearance in the document, this does not lead to the entire document becoming a quote the first time html_normalize is called. As the signature is typically the last element, the "container" attribute is only set after the whole body was already processed. However if the body is normalized again, the main div is now marked as a "quote container" and the whole body becomes a quote. - `<div><p>body</p><div>--<br>John</div></div>` - `<div quote-container><p>body</p><div quote>--<br quote>John</div></div>` - `<div quote-container><p quote>body</p><div quote>--<br quote>John</div></div>` We now check whether a quoted sibling exists in the container before marking a node as "quote". All nodes following the original quote and their children will be quoted as before, all nodes before will not be quoted anymore. triggered by https://github.com/odoo-dev/odoo/commit/24731938f75358fd3c72b91465b72ab80d62d208 task-4381505
The point of sale now gives offline restaurant orders a default receipt print count when they sync back online. This prevents a system error when closing the register after printing full receipts during an internet outage, improving reliability for restaurant staff.
Original PR description
Currently, an exception is generated in the log when the users create a POS order as follows: - Install ``pos_restaurant`` module. - Open the register for the restaurant. - Stay connected to Wi-Fi…
Currently, an exception is generated in the log when the users create a POS order as follows: - Install ``pos_restaurant`` module. - Open the register for the restaurant. - Stay connected to Wi-Fi but disconnect from the internet (Inspect > Network > Go Offline). connection (Inspect > Network > Go offline) - Make two or more orders in offline mode and use ``Print Full Receipt``. - Reconnect to the internet, make one order, and ``Print Full Receipt``. - Close the register (Traceback appears in the terminal). ``error: `invalid literal for int() with base 10: 'null'`` Before commit : --- - ``nb_print`` is initialized in Python with fields.Integer(default=0) - When syncing data between the server and the client, nb_print is being sent as ``null`` instead of an integer. - The Python side is trying to convert ``null`` into an integer, which causes the error. After commit : --- - Added ``this.nb_print = vals.nb_print || 0;`` in ``pos_order.js`` to ensure it initializes to 0 for offline orders, aligning with the server-side default. sentry-6055024846 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a payment issue where Worldline transactions could fail if the server used certain regional language settings. The request date is now formatted consistently, helping businesses avoid failed payments caused by server locale configuration.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Set locale variable `LC_TIME` to `be_FR.UTF-8` via command line; 2. do the same for `LC_ALL`; 3. start Odoo server; 4. attempt to make a payment via Worldline. Example updating locale for a single shell session: ```bash $ export LC_TIME=be_FR.UTF-8 $ export LC_ALL=$LC_TIME $ ./odoo-bin ``` Issue ----- Invalid API request: ACCESS_TO_MERCHANT_NOT_ALLOWED Cause ----- The date string sent to the Worldline API is formatted via the `datetime.strftime` method to be RFC 1123 compliant. The issue is that the result of this method is locale-dependent. If it's not set to `en_US.UTF-8`, it no longer adheres to the format expected by Worldline. Solution -------- Use the `format_date_time` method from the Python's standard `wsgiref` library. This method will always return a RFC 1123 compliant date string, regardless of locale setting. opw-4472440
Fixes an issue where the scheduled mail process could fail when more than 50 messages were waiting to be sent. This helps ensure queued customer or internal messages continue processing without manual intervention.
Original PR description
Before this commit, `mail.ir_cron_post_scheduled_message` fails with a traceback when there are a lot of scheduled messages to be sent. Steps to reproduce ----- 1. Create a scheduled message from the chatter full composer 2. Duplicate it 50+ times 3. Run the scheduled action "Mail: Post scheduled messages" 4. Traceback occurs ``` File "/home/odoo/src/odoo/odoo/api.py", line 553, in __new__ assert isinstance(cr, BaseCursor) ^^^^^^^^^^^^^^^^^^^^^^^^^^ AssertionError ``` Cause ----- This commit (df18d5257cef737f3e1d245a8b85769e1fe1a032) introduced this cron which posts past-due scheduled messages with a default `limit=50`. If there are more messages than the limit, the cron is triggered again. However, there is a typo when restarting the cron that incorrectly calls `env`. Solution ----- Change the line to use `env.ref()` to correctly access the xml_id and restart the cron. opw-4474171
The Documents list view now opens the discussion panel for the correct folder or selected document. It also shows the proper parent folder name in the inspector instead of displaying “Unnamed,” making document navigation clearer for users.
Original PR description
Bug 1 ===== The chatter in the list view never open on the current folder / selected document. Bug 2 ===== If we are in the list view, and we are inside a folder, when selecting a document, it will show "Unnamed" for the folder. The reason is that with `column_invisible=1`, the display name is not loaded. To solve that, we can put the field in `optional="hide"`. Task-4461038
GSTR-1 error activities are now assigned more reliably to the right responsible user, and the needed activity type is created automatically if missing. This helps Indian GST reporting teams track and resolve filing issues with fewer assignment gaps or execution errors.
Original PR description
In this PR: - Introduced a new method `_get_gstr_responsible_activity_and_user` to dynamically retrieve or create the GSTR-1 exception mail activity type and determine the responsible user for…
In this PR: - Introduced a new method `_get_gstr_responsible_activity_and_user` to dynamically retrieve or create the GSTR-1 exception mail activity type and determine the responsible user for handling GSTR-1 errors. - Ensured that the activity type is created on-the-fly if it does not exist, avoiding potential errors during execution. - Updated `check_gstr1_status` to utilize the new method for assigning the responsible user and activity type when scheduling activities for invoices with GSTR-1 errors. - Improved logic to determine the responsible user: - Default to the activity type's `default_user_id` if they belong to the appropriate group and company. - Fallback to the last relevant `mail.message` for identifying a responsible user. - Enhanced activity scheduling to use the identified activity type and responsible user, improving traceability and accountability. This change improves error handling in the GSTR-1 process and ensures better alignment with user responsibilities.
Fixed an issue where timesheet hours on subscription sales orders were not reflected in the delivered quantity after the first recurring invoice was generated. This helps sales and billing teams see accurate delivered quantities and invoice customers correctly.
Original PR description
The issue: The delivered qty is not reflected on the order line after creating the first recurring invoice by the cron job. Steps to reproduce: 1. Create a product with the following configuration:…
The issue: The delivered qty is not reflected on the order line after creating the first recurring invoice by the cron job. Steps to reproduce: 1. Create a product with the following configuration: Product Type: Service Create on Order: Nothing Invoicing Policy: Based on Timesheets Product Category: Sellable and Subscription Product 2. Set up a recurring subscription plan for the product 3. Create a Sales Order (SO) for the product and confirm it 4. Add hours to a task linked to the SO 5. From Settings > Technical > Automation > Scheduled Actions, manually trigger the cron job "Sale Subscription: generate recurring invoices and payments" to update the `next_invoice_date`. Observed behavior: On the SO page, the smart button of the tasks reflects the hours added correctly. However, the delivered quantity field in the SO line does not update based on the added hours. The reason: The delivered quantity for timesheet based services is computed taking into account the current period [1], however, `next_invoice_date` was not added as a dependency to the compute method of `qty_delivered`, causing this latter to have a stale value when `next_invoice_date` gets updated when creating the first recurring invoice by `_create_recurring_invoice` [2]. The fix: Added `next_invoice_date` as a dependency for the compute function of `qty_deliverd`. [1]: https://github.com/odoo/enterprise/blob/e990d101cce90311f3e2c5d9be4d480b329f9f2a/sale_subscription_timesheet/models/sale_order_line.py#L39 [2]: https://github.com/odoo/enterprise/blob/07f01f39cb46f1763637b50e628dfb613b0d2266/sale_subscription/models/sale_order.py#L1168 opw-4378914 opw-4426787 opw-4463512
Corrects a rounding problem in Mexican electronic invoicing when invoice lines use even-numbered amounts with a 50% discount. This helps ensure generated tax documents match required totals and reduces the risk of invoice validation errors.
Original PR description
See the test in this commit.
This change prevents users from deleting document folders that are reserved for company processes, even when those folders belong to another company they cannot normally access. It also fixes cases where users were incorrectly blocked from moving or deleting their own documents when project folder permissions were restricted.
Original PR description
[FIX] documents, documents_hr: fix company folder protection How to reproduce: - install documents_hr - In Document, create a folder prjComp2 in /Marketing/Brand 2 - create a second company:…
[FIX] documents, documents_hr: fix company folder protection How to reproduce: - install documents_hr - In Document, create a folder prjComp2 in /Marketing/Brand 2 - create a second company: SecondCompany - Select SecondCompany - Activate centralization of document for HR and select prjComp2 folder - Log as Marc Demo and delete the folder Brand 2 (Move to Trash + delete) There is no error while this folder should have been protected by the method _raise_if_used_folder called when archiving or deleting a folder. The cause is that Marc user doesn't have access to SecondCompany and as the check is not done in sudo in _raise_if_used_folder, the folder is not identified as a folder to be protected. We solve the issue by running the check in sudo. Technical note: the protection mechanism is defined in the documents app but tested in documents_hr because there is no company folder defined in documents that could be used in a test. [FIX] documents,documents_project: fix document deletion How to reproduce (Move to the Trash): - Install documents_project - Remove any access to the project folder (except to Mitchel Admin) - Login as Marc Demo - Upload a file in Marketing - Move that file to the Trash You get an access error while you should be able to move that document to the Trash. How to reproduce (Delete): - install documents_project - Login as Marc Demo - Upload a file in Marketing - Move it to the Trash - Remove any access to the project folder (except to Mitchel Admin) - As Marc Demo, go to the Trash and delete the document You get an access error while you should be able to delete that document. We solve the problem by doing the check in sudo (in unlink_except_project_folder). Technical note: We haven't done that test in documents (where there are already delete tests) because we had to change the test so that they are executed after all the modules are installed and that cause query count issue in performance tests. Task-4480581
Portal users now only see document actions they can actually use, reducing errors and confusion when managing shared documents. Duplicated documents also keep their own attachment links, preventing copies from disappearing or affecting the original record.
Original PR description
[FIX] documents: clean portal action We disable action that portal user cannot perform: In the preview: - hide Split Pdf in the preview In the cog menu: - remove "Move to Trash" as portal user can't…
[FIX] documents: clean portal action We disable action that portal user cannot perform: In the preview: - hide Split Pdf in the preview In the cog menu: - remove "Move to Trash" as portal user can't archive document (and can't create folder nor access to the trash anyway) - Info&Tags as it opens the chatter which is disabled for portal user In action: - Info&Tags as it opens the chatter which is disabled for portal user - Duplicate only present if it doesn't lead to an error (canDuplicateSelection method). We also remove the line separator in the action if the user is not internal otherwise it leads sometimes to an empty section. In the "New" drop down button: - hide "Folder" (create Folder) - hide "Link" (create link): fails because of (users | folders.owner_id).fetch(['partner_id']) in _prepare_create_values (no access to user) Hide share button for portal user: Although the portal users could share any documents they have access to (by sending them by email for example), we remove the share action (for document and folder) for them as the only thing they could do was to change the rights for user that had already a link to that document. [FIX] documents: fix attachment not pointing to the copied document When copying a document, the copied attachment still points to the orginal record: - if it is a document with an attachment associated to an other record (ex.: hr.expense). The attachment of the copied document is pointing to the same record as the orginal document. Ex.: for an expense, the expense has now 2 attachments linked (one linked to the original document and one linked to the copied one). - if it is a pure document, the attachment points to the orginal document We solve that problem here by always making the copied attachment to the copied document. How to reproduce case 1: - Install documents_hr_expense - Upload a document in the Document App - Create an expense from that document - Duplicate that document - Open the expense App - The expense related to the document has now 2 attachments instead of one How to reproduce case 2: - Install documents - Log in as admin and open Documents App - In Marketing -> Brand 1, duplicate "LA landscape.jpg" - Move "LA landscape.jpg" to the Trash and delete it (from the Trash) - Return to Marketing -> Brand 1 The copy has disappeared as well and shoudln't. It means that deleting the original document deletes all copies. It works also if we delete the copy (it deletes the original). [IMP] documents: allow portal user to delete their own documents Instead of enabling the Trash for the portal user, we add the delete action for their own documents only so that a user that have uploaded a document by mistake can delete it. Indeed, as portal user don't have access to the Trash, moving a document to the Trash like an internal user would do is no use. Task-4221258