Monday, August 26, 2024
27 changes
17 changes
Resolved issues and error corrections
Products configured to keep selling when out of stock will no longer show a “Temporarily out of stock” warning in the ecommerce wishlist. This avoids confusing shoppers and keeps the wishlist messaging aligned with the merchant’s selling settings.
Original PR description
When the product has the "continue selling" box when "out-of-stock" checked, and you add the product to the wishlist from ecommerce, "Temporarily out of stock" message/warning will appear in the…
When the product has the "continue selling" box when "out-of-stock" checked, and you add the product to the wishlist from ecommerce, "Temporarily out of stock" message/warning will appear in the wishlist. To Reproduce on Runbot: 1. Make sure ecommerce module is installed 2. Go to a storable product (for example: Cable Management Box) 3. In the sales tab, make sure the option "Continue Selling" for Out-of-Stock field is checked 4. Go to ecommerce, search for the product (here, let's search for Cable Management Box), click on it 5. Click on add to wishlist 6. Go to wishlist. 7. We'll see "Temporarily out of stock" message. But, we don't want this because we want to continue selling even if it's out of stock, and don't want to customer to get confused with the message. So, since the message/warning doesn't align with the concept of continue selling when out of stock, we want to get rid of the message/warning if the product has "continue selling" box checked. opw-4121929
Features or functions removed from Odoo
This change removes a previously added step that carried attendee details into checkout for website event ticket purchases. The team found it added unnecessary processing and could create extra customer records when shoppers abandoned checkout, while logged-in users usually already have their details pre-filled.
Original PR description
This reverts commit 31ba553f283af73b9a84ba299ad9b7240e3ab779. After careful consideration, we deemed it overkill and not necessary. It adds extra overhead as most of the time you will be logged anyway and everything will be pre-filled for you. It also creates a lot of unnecessary partner records in case users decide to drop out of the checkout flow and not complete it.
Miscellaneous changes
Before this commit, the cog dropdown was getting clipped on mobile for longer widths Steps to reproduce: - Project> Open any project > Open any task. - Click on the cog button - Minimize the window or switch to mobile view After this commit, the width of the dropdown adjusts accordingly to prevent clipping. And the text of dropdown items is truncated. Task: 3763899 Forward-Port-Of: odoo/odoo#166135
Original PR description
Before this commit, the cog dropdown was getting clipped on mobile for longer widths Steps to reproduce: - Project> Open any project > Open any task. - Click on the cog button - Minimize the window or switch to mobile view After this commit, the width of the dropdown adjusts accordingly to prevent clipping. And the text of dropdown items is truncated. Task: 3763899 Forward-Port-Of: odoo/odoo#166135
8 changes
Enhancements to existing features
Clicking a statement total in bank reconciliation now opens a cleaner statement form experience instead of showing elements that do not fit well in the popup. This makes the reconciliation workflow look more polished and easier to use after recent form view changes.
Original PR description
Before, in the bank reconciliation widget, when clicking on the statement total, the form view of the statement was opened in a popup. This doesn't look good anymore after 120a546295b9e99b2bd50736003506311419562e as that commit adds the chatter and the attachment previewer to the form view. The popup now can be replaced with opening the form view directly instead of in a popup. No task.
2 changes
Resolved issues and error corrections
A spacing issue in the Mexican EDI payment report has been corrected where a space was missing between the VAT label and account information. The fix adds consistent styling to ensure proper spacing between these elements, improving the readability and professional appearance of payment reports.
Original PR description
In the payment report, a space was missing between the VAT label and the span "Emitter Acc. Ben.". In order to don't rely on spaces, a ps-1 class was added in both "Emitter Acc. Ben." and "Emitter Acc. Ord.". --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#53722
### Steps to reproduce: - Create and validate a delivery order for some product - Click on the "Detailed Operations" button on top of the picking form #### > You are able to create new move lines on your picking even thought it is done and locked. ### Cause of the issue: The `create` attribute of the view determines if the record can or can not be created. However, it is currently not set in the context of the view called by the `action_detailed_operations`. ### Note: This `a
Original PR description
### Steps to reproduce: - Create and validate a delivery order for some product - Click on the "Detailed Operations" button on top of the picking form #### > You are able to create new move lines on your picking even thought it is done and locked. ### Cause of the issue: The `create` attribute of the view determines if the record can or can not be created. However, it is currently not set in the context of the view called by the `action_detailed_operations`. ### Note: This `action_detailed_operations` did not exist in 16.0. opw-4103700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176709
Backport from 16.1: https://github.com/odoo/odoo/commit/bfa7a47c860452a8b27a942cd50dc61eba72f5cb hinder allocation date_to to precede date_from Purpose: In order to reduce the possibility to make errors, make the end date of the validity period always come after the start date. @Tecnativa TT50433 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176808 Forward-Port-Of: odoo/odoo#175841
Original PR description
Backport from 16.1: https://github.com/odoo/odoo/commit/bfa7a47c860452a8b27a942cd50dc61eba72f5cb hinder allocation date_to to precede date_from Purpose: In order to reduce the possibility to make errors, make the end date of the validity period always come after the start date. @Tecnativa TT50433 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176808 Forward-Port-Of: odoo/odoo#175841
This PR is created in order to sing the odoo CLA and contribute to Odoo. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176903
Original PR description
This PR is created in order to sing the odoo CLA and contribute to Odoo. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176903
Fixes 2 bugs (2nd noticed while investigating the 1st bug): 1. When selecting `create_backorder="always"` for a manufacturing operation type, the auto-printing didn't work for the MOs after they were marked as done. Steps to reproduce: - create a new lot tracked product - set the manufacture operation type `create_backorder="always"` - set the operation type > Hardware > Print When Done > Lot/SN Labels to true - create a MO for the lot tracked product with a product_qty > 1 - set a `l
Original PR description
Fixes 2 bugs (2nd noticed while investigating the 1st bug): 1. When selecting `create_backorder="always"` for a manufacturing operation type, the auto-printing didn't work for the MOs after they were…
Fixes 2 bugs (2nd noticed while investigating the 1st bug): 1. When selecting `create_backorder="always"` for a manufacturing operation type, the auto-printing didn't work for the MOs after they were marked as done. Steps to reproduce: - create a new lot tracked product - set the manufacture operation type `create_backorder="always"` - set the operation type > Hardware > Print When Done > Lot/SN Labels to true - create a MO for the lot tracked product with a product_qty > 1 - set a `lot_producing_id` and mark `qty_producing=1` - click "Produce" button Expected result: MO is backordered + the lot label is auto-printed (i.e. generated and downloaded as a pdf if no iot printer is set up) Actual result: MO is backordered and has a status=Done, but nothing is printed + the values that should be written within `button_mark_done` are not written (i.e. `priority` is not set to 0 and `date_finished` is not set to now()) Issue was due to use of the backorder wizard without passing the MOs that are always backordered as `mrp_production_ids`, this resulted in the MOs being backordered due to the context logic within the backorder wizard, but not applying the rest of the logic within `button_mark_done` that is applied to the `self` records (i.e. the MOs being backordered) 2. If more than 2 manufacturing operation types were set, then depending on the combination of `create_backorder` values, the backordering mechanism might not work. E.g. if `always` + `ask`, the `always` backordering logic would return and ended the logic before the `ask` or `never` MOs backordering logic was ever reached. Steps to reproduce: - set up 2 manufacture operation types, one with `always` and one with `ask`/`never` - set up 2 MOs with product_qty > 1 using the 2 different operation types - mark `qty_producing=1` for each MO and then select both MOs in the list view + action > "Mark as Done" Expected result: the `always` MO is backordered automatically and the `ask` MO has the backorder wizard pop up for it Actual result: the `always` MO is backordered automatically and the `ask` MO does nothing (it is not even set to done) opw-3987144 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174632
### Steps to reproduce: - Create a storable product A - Create and confirm a delivery order for 1 unit of A - Add one unit of A in stock - Inventory > Operations > Run Scheduler #### > The reservation of the delivery order is not performed ### Cause of the issue: The "reservation_date" of moves whose "picking_type" does not have a reservation method 'At Date' is removed each time it is computed because of these lines: https://github.com/odoo/odoo/blob/17a18f9d065d25095f80e6982b6d
Original PR description
### Steps to reproduce: - Create a storable product A - Create and confirm a delivery order for 1 unit of A - Add one unit of A in stock - Inventory > Operations > Run Scheduler #### > The…
### Steps to reproduce: - Create a storable product A - Create and confirm a delivery order for 1 unit of A - Add one unit of A in stock - Inventory > Operations > Run Scheduler #### > The reservation of the delivery order is not performed ### Cause of the issue: The "reservation_date" of moves whose "picking_type" does not have a reservation method 'At Date' is removed each time it is computed because of these lines: https://github.com/odoo/odoo/blob/17a18f9d065d25095f80e6982b6dc0673e5c382e/addons/stock/models/stock_move.py#L547-L553 However, during the `_run_scheduler_tasks` only the moves whose `reservation_date` is set will be reserved: https://github.com/odoo/odoo/blob/17a18f9d065d25095f80e6982b6dc0673e5c382e/addons/stock/models/stock_rule.py#L549-L554 https://github.com/odoo/odoo/blob/17a18f9d065d25095f80e6982b6dc0673e5c382e/addons/stock/models/stock_rule.py#L572-L574 opw-4105299 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177612
**Version:** 16, 17, master **Description of the issue/feature this PR addresses:** Argentinean localization: if a customer invoice with partner with "IVA Responsable Inscripto" AFIP Responsibility is confirmed, then reset to draft and changed the partner to one with "Responsable Monotributo" AFIP Responsibility, then "Document Type" field is changed and this is not the desired behavior because that field is readonly when the invoice was posted. Compute method should not overried the docum
Original PR description
**Version:** 16, 17, master **Description of the issue/feature this PR addresses:** Argentinean localization: if a customer invoice with partner with "IVA Responsable Inscripto" AFIP Responsibility…
**Version:** 16, 17, master **Description of the issue/feature this PR addresses:** Argentinean localization: if a customer invoice with partner with "IVA Responsable Inscripto" AFIP Responsibility is confirmed, then reset to draft and changed the partner to one with "Responsable Monotributo" AFIP Responsibility, then "Document Type" field is changed and this is not the desired behavior because that field is readonly when the invoice was posted. Compute method should not overried the document type if the invoice was posted before. If it does then an incosistency will occurr because the name, document type and sequence will not match. A new sequence non-real will be used. Also the user it is not aware is happening because the field is readonly. **But when a vendor bill with partner with "IVA Responsable Inscripto" AFIP Responsibility is confirmed then is needed to change "Document Type" field if that vendor bill is reset to draft and changed the partner to one with "Responsable Monotributo" AFIP Responsibility.** --> we introduced this bug on this pr [https://github.com/odoo/odoo/pull/172003](https://github.com/odoo/odoo/pull/172003) **Video showing how to replicate the bug:** https://drive.google.com/file/d/1endivnZ3EEBVn4kzt0hIkR-a5tecYUR7/view **Steps to reproduce:** 1. Log in with admin on runbot odoo enterprise 16 instance and install l10n_ar_edi (Argentinean Electronic Invoicing) module. 2. Take position on company "Responsable Inscripto". 3. Go to "Accounting / Vendor / Bills" and create a new vendor bill with vendor "ADHOC SA" (this partner has "IVA Responsable Inscripto" AFIP Responsibility), with a journal "Vendor Bills", add an invoice line and confirm it. 4. Reset to draft the vendor bill mentioned in step 3 (now journal and document type are readonly fields), change customer to "Gritti Agrimensura" (this partner has "Responsable Monotributo" AFIP Responsibility) and save. Check that the document type has not changed from "(1) FACTURAS A" to "(11) FACTURAS C" and this is not the desired behavior because is a readonly field now because the invoice was posted before. **Current behavior before PR:** When a vendor bill with partner with "IVA Responsable Inscripto" AFIP Responsibility is confirmed then "Document Type" field does not changes if that vendor bill is reset to draft and changed the partner to one with "Responsable Monotributo" AFIP Responsibility. **Desired behavior after PR is merged:** When a vendor bill with partner with "IVA Responsable Inscripto" AFIP Responsibility is confirmed then "Document Type" field does changes if that vendor bill is reset to draft and changed the partner to one with "Responsable Monotributo" AFIP Responsibility. Ticket Adhoc side: 77058 Task latam: 1242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175855
## Before this PR: Sometimes Delivered SMS Text Messages are not counted as Sent SMS, thus causes confusion among users. ## Technical: Sometimes we got 'Delivered' Status first instead of getting 'Sent' Status from 3rd party providers (IAP). Because of this 'sent_datetime' is not Set and return False. Sent SMS in tooltip as well in other views(i.e., traces list) are counted if Sent On(sent_datetime) has a value. ## After this PR: 'sent_datetime' will be set if SMS status i
Original PR description
## Before this PR: Sometimes Delivered SMS Text Messages are not counted as Sent SMS, thus causes confusion among users. ## Technical: Sometimes we got 'Delivered' Status first instead of getting 'Sent' Status from 3rd party providers (IAP). Because of this 'sent_datetime' is not Set and return False. Sent SMS in tooltip as well in other views(i.e., traces list) are counted if Sent On(sent_datetime) has a value. ## After this PR: 'sent_datetime' will be set if SMS status is not in '**Outgoing**', '**Processing**', '**Exception**' , '**Canceled**', thus counted as Sent SMS. This will also solve any potential future issue if we can't get any delivery status from 3rd party providers for some reasons (i.e., Delivered) but we can get click/open,... status directly from recipient. https://github.com/odoo/odoo/assets/157007055/a28f6c3c-883d-4f09-a591-25dfe35e029d Task-3972519 Forward-Port-Of: odoo/odoo#169186
**Description of the issue/feature this PR addresses:** Before this PR initial balance include line with a null balance. In database with lot of partner (e-commerce), the initial balance balance are huge. - Create e-commerce - Sale and invoice to 100 000 different customer in 2023, all invoice are paid - In 2024 extract a FEC --> Issue : in the initial balance there are 100 000 lines with a zero balance. This lines don't need to be included in the FEC. --- I confirm I have signe
Original PR description
**Description of the issue/feature this PR addresses:** Before this PR initial balance include line with a null balance. In database with lot of partner (e-commerce), the initial balance balance are huge. - Create e-commerce - Sale and invoice to 100 000 different customer in 2023, all invoice are paid - In 2024 extract a FEC --> Issue : in the initial balance there are 100 000 lines with a zero balance. This lines don't need to be included in the FEC. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160639 Forward-Port-Of: odoo/odoo#141321
To reproduce the issue: - In the project app, click on a project to enter the Kanban view - Refresh the page The "+ stage" button to add a stage to a project disappears upon page refresh. This is caused by a context check that functions correctly during the normal flow. However, when directly accessing the link or refreshing the page, the `active_model` context is lost. Since the action `act_project_project_2_project_task_all` always filter project on active_id, we can add as a default
Original PR description
To reproduce the issue: - In the project app, click on a project to enter the Kanban view - Refresh the page The "+ stage" button to add a stage to a project disappears upon page refresh. This is caused by a context check that functions correctly during the normal flow. However, when directly accessing the link or refreshing the page, the `active_model` context is lost. Since the action `act_project_project_2_project_task_all` always filter project on active_id, we can add as a default context ´'active_model': 'project.project'´ opw-4075290 Forward-Port-Of: odoo/odoo#176577
* PROPBLEM: The error is raised when user has access to Project Update, but not to Journal Item. * SOLUTION: Add `sudo` when searching `account.move.line` in the method `_get_already_included_profitability_invoice_line_ids`. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177150
Original PR description
* PROPBLEM: The error is raised when user has access to Project Update, but not to Journal Item. * SOLUTION: Add `sudo` when searching `account.move.line` in the method `_get_already_included_profitability_invoice_line_ids`. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177150
This commit fixes an issue regarding global discount lines on invoices that should be represented as allowance charge elements on the UBL file sent to ZATCA. In V17 the structure of the dictionary passed to the XML template in charge of rendering AllowanceCharge changed and expects the value of the tax_scheme_id to be passed inside a dict called tax_scheme_vals, which was not the case previously. Description of the issue/feature this PR addresses: When trying to submit an invoice containing
Original PR description
This commit fixes an issue regarding global discount lines on invoices that should be represented as allowance charge elements on the UBL file sent to ZATCA. In V17 the structure of the dictionary…
This commit fixes an issue regarding global discount lines on invoices that should be represented as allowance charge elements on the UBL file sent to ZATCA. In V17 the structure of the dictionary passed to the XML template in charge of rendering AllowanceCharge changed and expects the value of the tax_scheme_id to be passed inside a dict called tax_scheme_vals, which was not the case previously. Description of the issue/feature this PR addresses: When trying to submit an invoice containing global discounts to ZATCA, the server throws an error since it expects a Tax Scheme ID on the Allowance Charge element linked to the global discount. This only happens on V17 as the structure of the data passed to the AllowanceCharge XML template changed Current behavior before PR: ZATCA servers return an error when submitting invoices containing a global discount line Desired behavior after PR is merged: ZATCA servers correctly process invoices containing global discount lines --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177326
Versions -------- - 17.0+ Steps ----- 1. Activate a second language on the database; 2. enable debug mode; 3. go to Settings / Technical / Database Structure / Fields; 4. look for the `state` field of the `project.task` model; 5. change the name's translation of the of the `01_in_progress` value; 6. go to a task to select the state. Issue ----- It still shows the original translation. Cause ----- The JS side fetches the translations straight from the .po file instead of loo
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Activate a second language on the database; 2. enable debug mode; 3. go to Settings / Technical / Database Structure / Fields; 4. look for the `state` field of the `project.task` model; 5. change the name's translation of the of the `01_in_progress` value; 6. go to a task to select the state. Issue ----- It still shows the original translation. Cause ----- The JS side fetches the translations straight from the .po file instead of looking for translations stored in the database. Solution -------- The translations of the labels are already stored in `this.props.record.fields[this.props.name].selection`, as used in `super`'s `options` getter. Retrieving these, custom translations do take effect. opw-4009326 Forward-Port-Of: odoo/odoo#177676 Forward-Port-Of: odoo/odoo#176507
Before this commit, the 3aa8a0f commit forwards port the fix made in 16 but in 17.1, `website_form_project` has been renamed into `website_project` and the test added in `website_form_project` to check the fix made has not been moved during the forward port process. This commit moves the test in `website_project` module to make sure the test is correctly executed since the `website_form_project` module does not exist anymore. Forward-Port-Of: odoo/odoo#177773
Original PR description
Before this commit, the 3aa8a0f commit forwards port the fix made in 16 but in 17.1, `website_form_project` has been renamed into `website_project` and the test added in `website_form_project` to check the fix made has not been moved during the forward port process. This commit moves the test in `website_project` module to make sure the test is correctly executed since the `website_form_project` module does not exist anymore. Forward-Port-Of: odoo/odoo#177773
Currently, the `_run_action_object_create` method (used in particular to propose record creation using a `name` field in automations) assumes that all models have a `name` field, which is not true. In fact, before this commit, we used ```py res = {'name': self.value} res = self.env[self.crud_model_id.model].create(res) ``` This will cause a traceback in models without a `name` field. This commit uses `name_create` directly, which is what it's for. opw-4100885 Forward-Port-Of: od
Original PR description
Currently, the `_run_action_object_create` method (used in particular to propose record creation using a `name` field in automations) assumes that all models have a `name` field, which is not true.
In fact, before this commit, we used
```py
res = {'name': self.value}
res = self.env[self.crud_model_id.model].create(res)
```
This will cause a traceback in models without a `name` field.
This commit uses `name_create` directly, which is what it's for.
opw-4100885
Forward-Port-Of: odoo/odoo#177602Product catalog and document cards have been simplified to use newer layout standards, making the screens easier to maintain and more consistent. Users should see the same core information with a cleaner, more reliable presentation across field service sales, stock-related tours, and PLM document views.
Original PR description
In this commit we have simplified the kanban arch for the product and their related view modules. the goal is to simplify them,make them easier to read and use bootstrap utility classnames. - Previously, we used kanban-box, but now we are using kanban-card instead. - Deprecated oe_kanban_global_click and oe_kanban_global_click_edit. - More use of <field/> tags - Removed the oe_kanban_colorpicker class and replaced it with the kanban_color_picker widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - kanban_image from rendering context, is deprecated so we use <field name="..." widget="image"/> instead - kanban_color, kanban_getcolor and kanban_getcolorname are deprecated use new attribute highlight_color="color_field_name" on root node - oe_kanban_colorpicker is deprecated, use kanban_color_picker widget instead Task-3992107
The helpdesk timesheet and timesheet grid kanban views were updated to use newer, cleaner layout components. This makes the views easier to maintain and keeps them aligned with current Odoo interface standards, with minimal direct business impact.
Original PR description
In this commit we have simplified the kanban arch for the helpdesk_timesheet and timesheet_grid module.the goal is to simplify them, make them easier to read and use bootstrap utility classnames. - Previously, we used kanban-box, but now we are using kanban-card instead. - Deprecated oe_kanban_global_click and oe_kanban_global_click_edit. - More use of <field/> tags - Removed the oe_kanban_colorpicker class and replaced it with the kanban_color_picker widget. - Changed type='edit' to type='open' to open records. since version 16, records always open in edit mode by default. - kanban_image from rendering context, is deprecated so we use <field name="..." widget="image"/> instead - kanban_color, kanban_getcolor and kanban_getcolorname are deprecated use new attribute highlight_color="color_field_name" on root node - oe_kanban_colorpicker is deprecated, use kanban_color_picker widget instead Task-3992107
This update standardizes how website pages are identified across related apps, including appointments and helpdesk. It helps keep website behavior consistent and easier to maintain without introducing major visible changes for users.
Original PR description
to squash
Resolved issues and error corrections
The spreadsheet version history side panel now uses the correct padding, making the panel look cleaner and easier to read. This minor visual fix improves consistency in the spreadsheet editing experience without changing functionality.
Original PR description
Task: [4131488](https://www.odoo.com/web#id=4131488&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Fixed an issue that could prevent the IoT device page from working after a shared system update removed a library it depended on. The page now loads the needed component so device monitoring and related updates continue to work normally.
Original PR description
As a result of community PR #174213, jQuery has been removed from the backend JS bundle. The IoT device page relied on jQuery for longpolling requests. This PR simply adds a call to ensure jQuery is loaded. PR that caused the bug: https://github.com/odoo/odoo/pull/174213
Miscellaneous changes
When the user was connecting an IoT to the database there was no notification or any information to tell him that he succeded / failed / had to wait to see it in the "connected" list. We now display those notifications. Task: 4104811 Forward-Port-Of: odoo/enterprise#68394
Original PR description
When the user was connecting an IoT to the database there was no notification or any information to tell him that he succeded / failed / had to wait to see it in the "connected" list. We now display those notifications. Task: 4104811 Forward-Port-Of: odoo/enterprise#68394
round() on the fractional part of shift_template.end_time/start_time can lead to problems when the result is very close to 1.0 (e.g., anything greater than 0.994). Specifically, round() can cause the fractional part to round up to 1.0 (so 60 minutes), which is not wanted. We can either set it to 59 as done here, or 0 and add 1 hour to the hours. Forward-Port-Of: odoo/enterprise#68756
Original PR description
round() on the fractional part of shift_template.end_time/start_time can lead to problems when the result is very close to 1.0 (e.g., anything greater than 0.994). Specifically, round() can cause the fractional part to round up to 1.0 (so 60 minutes), which is not wanted. We can either set it to 59 as done here, or 0 and add 1 hour to the hours. Forward-Port-Of: odoo/enterprise#68756
This fix addresses a performance test failure in the Appointment module where database queries were exceeding expected limits. The issue occurred when the Appointment module was tested in isolation, and the fix ensures consistent test conditions by warming up the cache to prevent unexpected query increases from being missed in future updates.
Original PR description
Before the commit the [appointment single module build](https://runbot.odoo.com/runbot/build/66250461) is breaking due to query_count being more than 9 (11) The increase was introduced in b3487219c070cdc03c933d92bc0d362ad733e11f in `_unavailable_intervals_batch`. It wasn't detected because the are less queries in the standard build all modules installed) because of a warmer ormcache. (get_lang) This commit proposes to warmup the test in all case to avoid the extra queries when appointment is installed alone, hopefully avoiding to miss the increased query count next time.