Wednesday, May 22, 2024
23 changes · 17.0
Enhancements to existing features
When users click on internal links (like newly created leads) within a chat conversation, the chat window will now stay open alongside the linked document. This allows sales teams to quickly reference customer conversations while viewing related records, improving workflow efficiency without losing context of ongoing discussions.
Original PR description
When the CRM module is installed, people can use the /lead command to create a new lead from a conversation. When using that command, the Odoo bot will log a message in the chat with a link to the newly created lead. When people click on that link, they will be redirected to the lead form view and will lose track of the conversation they have with the customer. To avoid that, we will now open a chat window of the active conversation when clicking on the internal link. People will then be able to quickly answer the client from the chat window. task-3637983 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves how the Point of Sale system handles customer information when creating invoices for previous orders. When a customer wasn't initially recorded with an order, the system now properly saves the selected customer to the order, allowing the system to retrieve and use that information correctly when generating invoices.
Original PR description
This commit is used for the enterprise PR (odoo/enterprise#62261). When creating an invoice for a previous order in the POS, the class InvoiceButton handles missing partners, writing the selected partner to pos.order. But since the partner was not set to the order, the JS client cannot retrieve the partner directly. This commit remedies that by setting the partner to the order. task-3865331 --- 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 resolves two issues when editing documents from the activity view inspector: document name changes now persist after page refresh, and validation alerts now appear when attempting to save a document with an empty name. These behaviors now match the document kanban and list views for consistency.
Original PR description
Bug 1: How to reproduce: 1. Schedule an activity for a document. 2. Go to activity view. 3. Select the document to preview in the inspector. 4. Rename the document. 5. Refresh the page. The document…
Bug 1: How to reproduce: 1. Schedule an activity for a document. 2. Go to activity view. 3. Select the document to preview in the inspector. 4. Rename the document. 5. Refresh the page. The document name is not renamed. Similarly to what is done in document kanban and list controller where updating the document through the inspector works, we activate the parameter multiEdit which solve the problem. Bug 2: How to reproduce: 1. Schedule an activity for a document. 2. Go to activity view. 3. Select the document to preview in the inspector. 4. Erase the name of a doc and click anywhere to save. No alert pop-up is shown up while saving with an empty name while this is the case when editing the document from the kanban or the list view. Similarly to what is done in document kanban and list view, we add the required attribute to the field name. Technical note: to avoid duplicate a lot of code, we add the test inside documents_kanban_tests.js (while it is testing the update of a document in the inspector of the activity view). Task-3817795 Forward-Port-Of: odoo/enterprise#59263
Fixed a bug where the Planning calendar would crash when displaying a month for an employee with no scheduled or open shifts. The system was trying to access missing data attributes when loading an empty calendar. Now the calendar properly handles empty schedules without errors.
Original PR description
Steps to reproduce: - go to planning app - choose a month for a user without any planned or open shifts - publish - go to frontend via the email link - error raised Source: - many attributes like default_start are not present in planning_get reponse, trying to accessing default_start = undefined and converting it to a valid date that can be used to display the calendar raises an error. Solution: - when no_data = True, start function in fullcalendar should not compute anything as there are no data to display. task-3906551 task-3186609
Fixed an issue where the POS invoice popup was not respecting a customer's default CFDI usage setting. Previously, invoices would always show 'Acquisition of merchandise' as the usage type, ignoring the preference saved on the customer's contact record. Now the system correctly pulls and displays the customer's default CFDI usage when creating invoices in POS, improving accuracy and reducing manual data entry.
Original PR description
Steps to reproduce: 1. In the contact page for a Mexican-based contact, add a default usage 2. Start a new session in point of sale 3. Select the client with a default usage, add go to payment 4. Select invoice. The usage field shows 'Acquisition of merchandise', despit the default usage selected before Currently, the popup only takes into account the l10n_mx_edi_usage selected in the POS session or the code 'Acquisition of merchandise' if the field is undefined. The same behaviour happens if an invoice is created for a previous order. This commit adds l10n_mx_edi_usage to the partner fields to be loaded when loading the pos data. Then, the field in the popup can be filled with the default CDFI usage of the partner if it exists. Else, it behaves as before, displaying either the usage code selected in the POS session or code 'Acquisition of merchandise' if the field is undefined. task-3865331
This fix resolves an issue where replacement invoices in Mexico were using outdated currency exchange rates from the original invoice instead of current rates. When creating a replacement invoice for a cancelled invoice that was issued in a foreign currency, the system now correctly recalculates all financial amounts using today's exchange rate, ensuring the invoice balances properly.
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-3902683This fix resolves an issue where the email sender field was not being properly populated in marketing automation campaigns, causing errors when trying to send emails. The fix ensures that the mail server dependency is included in the form view so that the email sender field can be correctly calculated and populated automatically.
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#62403 Forward-Port-Of: odoo/enterprise#62164
This fix resolves a crash that occurred when exporting Spanish tax reports to BOE format. Users were encountering a "KeyError: 'res_id'" error when attempting to export tax reports (Mod 111/115/303/347/349) through the BOE export option. The issue was caused by a missing return value in the export wizard method, which has now been corrected to properly handle the export process.
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
This update fixes unreliable automated tests for the sales tax calculation feature that were failing unpredictably. The issue occurred because test steps were executing before required data requests completed, and buttons were being clicked before pages fully loaded. We've added safeguards to ensure proper sequencing and page readiness, making the tests more reliable and reducing false failures.
Original PR description
The tour is failing rarely and undeterministically. It seems like the reason is because 2 steps from the tour are done before a request is done (and so the number of the call to the function). We add a step to enforce that the request is made before the next step of the tour. We also enforce that we don't do the last action before closing the tour. In ulterior versions, the tour can be stuck when adding a product. Our guess is that the button is clicked before the page is fully loaded. The tour would then consider it did click the button, while the action didn't happen. We add a check to wait for the page to be fully loaded before clicking. Linked to runbot error 61458, 63532, 59031 (and happened before already). Forward-Port-Of: odoo/enterprise#62789 Forward-Port-Of: odoo/enterprise#61964
This fix resolves an issue in the bank reconciliation widget where exchange rate adjustments were being incorrectly duplicated when invoices were reset to draft status. When reconciling foreign currency transactions, the system was creating double reversals of exchange differences, leading to incorrect accounting records. This fix ensures exchange adjustments are properly linked and reversed only once.
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
Fixed a crash that occurred in the Timesheet grid view when users applied multiple groupings on date fields (such as grouping by both Week and Day). The system was incorrectly handling these multiple groupings, causing an error. This fix ensures all date groupings are properly processed so users can organize their timesheet data as intended.
Original PR description
To reproduce: - Log-in Administrator - Go to Timesheet app - Switch to list view - Add 2 group by: * Date > Week * Date > Day - Switch to grid view After odoo/enterprise@28337b5ae971 that result in a crash (error dialog) saying that `day` is not valid aggregation methods. This commit ensure we remove all groupby on the column field (no only the first one). opw-3908383 Forward-Port-Of: odoo/enterprise#62381
Fixed a critical issue where WhatsApp webhook updates for template quality were causing system errors. The system now correctly handles the "UNKNOWN" quality status that WhatsApp sends, preventing crashes when templates are evaluated. This ensures smooth communication with WhatsApp's messaging service.
Original PR description
When receiving a webhook to update for template quality it may crash with the following error: ``` ValueError: Wrong value for whatsapp.template.quality: 'unknown' ``` As indicated in the reference documentation [^1], whatsapp use the value `UNKOWN` whereas we're using `none` for `whatsapp.template` quality, so this commit convert it to the appropriate value. [^1]: https://developers.secure.facebook.com/docs/graph-api/reference/whats-app-business-account/message_templates/ Forward-Port-Of: odoo/enterprise#62756
This update fixes two navigation issues in Knowledge for portal users. First, when switching between articles, the URL now stays consistent so reloading the page loads the correct article instead of reverting to the original one. Second, the browser back button now properly loads the previous article instead of just changing the URL. These fixes ensure a smoother, more reliable browsing experience when navigating Knowledge articles.
Original PR description
This PR fixes two issues with the portal web client of Knowledge: - When a portal user opens an article and clicks on an article of the sidebar, the article id specified in the route url and the…
This PR fixes two issues with the portal web client of Knowledge: - When a portal user opens an article and clicks on an article of the sidebar, the article id specified in the route url and the session are not updated. The router only updates the url params of the url. When the user loads the page, the client script will load the article specified in the session. As the session is not updated when switching article, the script can load an incorrect article when reloading the page. This PR aims to fix that issue by ensuring that the client script will load the article with the id specified in the url params of the url. - When a portal user opens an article, clicks on an article of the sidebar and presses the back button, the system updates the url params and set the right id but it doesn't load the corresponding article in the view. This PR aims to fix that issue by ensuring that the web client load the article whenever the url changes. task-3743416 Forward-Port-Of: odoo/enterprise#62732 Forward-Port-Of: odoo/enterprise#60845
This fix addresses an issue where document names were not updating in the Activity view after being renamed, even after page refresh. The fix adds a technical mechanism to the Activity Controller that allows document changes to be properly synchronized, similar to how List and Kanban views already handle updates.
Original PR description
We prepare the following fix by adding a modelParam getter that can be overridden by sub-classes. How to reproduce: 1. Schedule an activity for a document. 2. Go to activity view. 3. Select the document to preview in the inspector. 4. Rename the document. 5. Refresh the page. The document name is not renamed. In the kanban and list view, the document is updated because multiEdit model parameter is enabled. It is not the case for the activity view. Similarly to what is done in list and kanban controller, we add a modelParam getter to the activity controller to allow to override the parameters in subclasses which will allows to enable the multiEdit parameter in the document activitty controller. Task-3817795 Forward-Port-Of: odoo/odoo#158874
This fix corrects an issue where timesheet revenues were being calculated incorrectly for fixed price products, showing amounts much higher than the actual sale order value. The problem was that the unit of measure (such as days) wasn't being properly accounted for in the revenue calculation. This ensures that timesheet revenue reports now accurately reflect the true project profitability.
Original PR description
Create a [TEST] Product with: - Invoicing Policy: Prepaid/Fixed Price product - Create on Order: Project & Task - Unit of Measure: Days Create a Sales Order with [TEST] prod Add a timesheet line on the recorded hours Go in Timesheet > Reporting > By Project Add the measure Timesheet Revenues Issue: Revenues are much greater than the sale order line amount. This occurs because we don't keep into account the UoM in the computation opw-3864227
This fix resolves an issue where the bill upload instruction popup was appearing every time users tried to upload a vendor bill, even when bills already existed. The popup should only appear the first time to guide new users. The fix ensures the system correctly tracks existing bills to determine when to show this helpful guide.
Original PR description
When attempting to upload a vendor bill in the Vendor Bills journal, the onboarding popup is incorrectly displayed every time, regardless of existing bills. ### Steps to reproduce * Install `account_accountant`. * Ensure your company has some vendor bills. * On the accounting dashboard, click the 'Upload' button on the Vendor Bill journal. Expected result: the file selector should open directly. Actual result: the onboarding popup appears every time a bill upload is attempted. ### Cause Previously, the method `_fill_dashboard_data_count` would count the entries in a journal and use this data to determine whether to display the onboarding popup. After commit d29a622740f6c34d25c52add5367bfdf58bbaf49, this method was replaced by a direct SQL query, which fails to update the count in the dictionary that informs the popup display logic. opw-3888114
This fix resolves an issue where serial numbers were not displayed when importing serials/lots for byproducts in manufacturing orders. The problem occurred because the system wasn't properly showing lot information for byproduct moves. Now users will be able to see and manage serial numbers correctly when working with tracked byproducts.
Original PR description
Steps to reproduce the issue:
- Create a storable product "P1" with the following BoM:
- Add any component.
- Add a tracked byproduct by serial number.
- Create a manufacturing order to produce one unit of P1.
- Navigate to the byproduct and click to open move details.
Problem:
The lot_name is not displayed. Therefore, when the user clicks on "Import Serials/lots" to create a serial number (SN), the SN is not displayed because the field "show_lots_text" in the move is set to False.
OPW-3925784Fixed an issue where the debug command in the command palette would not appear when users searched for it in non-English languages. The debug command name now includes the word "debug" as a non-translated part, ensuring it can always be found regardless of the system language. This improves the user experience for developers using Odoo in different languages.
Original PR description
- Before this commit The "debug" word in the command palette should display the item to activate the debugging feature. The problem is that the command palette still applies the fuzzy search to this item's name. If the lokked up string does not fuzzily match the letters "debug", the item will not get displayed. - After this commit The debug command name will now always have the `debug` word as a non translated part. opw-3889254 Forward-Port-Of: odoo/odoo#165363 Forward-Port-Of: odoo/odoo#165224
This fix prevents serial numbers and lot information from being lost when confirming internal stock transfers. Previously, when users selected a serial number for a tracked product in draft mode and then confirmed the transfer, the serial number would be removed. This update ensures serial numbers are properly retained throughout the transfer process.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- Track by SN
- Update the quantity with one unit and “SN1”
- Create an internal transfer and while in draft state:
- Add the product “P1”
- Select “SN1”
- Confirm the picking.
Problem:
The serial number is removed after the picking is confirmed.
opw-3925784The Hungarian EDI module can now be installed even if some tax configurations are missing or customized, instead of failing completely. This gives users the flexibility to use the EDI feature with their existing tax setup and manually configure taxes later if needed, rather than being forced to reload default tax settings.
Original PR description
If some of the taxes in l10n_hu have been deleted, the installation of l10n_hu_edi fails with a NotNullViolation. This is not ideal, because sometimes users have heavily customized taxes and may want to use the EDI without reloading the default taxes. We now avoid failing the installation if the tax configuration would fail. This therefore gives users 3 options: - manually setting the NAV tax code on their Hungarian taxes - reloading the CoA after installing l10n_hu_edi - uninstalling l10n_hu_edi (if they don't want to use it) opw-3912298
This fix resolves an issue where importing repair orders with new warehouse locations would fail with a database error. The system now properly handles location creation by automatically populating the required name field when importing data, allowing users to successfully import repair orders with new locations without encountering SQL errors.
Original PR description
**Current behavior:** In some instances we will try to create a `stock.location` record from a `complete_name` field value (one such case is creating from import). When this happens, the creation…
**Current behavior:**
In some instances we will try to create a `stock.location`
record from a `complete_name` field value (one such case is
creating from import). When this happens, the creation will fail
due to the not-null constraint on the `name` field in the table
and display a SQL error in logs.
**Expected behavior:**
Use part of the complete_name as the name.
**Steps to reproduce:**
1. Create an .xlsx document representing a Repair Order to be
imported, such that the `Location` cell value does not
already exist in the database
2. Install the test-import-export module, go into the Repair app
and from the favorites action button select import data
3. Upload the .xlsx file, press 'Test Import', select the
'Create New' option for offending data points
4. Observe that the new Location can not be created, and in the
console logs there is the output of the bad SQL query
**Cause of the issue:**
The `_rec_name` field for `stock.location` is `complete_name`,
however the `name` field as also a required field. When we
create the records in this flow, `_rec_name` is used to infer
which fields need to be included in the query. So `name` is
never added to the INSERT query and we end up violating the
not-null constraint on this column of the table (bad query).
**Fix:**
If there is no `name` in the create vals dict for the location
record, use the end segment of `complete_name`.
opw-3796010
Forward-Port-Of: odoo/odoo#165941
Forward-Port-Of: odoo/odoo#163298This fix improves the express checkout experience by removing shipping methods that failed to calculate rates. Previously, customers could select delivery options that weren't actually available, which could cause checkout issues. Now only successfully validated shipping methods are shown to customers.
Original PR description
In the express checkout flow delivery methods with failed rate shipment stay still available as a choice for the users. With this commit only carriers with successful rate will be shown. opw-3861519 Forward-Port-Of: odoo/odoo#165260 Forward-Port-Of: odoo/odoo#161524
This fix resolves an issue where users posting multiple quick messages in Discuss chats and channels would experience stuttering and lose characters. The composer now becomes available immediately after a message appears in the thread, rather than waiting for full server processing, allowing users to send rapid messages without interruption.
Original PR description
Before this commit, posting many small messages in a Discuss chat / channel was stuttering, which lead to posting messages with missing characters. Steps to reproduce: - Log with Mitchell Admin - Go…
Before this commit, posting many small messages in a Discuss chat / channel was stuttering, which lead to posting messages with missing characters. Steps to reproduce: - Log with Mitchell Admin - Go to Discuss > channel `#general` - Quickly post 10 messages numbered from 1, 2, 3, 4, 5, 6, 7, 8, 9, 0 => about half of messages are not posted This happens because the composer is inactive until the message is fully posted. This is far too long for Discuss chat and channels, where quick sending of small messages is expected. There's even some optimistic behavior in those conversations, which consists in pretending the message is posted before it's actually processed by the server. The composer is disabled even when the newly posted message is optimistically visible in the thread. This commit fixes the issue by clearing and enabling the composer immediately when the message becomes visible in the thread, which happens immediately when the user makes the action to post the message. This is made specifically for non-chatter threads, as chatter threads do not have this optimistic showing of the message thus it feels best to keep showing the composer content until the message is clearly in the thread. Before / After  