Daily updates from Odoo
Friday, February 16, 2024
33 changes · 17.0
Resolved issues and error corrections
This fix resolves an issue where subscriptions with partial tax exemptions were not being automatically invoiced. The problem was caused by field dependencies that recalculated order totals after confirmation, causing the system to incorrectly treat valid payments as partial payments. Now subscriptions with partial exemptions will invoice correctly and automatically.
Original PR description
Before this, a subscription with partial exemptions wouldn't be automatically invoiced. It's caused by field dependencies added by sale_subscription that cause the order totals to be recomputed after confirmation. More specifically, sale.order.line.discount is made to depend on subscription_state, which gets written to during action_confirm(). Because of this _invoice_sale_orders() will filter out the payment transaction because _get_partial_payment_subscription_transaction() considers it a partial payment. opw-3562613
This fix resolves a crash that occurred in the Barcode App when users dismissed a confirmation dialog after scanning a non-reserved product during a planned transfer. The issue was caused by unhandled promise rejections in the code, which has now been properly addressed to ensure a smooth user experience.
Original PR description
How to reproduce: - Open a planned transfer in the Barcode App; - Scan a non-reserved product => A confirmation dialog is shown; - Discard or close the confirmation dialog => Traceback! It happens because rejected promises have to be handle which is not the case here. To fix that, resolve the promise anyway. task-3677142
This fix resolves an access error that prevented users from viewing bank connections when working in a branch company. The issue occurred because the system was incorrectly restricting access to bank connection records based on company hierarchy rules. Users can now properly access their bank connections across the organization structure.
Original PR description
Create a branch In the system parameters, switch account_online_synchronization.proxy_mode to sandbox Add a bank with plaid for example and follow the different steps Switch to the branch only and try to access the accounting app Access error raises: """ Sorry, Mitchell Admin (id=2) doesn't have 'read' access to: - Bank Connection, Plaid (account.online.link: 2, company=parent nico) Blame the following rules: - Account online link company rule Note: this might be a multi-company issue. Switching company may help - in Odoo, not in real life! If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies. """ This occurs because the mentioned record rule allow access to the `account.online.link` record only from the same company opw-3725198
This update improves how appointment types are displayed on the appointment page by automatically sorting published appointments first. This makes it faster and easier for staff to find and access the most important appointments without having to search through unpublished options.
Original PR description
This PR changes the order of appointment types on the appointment page based on the appointment's published status. This makes it easier for internal users to access published appointments first. Task-3725160
This update fixes missing translations for three key terms ("gain", "loss", and "gain/loss") in the asset modification wizard. These terms are now properly translated for users in different languages, ensuring a consistent and professional experience across the accounting asset management features.
Original PR description
Fix translation for account_asset / wizard There was fixed strings without translation - gain - loss - gain/loss
Fixed an issue where users couldn't access the payroll dashboard when an employee's contract belonged to a company they didn't have access to. The system now properly handles this scenario by allowing the dashboard to load and display the appropriate warning, rather than blocking access entirely.
Original PR description
Currently, when an employee contract belongs to a company different than the employee's company, a warning is shown in the payroll dashboard [1]. However, if the current user has no access to the contract's company, an access error is raised, which makes not possible to neither see the warning nor load the dashboard. This commit fixes the above issue by ensuring the employee contract is read as sudo, to avoid requiring the current user to have both companies selected to see the warning. References: - [1] https://github.com/odoo/enterprise/blob/e41d2ce5/hr_payroll/models/hr_payslip.py#L1072 **Access Error:**  Forward-Port-Of: odoo/enterprise#56425 Forward-Port-Of: odoo/enterprise#56335
Fixed an issue where the command palette (Ctrl+K) in the PDF split tool was showing irrelevant commands that didn't work. Now it only displays commands relevant to the PDF Manager, providing a cleaner and more functional experience when users open the PDF split view.
Original PR description
How to reproduce: 1. Select a file/doc. 2. click on the split tool button 3. opens the PDF split view 4. press control+k (shows command palette) Before this commit: List all the commands, but those which are related to 'DocumentsKanbanRenderer' are not working. Technical Reason: PDF splitter is a dialog, the context of the Kanban Renderer stays in the background, 'Select all' and other command logic related to the 'DocumentsKanbanRenderer', do not work in PdfManager because of not having the state of it. After this commit: Showing commands related to the PdfManager only. Task-3623653 Forward-Port-Of: odoo/enterprise#53438
This update fixes how appointment types display in the kanban view when not grouped, ensuring they appear correctly on mobile phones, tablets, and desktop screens. Users will now have a consistent and properly formatted viewing experience across all devices when managing appointment types.
Original PR description
Fix the appointment type kanban view ungrouped display on all screen sizes. Task-3617435
This update prevents users from resubmitting electronic invoices that have already been submitted in Brazil. Previously, users could attempt to resubmit rejected invoices, but this would use outdated tax data and cause errors. Now, users must reset invoices to draft status, recalculate taxes, and then resubmit to ensure accurate tax information is used.
Original PR description
It's confusing to allow resubmitting electronic invoices. When invoices are rejected the user will probably make changes to them in Odoo. Resubmitting will use the old, saved tax response data in l10n_br_edi_avatax_data which won't be correct anymore for the new configuration. Instead, the user should reset to draft, redo tax computation and then resubmit. task-3711015
This fix prevents users from selecting property-type fields when creating related fields in the Studio view editor. Property fields were causing errors because they require special handling that isn't currently supported. By blocking this selection, we eliminate a source of configuration errors and simplify the user experience.
Original PR description
On a view, drag and drop a new related field. Go into one m2o field. Before this commit, it was possible to select a field of type "properties". This is not supported by python at the time. To do so, one would have to reflect the property "definition" of the python field. Also, some code would have to be written to create that other field, related as well that'd contain the properties' definition. After this commit, to make things simpler, we just blacklist property fields in the related field selector. opw-3730900 Forward-Port-Of: odoo/enterprise#56688 Forward-Port-Of: odoo/enterprise#56597
This fix corrects the error message that appears when a subscription code is already linked to another database. Previously, the message wasn't displaying properly, making it unclear to users what action to take. Now the helpful guidance message will display correctly, improving the user experience when managing subscription codes across multiple databases.
Original PR description
When a subscription code is already linked to a database and you try to use it on another database, the message displaying that this subscription code is already used and provides the informations of what to do is not correctly displayed. Forward-Port-Of: odoo/enterprise#56618 Forward-Port-Of: odoo/enterprise#47326
This update fixes a technical error that occurred when users tried to reply to comments in LinkedIn posts within Odoo. Previously, clicking the reply button on a comment would cause the system to crash. This fix ensures users can now reply to comments smoothly without encountering errors.
Original PR description
Bug === 1. Open the comments modal of a LInkedIn post 2. Click on "Reply" on a comment without answer => Traceback Task-3748995 Forward-Port-Of: odoo/enterprise#56773 Forward-Port-Of: odoo/enterprise#56689
This fix resolves an error that occurred when using the German POS system with Fiskaly payment certification in German language. The system was sending currency amounts with German formatting (using commas as decimal separators) instead of the standard format (using periods) that Fiskaly requires, causing transaction failures. The fix ensures amounts are sent in the correct format regardless of language settings.
Original PR description
Steps to reproduce:
1. install `l10n_pos_res_cert` and set up Fiskaly
2. set up a PoS restaurant
3. set the language to German
4. open a PoS session and make an order
error:
```
error parsing request body: amounts_per_vat_rate.0.amount: Does not match pattern '^-?\d+(.\d{2,5})$'
```
The issue is similar to that fixed in https://github.com/odoo/enterprise/pull/46682
It comes from the fact that formatCurrency method is used to convert the amounts to string. However it adds language specific formatting. In this case Fiskaly expects `12.50` but `12,50` is sent.
opw-3724456
Forward-Port-Of: odoo/enterprise#56619
Forward-Port-Of: odoo/enterprise#56498This fix resolves an issue where searching for documents in spreadsheets caused pagination to malfunction. When users entered a search term, the system wasn't properly resetting the page position and updating the total count of results. Now, searches work correctly with proper pagination handling, ensuring users see accurate results when filtering documents.
Original PR description
### Before: Before this fix, entering a search term in the bar caused pagination to malfunction. The issue stemmed from the offset not resetting to 0 upon entering a search term, leading to incorrect behavior. Additionally, the total count failed to update with search inputs. ### After: This PR resolves the issue by resetting the offset to 0 upon search term entry and updating the total count using the domain passed to the _fetchPagerTotal method. Task ID: [3631981](https://www.odoo.com/web#id=3631981&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#56549 Forward-Port-Of: odoo/enterprise#53122
This update adds the required XML declaration to the Belgian intrastat XML report. A Belgian partner identified that the XML report was missing the proper XML declaration header, which is now included to ensure compliance with XML standards and partner requirements.
Original PR description
We got a feedback from a Belgian partner that we don't have a xml declaration in the xml report. opw-3745820 Forward-Port-Of: odoo/enterprise#56764 Forward-Port-Of: odoo/enterprise#56727
This update corrects how email addresses are formatted when sending shipment information to UPS. The email field now uses the proper capitalization (EMailAddress) required by UPS's system, ensuring that customer email addresses are correctly processed and recognized in UPS shipment requests.
Original PR description
For email address to be considered in the UPS request, the `M` needs to be capitalized. UPS documentation for reference: UPS documentation for reference: https://developer.ups.com/api/reference?loc=en_US#operation/Shipment!path=ShipmentRequest/Shipment/ShipTo/EMailAddress&t=request opw-3487959 Forward-Port-Of: odoo/enterprise#56475
This fix restores the ability to properly control which users can create new inventory lots based on their picking type permissions. A recent change inadvertently removed a key piece of information needed to enforce these restrictions, which this update restores to ensure lot creation rules are correctly applied during stock operations.
Original PR description
Since 4da8c6ebca024, the lot creation when filling a stock move line is done via the stock quant "pick from" field. We thus don't have the 'active_picking_id' key that was set on lot_id field to check if the user can create or not new stock lot for a particular picking. This commit add this context key back on the stock move line one2many for it to be available at the stock quant creation. Task: 3670447 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#149253
This update resolves a technical issue that was preventing users from opening the emoji picker tool in the web editor. When users attempted to select an emoji, the system would display an error. This fix ensures the emoji picker works smoothly without interruptions.
Original PR description
**Current behaviour before commit:** In v17.0 and above trying to open emoji-picker throws traceback. This happens because not able to find input element inside `onPositioned` method. **Desired behaviour after commit:** Now there is no traceback when opening emoji-picker. task-3729610 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves a printing error that occurred when generating expense reports with analytic distributions in Odoo 17. The analytic distribution information has been removed from printed expense reports since it provides limited value and is not displayed in other Odoo printed reports.
Original PR description
This commit addresses an issue introduced after the Analytic distributions changes in v17 where printing expense reports with cross-analytic distribution raises a traceback. Given that analytic distributions offer limited value on printed expense reports and considering that no other printed reports in Odoo currently display the analytic distribution, they have been removed. task-3722135 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes how text labels appear in the web editor for users in non-English languages. Previously, all labels were automatically capitalized, which caused problems with translations that have different capitalization rules. The fix keeps automatic capitalization only for English while allowing other languages to display labels as translators intended them.
Original PR description
Commit [1] added a rule whose intention was to unify the way our editor labels look: capitalized. However, this is not working as intended for translations as some languages have different rules for capitalization. In the future, we will rely solely on the labels being written with the intended capitalization in the first place (which is currently not the case for dozens of English labels). As a fix, we keep the auto CSS rule for English languages only. Hopefully, the amount of translations made by translators being better than their auto-capitalized versions is greater than non-capitalized English labels translated by mistake without the auto-capitalization. Note: this is the way python fields work too, they are not displayed auto-capitalized in the webclient, although we want them to be. [1]: https://github.com/odoo/odoo/commit/5db73c12d3ed14239dc81f60eec6c21d0f65af26 Forward-Port-Of: odoo/odoo#153248
This fix resolves an issue where users encountered an error when trying to change the start date of an all-day calendar meeting that has additional attendees. The problem occurred because the system was attempting to send email notifications using incomplete meeting data. The fix prevents unnecessary email notifications during the date adjustment process, allowing users to successfully reschedule all-day meetings.
Original PR description
Steps to reproduce: - - Calendar > create an all_day meeting with an additional attendee - Save > Edit > change starting date to a later day > traceback Cause of the issue: - The write call of the method _onchange_date is applied to a pseudo record. However, the write method expects a record with an integer id to correctly _send_mail_to_attendees down the line. https://github.com/odoo/odoo/blob/31100f22ad7e31daea65de446439b090f70ad9de/addons/calendar/models/calendar_event.py#L548-L556 Fix: - Since we don't want to send_mail_to_attendees anyway, we skip this part of the write method using the already existing contextual escape 'is_calendar_event_new'. opw-3733753 - --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153908 Forward-Port-Of: odoo/odoo#153430
This fix restores the background color of notification messages that appear on the website front-end. Previously, notifications had transparent backgrounds making them difficult to read for visitors. The fix improves the styling approach to ensure notifications display properly with appropriate backgrounds across all user states.
Original PR description
This PR fixes the background of notifications in the front-end. Before this PR, `.o_notification` background was set to `bg-view` . This was creating an issue in the front-end where `.bg-view` doesn't exist, making the background of the notification transparent when an user is not logged in and ultimately causing readability issues. Issue introduced in [1]. This PR changes the way we apply the background from a utility class approach to a SCSS approach. That way, we can easily override in `website.scss` with the `$body-color` of the website. task-3716367 [1] 4e1f0b8ea522accae4860937c2fb3815281e8483 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153909 Forward-Port-Of: odoo/odoo#152432
This update fixes two issues in the mass mailing email editor: text in coupon code blocks is now visible (previously hidden due to matching background and text colors), and the link button now properly appears and disappears when selecting single or multiple content blocks. These improvements make the email editor more responsive and user-friendly.
Original PR description
**Current behavior before PR:** - When coupen code template is selected and we drag text block then text will not be visible because of bg color as the background color and text color are same. -…
**Current behavior before PR:** - When coupen code template is selected and we drag text block then text will not be visible because of bg color as the background color and text color are same. - When selecting multiple blocks, the link button sometimes fails to disappear, and sometimes, after selection clicking on a line, the link button does not reappear because the code resides within the `_updateEditorUi` function, and this function is not invoked upon a selection change. Therefore, after modifying the selection, the user must wait for the `_updateEditorUi` function to be triggered, which happens upon a click or keydown event. **Desired behavior after PR is merged:** - Now in coupen code we can see text in text block. - Now the link button will disappear on multiple block selection and it will be reappear on single block. as we moved code to updateToolbar which is triggered on selection change. task-3514347 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153914 Forward-Port-Of: odoo/odoo#136099
This update changes how Odoo organizes its internal module list from an unpredictable set to a sorted list. This ensures that tests run consistently and reliably, fixing issues where security tests were failing randomly due to module order variations. The change is internal and won't affect how users interact with Odoo.
Original PR description
Make the set() of module sorted, aka a list. We can be pretty sure that nobody relied on the order of this set before since it was completely underterministic. Therefore this change should not break anything and make the testing on runbot more consistant. This is mainly following the issue with the sql-injection testing failing randomly with the order of the modules. Forward-Port-Of: odoo/odoo#154140
Fixed an issue in the calendar application where users couldn't create 15-minute events by dragging on the calendar. The system was incorrectly detecting both a drag selection and a click event, causing it to create a default 1-hour event instead. This fix prevents the duplicate click event from interfering with the intended short-duration event creation.
Original PR description
Issue: ------ On the calendar application, it is not possible to create a 15-minute event directly from a selection using the mouse. An event with a default duration of one hour is created. Cause: ------ The fullcalendar library detects two events: - a date selection - a click The date selection is correct, but the size of the "rectangle" is the same (15 minutes is the smallest unit in terms of size). As a result, a click using a default time is detected. Solution: --------- We can use `preventDefault` to block the second event (the click) because the event is the same. Note: ----- This fix is safer than patching the `FullCalendar` library (which may change in future versions). opw-3743945
This update fixes an issue where stock transfers were not being properly consolidated when they had different delivery deadlines. A new system parameter has been added that allows users to optionally ignore deadline differences when merging inventory movements, preventing the creation of duplicate daily transfers in automated resupply scenarios.
Original PR description
'date_deadline' is always present in a 'stock.move' and in some specific cases, can prevent the merge of moves in the same transfer. In the example bellow, new moves are added to the same transfer…
'date_deadline' is always present in a 'stock.move' and in some specific cases, can prevent the merge of moves in the same transfer. In the example bellow, new moves are added to the same transfer every day (for each scheduler run), but the moves are not merged together. There is 2 thing we could d oto fix this situation: - Create a new transfer for each date_deadline - Merge the move with distinct date_deadline Usually, it makes sense to not merge moves with distinct date_deadline, but it also makes sense to not create a new resupply transfer every day. So for now, we treat this situation as a limitation, but we still provide a workaround: By adding a system parameter, we give the possibility to the user to ignore the date_deadline when merging moves. ## HOW TO REPRODUCE: - Create new Warehouse 'Warehouse 2' WH2 - Create Custom Route to resupply 'WH/Stock' from 'Transit' From 'WH2/stock' (see screenshot) - Create product P1 (storable, with custom route selected) - Create reordering rule on default warehouse, with min=1, max=1, route=custom route - Create Sale Order for 10 units of P1, confirm => New Receipt from 'Transit' -> 'WH/Stock' generated - Wait 1 day (alternative is to increment the Lead Time on the Stock Rules). - Create Sale Order for 10 units of P1, confirm => Same Receipt used, 2 lines are present. OPW-3633551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151499
This update fixes access control settings for Polish tax office information in the accounting module. A field that references tax office data now properly enforces the same access restrictions as the underlying tax office model, making the system more secure and eliminating test warnings.
Original PR description
The model `l10n_pl_tax_office` has a group to be able to access it. The Many2one that refers to it, `l10n_pl_reports_tax_office_id`, does not. Currently, it is not really an issue as the accounting's settings are invisible if you don't have the group, but it creates a warning in a test and is more robust Linked to runbot error 24602, 24721 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154215 Forward-Port-Of: odoo/odoo#153660
This fix improves the e-way bill submission process for Indian electronic invoicing by validating orders before sending them to the government system. Previously, if an order contained only services (no physical products), the system would attempt to submit it and then display an error. Now, the system checks upfront that at least one product line exists and prevents submission with a clear error message, providing a better user experience.
Original PR description
In this commit ============================================= Before if all the lines were of service the error was displayed in a banner after error in response was received, but now before sending request the lines are checked if at least one line is of product and error is raised. Issue in this: https://github.com/odoo/odoo/pull/153522/commits/c81595db6a7a135a3289751a9b881b2f947bc6d2 Forward-Port-Of: odoo/odoo#154120
This fix prevents the product configurator from displaying product options that have been deleted or archived. Previously, when a product attribute option was removed, it could still appear in the configurator, causing confusion for customers. The system now filters out inactive options to show only available choices.
Original PR description
If product has no_variant attributes with 2 values and the first value was deleted, it is still returning it in the product configurator. Filter the template's value ids to return only active variants opw-3570604 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153398
This fix resolves an access rights error that occurred when users with limited permissions tried to load additional sales order items in a project update. The issue happened because the system wasn't properly granting temporary elevated permissions for all items being loaded. This update ensures all items load correctly regardless of user permission level.
Original PR description
Steps to reproduce: ------------------- 1. Install sale_project with demo data 2. Create a user with no access rights other than Project/User 3. With that user, navigate to the 'AGR - S00064 - Sales Order' project > Project Update 4. In the Right Side Panel, at the bottom of the 'Sale Order Items' section, click on 'Load More' This will give an access rights error. The reason is that while we load the first five SOLs with sudo rights, we don't use sudo for subsequents items, thus leading to an access right error. This PR adds two sudos to avoid that error. Forward-Port-Of: odoo/odoo#154025
This update fixes a bug that occurred when users tried to create loyalty cards directly from a contact's Loyalty Cards button. The system was incorrectly allowing this action, which resulted in an error. The fix removes this unintended functionality and hides the Loyalty Cards button when there are no cards to display, preventing users from encountering this error.
Original PR description
### Steps to reproduce issue: 1. Select a Contact 2. Click on Smart Button "Loyalty Cards" 3. Create a new Loyalty Coupon 4. Save 5. Receive an error: > The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead. > > Model: Loyalty Coupon (loyalty.card) > Constraint: loyalty_card_program_id_fkey ### Explanation: The model given to `program_id` by the `default` attribute is not always `loyalty.program`. In the case of the issue, for example, the model is `res.partner`. https://github.com/odoo/odoo/blob/a3201d636505dc1976d3f0ee7f8cbf65d2488966/addons/loyalty/models/loyalty_card.py#L27 ### Suggested fix: The creation of `loyalty.card` from `res.partner` Smart Button is not intended, therefore we will remove this option and set the Smart Button as invisible if `loyalty_card_count` is null. opw-3707588 Forward-Port-Of: odoo/odoo#152644
This update fixes how VAT identifiers are formatted in electronic invoices sent through Peppol Bis 3, a standard used for cross-border business invoicing. The system now automatically adds the required country code prefix to VAT numbers when missing, and validates that all VAT identifiers follow the correct format. This prevents invoices from being rejected by trading partners and ensures compliance with international invoicing standards.
Original PR description
In Peppol Bis 3, the value on PartyTaxScheme/CompanyID should be prefixed with a 2 letters code representing the country of the partner. Currently, filling a VAT without this country code will lead…
In Peppol Bis 3, the value on PartyTaxScheme/CompanyID should be prefixed with a 2 letters code representing the country of the partner. Currently, filling a VAT without this country code will lead to the error: "[BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’." On the other hand, some extra-european countries use Peppol Bis 3 but do not prepend their VAT with the country code (i.e. Australia). To allow such cases, we automatically add the country code when it's missing. To prevent regression, we also add a contraint mimicking the schematron: we check that the final value of the PartyTaxScheme/CompanyID is prefixed with a 2 letters code. This way, the constraint is independant from the code. Forward-Port-Of: odoo/odoo#154076 Forward-Port-Of: odoo/odoo#151352
This update prevents the web interface from crashing when it encounters permission errors while checking stylesheets for compilation issues. The system now gracefully handles these errors instead of failing, ensuring a more stable user experience when stylesheet features are restricted.
Original PR description
This commit follows [1], which attempted to fix CORS errors occurring when we access the `cssRules` property of stylesheets, to detect scss compilation errors and display a warning to the user. [1] doesn't seem to be enough, as we faced another source of CORS errors. Indeed, in non-secure http, the error is raised even if the origin is the same. We never want this access to crash anyway, as it's a nice to have feature, and if reading `cssRules` is forbidden, there's nothing the user can do anyway. For those reasons, we decided to simply protect the code with a try/catch. [1] odoo/odoo#152696 opw 3746910 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