Daily updates from Odoo
Tuesday, May 14, 2024
30 changes
1 change
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.
29 changes
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