Daily updates from Odoo
Navigate
Branch
Tuesday, May 14, 2024
63 changes
1 change
Miscellaneous changes
Allow pos users to have the "internal note" button available even in non-restaurant shops. Task-ID: 3878947 **Before:** Internal note button is only for restaurant. <img width="1800" alt="Screenshot 2024-04-22 at 15 56 44" src="https://github.com/odoo/odoo/assets/3245568/b923a1f5-e7fe-4a8a-b624-c0c31135c4fb"> **After:** <img width="1800" alt="Screenshot 2024-04-22 at 15 55 28" src="https://github.com/odoo/odoo/assets/3245568/fc82f296-7598-46b7-bbe0-0eb199872515"> Forward-Port-Of:
Original PR description
Allow pos users to have the "internal note" button available even in non-restaurant shops. Task-ID: 3878947 **Before:** Internal note button is only for restaurant. <img width="1800" alt="Screenshot 2024-04-22 at 15 56 44" src="https://github.com/odoo/odoo/assets/3245568/b923a1f5-e7fe-4a8a-b624-c0c31135c4fb"> **After:** <img width="1800" alt="Screenshot 2024-04-22 at 15 55 28" src="https://github.com/odoo/odoo/assets/3245568/fc82f296-7598-46b7-bbe0-0eb199872515"> Forward-Port-Of: odoo/odoo#163355 Forward-Port-Of: odoo/odoo#162863
26 changes
New functionality added to Odoo
Field service teams can now mark task-related products as under warranty. When enabled, the related sale item is automatically priced at zero, helping ensure warranty work is not billed to customers by mistake.
Original PR description
In this commit, we introduce the functionality to activate the "under warranty" feature for tasks within the industry_fsm_sale module. When this feature is enabled for a task, the sale item price is automatically set to zero, indicating the warranty status. task-3784174
Enhancements to existing features
Approval product selection now defaults to items that can be purchased instead of items that can be sold. This better matches how most approval requests use products, making it faster for users to find the relevant purchase-related items.
Original PR description
Before this commit the default filter on the product form of approval was 'Can be Sold'. But in approvals, majority users uses purchase related products. This commit adds the default filter of 'Can be Purchased' on the products and products variants form of approval. Same default filter is also applied on more product list for selecting products for approval request. task-3633895
Planning shift forms are easier to use, with a clearer Save Template action and repeat options placed near the shift dates. The planning workflow also opens the correct form when creating a new shift from the sales planning dialog, reducing confusion for users.
Original PR description
- following improvement made in this PR:
- Instead of saving template on boolean field add a 'save template' button to the planning slot form view.
- move the 'repeat' field under the date with boolean icon fa-repeat.
- update test tour with 'mitchell' as it is already considering user timezone
first when calculating start and end time in `_calculate_start_end_dates`.
task-3636218The rental eCommerce module was adjusted to stay aligned with recent changes in the main website and sales platform. This helps keep rental product snippets and related website content working consistently after the broader platform update.
Original PR description
See also odoo/odoo#154632
The website sales dashboard tests were updated to match a related change where the old sales onboarding flow was removed and replaced. This keeps validation aligned with the current experience and helps prevent false test failures during future releases.
Original PR description
This PR include the following changes: - Remove the configuration bar. task-3645924 COM PR: odoo/odoo#152270 ENT PR: odoo/enterprise#61325 UPG PR: odoo/upgrade#5644 DOC PR: odoo/documentation#8391
Managers can now request appraisals for employees anywhere below them in their reporting hierarchy, not just direct reports. This makes the appraisal process more flexible for senior managers and avoids unnecessary errors when managing broader teams.
Original PR description
The system now allows for creating appraisals for individuals even if you're not their direct manager but are in their managerial hierarchy. For instance, if A is the manager of B, and B is the manager of C, A can request an appraisal for C. Previously, this resulted in an error because only direct managers could create an appraisal.
Polish financial reports have been updated to match the latest Polish chart of accounts and account groups. This makes the reports more relevant and usable for companies relying on Polish accounting standards.
Original PR description
Currently, the polish chart of account is not up to date and is therefore underused by user since it is not relevant. This PR goes with a community PR which goal is to update the chart of accounts and account groups. Because of this change, financial reports have to be updated too so they match the new chart. Adding this, the financial reports should be relevant and match the new chart of accounts. Community PR : [odoo/odoo#130538](https://github.com/odoo/odoo/pull/130538) task-3332731
Odoo now checks that a bank journal currency matches the linked bank account currency before importing transactions. If the journal is empty it can update the journal currency automatically, while journals with existing entries are blocked from importing mismatched transactions to prevent incorrect amounts; the reconciliation view also avoids an error when currency data is missing.
Original PR description
Previously, when you sync a bank journal with a bank account that have different currency, odoo will import all the transaction with the amount of the bank account, but in the currency of the…
Previously, when you sync a bank journal with a bank account that have different currency, odoo will import all the transaction with the amount of the bank account, but in the currency of the journal. For example: when importing 500 USD from the bank account to an IDR journal, it will become 500 IDR. This behavior also gets a bit weirder because the code checks the currency of the bank with the company (which should be unrelated here). This commit aims to fix that, and establish these new behaviors: - The currency of the company is irrelevant. Only the journal matters. (because a journal can have different currency than the company's) - If the journal currency has a mismatch with the bank account's: - If there's no existing entries in the journal, re-assign the journal's currency to the bank account's currency - If there's existing entries, prevent the import process from happening to prevent the mentioned weird behaviors. related community-PR: https://github.com/odoo/odoo/pull/162235 task-id: 3798134
Knowledge articles now show their place in the article hierarchy directly in the top bar, replacing generic breadcrumbs. Users can more easily understand where an article sits, jump to related parent articles, and move back and forward through recently opened articles, while less-used article setup actions are grouped under more options to save space.
Original PR description
Purpose: -------- Instead of showing the general breadcrumbs, the form view of knowledge now displays the current article's hierarchy. This makes it easier for users to jump to articles (no need to look for the parent in the sidebar anymore) and to have more context about the current article. Two new buttons on the left of the hierarchy allow the user to jump back to previously opened articles, as well as to the previous action when applicable (like clicking on the previous breadcrumb item if any). The "add icon", "add cover" and "add properties" buttons are moved in the "more options" panel to save space as the breadcrumbs and hierarchy may take a lot of space in the topbar. See underlying commits for more details. Task-3790413
Payroll now avoids sending an extra profile-update notification to the HR responsible person when employee self-editing is enabled. This keeps notifications cleaner by ensuring the same person receives only one relevant message.
Original PR description
While employee editing is allowed through the settings, HR responsible will receive a notification when an employee updates his/her profile information In this commit, When HR responsible is present in the users to notify while employee editing It won't send this other notification to the HR responsible This way only one notification will be sent to the users task-3642351
Financial report filters have been simplified to make reports easier to configure and use. The update also touches budget-related report controls, helping users work more efficiently when reviewing financial information.
Resolved issues and error corrections
Appointment bookings linked to Google or Microsoft calendars will no longer send extra cancellation or update emails when the calendar provider already notifies attendees. This reduces duplicate messages and gives customers a cleaner booking communication experience.
Original PR description
There is now a method on calendar to know whether a notification email should be sent to attendees. We use it for appointment too to avoid sending updates to users who will already be alerted via the calendar provider (google/microsoft) when syncing the event.
Features or functions removed from Odoo
Unneeded access rules in the Approvals app were removed because the same permissions are already handled by an existing rule. This reduces duplication and helps keep access management easier to maintain without changing normal user workflows.
Original PR description
This will remove unnecessary access rules as they are already covered by another rule. Task: 3786622
The point-of-sale IoT customer display code was cleaned up after the customer display was moved into its own dedicated app. This reduces duplicated functionality and helps keep the point-of-sale IoT module easier to maintain without changing the intended customer experience.
Original PR description
In the corresponding community commit we refactor the customer display into it's own module. In this commit we remove the code that is no longer needed, because it is replaced by said customer display module
Appointment publishing can no longer be managed from the backend form or Kanban views. This simplifies the backend interface and helps ensure publishing is handled through the intended website flow.
Original PR description
This PR removes the functionality of publishing the appointment from the backend. - Remove the publish unpublish button from the appointment.type form view. - Remove the publish toggle button from Kanban cards. Task-3905167
Miscellaneous changes
Check Report Summary line columns were not aligned correctly, fixing it to have partner_name at the beginning, date at the middle, and check sequence number at the end of the line. task id: 3708433 Forward-Port-Of: odoo/enterprise#61149
Original PR description
Check Report Summary line columns were not aligned correctly, fixing it to have partner_name at the beginning, date at the middle, and check sequence number at the end of the line. task id: 3708433 Forward-Port-Of: odoo/enterprise#61149
Currently, when a warning is displayed on the progress bar, the hours overlap with the name of the line. This PR will fix it by adding the class 'bg-view' to the span. task-3888502 Forward-Port-Of: odoo/enterprise#61365
Original PR description
Currently, when a warning is displayed on the progress bar, the hours overlap with the name of the line. This PR will fix it by adding the class 'bg-view' to the span. task-3888502 Forward-Port-Of: odoo/enterprise#61365
In this commit [1], we changed the way we display intrastat report lines by grouping them. We did it for all the intrastat report, it was wrong. Actually, we should only do it for the belgian report. The aim of this commit is adding a key in options to know if lines should be grouped or not. By default the option is set to False except for the Belgian report. Since version 16.4, users can change the value by using the filter. task-3892823 [1]: https://github.com/odoo/enterprise/commit/217
Original PR description
In this commit [1], we changed the way we display intrastat report lines by grouping them. We did it for all the intrastat report, it was wrong. Actually, we should only do it for the belgian report. The aim of this commit is adding a key in options to know if lines should be grouped or not. By default the option is set to False except for the Belgian report. Since version 16.4, users can change the value by using the filter. task-3892823 [1]: https://github.com/odoo/enterprise/commit/217594fe8ba00329b3eb5c68e3eca3b556127cde Forward-Port-Of: odoo/enterprise#61783 Forward-Port-Of: odoo/enterprise#61455
The `use_create_components_lots` option of manufacturing picking type was never read as the context to get the active production order was not always specified. Forward-Port-Of: odoo/enterprise#61267 Forward-Port-Of: odoo/enterprise#61137
Original PR description
The `use_create_components_lots` option of manufacturing picking type was never read as the context to get the active production order was not always specified. Forward-Port-Of: odoo/enterprise#61267 Forward-Port-Of: odoo/enterprise#61137
This will add the previous year occupation to the double holiday computation. Task: 3893810 Forward-Port-Of: odoo/enterprise#61862
Original PR description
This will add the previous year occupation to the double holiday computation. Task: 3893810 Forward-Port-Of: odoo/enterprise#61862
As packages amount on customer locations side could be huge, don't retrieve those packages as they are not needed. @svs-odoo @Aurelienvd Forward-Port-Of: odoo/enterprise#59473
Original PR description
As packages amount on customer locations side could be huge, don't retrieve those packages as they are not needed. @svs-odoo @Aurelienvd Forward-Port-Of: odoo/enterprise#59473
part of task-3818666 Forward-Port-Of: odoo/enterprise#62350
Original PR description
part of task-3818666 Forward-Port-Of: odoo/enterprise#62350
Before this commit, when having opposite tax grid the domain of the journal_report_tax_tag_template_open_aml function was wrong. In case of opposite tax grid we should have put a list of tax_grid in the tag_id key which wasn't the case. It was only taking the last one since it was overridden in the next iteration of the loop. task-3869482 Forward-Port-Of: odoo/enterprise#62340 Forward-Port-Of: odoo/enterprise#61302
Original PR description
Before this commit, when having opposite tax grid the domain of the journal_report_tax_tag_template_open_aml function was wrong. In case of opposite tax grid we should have put a list of tax_grid in the tag_id key which wasn't the case. It was only taking the last one since it was overridden in the next iteration of the loop. task-3869482 Forward-Port-Of: odoo/enterprise#62340 Forward-Port-Of: odoo/enterprise#61302
Ensuring TZ allows to avoid issues in no-demo mode, notably when a timezone is required in sub records, like appointment types. Runbot-60487 Forward-Port-Of: odoo/enterprise#62061
Original PR description
Ensuring TZ allows to avoid issues in no-demo mode, notably when a timezone is required in sub records, like appointment types. Runbot-60487 Forward-Port-Of: odoo/enterprise#62061
Issue: --------- When a user lacks access to employee and setting permissions, the resource image does not appear. Fix: -------- We used the `hr.employee.public` model instead of `hr.employee` because everyone can access this one. Steps: --------- - Install the planning app - Create a user with planning user access, without employee and setting access - Create a Test employee(Test) - Create a shift and assign it to Test - Log in as the planning user
Original PR description
Issue: --------- When a user lacks access to employee and setting permissions, the resource image does not appear. Fix: -------- We used the `hr.employee.public` model instead of `hr.employee` because everyone can access this one. Steps: --------- - Install the planning app - Create a user with planning user access, without employee and setting access - Create a Test employee(Test) - Create a shift and assign it to Test - Log in as the planning user - Open planning and group by department Forward-Port-Of: odoo/enterprise#62251
[IMP] account_online_synchronization: populate swift/bic in journals Swift_code/BIC is already being returned by bank connection with odoofin accounts api We already populate the rest of the journals' details. So, We populate the swift/bic and link it with the journals Reason: Improve the user-experience Task-3891695 odoofin-pr: https://github.com/odoo/odoofin/pull/273 Forward-Port-Of: odoo/enterprise#61639
Original PR description
[IMP] account_online_synchronization: populate swift/bic in journals Swift_code/BIC is already being returned by bank connection with odoofin accounts api We already populate the rest of the journals' details. So, We populate the swift/bic and link it with the journals Reason: Improve the user-experience Task-3891695 odoofin-pr: https://github.com/odoo/odoofin/pull/273 Forward-Port-Of: odoo/enterprise#61639
36 changes
New functionality added to Odoo
This update adds balance sheet and profit and loss financial reports for Malta, enabling businesses operating in Malta to generate compliant financial statements. These reports are now available in the system for use in financial reporting and analysis.
Original PR description
Backport of: https://github.com/odoo/enterprise/pull/53580 This commit will add the balance sheet and profit and loss of the malta. task: 3627705
This update adds complete localization support for Malta, including the chart of accounts, tax configurations, default business settings, tax reporting, and fiscal position rules. This enables Odoo users in Malta to operate with proper local compliance and accounting standards out of the box.
Original PR description
Backport of: https://github.com/odoo/odoo/pull/147902 This commit will add the basic package of the malta localisation. - COA - Taxes - Default settings - Tax report - Fiscal position task: 3627705 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
The barcode scanning system has been optimized to stop retrieving package information from customer locations, which can be very large and unnecessary for operations. This improvement reduces system load and speeds up barcode scanning processes without affecting functionality.
Original PR description
As packages amount on customer locations side could be huge, don't retrieve those packages as they are not needed. @svs-odoo @Aurelienvd Forward-Port-Of: odoo/enterprise#59473
This update removes the validation restriction that prevented users from creating multiple bills with the same reference number. This change improves the user experience by eliminating a frustrating limitation that doesn't align with real-world business scenarios where duplicate reference numbers may be necessary or unavoidable.
Original PR description
[REM] account: remove validation on bills ref Remove validation on bills ref and allow users to have multiple bills with same ref Reason: improve user experience with the system as it's a pain for them in a real life senario Task-3869240 odoo-pr: https://github.com/odoo/odoo/pull/161995
This update allows users to apply text animations and text highlights while translating website content, improving the translation workflow. Previously, these text formatting options were disabled during translation mode, limiting what translators could do. Now translators have full access to text styling features without switching modes.
Original PR description
The goal of this PR is to simply disable the "Text Animation" button from the editor's toolbar in translate mode. An adaptation of code in stable `17.0` will be added to allow the use of text options (text animations & text highlights) in the translation mode, mainly by allowing the creation of snippet editors if the target is a text option snippet. opw-3686777 Forward-Port-Of: odoo/odoo#157726 Forward-Port-Of: odoo/odoo#157087
The system now allows multiple bills to have the same reference number. This change removes a validation restriction that was causing inconvenience for users in real-world scenarios where duplicate bill references are common or necessary.
Original PR description
[REM] account: remove validation on bills ref Remove validation on bills ref and allow users to have multiple bills with same ref Reason: improve user experience with the system as it's a pain for them in a real life senario Task-3869240 enterprise-PR#https://github.com/odoo/enterprise/pull/62395 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes how fixed taxes are displayed on Point of Sale receipts. Previously, all taxes showed a percentage symbol (%), but fixed taxes are not percentages—they're flat amounts. The change removes the incorrect % symbol for fixed taxes and improves the layout by displaying the tax name alongside the amount for better clarity.
Original PR description
Before this commit, the `point_of_sale.OrderReceipt` template would always print taxes followed by a % symbol. This should not be so for fixed taxes, whose amount is not a percentage. This commit removes the % symbol after fixed taxes. As an improvement it also displays the tax name in the first column, since the tax amount is already displayed in the following column. No task. 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
Resolved issues and error corrections
This fix ensures that inventory storage location rules (putaway strategies) are properly applied when receiving goods in inter-company transactions. Previously, when a delivery was confirmed in one company, the storage location rules set up in the receiving company were being ignored, causing items to be placed in the wrong warehouse location. This fix restores the correct application of these rules during the receiving process.
Original PR description
### Steps to reproduce: With company 1: - Go to the General Settings and activate: 1) Inter-Company Transactions: - "Synchronize Sales and Purchase Order" - "Automatic Validation" - "Copy Lots on…
### Steps to reproduce:
With company 1:
- Go to the General Settings and activate:
1) Inter-Company Transactions:
- "Synchronize Sales and Purchase Order"
- "Automatic Validation"
- "Copy Lots on Delivery Validation"
2) Multi-Step Routes
- Go to Inventory > Configuration > Warehouse Management > Locations
- Create a new Location SHELF with COMP1/STOCK as parent
- Go to Inventory > Configuration > Warehouse Management > Putaway Rules
- Create a new putaway rule applicable to all products from COMP2/STOCK to COMP2/STOCK/SHELF
With company 2:
- Create a storable product tracked by a Unique Serial Number
- Click on "On Hand" > Register 1 on hand qty with a new serial Number
- Create and confirm an SO for company 2 with your product
At this point, if you go to company 1:
A purchase order related to the SO was created and confirmed. If you open the related delivery and inspect the related stock move line the destination, it will correctly be set to COMP1/STOCK/SHELF.
With company 2:
- Open the delivery linked to your SO click on the list icon of you stock move line
- Add a stock picking referencing the serial number you created
- Validate the delivery
If you go to company 1, the move line is now attached with a serial number but the destination is set to set to COMP1/STOCK.
#### > The putaway rule is not applied anymore
### Cause of the issue:
When you confirmed the SO with company 2, it will create an PO in company 1:
https://github.com/odoo/enterprise/blob/3190d36192def6c63c254e16e754b12353a865e6/sale_purchase_inter_company_rules/models/sale_order.py#L22 and a related stock move will then be created. During the "_action_confirm" of this stock move the putaway rules will be applied to the stock move lines a few lines after creation: https://github.com/odoo/odoo/blob/58fefc94ca39f7951392063921fe9b5e606178e6/addons/stock/models/stock_move.py#L1720 When you confirm the delivery, this correclty set stock move line will be deleted and a new one will be created:
https://github.com/odoo/enterprise/blob/3190d36192def6c63c254e16e754b12353a865e6/sale_purchase_inter_company_rules/models/stock_picking.py#L30-L33 However, as the "apply_putaway_strategy" method is not called after the creation of this newly created stock move line, the destination of the line will entirly be set by the destination of the stock move: https://github.com/odoo/odoo/blob/42b760c8fa27cfc75fcb2fd5b232defc9002e85f/addons/stock/models/stock_move.py#L1441 so that the put away rules will not be applied anymore.
opw-3744375This fix removes overly strict validation rules for NSSF (National Social Security Fund) numbers in Kenya's payroll system. The system now accepts NSSF numbers in various formats that exist in real-world scenarios, such as numbers with letters or different digit patterns, making the system more flexible and practical for actual business use.
Original PR description
the nssf number restriction should not be apply given the real world scenario where the number can be in other format (eg 000000000x) task-3908312
This update fixes a bug in the Kenya payroll module that was preventing tax deduction cards from being generated as PDF documents correctly. The fix ensures that employees in Kenya can properly generate and access their tax deduction card documents, which are important for tax compliance and record-keeping purposes.
Original PR description
task-3908271
This fix closes a security gap where users could validate incoming receipts without completing required quality control checks. The system now enforces quality checks on receipts the same way it does for other operations, ensuring all items meet quality standards before acceptance.
Original PR description
Steps to reproduce: - Create a QC of type operation - Set it on reciepts Bug: you are able to validate reciepts without passing the QC Fix: use the same logic as in "check_quality" opw-3839794
The quality control wizard was displaying "- False" instead of the serial number in its title when no lot name was available. This fix corrects the display logic so users see the appropriate serial number information in the wizard title, improving clarity during quality checks.
Original PR description
Quality check wizard shows '- False' instead of Serial number in title if no lot_name opw-3839794
This update corrects how "complete months" of work are calculated for Belgian payroll. Previously, the system was flexible with the definition, but now it properly counts a complete month only when an employee works from the first to the last working day of the month, excluding weekends and public holidays. This ensures accurate payroll calculations and compliance with Belgian localization requirements.
Original PR description
In the BE loca, we were flexible on the notion of complete month. This was useful for odoo but did not make sense for the localization. A complete month of work is if you work from the first work day of the month to the last. Non-working days and public holidays are excluded.
This fix resolves a system error that occurred when creating job offers with certain advantage configurations in the HR module. The issue happened when an advantage was set as mandatory but had an empty field reference. The fix ensures the system properly handles these empty fields instead of crashing.
Original PR description
Steps to Reproduce: ------------------- 1. Install hr_contract_salary module, create an advantage. 2. In the advantages 'Display Type' field should be 'Always selected'. 3. Leave the res_field_id…
Steps to Reproduce:
-------------------
1. Install hr_contract_salary module, create an advantage.
2. In the advantages 'Display Type' field should be 'Always selected'.
3. Leave the res_field_id field empty.
4. Put this advantage as Mandatory Advantage for another field.
5. Open Recruitement App, create and send an offer.
6. Go to Offers smart button and open the Offer link.
7. There will be an Internal Server Error.
To resolve this issue we'll just continue wherever the res_field_id is not set. Because
if the res_field_id is not set it'll have no value which in return gives False(bool) which
can't be appended.
Traceback:
```py
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1770, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/home/odoo/src/odoo/17.0/odoo/service/model.py", line 133, in retrying
result = func()
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1797, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 1914, in dispatch
return self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/17.0/odoo/http.py", line 725, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/enterprise/17.0/hr_contract_salary/controllers/main.py", line 231, in salary_package
values = self._get_default_template_values(contract, offer)
File "/home/odoo/src/enterprise/17.0/hr_contract_salary/controllers/main.py", line 131, in _get_default_template_values
values = self._get_salary_package_values(contract, offer)
File "/home/odoo/src/enterprise/17.0/hr_contract_salary/controllers/main.py", line 411, in _get_salary_package_values
mapped_benefits, mapped_dependent_benefits, mandatory_benefits, mandatory_benefits_names, benefit_types, dropdown_options_2, dropdown_group_options, initial_values_2 = self._get_benefits_values(contract, offer)
File "/home/odoo/src/enterprise/17.0/hr_contract_salary/controllers/main.py", line 397, in _get_benefits_values
dependent_name = dependent_benefit.field + '_' + dependent_benefit.display_type
TypeError: unsupported operand type(s) for +: 'bool' and 'str'
```This fix ensures that when subscription renewals and upsells are created, the product line items are automatically translated into the customer's preferred language. Previously, these documents were displayed in the default system language, which could cause confusion for international customers. This improvement enhances the customer experience by providing documents in their native language.
Original PR description
Before this commit, the upsell lines were not translated into the customer lang. taskid: 3911032 Forward-Port-Of: odoo/enterprise#62180 Forward-Port-Of: odoo/enterprise#62086
This fix resolves an issue where undo history was not being cleared when users clicked the discard button in the web editor. Previously, users could undo discarded changes by pressing Ctrl+Z, which would restore the content in reverse order. The fix ensures that when changes are discarded, the editor's history is properly reset so users cannot recover discarded content through undo.
Original PR description
Issue: ====== History steps aren't cleared when we click discard Steps to reproduce the issue: ============================= - Add anything to a todo record - Click discard - Click ctrl+Z - The block reappears but in reverse order Origin of the issue: ==================== This commit introduced the behavior: https://github.com/odoo/odoo/commit/0e22763a85ee2f4caf663185eb70d3d181b954b0 We only set the value of the edtior and we don't reset it that's why the history stays. Solution: ========= When we discard the field, it will have `dirty=false` , we can use this information in the field to check if we are in a discard flow or not. task-3768456
This fix resolves an issue where product revaluation in stock accounting was using the wrong company context when working with multiple companies. Previously, the system would default to the primary company instead of the selected company, causing incorrect valuations. The fix ensures the correct company is applied when revaluing inventory across different business units.
Original PR description
Steps to reproduce: - Install stock_account and UAE account (l10N_ae) "UAE has nothing to do with the bug it's just a pain to setup a new company accounting otherwise" - Create and configure a product FIFO automated with on hand qty for both companies - In stock valuation select UAE and try to reavluate that product Bug: wrong company (the default one) is set on the context Fix: set the correct allowed_company_ids from the cids in the request cookies opw-3765174
This update ensures that invoice payment status is recalculated when an account's classification changes. This is particularly important for migrated systems where account settings may be updated, preventing invoices from incorrectly showing as unpaid when they are actually fully paid and reconciled.
Original PR description
…idual This pr adds the account_id.internal_group field in the depends of the _compute_amount_residual method. The residual amount of an account line should be recalculated when the internal_group of an account changes. While this is not common practice, it may be necessary (mainly in migrated installations from previous versions). If recomputed, invoices may remain in the process of payment, when in fact they are paid and reconciled. 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 an issue where custom footers in form dialogs were not displaying correctly after the first dialog was opened. When users opened multiple related record dialogs in a list field, the custom footer would disappear and revert to the default footer. The fix ensures each dialog uses its own copy of the form layout, preventing interference between multiple dialogs.
Original PR description
Before this commit, if the form view of an x2many (non editable inline) field contained a custom footer (i.e. a <footer> node in its arch, to override the default footer of the FormViewDialog), the custom footer was correctly displayed for the first dialog to open, but as of the second one, the default footer was displayed instead. The issue has been introduced by [1], since which we directly receive the arch as an xmlDoc, shared between all instances of FormViewDialog that can be opened from that x2many. So manipulating it (e.g. to remove the <footer> from it), impacts the subsequent dialogs that can be opened. This commit ensures that we manipulate a copy. [1] #136376 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
A recent change broke the ability to click calendar icons to open date pickers across the website and survey applications. This fix restores that functionality by automatically detecting and enabling calendar icons in date input fields. Users can now click the calendar icon to open the date picker in forms, opportunity management, product rentals, and surveys.
Original PR description
*: website, survey Since commit [1] the calendar icon in input group date is not clickable anymore and does not open the date picker anymore. This commit simply restore that by auto discovering the…
*: website, survey
Since commit [1] the calendar icon in input group date is not clickable
anymore and does not open the date picker anymore.
This commit simply restore that by auto discovering the calendar icon,
should the input group follow this common pattern:
```xml
<div class="input-group date">
<input
type="text"
class="form-control datetimepicker-input"
/>
<div class="input-group-text"><i class="fa fa-calendar"></i></div>
</div>
```
This seems enough to cover all cases detected in the website apps:
- <details><summary>The two datepicker in /my/opportunity when editing the lead to adapt
the "Expected Closing" and "Next Activity Date" fields</summary>
</details>
- <details><summary>The website form date(time) input</summary>
</details>
- <details><summary>The ecommerce renting product rental period inputs ("from" and "to"
dates) </summary>
</details>
- <details><summary>The `o_website_sale_daterange_picker` snippet</summary>
</details>
- <details><summary>The survey date fields</summary>
</details>
- ..maybe other places..
Should there be cases needing this feature for calendar icons which are
not following the suggested input group layout, they can do it this way:
```diff
- this.call("datetime_picker", "create", {
+ const picker = this.call("datetime_picker", "create", {
// ...
}).enable();
+ this.el.parentNode.querySelector(".input-group-text").addEventListener("click", picker.openPicker(0));
```
[1]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628This fix resolves a bug in the Maintenance Calendar where dragging, dropping, or editing maintenance requests would often affect the wrong request when recurring events were involved. The system now correctly identifies and updates the intended maintenance request by using the proper record reference, ensuring users can reliably manage their maintenance schedules through the calendar interface.
Original PR description
### Steps to reproduce the issue: 1. In _Maintenance > Maintenance > Maintenance Requests_, set multiple maintenance requests with scheduled dates 2. In _Maintenance > Maintenance > Maintenance…
### Steps to reproduce the issue:
1. In _Maintenance > Maintenance > Maintenance Requests_, set multiple maintenance requests with scheduled dates
2. In _Maintenance > Maintenance > Maintenance Calendar_, get to a week or month with multiple requests
3. Drag and drop one of the requests in the calendar
- You can also double click or resize the request
4. In most cases, the request that is changed or accessed is not the right one
### Explanation:
`rawRecord` is the record as retrieved by `fetchRecords`, it is then processed in `loadRecords`. In `CalendarWithRecurrence`, with the option of having recurring events, `record.id` is nearly always different from `rawRecord.id`.
https://github.com/odoo/odoo/blob/74a0703671f29fefad02843c0d679f903b812575/addons/maintenance/static/src/views/calendar_with_recurrence/calendar_with_recurrence_model.js#L11-L17
### Suggested fix:
Overriding the methods that lead to the wrong model to replace `record.id` with `record.rawRecord.id` solves the issue without breaking other methods.
For requests with recurrence, any change made using an occurrence in the calendar view would target the original request instead. Accessing it is not an issue, so we will only disable the edition of the occurrences.
opw-3848278
opw-3849852This fix resolves a system error that occurred when scanning event tickets that were not linked to a sale order. The issue happened when attendees received tickets via email and scanned them at the registration desk. The system now properly handles tickets without associated sales, preventing the error and allowing the registration process to complete successfully.
Original PR description
Steps to reproduce: - Enable event barcode in Event settings - Create a new event - Add an attendee and send him the ticket by email - Download the ticket - Scan the ticket in the registraion desk - Server Error: 'payment_status_value': dict(self._fields['payment_status']._description_selection(self.env))[self.payment_status], KeyError: False Bug: the field is a selection field we use _description_selection to get the string to display but in this case the ticket is not linked to a sale so the value is False Note: -the value is correctly checked before being displayed \<tr t-if="registration.payment_status_value"> -in V17 same for sale_status instead opw-3870653
This fix resolves issues with the course creation tutorial in the website slides module. Previously, when users clicked to create a new course, the tutorial would freeze and fail to display prompts for entering the course title and section name. This update corrects the tutorial pointer positions so users now see all necessary guidance when creating courses.
Original PR description
**[FIX] website_slides: rectify the trigger on the course title input field** Before this commit: - While running the `slides_tour`, it freezes after we click on `Course` to create a new course. The prompt to input the title while creating the new course is not visible. - The prompt to add 'Section Name' is missing. Reason: The 'trigger' update was not addressed in the following PR: https://github.com/odoo/odoo/pull/117799 After this commit: - The prompt to input the course title is visible. - The prompt to add the 'Section Name' is added. task-3539126 Forward-Port-Of: odoo/odoo#161646 Forward-Port-Of: odoo/odoo#138651
This fix corrects an issue where kit products with sub-kits were showing incorrect delivered/received quantities on sales orders when using multi-step delivery processes. The system now properly accounts for all bill of materials levels and tracks actual completed quantities instead of just demand quantities, ensuring accurate order fulfillment reporting.
Original PR description
Steps to reproduce: - Enable multistep delivery/reciept - Create a kit and subkit with product quantity set on the bom (exemple values in the tests) - Create and confirm an SO (pickings created with correct values) - Update the orders quantity Bug: wrong Delivered/Recieved ammount on the SO line FIX: all boms should be taken into account not just the one on the move line to handle subkits in "_compute_kit_quantities" done quantity of moves should be considered for done moves instead of their demand opw-3827388
The Attendee List report in the Event module was displaying event dates and times in UTC instead of the time zone configured for each event. This fix updates the report to use the correct time zone information, ensuring attendees see event times in the proper local time zone as set by the event organizer.
Original PR description
Description: The Attendee List report uses `date_begin` and `date_end` to display the Event's Dates, however these values are always UTC rather than using the `date_tz` set on the Event. In order to show the times with the correct tz, we should use the already existing `date_begin_located` and `date_end_located` fields instead, which already formats the fields with tz. Desired Behavior after fix: Attendee List report properly displays the datetime based on the tz set on the record. opw-3895264
Portal users creating tasks in projects were seeing tasks appear in a "None" stage instead of the project's default stage. This fix ensures that when portal users create tasks, the system properly assigns them to the correct initial stage by retrieving the project information from the system context, preventing the creation of unwanted empty stages in the project workflow.
Original PR description
Currently, when a portal user creates a task in a project, the stage is set to none, which create a new stage in the pipe. Steps to reproduce: ------------------- * Connect to the db as a portal user…
Currently, when a portal user creates a task in a project, the stage is set to none, which create a new stage in the pipe.
Steps to reproduce:
-------------------
* Connect to the db as a portal user
* Navigate to **Projects**
* Select any
* Create a new task
* Refresh the page
> Observation: The task is created in the None stage
Why the fix:
------------
The `stage_id` of the task created by the portal user is set to false here:
https://github.com/odoo/odoo/blob/e38f711864bd380f793c1efa16c86c6ba2229646/addons/project/models/project_task.py#L928-L929
Prior to https://github.com/odoo/odoo/commit/fb88a7448c75fdcbe1d9c3664402a1dea2733326, the `project_id` was computed as `project_id = vals.get('project_id') or self.env.context.get('default_project_id')`. Now it is defined as follows:
https://github.com/odoo/odoo/blob/e38f711864bd380f793c1efa16c86c6ba2229646/addons/project/models/project_task.py#L894
If `vals.get('project_id')` is false/none, the task is still created using `self.env.context.get('default_project_id')` for portal users.
https://github.com/odoo/odoo/blob/e38f711864bd380f793c1efa16c86c6ba2229646/addons/project/models/project_task.py#L955-L958
https://github.com/odoo/odoo/blob/e38f711864bd380f793c1efa16c86c6ba2229646/addons/project/models/project_task.py#L813-L820
We recompute `project_id` using the context value. We do that after the following piece of code so that, in the case of subtasks, they are not displayed in the project.
https://github.com/odoo/odoo/blob/8780f8d9799eed7188d6577c6bb2690df598196e/addons/project/models/project_task.py#L916-L929
This allows to keep the writing cascade on the field `project_id`
https://github.com/odoo/odoo/blob/8780f8d9799eed7188d6577c6bb2690df598196e/addons/project/models/project_task.py#L1007-L1009
opw-[3873983](https://www.odoo.com/web#id=3873983&view_type=form&model=project.task)
X-original-commit: https://github.com/odoo/odoo/commit/28a95dc7d2890ddfad95665a722bb19fc622614fThis fix ensures that Spanish translations work correctly across all Spanish-speaking regions (Spain, Venezuela, Argentina, Bolivia, etc.). Previously, translations written for Spanish (Spain) were not being loaded for other Spanish locales. Now both Spanish (Spain) and the regional Spanish base are checked, so translations load properly regardless of which file they're stored in or which Spanish variant the user has selected.
Original PR description
Starting Odoo 17, es_419 is used as a base for every Spanish locale (es_VE, es_AR, es_BO...), but a lot of localizations still have their translations written for es_ES only. After this commit, both es_ES and es_419 will be used as base languages for Spanish variations, ensuring that the translations will be loaded whatever the file they where put into and the language of the user.
This fix ensures that new accounting chart accounts for Switzerland are properly created when the localization module is updated. Previously, these accounts stored in data files were not being created during updates. A migration script now triggers their creation automatically, similar to how new tax records are handled.
Original PR description
New accounts added in https://github.com/odoo/odoo/commit/d8873ee01f0974e82de2e6cc906b0c77f8a3687f will not be created upon module update because they are stored in a csv. A migration script will trigger their creation by calling `try_loading()`, similarly as was done here for new taxes: https://github.com/odoo/odoo/blob/512574861691f425ec6a17f20fe4b586bb88a299/addons/l10n_fr/migrations/2.1/post-migrate_update_taxes.py#L8 https://github.com/odoo/odoo/blob/eb7ea22ea036c645d3c22049b6e874f9e8ada6d4/addons/l10n_ch/migrations/11.1/post-migrate_update_taxes.py#L21 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that numeric fields in Odoo's web interface properly display formatted values when you click out of the field, even if the underlying value hasn't changed. For example, if you edit a field showing "25.00" to just "25", it will now correctly display as "25.00" when you leave the field, maintaining consistent formatting across the application.
Original PR description
Have a numeric field with a given value (e.g. 25.00). Edit it in a way the value is actually the same (e.g. 25). Click out. Before this commit, the value wasn't formatted as it should be, i.e. 25 was still displayed in the input, whereas it should display 25.00. This commit fixes the issue. Similar as https://github.com/odoo/odoo/pull/164953 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 an issue where product names were appearing multiple times on invoices in the GCC region (Saudi Arabia and other Gulf countries). The system was displaying both the product name and its description even when they were identical, causing redundant information. Now the report intelligently shows only the description when it differs from the product name, or displays the product name in the customer's preferred language to avoid duplication.
Original PR description
Problem: The arabic_english_invoice report displays product name twice since the description includes the product name by default. Solution:The report should only display the description if the description is not the same as the products' name. Otherwise, the report should display the products' name in the same language as the customer. Steps to Reproduce on Runbot: 1. Install `sale`, `l10n_sa`, `l10n_gcc_invoice` 2. Switch to SA Company 3. Create a product with sales description 4. Create an invoice with the product from step 3 5. Print the invoice report 6. Observe the product name is displayed twice 7. If Arabic is enabled as a language, the product name will be displayed three times, with the 3rd being in Arabic. [Ticket link](https://www.odoo.com/web#model=project.task&id=3768196) opw-3768196 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157774
This update resolves a system error that occurred when unarchiving multiple products that have dynamic attributes and variants. The fix ensures the unarchiving process works smoothly for products with complex configurations, improving the reliability of product management operations.
Original PR description
Currently, an error is generated when unarchiving multiple products which have dynamic attributes & variants. Step to produce: - Install a 'Sales' module. - Navigate to the Sales / Products /…
Currently, an error is generated when unarchiving multiple products which have dynamic attributes & variants. Step to produce: - Install a 'Sales' module. - Navigate to the Sales / Products / Products, And create a product. - Add a 'Product Name' and save a record, and then add dynamic Attributes & Variants. - Repeat the process described in the above step to create another product with the same configuration as the first one. -Go to list view of 'Product'. select both products that we made recently and click on the Action button to archive both products. - Click on 'Filters' to see the archive product, And select those products to Unarchive. ValueError: Expected singleton: product.template(39, 37, 40, 42, 38, 46, 34) The issue occurs when unarchive multiple products that contain dynamic attributes & variants. As a result, the system receives multiple product templates at [1]. link[1]: https://github.com/odoo/odoo/blob/e5635c38810a745f00b106d7a075ae1553de50c7/addons/product/models/product_template.py#L745 To resolve the issue, replace a 'self' with 'tmpl_id' to get a single product template record instead of multiple. sentry-5222160918 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes a duplicate dialog size configuration in the Project module that was unnecessarily repeated in the code. By cleaning up this redundancy, the system becomes more efficient and easier to maintain without affecting how the application functions.
Original PR description
-Remove duplicate dialog_size 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
Employees can now delete their own time off requests for today if they haven't been validated yet. This provides flexibility for users to cancel same-day leave requests before approval. Past leave requests cannot be deleted, maintaining data integrity for historical records.
Original PR description
In this PR, if the user has created a leave request for today and it remains unvalidated, they can delete it However, past leave cannot be deleted Task-3775186
This update adds necessary safety protections to the Mercado Pago payment module to prevent test database copies from accidentally interacting with external payment systems. This ensures that when support teams create copies of production databases for investigation, those copies won't process real transactions or impact customers.
Original PR description
This commit adds the missing neutralization necessary for the pos_mercado_pago module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or wont result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] https://github.com/odoo/odoo/pull/154962
This update fixes a display issue in the eCommerce product categories form that was causing improper layout on mobile devices. The form content was incorrectly positioned, making it difficult to view and interact with on smaller screens. The fix adjusts the styling to ensure the form displays properly across all device sizes.
Original PR description
This PR fixes a layout issue inside the eCommerce categories form view on mobile devices. Prior to this PR, a `.oe_left` class was applied to the content of the sheet, moving it "out of the flow", resulting in a wrong sized `form_sheet`. To fix the issue, we have to provide a CSS workaround to modify the view without modifying the XML directly. To do so, we set a `float:none` that will cancel the utility class, and we apply a `.col-md-6` and a `.pe-3` class to ensure that the labels are not placed right next to the image in mobile and the layout doesn't take the full width on larger devices. task-3847917 Forward-Port-Of: odoo/odoo#162034
This update fixes an issue where the close button for onboarding steps was being hidden behind the illustration on smaller screens, making it difficult for users to dismiss the onboarding. The fix ensures the close button remains visible and accessible on all screen sizes.
Original PR description
Before this PR, on smaller screens the onboarding steps illustration sometimes overlapped the close button, making it difficult to dismiss the onboarding steps. This fix ensures the close button is no longer obscured. task-3749740 <details> <summary>Preview (See changes)</summary> <table> <tr> <td>Before</td> <td>After </td> <tr> <td><img src="https://github.com/odoo/odoo/assets/80678921/01cd9478-1e9d-4736-9599-3df8bda380b1" alt="before"></td> <td><img src="https://github.com/odoo/odoo/assets/80678921/b8d2ec5a-3bea-48d9-8320-b0872ae04be8" alt="after"</td> </table> </details> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163966