Daily updates from Odoo
Thursday, February 29, 2024
51 changes
9 changes
New functionality added to Odoo
This update introduces direct integration with Starshipit, a leading fulfillment provider specializing in Australia and New Zealand. Users can now automatically receive shipping rates and options through Odoo, streamlining the order fulfillment process for online businesses. This enhancement supports key markets and improves shipping efficiency.
Original PR description
Starshipit is the leading provider of integrated and automated fulfillment solutions for online businesses integrating with the leading carriers used in Australia and New Zealand, such as Australia Post, DHL, Aramex, CouriersPlease, and more This PR will add support to integrate with starshipit directly in Odoo, providing rates and shipping for users who need it. Task ID # 3041982 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#135839
Enhancements to existing features
This update enhances the testing of Odoo's email functionality, specifically focusing on how event attendee emails are sent in batches. The changes include new tests for batch email sending, improved test setup for event scheduling, and added checks for registration emails. These improvements ensure more reliable email delivery and scalability.
Original PR description
PURPOSE Mail: add tests for MailTemplate send_mail Several flows use MailTemplate.send_mail() in batch, notably event email scheduler which sends emails to event attendee in batch. This commit adds…
PURPOSE
Mail: add tests for MailTemplate send_mail
Several flows use MailTemplate.send_mail() in batch, notably event email
scheduler which sends emails to event attendee in batch. This commit adds
tests around 'send_mail' method of MailTemplate model
* add tests for batch: it is currently not supported hence using a loop but
batch is going to be added soon, allowing to test the batch version works
as intended;
* add query counters, notably for batch mode and when dynamic reports are
involved in templates;
Event: improve mail scheduler tests
Make them easier to improve and modify
* use a dedicated setup (allowing to add specific unit tests on test data);
* move initial asserts into its own unit test (to keep other tests shorter);
* use available mocks for freezetime and sql.now;
Then add tests for registration emails, to check what happens for communication
scheduled right at registration time.
LINKS
Part of Task-3764894: Event: Allow using cron triggers for communication
Part of Task-3764891: Mail: Batch-ize MailTemplate send_mail
Part of Task-3164278: Mail: Batch send: ensure limit, avoid force
Part of Task-3084943: Event: Improve communication scheduler scalability
Forward-Port-Of: odoo/odoo#155717Resolved issues and error corrections
This update corrects duplicated navbar and mega menu elements, improving website stability and user experience. The changes ensure consistent menu behavior across desktop and mobile views, addressing synchronization problems and preventing unexpected behavior during interactions.
Original PR description
This PR fixes issues linked to the new headers: - fix the duplicated navbar ids - consider Offcanvas instead of Collapse for "burger" menus - fix the header history, as some observed changes were breaking it (needed for the next commit, but should also be backported in earlier versions) - fix duplicated mega menu synchronization issues task-3609531 opw-3730165 Forward-Port-Of: odoo/odoo#146492
This update resolves a previous issue where users couldn't successfully unsubscribe phone numbers from receiving SMS notifications. The fix ensures users can now properly blacklist numbers and opt out of SMS communications, improving the reliability of the mass mailing system. This was a follow-up to a previous bug fix.
Original PR description
**Description of the issue/feature this PR addresses:** Before this PR: Users encountered errors when attempting to unsubscribe a phone number from receiving SMS. After this PR: Now, issue has been fixed, allowing users to successfully blacklist numbers and opt out of receiving SMS notifications. issue raised from - (https://github.com/odoo/odoo/commit/adfdf5ab33e719a55f65e2d9ff34ff265fe1b579) task-3651401 Forward-Port-Of: odoo/odoo#152638
This update fixes an issue where UBL invoice imports didn't correctly account for line quantities, leading to incorrect tax calculations. The fix ensures that fixed tax amounts are properly adjusted based on the quantity of items, improving the accuracy of imported invoices. A new test case has also been added to verify this functionality.
Original PR description
Fix import of invoices with fixed taxes, discount and quantity > 1. When exporting the UBL xml, we compute the fixed tax amount of the line and create a charge on the line with this amount (e.g. see the test). When importing this xml, we read the charges with code 'AEO' on each lines and use the `amount` and `name` to search the fixed taxes on the database. This issue is that we do not take the quantity of the line into account: if we have a line with quantity = 2, and the fixed tax amount = 1, the xml indicates a charge of 2. When we import the line, the amount of the fixed tax to be searched should be 2 / quantity = 1. In addition, add an test for the export and import of a line with quantity > 1, a discount, a fixed tax and a regular tax. opw-3717306 Forward-Port-Of: odoo/odoo#155468 Forward-Port-Of: odoo/odoo#153639
This update ensures that tax information is correctly displayed on Point of Sale (POS) tickets in India, as required by local regulations. Previously, this crucial detail was missing, creating a compliance issue. This change ensures Odoo POS systems meet Indian tax reporting standards.
Original PR description
In India, it is mandatory to show the tax info This commit solves the issue where tax info was missing on POS ticket 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
This update fixes a calculation error in the Point of Sale module. Previously, taxes with multiple distribution lines were incorrectly multiplying the base amount, leading to inaccurate sales totals. This change ensures the base amount is calculated only once, resulting in correct tax calculations and improved sales reporting.
Original PR description
Before this commit, if a tax had multiple distribution lines, the base amount was calculated for each line. This resulted in the base amount being multiplied by the number of distribution lines. This issue has been resolved by ensuring the base amount is counted only once for each tax and line. opw-3696800 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154783 Forward-Port-Of: odoo/odoo#152823
This update resolves an issue preventing Romanian companies from generating CIUS-RO XML invoices without a country code prefix on their VAT IDs. The fix adjusts how the system handles Romanian tax IDs, ensuring compliance with XML validation rules while allowing for the valid practice of not including the 'RO' prefix. This improves the usability of the CIUS-RO feature for Romanian businesses.
Original PR description
Previously, when exporting CIUS-RO XML and the supplier (company) or customer doesn't have a country code prefix on either their VAT or company ID, an error will be thrown preventing the user from…
Previously, when exporting CIUS-RO XML and the supplier (company) or customer doesn't have a country code prefix on either their VAT or company ID, an error will be thrown preventing the user from generating the XML. But after allowing the XML generating process, the XML is then rejected by the validator because of `BR-CO-09` rule: ```xml <assert id="BR-CO-09" flag="fatal" test="( contains( ' 1A AD AE AF AG AI AL AM AO AQ AR AS AT AU AW AX AZ BA BB BD BE BF BG BH BI BJ BL BM BN BO BQ BR BS BT BV BW BY BZ CA CC CD CF CG CH CI CK CL CM CN CO CR CU CV CW CX CY CZ DE DJ DK DM DO DZ EC EE EG EH EL ER ES ET FI FJ FK FM FO FR GA GB GD GE GF GG GH GI GL GM GN GP GQ GR GS GT GU GW GY HK HM HN HR HT HU ID IE IL IM IN IO IQ IR IS IT JE JM JO JP KE KG KH KI KM KN KP KR KW KY KZ LA LB LC LI LK LR LS LT LU LV LY MA MC MD ME MF MG MH MK ML MM MN MO MP MQ MR MS MT MU MV MW MX MY MZ NA NC NE NF NG NI NL NO NP NR NU NZ OM PA PE PF PG PH PK PL PM PN PR PS PT PW PY QA RE RO RS RU RW SA SB SC SD SE SG SH SI SJ SK SL SM SN SO SR SS ST SV SX SY SZ TC TD TF TG TH TJ TK TL TM TN TO TR TT TV TW TZ UA UG UM US UY UZ VA VC VE VG VI VN VU WF WS XI YE YT ZA ZM ZW ',substring(cbc:CompanyID,1,2) ) )">[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’.</assert> ``` In Romania however, there are multiple types of "Tax IDs", and it is perfectly valid in Romania to have a Tax ID without RO (country code prefix) in front of them. They are not a subject to paying VAT, and it should still be possible to generate CIUS-RO XML with their tax identifications. This commit aims to fix this behavior by applying some special treatment to Romanian partners when generating the XML: by modiying the TaxScheme ID. The error only raises when the detected ID is 'VAT'. This commit also fixes and clean some of the irrelevant constraints and tests previously written in `l10n_ro_edi`. task-id: 3649426 Forward-Port-Of: odoo/odoo#155252
This update fixes a bug where Kanban progress bars weren't showing the correct aggregated data when grouped by date or many2one fields. The fix ensures that the system accurately calculates and displays the aggregate values, improving the usability of the Kanban view. This also includes a related fix to the testing environment, allowing for more robust testing of this functionality.
Original PR description
Before this commit, in a kanban view grouped by a date(time) field, with progressbars and an aggregate field, after clicking on a bar to filter records, the aggregate value was always 0. This was due…
Before this commit, in a kanban view grouped by a date(time) field, with progressbars and an aggregate field, after clicking on a bar to filter records, the aggregate value was always 0. This was due to a mismatch when trying to find the value of the aggregate in the web_read_group result, as when grouped by a date or datetime field, the key is `fieldname:granularity`, and we were looking for the fieldname only. This commit fixes the issue. It also fixes the mocked version of read_progress_bar in the MockServer, s.t. we can correctly reproduce the scenario in tests, as in the previous version, keys in the returned object weren't computed the same way as in the real read_progress_bar (e.g., "14,Mitchel", instead of "Mitchel"). A similar fix has been done in [1]. This allows us to introduce a test when grouped by many2one, which doesn't work as of 17.0. [1] fd759f18d056844c486a68d0c394df5a03e789f0 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#155701 Forward-Port-Of: odoo/odoo#155524
2 changes
Enhancements to existing features
Recruitment reports now open the related applicant record directly instead of showing a generic report form. This makes it easier for recruiters to review candidate details and move through the report with fields arranged more logically.
Original PR description
This commit add a form view to replace the auto-generated one. The purpose is to have a better UX for the user to make them able to go to the applicant and order the fields in a way that make more sense to them to enhance the navigation experience. task-3613046
Salary attachments can now only be created for employees who belong to the companies currently selected in the multi-company view. This helps prevent payroll records from being created for the wrong company context and keeps payroll work focused on the relevant companies.
Original PR description
Prevent the creation of salary attachments for employees working in companies not selected in the multi-company widget. This enhancement ensures that salary attachments are relevant and specific to the currently focused companies. Task-3693473
40 changes
Enhancements to existing features
This update adds last modification dates to forum post URLs in website sitemaps, helping search engines like Google prioritize crawling more recent content. By providing accurate update information, the change helps search engines use their crawling resources more efficiently and improves the visibility of active forum discussions.
Original PR description
When a crawler (eg Googlebot) come to visit your website, it grants you a limited amount of time and ressources, it's called "Crawler budget". If you have millions of URLs, it won't go through each…
When a crawler (eg Googlebot) come to visit your website, it grants you a limited amount of time and ressources, it's called "Crawler budget". If you have millions of URLs, it won't go through each one of them in a single go.
The best you can help those crawler, the better. The sitemap `lastmod` attribute, despite not being fully respected and trusted by crawlers, is one of the way you can still try to help them.
For website.pages, it's already done. But for controllers, it's not an easy thing to do as we have no way to automatically figure what are the relevant records/fields to look at to know the last update date. For instance, on the event pages, some pages content are mostly stored inside an `ir.ui.view`, but the title, hours etc are part of the event itself.
We can't just say "we take the last write_date of the record", it's wrong in 2 ways:
- The first one I just explained where we wouldn't be able to easily get all the elements part of the page rendering and would miss a possible element write_date, leaving an outdated date in `lastmod`.
- Then, there is another issue (which is more problematic in stable): the `write_date` is often updated for non website related purposes. For instance, on /partners/<partner>, we wouldn't be able to use the write date on odoo.com as the partners shown there (having a grade) are update every weeks in average, because of many fields, for instance: commission_plan_id, partner_weight, grade_id, ...
Still, there is a quick win possible in stable about forum posts which are not impacted by the 2 issues explained above:
- There is a dedicated `last_activity_date` field which is updated only when relevant information are modified. We can ensure to show a date which is not updated too frequently for no reason.
- All the forum.post information displayed on the page are stored inside the forum.post itself.
This commit is thus adding the `lastmod` on forum.post URLs in the sitemap in hope of not making Google waste time on (very) old posts.
Note: the `lastmod` has to be trustworthy and correct, if you set wrong
or outdated info inside it, Google won't trust you/it anymore.The analytic widget's save button has been redesigned to reduce user confusion. The confusing floppy disk icon that appeared when creating analytic accounts has been replaced with a clearer "New model" link. Additionally, the widget now automatically populates related fields like partner and product information when available, making the workflow more intuitive.
Original PR description
On the analytic widget, when putting an Analytic Account, a floppy disk appear on top of the wizard. This button is used to create a new analytic distribution template. It is confusing for users that thinks that the purpose of the button is to save the analytic distribution. This PR will replace the button to be a link called "New model". Also, this pr will fill some field (partner_id, account_prefix and product_id) if there are populated. task: 3736786 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153588
Resolved issues and error corrections
This fix resolves an issue where work centers were not displaying correctly in the Manufacturing app's Work Centers Overview. When users opened a work center from the desktop, previously selected work centers would disappear from the view. The fix ensures that all selected work centers remain visible and accessible, preventing confusion and maintaining consistency between what users select and what they see displayed.
Original PR description
### Steps to reproduce: - Install **Manufacturing** app. - Open Shop Floor app and select work centers **Assembly Line 1** and **Drill Station 1** -This is not actually the only way to recreate the…
### Steps to reproduce:
- Install **Manufacturing** app.
- Open Shop Floor app and select work centers **Assembly Line 1** and **Drill Station 1** -This is not actually the only way to recreate the bug but the most forward-.
- Open Manufacturing app. In the Work Centers Overview, open **Assembly Line 2** by clicking on the **desktop icon**. Notice how there's only one button on the top bar **Assembly Line 2** **_although_** we should have 3 buttons by now **Assembly Line 1**, **Drill Station 1** and **Assembly Line 2**.
### Discussion:
- This Solution extends upon this PR https://github.com/odoo/enterprise/pull/52886 making some improvements
- when the `activeWorkcenter` doesn't exist on the array of the `workcenters`, add it to the array instead of reassigning the array with only the `activeWorkcenter`, That way we avoid the weird behavior of having the work center you selected get unselected implicitly https://github.com/odoo/enterprise/blob/adfe96612cfd0a0b29c8af7d03b19e87ed14155d/mrp_workorder/static/src/mrp_display/mrp_display.js#L108-L111
- U can select work centers inside the shop floor overview, using the **plus** icon. so an improvement was made to switch to the **All MO** tab if the user de-selected the _active_ work center in order:
- not to create inconsistency between the view of the work orders shown and the select buttons above.
- to prevent the error happening due to the inconsistency between the `activeWorkcenter` and the array of `workcenters` not including the `activeWorkcenter` anymore as it was de-selected.
opw-3638276This fix corrects how feedback request emails are sent to employees during 360 appraisals. Previously, employees without user accounts would receive feedback requests at their private email instead of their work email. The system now prioritizes sending to work email addresses first, then falls back to user email only if no work email exists.
Original PR description
Before this commit, answer's partner for 360 feedbacks were set as the employee's user partner or the employee's private email. This meant that all employees with no user would get the feedback request through their private email instead of their work email. However, it's not a wanted behaviour. This commit changes the way the answer's partner is determined, taking first the work partner, then the user partner if no work partner is found. task-3627757 based on ticket-3612515 Forward-Port-Of: odoo/enterprise#53518 Forward-Port-Of: odoo/enterprise#52235
This fix resolves an issue where non-recurring products were being incorrectly duplicated when creating upsells for subscriptions, causing multiple delivery orders and inflated sales reports. The update ensures that only recurring products are carried forward during upsell confirmations, and delivery quantities are properly synchronized between upsell and parent subscription orders.
Original PR description
If you create an upsell for a subscription, when the upsell is confirmed the non-recurring products are copied into the parent subscription which trigger the creation of 2 delivery orders (one on upsell, one on parent sub) and also as there are 2 SOL in the report the product is considered sold twice. This commit fixes this by not creating lines for non recurring products in _subscription_update_line_data. task-3689908
The 'My Team' filter in the Timesheets view was incorrectly displaying employees with no assigned manager or approver. This fix ensures the filter now shows only employees that the current user directly manages or approves timesheets for, providing a more accurate team view.
Original PR description
**Current behavior:** Selecting the pre-loaded 'My Team' filter from the search bar in the Timesheets view grid will list, in addition to employees managed by the current user, employees who have no assigned manager nor time sheet approver. **Expected behavior:** This filter will list exclusively employees who the current user is either the manager of or is the time sheet approver of. **Steps to reproduce:** 1. In the Timesheets application, select the My Team filter **Cause of the issue:** The filter's domain includes these aforementioned un-managed employees. **Fix:** Remove that part of the domain. This commit is a partial revision to one of the changes made by https://github.com/odoo/enterprise/commit/60dc8c38519b75b5383a54e923135d557e3737e0 (see log chatter on Odoo for associated ticket for justification) opw-3708825
Fixed a bug that caused an error when viewing tickets from a sales order and grouping them by stage. The issue was resolved by properly passing the team identifier through the system context, ensuring the correct data is retrieved without technical errors.
Original PR description
Steps to reproduce: ------------------- - go to Sales; - click on a sale order with tickets assigned to it; - click on the "Tickets" smart button; - group by stage. Issue: ------ A traceback appears. Cause: ------ The query formed is incorrect. We are using a Query object in the domain instead of the team id. Which has been placed in context beforehand. Solution: --------- Place the team id in the context. Note: ----- This will automatically be converted to a list if necessary when generating the query with a domain using the `IN` operator (relation). opw-3759882
This update resolves a technical error where a variable wasn't being properly assigned in the account reconciliation process. While this issue typically only affects customized versions of the system, the fix ensures the reconciliation feature works reliably for all users, preventing unexpected errors during manual account reconciliation.
Original PR description
It seems some people are getting an "unassigned variable 'balance'". This shouldn't happen with the standard code because _get_write_off_move_lines_dict is only called from the manual reconciliation widget in which, you only have access to models having strictly lines being percentage or fixed (see get_reconcile_modelds_for_manual_reconciliation). This method is not called from the bank reco widget pointed by "RECONCILE x ITEMS" on the accounting dashboard. It probably comes from some customization but I don't know which ones. github issue: 116064 X-original-commit: 99525f8dac17170a59ed10e471a8ea364258884c Forward-Port-Of: odoo/enterprise#57047
This update fixes and completes Spanish translations for Mexico-specific features in Odoo. Several translation files were missing or incorrectly configured after recent system updates, which has now been corrected to ensure Mexican users see proper Spanish text throughout the system.
Original PR description
Enterprise side of COM PR: odoo/odoo/pull/155214 Note that a couple of terms were manually translated by finding the terms in other es_MX.po files so that all terms from ticket screenshot will be correctly translated. This is due to a ecommerce (website_sale) refactoring in v17 that made it so some of the terms no longer exist specifically in the l10_mx* locale, so their translations couldn't be automatically backported from the existing v17 translations. opw-3452127 Forward-Port-Of: odoo/enterprise#57395 Forward-Port-Of: odoo/enterprise#57358
This update fixes how product prices are rounded in Peru's electronic invoicing system (EDI). Previously, prices weren't being properly rounded to meet SUNAT's requirement of maximum 10 decimal places, which could cause invoices to be rejected. The fix ensures all prices are correctly rounded to comply with Peru's tax authority standards.
Original PR description
Due to a change in the base UBL template, the `<PriceAmount>` is no longer rounded to the number of decimals of the product price. Since the SUNAT only accepts numbers with a maximum of 10 decimals, we round the computed product price for Peru specifically to 10 decimals. [Issue reported by Fernando Vazquez (fvz)](https://www.odoo.com/web#id=3415758&cids=1&model=project.task&view_type=form)
Portal users can now successfully search for tickets by assignee. Previously, the search would return no results because portal users lacked permission to access the user database. The fix uses elevated permissions to look up matching assignees first, then searches for tickets assigned to those users.
Original PR description
**Steps to reproduce:** 1- Install Helpdesk, Website module 2- Login using portal user 3- Navigate to tickest and search by assignees **Current behavior before PR:** When searching by assignees using a portal user you will not get any results. This is happening because the portal user seems to not have the access to search in 'res.users' so when the orm parse the user_id assigned to the ticket to a name it will not be able to parse it for the portal user. **Desired behavior after PR is merged:** We search first for the users that are matching the search key in 'res.users' using 'sudo()' then get their ids and search in 'helpdesk.ticket' using those ids opw-3719387 Forward-Port-Of: odoo/enterprise#56716
Fixed a bug in the AvaTax address validation feature that caused the system to crash when validating addresses in certain locations where AvaTax doesn't return geographic coordinates. The system now gracefully handles cases where coordinates are not provided, allowing address validation to complete successfully for all supported addresses.
Original PR description
### Cause When validating an address, we take for granted that Avatax returns latitude and longitude, while it's optional. We started using Avatax's returned geocoordinates in `saas-16.2`, https://github.com/odoo/enterprise/commit/282b878d8c441aaf546e6ce5d5c7dbe9f831d5b2 ### Steps to reproduce * install `account_avatax` * in the settings, enable and setup Avatax. Make sure to enable Address Validation. * create a partner with the following address: - Street 1: 999 Canada Pl - City: Vancouver - State: British Columbia (CA) - Zip: V6C 3B5 - Country: Canada * click the 'Validate' button, next to the country You should be met with a traceback: `KeyError: 'latitude'` Ticket link: https://www.odoo.com/web#model=project.task&id=3752775 opw-3752775 Forward-Port-Of: odoo/enterprise#57612
This fix restores a filter that was accidentally removed, ensuring that service-type products are properly excluded from intrastat reports. Services should not be included in intrastat documentation, and this change ensures the system handles this correctly again.
Original PR description
This commit(https://github.com/odoo/enterprise/commit/217594fe8ba00329b3eb5c68e3eca3b556127cde) removed a filter on products that are services and that shouldn't be in the intrastat report (for now). This commit adds again this filter. opw-3763306 opw-3764904 opw-3730803 Forward-Port-Of: odoo/enterprise#57701 Forward-Port-Of: odoo/enterprise#57607
This fix resolves an issue where employee profile images displayed differently in appraisal forms compared to their actual profile images. The solution removes a cached thumbnail image that was causing browser caching conflicts, ensuring users see the correct and up-to-date employee image when viewing appraisals.
Original PR description
**Made for 16.3, 16.4 and 17.0 not later** Steps to reproduce the bug: 1. Have a user that have a user image that is different from the employee image. 2. Go to an appraisal form of that employee. (or create one) -> the miniature is different from the full image. expected result: the miniature should be the same as the full image if possible. correction: The image of the right as been removed because browsers will cache the small one even if not stored in db and will not update it when The employee image is updated. So in some cases the problem is just not solvable without clearing the browser data even if all is done properly. task-3644834 Forward-Port-Of: odoo/enterprise#54067
This update corrects account classification tags in Mexico's SAT (XML) export functionality. Accounts in the 1xxx range are now properly marked as debit accounts, ensuring accurate financial reporting for Mexican tax compliance. This fix aligns with recent updates to the core accounting system.
Original PR description
Fix test after Community change, 1xxx accounts should have been debit tag, thus Natur='D'. Community: https://github.com/odoo/odoo/pull/119485 Forward-Port-Of: odoo/enterprise#57666 Forward-Port-Of: odoo/enterprise#57531
This fix resolves a crash that occurred when viewing the gantt calendar in the appointment scheduling system. The issue happened because the system was using the wrong employee calendar information, which could differ between user and employee records. The fix ensures the correct employee calendar is used consistently throughout the system.
Original PR description
Make sure to use the resource calendar of the employee. Indeed, it is possible that the resource calendar set on the user is different than the one on the employee. Which can leads to a traceback if the resource calendar was not in the unavailabilities_by_calendar. As we base previous computation on employee, we also use the employee here. task-3698586
Fixed an issue in the approval workflow where notification recipients were not being alerted when a rule had no assigned responsible person. Now, designated notification users will receive alerts even when there is no responsible party, ensuring important approvals don't go unnoticed.
Original PR description
… the time Have a rule with no responsible but with some users to notify. Have a user who cannot validate the rule execute the action. Before this commit, the users to notify were not pinged. After this commit, those users are pinged, even though there is no responsible. opw-3752133
This fix corrects how exchange rate differences are calculated and displayed in the bank reconciliation widget. The previous version was incorrectly calculating the exchange difference by counting debits twice while missing credits, and not properly handling cases where a single transaction had multiple partial matches. This ensures users see accurate exchange rate adjustments when reconciling bank accounts.
Original PR description
Fix wrong computation of displayed exchange difference in the bank rec widget. 1. We are adding twice the debit side and not the credit one. 2. In the bank rec widget you can have an `account.move.line` with multiple partials, thus multiple `matched_debit/credit_ids` and we are acting as if there is only one. Forward-Port-Of: odoo/enterprise#57758 Forward-Port-Of: odoo/enterprise#57709
The search field in the website header can now be accessed using keyboard navigation (tabbing). This fix improves accessibility for users who rely on keyboard navigation instead of a mouse, making the website more usable for everyone.
Original PR description
This commit resolves the accessibility issue where the search field located within the header was not navigable (see [1]) via keyboard tabbing, rendering it inaccessible to users relying on keyboard navigation. This fix ensures that users can seamlessly navigate to the search field in the header using the keyboard, thereby enhancing the overall accessibility and usability of the website. [1]: https://github.com/odoo/odoo/commit/ac5866a059c345480e246b558eeae1e94aead822 task-3607481
This fix corrects an issue where CRM kanban column headers displayed incorrect status colors (showing red/overdue) even after all overdue activities were marked as done. The problem occurred because archived activities were being incorrectly included in the status calculation. After this fix, kanban column headers now accurately reflect the current activity status when activities are completed.
Original PR description
How to reproduce: - Install CRM with demo data - Configure one activity type to keep done activities - Go to CRM and chose a kanban column with a green status (only planned activities for that state)…
How to reproduce: - Install CRM with demo data - Configure one activity type to keep done activities - Go to CRM and chose a kanban column with a green status (only planned activities for that state) - On a lead of that column, add an activity of the type chosen above with a deadline in the past - When going back to the kanban view, that column has the overdue status (red) - Mark that activity as done - Reload the kanban view The kanban column has still the status overdue (red) while there are no more overdue activity in that state. With this fix, after reloading the kanban view, the header displays the correct status summary. In the example above, the kanban column header is green. Technical note: archived activities were returned when grouping by activity_state because that part was done in SQL and not taking into account the recently added active field. While adding it in the "_read_group_groupby" method, we also add it in "_search_activity_state" to avoid the same problem when searching on activity_state. Note that we don't add flush in those methods using raw SQL so flush is needed in the added test. Task-3732333
This fix resolves an error that occurred when installing the Argentina withholding tax module for multiple Argentine companies. Previously, tax data was incorrectly linked to the first company's accounts, causing conflicts when setting up additional companies. The fix ensures tax data is properly computed for each company independently, allowing seamless installation across multiple Argentine operations.
Original PR description
Steps to reproduce: - Install Accounting and l10n_ar - Create 2 companies located in Argentina (e.g. Company A & Company B) - Switch to Company A - Go to Accounting settings - Set Fiscal Localization…
Steps to reproduce: - Install Accounting and l10n_ar - Create 2 companies located in Argentina (e.g. Company A & Company B) - Switch to Company A - Go to Accounting settings - Set Fiscal Localization to Argentina (e.g. Argentina - Argentine Generic Chart of Accounts for Excempt individuals) - Switch to Company B - Go to Accounting settings - Set Fiscal Localization to the same Fiscal Localization than Company A (i.e. Argentina - Argentine Generic Chart of Accounts for Excempt individuals) - Try to install "l10n_ar_withholding" module Issue: A User Error is raised: "Incompatible companies on records: - 'account.tax.repartition.line,1230' belongs to company 'Company A' and 'Account' (account_id: '1.1.4.03.020 SUSS Withholding incurred') belongs to another company. - 'account.tax.repartition.line,1232' belongs to company 'Company A' and 'Account' (account_id: '1.1.4.03.020 SUSS Withholding incurred') belongs to another company. - 'account.tax.repartition.line,1234' belongs to company 'Company A' and 'Account' (account_id: '1.1.4.05.030 Withholdings of Profits incurred') belongs to another company. - 'account.tax.repartition.line,1236' belongs to company 'Company A' and 'Account' (account_id: '1.1.4.05.030 Withholdings of Profits incurred') belongs to another company." Cause: When installing "l10n_ar_withholding" module, each Argentine company is updated with some tax data. These data are "generic" (not linked to any company) and used for each company, but some treatment is performed on them by the first Argentine company, linking them to the account ids of that company. The following companies are then updated with data linked to the first company. Solution: Compute the data for each company. opw-3709819 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an error that occurred when duplicating payment providers for subsidiary companies. The system was incorrectly trying to link payment methods to shared parent company bank accounts, causing duplicate payment method conflicts. Now the system properly uses bank accounts specific to the subsidiary company, allowing payment providers to be duplicated and used independently across different company branches.
Original PR description
…mpany Steps to reproduce: - Create a branch - Select the two companies in the company selector - Go to payment provider and duplicate the "Demo" one: * set the name as "Demo child" * set the company…
…mpany
Steps to reproduce:
- Create a branch
- Select the two companies in the company selector
- Go to payment provider and duplicate the "Demo" one:
* set the name as "Demo child"
* set the company as the child
* delete the journal
- Go back in payment provider and try to select the created payment
provider
Issue:
UserError: "You can't have two payment method lines of the same payment type (%s) and with the same name (%s) on a single journal."
Cause:
When opening the provider view, it triggers:
- payment.provider._compute_journal_id: if there is no journal_id set on the provider and there is a default bank journal (journals are shared between branches) we'll try to link the payment method to this journal.
https://github.com/odoo/odoo/blob/7d39137df61832e4fe2240fef8e33ad7435359e8/addons/account_payment/models/payment_provider.py#L52-L64
If there is no payment method line (pml), we'll create one with the defaul_payment_method (Demo, the one we duplicated) and with the default journal (Bank from parent company)
- account.payment.method.line._compute_name: it sets the pml.name to 'Demo'
https://github.com/odoo/odoo/blob/7e8185ba20476dd3428ce5e0196207b3bc03eccf/addons/account/models/account_payment_method.py#L134-L138
The constraint in
https://github.com/odoo/odoo/blob/7e8185ba20476dd3428ce5e0196207b3bc03eccf/addons/account/models/account_payment_method.py#L140-L151
is raised since we have to pml with the same name (Demo), the same Journal (Bank from parent) and the same payment type (inbound) with different id's.
Solution:
Find only Bank journals created i n the child company
opw-3692146This fix resolves an issue where the HR Skills module was creating duplicate "Work Information" tabs in the employee form, causing errors when trying to remove tabs in Studio. After this update, users can now remove tabs without encountering errors or system crashes.
Original PR description
Description of the issue/feature this PR addresses: When hr_skills is installed we have 2 tabs/page with the same name in xml (Work Information and Resume). As "Work Information" is defined in hr modules hr_skills must be updated.  - In employee form - Open studio - Click on "Work Information" tab/page - Remove "Work Information" tab/page view Current behavior before PR: - Traceback due to invalid xpath expression (or error depending of version and/or module installed - Invalid xpath due to duplicated name for a node Desired behavior after PR is merged: - Tab is removed without traceback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154776 Forward-Port-Of: odoo/odoo#154731
This fix corrects how loyalty points are displayed to customers during checkout. Previously, customers would see points with excessive decimal places (like "268.28000000000003") due to a technical rounding issue. Now points display cleanly and accurately, improving the customer experience when viewing their loyalty rewards.
Original PR description
Steps ----- 1. Create a loyalty card program awarding 1 point per $ spent; 2. make sure "Show points Unit" is enabled; 3. give yourself a loyalty card with 267.39 points on it; 4. create a product with a price of $0.89; 5. go to website and add it to your shopping car; 6. go to checkout. Issue ----- > You have 268.28000000000003 Loyalty point(s) Cause ----- The number comes from the `_get_real_points_for_coupon` method, which uses `float_round` by way of `res.currency`. The `float_round` function isn't suited for raw number display, as it can make tiny rounding errors due to floating point arithmetic. Solution -------- Add a `_format_points` method to `loyalty.card` which will return a string using the same format the `points_display` field uses. opw-3705546 Forward-Port-Of: odoo/odoo#155466 Forward-Port-Of: odoo/odoo#153541
Fixed an issue where restaurant staff without admin privileges couldn't view custom splash images on the mobile ordering menu. The fix allows images to load properly for any user with valid access to the ordering page, improving the experience for restaurant employees managing mobile orders.
Original PR description
**Current behavior:** Trying to access the mobile order menu for a pos restaurant with some non-default landing page images as a non-admin user will result in an access error. **Expected behavior:**…
**Current behavior:** Trying to access the mobile order menu for a pos restaurant with some non-default landing page images as a non-admin user will result in an access error. **Expected behavior:** The images should load on this page for anyone who has a valid access token for the page route. **Steps to reproduce:** 1. Make a restaurant in the POS application 2. Enable mobile ordering and set a database user with `user` level access to the POS app to be the default user for this newly created restaurant 3. Upload a splash image for the restaurant 3. On the POS dashboard, select the three vertical dot button on the restaurant -> `Mobile Menu` to get the access error **Cause of the issue:** The default user on the restaurant POS will not necessarily have access rights to the `ir.attachment` model/records. **Fix:** Get the images as sudo()- IMO there isn't a reason these should be inaccessible to anybody considering they are intended to be seen on the landing page by people trying to order. opw-3748314
The iOS mobile app's check-in feature was not working because the app couldn't properly request location access. This fix updates the code to properly detect when the app is running on iOS and skips the location request in those cases, allowing employees to successfully check in using the iOS app.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Use iOS app; 2. click on red dot on top; 3. click check in. Issue ----- Nothing happens. Cause ----- The iOS app cannot request the user's location. Commit 1acd0b6c5d7ce292f670882f6ff48a2ff9db05f0 attempted to fix this by first checking whether `navigator.geolocation` exists, but the cause is likely with its `getCurrentPosition` method instead of its existence. Solution -------- Instead of checking for `navigator.geolocation`, use `isIosApp` to skip the geolocation part when using the iOS app. opw-3734385
This fix resolves warnings that appeared when exporting the Mexican Chart of Accounts (COA SAT) report in the accounting module. The issue was caused by missing account tags and incorrect tag assignments on 102 accounts. The fix corrects the existing data and ensures new accounts are automatically assigned the proper tags, allowing the report to work smoothly out-of-the-box for Mexican users.
Original PR description
Steps to reproduce: 1. Install l10n_mx 2. Go to Accounting > Reporting > Trial balance. 3. Click the COA SAT(XML) export button. 4. Warnings are raised. Problem: the report should work out-of-the-box on new databases. Cause: 1. Some tags are missing on auto-generated accounts. 2. Some data were not correct and had the wrong tag. 102 accounts in particular should be debit and not credit. This PR migrate the incorrect data and add a default naive computation of the tag on newly created accounts. opw-3283746 Enterprise: https://github.com/odoo/enterprise/pull/57531 Forward-Port-Of: odoo/odoo#155677 Forward-Port-Of: odoo/odoo#119485
This fix resolves an issue where employees with leave allocations would show zero remaining leaves on their dashboard after their personal calendar was removed. The system now properly falls back to the company calendar to calculate leave balances, ensuring accurate leave information is always displayed to employees and managers.
Original PR description
Steps to reproduce the issue: - have an employee with an allocation with an end date - remove the employee's calendar - go on his dashboard - his remaining leaves amount is 0 This commit implements a new method on the resource mixin to fetch a calendar for the record even though it might not have one. The default behaviour is to fall back on the company's calendar to ensure a value. This is overrided in the `hr_contract` module so that the calendar of the contract is prioritized. task-3609738 Forward-Port-Of: odoo/odoo#144418
This fix resolves a crash that occurs when displaying partner contact information if their name field is empty or null. The contact widget was attempting to process null values incorrectly, causing the system to fail. This fix ensures the widget handles missing names gracefully, which is important since approximately 3,000 partners in the system have null name values.
Original PR description
In case where display_name is null, the widget contact crash - AttributeError: 'bool' object has no attribute 'split' On odoo.com we have around 3K of partners that have name with null value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where changing an end date in datetime fields would unexpectedly reset to a template value. The problem occurred because the system wasn't properly protecting unchanged start dates from being recalculated. The fix ensures both date fields are properly tracked when changes are made, preventing unwanted resets.
Original PR description
To reproduce: ============ - on Planning create new shift - select a template - change the end date -> the end date is reset to the template value Problem: ======== - `end_datetime` and…
To reproduce: ============ - on Planning create new shift - select a template - change the end date -> the end date is reset to the template value Problem: ======== - `end_datetime` and `start_datetime` have the same compute method - `template_id` depends on `start_datetime` and `end_datetime` - so changing `end_datetime` triggers the compute method of `template_id` that will read `start_datetime` - reading `start_datetime` triggers the compute method of `end_datetime`, that will check if `template_id` is set and if so, will take its values ------- why the compute method of `end_datetime` is triggered ? : ------- - `start_datetime` is not protected from recomputing, at this line : https://github.com/odoo/odoo/blob/83aa46a4ab88c0226b1aa1dc36671d3208a0835a/odoo/models.py#L6746 we only protect the fields sent by frontend (only `end_datetime`) - frontend doesn't send `start_datetime` as it was not changed Solution ======== as ORM fix can't be made in stable, we send `start_datetime` in the `onchange` query even if it's unchanged to make sure both fields are protected opw-3693206 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154566 Forward-Port-Of: odoo/odoo#154190
This fix resolves an issue where the list of available documents for scheduling activities became progressively restricted after the first two scheduling attempts. The problem occurred because system filters were being incorrectly applied to the activity scheduling dialog, limiting visibility to only documents that already had activities. The fix ensures all documents remain accessible for activity scheduling regardless of how many times activities have been scheduled.
Original PR description
**Steps to reproduce:** - Go to activity view. - Schedule an activity for one document. (Say 8 docs are available) - Schedule an activity for the second time. (Again 8 docs are available) - Try to…
**Steps to reproduce:** - Go to activity view. - Schedule an activity for one document. (Say 8 docs are available) - Schedule an activity for the second time. (Again 8 docs are available) - Try to schedule an activity for the 3rd time. (Only 2 docs are available) **Issue:** Since 7682286, the existing props of activity model are being passed as params while scheduling an activity. Currently, `["activity_ids", "!=", false]` is being pushed to the domain of activity model in order to display only those records on which activities have been set. As a result, after you schedule activities more than once, `["activity_ids", "!=", false]` domain gets applied and the list of documents available for scheduling activity is restricted to only those specific records from the third time onwards. **Fix:** This PR passes the 'searchParams' of activity model as params to the 'load' method while scheduling activity, instead of existing props, to ensure that the existing params are applied, as well as all documents are accessible while scheduling activity in `searchCreateDialog` (i.e. ["activity_ids", "!=", false] condition is not added to its domain). Task: [3721750](https://www.odoo.com/web#id=3721750&menu_id=4722&cids=2&action=333&active_id=10888&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#155595 Forward-Port-Of: odoo/odoo#153606
This fix restores the ability for form selection fields to keep their default selected values after a page is saved in the Website editor. Previously, when users set a default option for a dropdown field in a form snippet, that selection would be lost upon saving. This update ensures that default selections are properly preserved, improving the user experience when building forms on websites.
Original PR description
Since the PR [1] changed the rendering engine of qweb, the default "selected" value set on selects field on the form snippet were lost once the page is saved. This commit builds upon the changes made in [this commit] by reinstating the default "selected" value. Steps to replicate: - Go to Website -> Edit. - Drop a Form snippet onto the page. - Click on the 'Company' field. - In Field > Type, opt for "Selection". - Choose option 3 from the options list to establish it as the default. - Save the modifications. Issue: The expected default value for the selection field is not retained after saving. [1]: https://github.com/odoo/odoo/pull/130467 [this commit]: https://github.com/odoo/odoo/commit/b42e9cc686e7d3ccf82cd091a5dc24028fff8a2b task-3767819
Users can now edit dropdown selection fields in kanban views that support drag-and-drop reordering. Previously, the drag-and-drop feature was preventing dropdown menus from opening. This fix allows both features to work together seamlessly.
Original PR description
Before this commit, if a SelectionField was used in a kanban view alongside the HandleField (enabling re-sequencing, i.e. drag&drop), the "select" element couldn't be edited. This is because the d&d feature calls preventDefault on almost all "pointerdown" events occuring in the card, and the "pointerdown" event is the one that opens the select. There's no usecase in 17.0, but there's one in master, in the product document kanban view. We fix this in 17.0 which is the version that introduced the kanban version of the SelectionField. 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
This fix resolves inconsistent behavior in how tax calculations handle price inclusion settings. Previously, the system interpreted the same setting differently depending on which calculation method was used, causing incorrect tax computations in certain scenarios. The fix ensures all tax calculation methods now interpret price inclusion settings consistently, which resolves issues where clients need to override how taxes are calculated relative to product prices.
Original PR description
Before this commit, using context key `force_price_include=False` had different interpretations in different methods In `compute_all` its semantic was forcing the "price_include" of taxes to be False In `_compute_amount` it was ignored (as only value "True" was overriding anything) To add to this incoherence, compute_all does use `force_price_include=False` when calling `_compute_amount`. This commits brings semantical coherence to the `account_tax` methods by keeping both interpretations of the context key the same: an override of price_include, whether its value True or False. This fixes a ticket in which the client uses that override to inverse the computation of `price_unit` from a tax-excluded counterpart. owp-3770871 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155769
This update fixes an issue where the project tour guide was getting stuck and not working properly when users accessed it on mobile devices. The fix adds mobile-specific steps and adjusts how the tour triggers work to ensure a smooth experience for mobile users.
Original PR description
The tour isn't working if you run it on mobile mode, it gets stuck at some points. To fix this issue, a mobile step was added, and one trigger was edited to work with mobile mode as well. task-3709501 Forward-Port-Of: odoo/odoo#153444
This fix restores the partner autocomplete feature that was accidentally disabled when creating new invoices. When users start typing a partner name, the autocomplete dropdown will now display properly, making it easier and faster to select or create partners during invoice entry.
Original PR description
Steps to reproduce: [account, iap credit] - create a new invoice - start to write "test" for the partner Issue: The partner autocomplete is not displayed Cause: in https://github.com/odoo/odoo/pull/150106 we add a condition for the quickCreate bypassing the possibility of having createEdit set to true opw-3698400 Forward-Port-Of: odoo/odoo#154771 Forward-Port-Of: odoo/odoo#153608
This update removes unnecessary state validation requirements for overseas business partners in the Indian e-invoicing system. State information is now only required when the partner is located in India, making the system more flexible for international transactions and reducing data entry errors for foreign customers.
Original PR description
This commits removes the state validation for `l10n_in_edi` for overseas partner and now state will be only required for e-invoicing for partner having country `India` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154118
This update corrects how tax closing accounts are configured across multiple country-specific tax modules (localization packages). A previous update introduced default tax closing accounts but didn't properly apply them to tax groups in the newer system format. This fix ensures tax closing accounts are correctly set up for proper tax reporting and compliance across all affected countries.
Original PR description
Commit 14abe7acb11 (PR #123816) introduced default tax closing accounts for localizations that were so far missing them. However, the mechanism for specifying the default tax closing accounts changed in 16.2: they must now be specified on the tax groups. This was not correctly done in the fw-port, so we fix this in this commit. taskid: 3524378 Forward-Port-Of: odoo/odoo#155660 Forward-Port-Of: odoo/odoo#155074
This fix improves the reliability of duration widget formatting in Odoo by gracefully handling formatting errors from the Babel library. When Babel encounters an unsupported date/time format for certain locales, the system now automatically falls back to English (US) formatting instead of displaying an error. This ensures users see properly formatted durations even when using locales with known Babel formatting issues.
Original PR description
In case of exception of type KeyError during the formatting with Babel instead to raise a Traceback, we first retry with the en_US locale. Babel fixes each week new bug of formatting like the one in the test, but we cannot bump our default babel version since it is not in the stable Ubuntu 22 so it is a best effort fix that will not hide all bugs but is better that nothing. https://github.com/python-babel/babel/pull/827 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
Fixed an issue where the live chat widget could be hidden behind other elements on websites that embed it. The fix ensures the live chat always appears on top by setting its display priority to the maximum level, improving visibility and accessibility for customers trying to reach support.
Original PR description
The live chat should always be on top of other elements: some sites that embeds it use z-index for various purpose. Currently, the live chat does not uses z-index, thus is it can be hidden by other elements. This PR sets the z-index to the largest value of a signed integer on a 32 bit system which is the theorical maximum value for this property. opw-3732033 e.g. on squarespace (before)  (after) 