Search
Navigate
Branch
Tuesday, March 11, 2025
48 changes
24 changes
Enhancements to existing features
This update adds support for Belgium's CCT90 non-recurring results-based bonus scheme in payroll. It helps employers calculate and process these bonuses more accurately within Belgian payroll workflows.
Original PR description
task-4609727
This update adjusts how dropdown state is handled in the Gantt view, helping the interface behave more consistently. It is a small usability improvement for teams using planning or scheduling views.
Changes to a Mexico electronic invoicing setting are now recorded in the activity log. This helps businesses notice accidental changes to a setting that can affect the fiscal structure of generated CFDI documents.
Original PR description
Because the field l10n_mx_edi_cfdi_to_public affects the structure of the cfdi generated and this has a fiscal impact the field was made tracked so that if anyone by error enables or disables this field a log note is generated informing this event
Belgian CP200 payroll now supports recording salary advances separately and automatically recovering them on the regular monthly payslip. This makes payroll clearer for HR teams and reduces confusion by renaming the deduction to “Salary Advance Recovery.”
Original PR description
This commit improves how salary advances are managed. Now, there is a new structure type within the CP200 structure that allows to create a payslip with a salary advance amount as an other input. When generating the CP200 monthly payslip, the total salary advance already granted is added as an editable other input 'Salary Advance Recovery', which is deducted from the total net. This commit also renamed the existing 'Salary Advance' input type and rule (which represented a recovery) to 'Salary Advance Recovery' to avoid confusion with the initial salary advance. task-3614756
Employees can now mark bank accounts as trusted from their employee record without requiring the account to follow IBAN formatting. This makes payroll bank account handling consistent across screens and better supports countries where non-IBAN accounts are common, such as the US.
Original PR description
When trusting a bank account from the employee's form view, a check was performed to verify that the bank account has a valid IBAN. This check is not performed on the bank account form view as a bank account (e.g. in the US) does not necessarily follow the IBAN format. This commits remove the IBAN validity check on the employee form view for consistency with the bank account view. task-4613593
Updated WhatsApp-related tests to match the latest message payload format, helping ensure the system continues to validate messaging behavior correctly. This is an internal quality improvement with no expected change for day-to-day users.
Original PR description
PR community: https://github.com/odoo/odoo/pull/180745 PR upgrade: https://github.com/odoo/upgrade/pull/6722
This update streamlines how Kenya OSCU e-invoicing information is handled for products that have only one variant. It reduces duplicated setup work and helps keep product reporting data more consistent.
Original PR description
Related to: - https://github.com/odoo/odoo/pull/189001
Recruiters can now send interview scheduling emails that create meetings linked directly to the candidate application. This makes application records easier to track and avoids incorrect reuse of shared calendar invitations across candidates.
Original PR description
Goal --- When a "Schedule interview" mail template is sent from an application, if the recipient uses the link the schedule a meeting, the meeting should be linked on the smart button on the…
Goal
---
When a "Schedule interview" mail template is sent from an application,
if the recipient uses the link the schedule a meeting, the meeting
should be linked on the smart button on the application form.
Note
---
Previously we had a demo "Schedule Intreview" mail template, from which
a recipient could schedule an interview -- but the `appointment.invite`
was the same for all recipients and the meeting would not be linked back
to the application.
Changes
---
* Edit appointment booking route to take an applicant_code in the url
* The applicant_code makes it possible to match calendar event with
applicants at creation time
(not just an applicant_id to avoid "attackers" guessing ids)
* the mail template now creates an invite link for the recruiter's
`anytime` appointment type and the current applicant.
* Remove applicant_id from appointment invites
* instead we append the applicant_code to the url when copying the link
to share
* all other buttons in this view also append the applicant_code
* Note: this is needed because the field relation made it impossible to
use the same invite for several applicants
Beneficial "Side Effects"
---
* This makes it so we don't have to regenerate an invite for every
applicant when sending a link for a specific appointment type
* Fix the following bug:
* when admin has no `anytime` appointment type -- go to the
calendar view from the applicant form button.
* *Share Calendar* -- the invite's applicant is the current one
* repeat for another applicant -- no new invite is generated and the
applicant stays the same.
task-4251911Resolved issues and error corrections
This fixes internal template names so they correctly match the spreadsheet editing module they belong to. It reduces the risk of confusion or loading issues when maintaining or using spreadsheet-related screens.
Original PR description
Some templates were named as if they belonged to `documents_spreadsheet` while actually being part of the `spreadsheet_edition` module. Task-4624479
Miscellaneous changes
During the introduction of the Kanban's selection feature (cf. commit [1]), the extraction of the SelectionBox component left some `nbSelected` getters' references while it actually was renamed `hasSelectedRecords`. This commit adapts them properly. [1]: https://github.com/odoo/odoo/commit/877895cc10b1218396f77f995dc7c87a9d22f585 Forward-Port-Of: odoo/enterprise#80246
Original PR description
During the introduction of the Kanban's selection feature (cf. commit [1]), the extraction of the SelectionBox component left some `nbSelected` getters' references while it actually was renamed `hasSelectedRecords`. This commit adapts them properly. [1]: https://github.com/odoo/odoo/commit/877895cc10b1218396f77f995dc7c87a9d22f585 Forward-Port-Of: odoo/enterprise#80246
24 changes
New functionality added to Odoo
Odoo Point of Sale now supports Pine Labs payment terminals through a new dedicated module. This allows businesses using Pine Labs devices to accept terminal payments directly from the POS workflow, improving checkout integration and reducing manual payment handling.
Original PR description
In this commit: ========== - We have introduced a new module, `pos_pine_labs`, for the `Pine Labs` payment terminal to facilitate point of sale payment methods. - We are exporting `offlineErrorHandler` from `point_of_sale`'s `error_handlers` to use in the `pos_pine_labs` module. task-4359883
This update corrects two small issues in the employee appraisal workflow. It helps keep appraisal goals and appraisal campaign actions working as expected, reducing minor disruptions for HR users.
### Before Codabox used to require a fiduciary VAT and the VAT of a company (managed by the fiduciary) in order to connect to their services. - Access to Codabox was limited to companies with an accounting firm with a VAT number assigned ### Now Codabox gives the opportunity for companies to directly connect (without being a fiduciary/ being managed by one). This is through the same port as before, just receiving two identical VAT numbers. - Module summary, descriptions and ot
Original PR description
### Before Codabox used to require a fiduciary VAT and the VAT of a company (managed by the fiduciary) in order to connect to their services. - Access to Codabox was limited to companies with an accounting firm with a VAT number assigned ### Now Codabox gives the opportunity for companies to directly connect (without being a fiduciary/ being managed by one). This is through the same port as before, just receiving two identical VAT numbers. - Module summary, descriptions and other texts are updated to generalize - Companies without an accounting firm can access the Codabox configuration settings task - 4460499 Forward-Port-Of: odoo/enterprise#80907 Forward-Port-Of: odoo/enterprise#77240
Overrides xml and xlsx export for Estonia intrastat because the current columns of the default intrastat report don't match with estonian government requirements. More information can be found at those addresses: - Arrivals: https://www.stat.ee/en/questionnaires/intrastat-arrivals-2024-month - Dispatches: https://www.stat.ee/en/questionnaires/intrastat-dispatches-2024-month task-3989930 Forward-Port-Of: odoo/enterprise#80990 Forward-Port-Of: odoo/enterprise#71114
Original PR description
Overrides xml and xlsx export for Estonia intrastat because the current columns of the default intrastat report don't match with estonian government requirements. More information can be found at those addresses: - Arrivals: https://www.stat.ee/en/questionnaires/intrastat-arrivals-2024-month - Dispatches: https://www.stat.ee/en/questionnaires/intrastat-dispatches-2024-month task-3989930 Forward-Port-Of: odoo/enterprise#80990 Forward-Port-Of: odoo/enterprise#71114
New purchases/sales ledger tax report for Bulgaria. In additional, we add few fields on account_journal and account_move, to deal with the 2 new reports. task-4280578 linked:https://github.com/odoo/odoo/pull/187779 Forward-Port-Of: odoo/enterprise#74258
Original PR description
New purchases/sales ledger tax report for Bulgaria. In additional, we add few fields on account_journal and account_move, to deal with the 2 new reports. task-4280578 linked:https://github.com/odoo/odoo/pull/187779 Forward-Port-Of: odoo/enterprise#74258
This commit fixes the style of the pin counter on the map view. The counter didn't display the number correctly. task-4544732 Forward-Port-Of: odoo/enterprise#80352
Original PR description
This commit fixes the style of the pin counter on the map view. The counter didn't display the number correctly. task-4544732 Forward-Port-Of: odoo/enterprise#80352
This commit introduces an easy way to recognize "orders" which are intended to settle customer accounts. opw-4185144 Community PR: https://github.com/odoo/odoo/pull/183682 Forward-Port-Of: odoo/enterprise#80791 Forward-Port-Of: odoo/enterprise#71958
Original PR description
This commit introduces an easy way to recognize "orders" which are intended to settle customer accounts. opw-4185144 Community PR: https://github.com/odoo/odoo/pull/183682 Forward-Port-Of: odoo/enterprise#80791 Forward-Port-Of: odoo/enterprise#71958
Purpose ======= In the Facebook settings, a user can ask an application (eg Social) to remove his data. If the deletion is not implemented, it should be done manually for each user, and so we want to automate that process. Technical ========= The deletion process is done in that order: 1. The user go to his settings and ask Odoo to remove the data we have 2. Facebook will hit an endpoint in IAP, with a signature, and the Facebook user id 3. IAP will reach the database, (with a shar
Original PR description
Purpose ======= In the Facebook settings, a user can ask an application (eg Social) to remove his data. If the deletion is not implemented, it should be done manually for each user, and so we want to…
Purpose
=======
In the Facebook settings, a user can ask an application (eg Social) to remove his data.
If the deletion is not implemented, it should be done manually for each user, and so we want to automate that process.
Technical
=========
The deletion process is done in that order:
1. The user go to his settings and ask Odoo to remove the data we have
2. Facebook will hit an endpoint in IAP, with a signature, and the Facebook user id
3. IAP will reach the database, (with a shared secret to authenticate itself) and that endpoint will remove the social accounts, and also the social posts / templates if the account is selected
We do it that way, instead of having a CRON on the client database, because we are able to know if the user uninstalled social, or if he already removed the account.
If the database is not reachable from the internet, we will have it's dbuuid, and so, we will be able to take an action.
Authentication
==============
IAP needs to authenticate to the Odoo database,
so both need to share a secret.
That secret can not be the extended token,
because we don't store it on the Odoo side.
That secret is derived from the database secret, and sent when we ask the Facebook URL (in python, without a browser redirection), so the social user can not see it (otherwise, he will be able to bypass company access rules, and delete the social accounts of different company).
Setup
=====
1. Start Odoo and IAP instances
2. Start ngrok on the IAP port
3. In the Facebook settings ("Facebook Login For Business" -> Settings)
- Add <ngrok_url>/api/social/facebook/1/callback in the Facebook settings
- Add <ngrok_url>/api/social_facebook/1/deletion_callback in the Facebook settings
4. Add the Facebook credentials in the IAP settings
5. In the Odoo db, add the system parameter `social.social_iap_endpoint` with the ngrok url
6. In the IAP db, change the system parameter `web.base.url` with the ngrok url
7. In the IAP code, in `facebook_controller.py`, comment the dbuid check `_check_has_access`
8. Add your accounts
9. Go to `https://www.facebook.com/settings/?tab=business_tools`, and remove the app
10. Go to the "Removed" tab, then "View Details" and click on "Send Request"
Task-4350697
Forward-Port-Of: odoo/enterprise#79992
Forward-Port-Of: odoo/enterprise#74865This commit improves the tool tip and the presentation of the quality control random view. When you set a quality point to "random" with a percentage of 20% and process a transfer of 100 units, it does not mean that exactly 20% of the transfer will be inspected. Instead, each unit has a 20% probability of being checked. For example, if you process ten transfers of 100 units each, you might get 18 quality checks in one transfer, 10 in another, 25 in the next, and so on. The key point is tha
Original PR description
This commit improves the tool tip and the presentation of the quality control random view. When you set a quality point to "random" with a percentage of 20% and process a transfer of 100 units, it does not mean that exactly 20% of the transfer will be inspected. Instead, each unit has a 20% probability of being checked. For example, if you process ten transfers of 100 units each, you might get 18 quality checks in one transfer, 10 in another, 25 in the next, and so on. The key point is that, statistically, approximately 20% of your total quantities will be inspected over multiple transfers. opw-4527413 Forward-Port-Of: odoo/enterprise#80884 Forward-Port-Of: odoo/enterprise#80482
Problem ---------- Missing account code "223100" for the SHIF Objective ---------- Add the new account code Forward-Port-Of: odoo/enterprise#81025
Original PR description
Problem ---------- Missing account code "223100" for the SHIF Objective ---------- Add the new account code Forward-Port-Of: odoo/enterprise#81025
This commit restores the position of the working schedule dropdown to be just below the label in the salary configurator, like in previous versions.  The cause of the issue is that the SelectMenuWrapper component is attached just after the invisible select element: https://github.com/odoo/enterprise/blob/9f6a4f0697edcc9330ad7976c6602d892e7b6ef9/hr_contract_salary/static/src/js/hr_contract_salary.js#L69-L71
Original PR description
This commit restores the position of the working schedule dropdown to be just below the label in the salary configurator, like in previous versions.…
This commit restores the position of the working schedule dropdown to be just below the label in the salary configurator, like in previous versions.  The cause of the issue is that the SelectMenuWrapper component is attached just after the invisible select element: https://github.com/odoo/enterprise/blob/9f6a4f0697edcc9330ad7976c6602d892e7b6ef9/hr_contract_salary/static/src/js/hr_contract_salary.js#L69-L71 But before other elements are placed in the DOM between them. A solution is to add a wrapper div around the selection, ensuring the `SelectMenuWrapper` component is attached inside that div, and further elements placed in the DOM after the wrapper div. **Steps to reproduce** - Install hr_contract_salary_payroll - Select any employee contract > Generate offer > Salary configurator - Add `part?=80` (any value != 100) at the end of URL opw-4496279 Forward-Port-Of: odoo/enterprise#79966
Versions: ----------- - 17.0 Steps to reproduce: ------------------------- - go to timesheet module - click on grid cell Issue: ------- The action helper in web grid was resulting in only the web content being displayed in the timesheet grid and so helper was missing Cause: --------- The action helper was being called from web_grid, causing a lack of content in the timesheet_grid. Solution: ----------- Create a dedicated function to retrieve the no-content helper, enhanc
Original PR description
Versions: ----------- - 17.0 Steps to reproduce: ------------------------- - go to timesheet module - click on grid cell Issue: ------- The action helper in web grid was resulting in only the web content being displayed in the timesheet grid and so helper was missing Cause: --------- The action helper was being called from web_grid, causing a lack of content in the timesheet_grid. Solution: ----------- Create a dedicated function to retrieve the no-content helper, enhancing portability for easy customization. task-3429403 Forward-Port-Of: odoo/enterprise#80784 Forward-Port-Of: odoo/enterprise#56158
Before this commit, the map view removed the routes after reordering the items. Now, the routes are kept and the path recalculated. task-4493063 Forward-Port-Of: odoo/enterprise#80359
Original PR description
Before this commit, the map view removed the routes after reordering the items. Now, the routes are kept and the path recalculated. task-4493063 Forward-Port-Of: odoo/enterprise#80359
Since odoo/enterprise#80074, the test `appointment status pill colors` randomly fails on runbot. The reasons are not clear yet, but to prevent that error from randomly popping on builds and potentially from slowing down the merge process, this commit simply reverts the changes to come back to the version of this test file as it was before odoo/enterprise#80074 Runbot error-159865 Forward-Port-Of: odoo/enterprise#81030
Original PR description
Since odoo/enterprise#80074, the test `appointment status pill colors` randomly fails on runbot. The reasons are not clear yet, but to prevent that error from randomly popping on builds and potentially from slowing down the merge process, this commit simply reverts the changes to come back to the version of this test file as it was before odoo/enterprise#80074 Runbot error-159865 Forward-Port-Of: odoo/enterprise#81030
Since 18.0, the name field of draft invoice is false instead of "/", this causes an issue in the name replace as we try to use the replace() method on a False boolean. Forward-Port-Of: odoo/enterprise#80922
Original PR description
Since 18.0, the name field of draft invoice is false instead of "/", this causes an issue in the name replace as we try to use the replace() method on a False boolean. Forward-Port-Of: odoo/enterprise#80922
This adds a new Belgian payroll module that lets companies export payroll data in a format supported by Acerta. It helps Belgian employers streamline payroll processing by reducing manual data preparation for their payroll provider.
Original PR description
Create a new module to export payroll data for Acerta. **NOTE during fw port I need to move the test for the other ss to the main test module** task-3750799
Enhancements to existing features
Opening the Replenishment view is now much faster in databases with many automatically triggered replenishment rules. The change avoids unnecessary calculations when there are no relevant manual replenishment records to clean up, reducing wait times significantly.
Original PR description
Issue --> When the Replenishment view is opened, the method `_unlink_processed_orderpoints` is called to remove previously automatically created orderpoints that have since been refilled. In this…
Issue -->
When the Replenishment view is opened, the method `_unlink_processed_orderpoints` is called to remove previously automatically created orderpoints that have since been refilled. In this method, the search domain contains `qty_to_order` which causes computations to fulfil the search query. The search_query also contains `("trigger", "=", "manual")`. Even if the recordset for this leaf is 0, the `qty_to_order` computations still occur, only to return 0 records in the search.
Solution -->
Move the `qty_to_order <= 0` check after the search produces a recordset for `("trigger", "=", "manual")`. This avoids unnecessary computations.
Benchmarks -->
For this benchmark, we'll assume the worst case, where every orderpoint on the database has trigger set to `auto`. The number of seconds represents the time taken to open the Replenishment view.
| # of auto trigger orderpoints | Before | After |
|--------|--------|--------|
| 12.2k | 155.58 s | 4.49 s |
| 6k | 59.87 s | 3.78 s |
opw-4606704HR teams can now import time off allocations that use accrual plans more reliably. When an accrual plan is provided, the allocation type is set automatically, and allocation duration values are compatible with export and import workflows.
Original PR description
Problem ---------- It is impossible to import batch of data with allocation_type set to 'accrual' and an allocation duration Objective ---------- - DO NOT make it possible by removing the readonly attribute on the allocation_type field - Allow the user to set directly an accrual plan and the allocation_type will be set automatically accordingly - Same fot the allocation duration make it importable Solution ---------- - Accrual plan : create an inverse, if accrual plan exists set allocation type to accrual else regular - Allocation duration, make an inverse to make it compatible export/import. It will parse the float value from the string. task-4521658
Resolved issues and error corrections
Product images in the catalog no longer show an unwanted rectangle underneath when dark mode is enabled. The image container now matches the photo size, keeping product cards cleaner and more polished for users.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable dark mode (requires `web_enterprise`); 2. go to Sale; 3. create a quotation; 4. open product catalog. Issue ----- There's a weird rectangle visible…
Versions -------- - 18.0+ Steps ----- 1. Enable dark mode (requires `web_enterprise`); 2. go to Sale; 3. create a quotation; 4. open product catalog. Issue ----- There's a weird rectangle visible below the product images:  Cause ----- Commit 5234fad374c9c adapted Odoo for darkmode. As part of it, it added a background color for image fields, which defaults to `#E4E4E4`. There is no background color defined for image fields in light mode. Commit f601823a19231 added kanban cards to supersede kanban boxes. Part of this is to style `.o_field_image > div` elements to have 100% height and width, filling up as much space as possible. Commit e8836b42200e3 changed the catalog kanban to use cards instead of boxes. As a consequence, the background color for image fields now gets used on the `div` containing the image, which is sized to fill up all of the available space. Normally this background color is invisible if the image is allowed to fill up all the avaialble space as well, but for the catalog, they get restricted to 55 by 55 px. Hence the `img` element has its `max-height` set to 55px while its parent `div` element has `height` set to `100%`, filling up all available space with no regard for the image size. Solution -------- Rather than basing size on the parent element, have the `div` size be based on the containing image via `fit-content`. This ensures the image background doesn't leak out of its intended element. opw-4499252
This fix prevents an error when a helpdesk user starts a return for a customer who has no delivered orders or pickup records. The system now checks that a pickup exists before reviewing its status, allowing the return flow to handle this case safely.
Original PR description
### Steps to reproduce: - Install the helpdesk module. - Enable the return option in the helpdesk team. - Create a new helpdesk ticket. - Add a customer with zero sales orders picked (i.e., no pickup is present, meaning no order has been delivered to that customer). - Click on return. ### Issue: - Traceback error ### Cause: - The system tries to check the pickup state even when no sales order has been delivered for the customer, meaning no pickup is generated. ### Solution: - First, check if any pickup is generated. - Only proceed to check the pickup state if a pickup exists. task-4522134 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change removes a now-unneeded customization in the store pickup area after a related update made it redundant. It helps keep the checkout code simpler and reduces the chance of future maintenance issues, with no expected change for customers.
Original PR description
After commit 2d4be3a1111451c67c69c016676c935be956c981 the override is no longer needed.
Product images in the catalog now display without an unwanted rectangle appearing underneath when dark mode is enabled. This improves the visual polish of quotations and product selection without changing business workflows.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable dark mode (requires `web_enterprise`); 2. create a quotation; 3. open product catalog. Issue ----- There's a weird rectangle visible below the images. Cause ----- Commit 5234fad374c9c adapted Odoo for darkmode. As part of it, it added a background color for image fields, which defaults to `#E4E4E4`. There is no background color defined for image fields in light mode. Commit e8836b42200e3 changed the catalog kanban to use cards instead of boxes. As a consequence, the background color for image fields now gets used on the `div` containing the image. Normally this background color is invisible, as the image overlaps the `div`, but because the catalog resizes images to 55px, the `div` is now taller than the image, revealing the element's background color. Solution -------- Add a `style="max-height: 55px;` attribute to the element to ensure its height corresponds to the image's. opw-4499252
This fix moves standard work schedule calculations into the core HR module so recruitment features can access them without requiring payroll. It prevents errors when posting or using recruitment integrations that need weekly hours or full-time status.
Original PR description
Currently, we are getting an attribute error while executing the below lines of code.…
Currently, we are getting an attribute error while executing the below lines of code. https://github.com/odoo/enterprise/blob/a0215115c13d5e32f1ba3c821f138b188083e76b/hr_recruitment_integration_monster/wizard/hr_recruitment_post.py#L16 https://github.com/odoo/enterprise/blob/a0215115c13d5e32f1ba3c821f138b188083e76b/hr_recruitment_integration_monster/wizard/hr_recruitment_post.py#L31 Error:- ``` AttributeError: 'resource.calendar' object has no attribute 'hours_per_week' ``` This is because the `hours_per_week`, `is_fulltime` are defined in the `hr_payroll`. But they are used in the `hr_recruitment_integration_monster`. Which is not dependent directly/indirectly on `hr_payroll`. https://github.com/odoo/enterprise/blob/a0215115c13d5e32f1ba3c821f138b188083e76b/hr_payroll/models/resource_calendar.py#L20-L21 So this will lead to the above traceback. We can resolve this issue by moving the hr_payroll code of calculating the `hours_per_week` and `is_fulltime` to hr module. sentry-6267814511 Related Enterprise PR:-https://github.com/odoo/enterprise/pull/78521
Marketing automation reports now show accurate rejected message counts when WhatsApp marketing is installed. This prevents valid email campaign statistics from being overwritten by WhatsApp-specific data, giving users more reliable campaign performance figures.
Original PR description
Currently, when `marketing_automation_whatsapp` is installed, marketing automation campaign statistics are not computed correctly. ### Steps to Reproduce 1. Install `marketing_automation_whatsapp`.…
Currently, when `marketing_automation_whatsapp` is installed, marketing automation campaign statistics are not computed correctly. ### Steps to Reproduce 1. Install `marketing_automation_whatsapp`. 2. Create a marketing automation campaign with an email activity. 3. Ensure one or more traces are rejected (e.g., by using invalid email addresses). 4. View the activity statistics. Expected Result: The rejected count on the right correctly displays the number of rejected traces. Actual Result: The rejected count on the right always displays `0`, even when rejected traces exist. ### Cause The `marketing_automation_whatsapp` module overrides `_get_full_statistics` to include WhatsApp-related statistics in addition to the marketing data. However, the override currently concatenates the results from the base `_get_full_statistics` and the WhatsApp-specific statistics. And because `MarketingActivity._compute_statistics` doesn't expect `_get_full_statistics` to return multiple entries for a given `activity_id`, the values from the WhatsApp-specific results end up overwriting the base values. opw-4292488 opw-4523885 opw-4585705 opw-4585779
This fixes leave allocation creation so the correct day or hour amount is used based on the leave type. It helps ensure employee leave balances are calculated and displayed accurately, especially for leave managed in hours.
Original PR description
Problem ---------- wrong behaviour with the number_of_days_display / number_of_hours_display / number_of_days : Objective ---------- Fix the TestHR.test_flow : in the creation of leave allocation. Only number_of_days_display can have a value. But with a leave_type.request_unit = 'hour', number_of_hours_display should be used Solution ---------- Depends on the visibility of number_of_days_display and number_of_hours_display, put the value in the good field task-4521658
Subscription credit notes now use the proper credit note email template instead of the standard invoice template. This helps customers receive clearer, more accurate communications when invoices are reversed.
Original PR description
## Problem When reversing an invoice and making a credit note on a subscription, the email template was still "Invoice: Sending" instead of choosing the credit note template "Credit Note: Sending". The condition on the following code was always True, meaning the super method, that is used to decide which template to take in case of a credit note, was never called. https://github.com/odoo/enterprise/blob/eb1eff85d2119a34997067fedb602e963a5d6f02/sale_subscription/models/account_move_send.py#L9-L14 ## Steps to reproduce - Take an invoice created through a subscription, reverse it (credit note action) - Try to send it - See that the email template is "Invoice: Sending" and not "Credit Note: Sending" ## Fix A condition was added to differentiate an invoice from a credit note. opw-4455155
This fixes an issue where copying a document folder or document structure did not correctly update ownership on its child items. The change helps keep access and accountability consistent when teams duplicate document hierarchies.
Original PR description
Backport of 8d613a60, forward port of 3ad8bf85 where we forgot about these children. Task-4593290
This fix prevents an error when preparing job posting data for Monster recruitment integration in setups that do not use payroll. It ensures working time information is available from the HR module, improving reliability for recruitment workflows.
Original PR description
Currently, we are getting an attribute error while executing the below lines of code.…
Currently, we are getting an attribute error while executing the below lines of code. https://github.com/odoo/enterprise/blob/a0215115c13d5e32f1ba3c821f138b188083e76b/hr_recruitment_integration_monster/wizard/hr_recruitment_post.py#L16 https://github.com/odoo/enterprise/blob/a0215115c13d5e32f1ba3c821f138b188083e76b/hr_recruitment_integration_monster/wizard/hr_recruitment_post.py#L31 Error:- ``` AttributeError: 'resource.calendar' object has no attribute 'hours_per_week' ``` This is because the `hours_per_week`, `is_fulltime` is defined in `hr_payroll`. But it is used in `hr_recruitment_integration_monster`. Which is not dependent directly/indirectly on `hr_payroll`. https://github.com/odoo/enterprise/blob/a0215115c13d5e32f1ba3c821f138b188083e76b/hr_payroll/models/resource_calendar.py#L20-L21 So this will lead to the above traceback. We can resolve this issue by moving the hr_payroll code of calculating the `hours_per_week` and `is_fulltime` to the hr module. sentry-6267814511 Related Community PR:- https://github.com/odoo/odoo/pull/196427
Miscellaneous changes
### Description of the issue/feature this PR addresses: If someone creates an invoice after 9 pm Argentina time, if the invoice is created automatically, then it is created with the date of the next day (UTC date) instead of today. This causes problems validating invoices in ARCA (ex AFIP), since when generating the invoice with the next day's date, no more invoices could be generated with today's date. ### Current behavior before PR: 1. Make e-commerce sales after 9 PM local time AR in
Original PR description
### Description of the issue/feature this PR addresses: If someone creates an invoice after 9 pm Argentina time, if the invoice is created automatically, then it is created with the date of the next…
### Description of the issue/feature this PR addresses: If someone creates an invoice after 9 pm Argentina time, if the invoice is created automatically, then it is created with the date of the next day (UTC date) instead of today. This causes problems validating invoices in ARCA (ex AFIP), since when generating the invoice with the next day's date, no more invoices could be generated with today's date. ### Current behavior before PR: 1. Make e-commerce sales after 9 PM local time AR in a website set as automatic invoicing = True (journal by default it is an electronic journal) 2. Try to generate another invoice after that day, A simple way to test it is to make an invoice and then validate it. 3. We will receive ARCA (ex-AFIP) error telling us that we can not generate the invoice with today's date, we can only validate invoices with a date equal to or greater than tomorrow. ### Desired behavior after PR is merged: 1. Make e-commerce sales after 9 PM local time AR in a website set as automatic invoicing = True (journal by default it is an electronic journal) 2. Try to generate another invoice after that day, A simple way to test it is to make an invoice and then validate it. 3. Manual invoice will be generated and validated in AFIP with today's date as the invoice date. NOTE: We took the same approach that was used in the [POS module](https://github.com/odoo/odoo/blob/16.0/addons/point_of_sale/models/pos_order.py#L615-L631) to set the date, in this case, always forcing the Argentina timezone --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192808
maxmind decided to remove support for `raw_response` and chhange the API of Country/City to take all the raw_response components by keywords instead (maxmind/GeoIP2-python@4518919151e1b39bd544df653b41cd155dc2f708). This leads to location mocking not working anymore, which leads to the failure of `:TestWebsiteSaleCart.test_cart_new_fpos_from_geoip` when using geoip2 5.0. When mocking the request with a country code set, just try the new API then fallback on the old one (note: the commit also
Original PR description
maxmind decided to remove support for `raw_response` and chhange the API of Country/City to take all the raw_response components by keywords instead (maxmind/GeoIP2-python@4518919151e1b39bd544df653b41cd155dc2f708). This leads to location mocking not working anymore, which leads to the failure of `:TestWebsiteSaleCart.test_cart_new_fpos_from_geoip` when using geoip2 5.0. When mocking the request with a country code set, just try the new API then fallback on the old one (note: the commit also removes the `locales` default fallback, so make that explicit). Forward-Port-Of: odoo/odoo#200980
Normally a `date` and a `datetime` compare `False`. For some reason however a `datetime` and a `freezegun.api.FakeDate` compare equal as long as the datetime's date part matches the fakedate's... until Python 3.13, when it stop working. I've no idea why it ever worked, but it's completely unnecessary, we can just get the reference datetime's `date()` part and compare that to the date. upstream issue: spulec/freezegun#568 Forward-Port-Of: odoo/odoo#200978
Original PR description
Normally a `date` and a `datetime` compare `False`. For some reason however a `datetime` and a `freezegun.api.FakeDate` compare equal as long as the datetime's date part matches the fakedate's... until Python 3.13, when it stop working. I've no idea why it ever worked, but it's completely unnecessary, we can just get the reference datetime's `date()` part and compare that to the date. upstream issue: spulec/freezegun#568 Forward-Port-Of: odoo/odoo#200978
In order to be created, virtual operators like "is", "not_set" need field definitions to be known. It turns out that in sub trees corresponding to sub domains for any/not_any operators), the virtual operators are not created because: - the option getFieldDef is not passed when constructing sub trees - the getFieldDef function does not collect info on paths in sub trees. Here we solve each problem so that when modifying the tree in some way all virtual operators are restored correctly. For i
Original PR description
In order to be created, virtual operators like "is", "not_set" need field definitions to be known. It turns out that in sub trees corresponding to sub domains for any/not_any operators), the virtual operators are not created because: - the option getFieldDef is not passed when constructing sub trees - the getFieldDef function does not collect info on paths in sub trees. Here we solve each problem so that when modifying the tree in some way all virtual operators are restored correctly. For instance if a condition involving a boolean field like "Active is not set" is found in a sub tree, and a condition is added/removed elsewhere, the above condition will remain the same and not become "Active = False". Forward-Port-Of: odoo/odoo#200592
Description of the issue/feature this PR addresses: Spurious log entries Current behavior before PR: Odoo [logs](https://github.com/odoo/odoo/blob/17.0/odoo/modules/registry.py#L653-L654) indexes created by [_sync_plan_column](https://github.com/odoo/odoo/blob/17.0/addons/analytic/models/analytic_plan.py#L281) as unexpected Desired behavior after PR is merged: No log entry for expected index Steps to reproduce: - create a new analytic plan, ie 'Test plan' - go to technical/database
Original PR description
Description of the issue/feature this PR addresses: Spurious log entries Current behavior before PR: Odoo [logs](https://github.com/odoo/odoo/blob/17.0/odoo/modules/registry.py#L653-L654) indexes…
Description of the issue/feature this PR addresses: Spurious log entries
Current behavior before PR: Odoo [logs](https://github.com/odoo/odoo/blob/17.0/odoo/modules/registry.py#L653-L654) indexes created by [_sync_plan_column](https://github.com/odoo/odoo/blob/17.0/addons/analytic/models/analytic_plan.py#L281) as unexpected
Desired behavior after PR is merged: No log entry for expected index
Steps to reproduce:
- create a new analytic plan, ie 'Test plan'
- go to technical/database structure/fields, search for the custom field created on model account.analytic.line, named `x_plan{the id of the plan you created in step 1}_id`
- observe the field is not marked as indexed, even though the code creates an index
- update the analytic module, observe there will be an entry of the form `Keep unexpected index account_analytic_line__x_plan{the id of the plan you created in step 1}_id_index on table account_analytic_line`
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#200764
Forward-Port-Of: odoo/odoo#189240Issue: ----- This issue happens in mobile view only. When a user without any HR access rights tries to assign an Employee to a piece of equipment, they don't see the list of employees as expected. Instead, they get a "No records found!" message. Steps to reproduce: ----- - Install Employees & Maintenance apps - Create a new user and set the following acces rights - Employees -> None - Switch to that user - Go to Maintenance -> Equipment and select an equipment - Ensure the page
Original PR description
Issue: ----- This issue happens in mobile view only. When a user without any HR access rights tries to assign an Employee to a piece of equipment, they don't see the list of employees as expected.…
Issue:
-----
This issue happens in mobile view only. When a user without any HR access rights
tries to assign an Employee to a piece of equipment, they don't see the list of
employees as expected. Instead, they get a "No records found!" message.
Steps to reproduce:
-----
- Install Employees & Maintenance apps
- Create a new user and set the following acces rights
- Employees -> None
- Switch to that user
- Go to Maintenance -> Equipment and select an equipment
- Ensure the page is in mobile display mode (refresh if not already in mode)
- Select an equipment & try to assign an Employee
-> The widget displays a "No records found!" message
Other issue discovered:
-----
There is also a problem for the department field, where the user has access to
the field when in desktop mode but gets an "Access error" in mobile mode.
Cause:
-----
The equipment model stores the owner by referencing a hr.employee. Depending on
the display type, the user will get a simple dropdown list in desktop mode or a
kanban view in mobile mode.
When the kanban view is loaded in mobile mode, since the user does not have read
access to the hr.employee model, the ORM tries to load from the cache. Since it
doesn't find the content of a field (avatar_128 here) in the cache, it clears
the whole record, leading to the "No records found!" message. The hr team has a
workaround for this issue in the form of a custom many2one widget for employee
avatars.
Ticket:
opw-4309746
Forward-Port-Of: odoo/odoo#195718- disable duplicate for interviewer_ids - add `(copy)` to the name Task: 4606811 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199935
Original PR description
- disable duplicate for interviewer_ids - add `(copy)` to the name Task: 4606811 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199935
### Steps to reproduce: - Create a manufacturing order - Navigate to the Miscellaneous tab and add an Analytic Distribution - Add a component to the manufacturing order with the quantity set to 10000, for example - Produce the manufacturing order - Navigate to the analytic account line associated with the stock move with 10000 units - Update the analytic account line’s date to be in the previous week - Navigate to Timesheets > Timesheets > All Timesheets and then navigate to the pr
Original PR description
### Steps to reproduce: - Create a manufacturing order - Navigate to the Miscellaneous tab and add an Analytic Distribution - Add a component to the manufacturing order with the quantity set to…
### Steps to reproduce: - Create a manufacturing order - Navigate to the Miscellaneous tab and add an Analytic Distribution - Add a component to the manufacturing order with the quantity set to 10000, for example - Produce the manufacturing order - Navigate to the analytic account line associated with the stock move with 10000 units - Update the analytic account line’s date to be in the previous week - Navigate to Timesheets > Timesheets > All Timesheets and then navigate to the previous week - Observe that your user has worked a very large amount of overtime ### Cause: This is happening because for MO when creating an analytic line in some cases we store the unit_amount as the quantity of the materials used. https://github.com/odoo/odoo/blob/ee7fbcb759fd8257ed2f52d1d5acfc6921d42870/addons/stock_account/models/stock_move.py#L437-L438 And when fetching the worked hours for the overtime indication we don't check if the analytic line is a timesheet or not https://github.com/odoo/enterprise/blob/ca935872fd70b9fc5b2d13359424916b3afa01eb/timesheet_grid/models/hr_employee.py#L120-L126 https://github.com/odoo/enterprise/blob/ca935872fd70b9fc5b2d13359424916b3afa01eb/timesheet_grid_holidays/models/hr_employee.py#L10-L16 ### Fix: Since we are only fetching timesheets so we will check if the project is set or not as if it is set it means that the record is a timesheet opw-4179137 Forward-Port-Of: odoo/enterprise#81026
Version: - 17.0 Steps to reproduce: - Create subscription order. - Add one product with an "Order-Based" invoice policy and another with a "Delivery-Based" invoice policy. - Create one downpayment invoice and cancel it. - Click on "Create Invoice" button. Issue: - The 'Already Invoiced' amount is calculated incorrectly. Cause: - The issue occurs because the system calculates `amount_invoiced` by subtracting `amount_to_invoice` from `amount_total`. For delivery-based products tha
Original PR description
Version: - 17.0 Steps to reproduce: - Create subscription order. - Add one product with an "Order-Based" invoice policy and another with a "Delivery-Based" invoice policy. - Create one downpayment…
Version: - 17.0 Steps to reproduce: - Create subscription order. - Add one product with an "Order-Based" invoice policy and another with a "Delivery-Based" invoice policy. - Create one downpayment invoice and cancel it. - Click on "Create Invoice" button. Issue: - The 'Already Invoiced' amount is calculated incorrectly. Cause: - The issue occurs because the system calculates `amount_invoiced` by subtracting `amount_to_invoice` from `amount_total`. For delivery-based products that are not yet delivered, their amounts are not included in `amount_to_invoice`. As a result, only the order-based product's amount is considered, leading to incorrect calculations of `amount_invoiced`. Solution: - For subscription order calculate the `amount_invoiced` based on the amounts of order-based policy products and For delivery-based products, include only the amounts corresponding to delivered quantities and avoid subtracting it from `amount_total`. task-4453645 Forward-Port-Of: odoo/enterprise#81046 Forward-Port-Of: odoo/enterprise#76869
Before this commit, the map view removed the routes after reordering the items. Now, the routes are kept and the path recalculated. task-4493063 Forward-Port-Of: odoo/enterprise#80359
Original PR description
Before this commit, the map view removed the routes after reordering the items. Now, the routes are kept and the path recalculated. task-4493063 Forward-Port-Of: odoo/enterprise#80359