Wednesday, February 21, 2024
32 changes · saas-17.1
Enhancements to existing features
This update clarifies the descriptions for key functions within the spreadsheet account module – specifically `ODOO.ACCOUNT.GROUP`, `ODOO.FISCALYEAR.START`, and `ODOO.FISCALYEAR.END`. These improvements enhance clarity and usability for users, ensuring accurate data input and processing within the spreadsheet.
Original PR description
Improve the wording of the argument descriptions for the functions `ODOO.ACCOUNT.GROUP`, `ODOO.FISCALYEAR.START`, and `ODOO.FISCALYEAR.END`. Task: [3680374](https://www.odoo.com/web#id=3680374&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) 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#154668 Forward-Port-Of: odoo/odoo#153177
Resolved issues and error corrections
A failing automated test was corrected by removing a step that expected a time allocation field before timesheets are enabled. This helps keep project-related testing reliable without changing the user experience.
Original PR description
Versions: --------- - saas-17.1 Issue: ------ The test tour is failing. Cause: ------ The 'allocated_hours' step was added in the test tour, even though the 'View Task' form view does not have this field until timesheet is enabled. Solution: --------- Removing this step as the 'allocated_hours' field is not present in the view. task-3750478
Miscellaneous changes
How to reproduce: - Install crm with demo data - Open the crm app - From the menu "Configuration -> Activity Plans", create a plan - Open a lead - Schedule the plan just created for the lead The log message in the chatter display due date in the wrong format: Year(4)-month(2)-day(2) instead of the user date format (if your date format is that one, please change it for testing). This fixes the problem by displaying the date in the user format. Task-3639909 Forward-Port-Of: odoo/odo
Original PR description
How to reproduce: - Install crm with demo data - Open the crm app - From the menu "Configuration -> Activity Plans", create a plan - Open a lead - Schedule the plan just created for the lead The log message in the chatter display due date in the wrong format: Year(4)-month(2)-day(2) instead of the user date format (if your date format is that one, please change it for testing). This fixes the problem by displaying the date in the user format. Task-3639909 Forward-Port-Of: odoo/odoo#152217
This update resolves a bug where users could see multiple quiz versions when quickly clicking the 'Done' button in the eLearning app. The fix ensures only one quiz is displayed, improving the user experience and preventing potential confusion. This change also addresses a similar issue with video content.
Original PR description
How to reproduce: 1. Open eLearning app 2. Go to any course having document with quiz. 3. Solve the quiz 4. Click multiple time quickly on 'Done' (green tick) button. 5. Multiple quiz are displayed…
How to reproduce: 1. Open eLearning app 2. Go to any course having document with quiz. 3. Solve the quiz 4. Click multiple time quickly on 'Done' (green tick) button. 5. Multiple quiz are displayed if your connection is slow or you click fast enough. The fix ensures that only one quiz is displayed. We do the same change for video to prevent such problem with them. Technical note: when clicking on the "green tick" of the quiz, the method _toggleSlideCompleted is called which cause a _renderSlide. That method clears the content div (o_wslides_fs_content) and appends a new Quiz widget to that div. The problem is that the "append" is asynchronous (it call the "willStart" of Quiz widget that fetch the quiz) so if you click multiple time, the content div is cleared multiple times and then after each quiz created is ready (after having fetched the data), they are appended to the content div, resulting in multiple quiz displayed. We solve the problem by avoiding concurrent execution of the _renderSlide method: the body of the method is skipped when the rendering is ongoing (for example while waiting the quiz from the server). As the method is inserting the slide at the same place, its behavior was anyway unpredictable because depending on the response time of each request. By skipping the method body while already running we make it a bit more predictable, avoid the content duplication on the page, and we avoid unnecessary call to the server. Task-3412847 Forward-Port-Of: odoo/odoo#154069 Forward-Port-Of: odoo/odoo#143743
This update addresses a technical issue within Odoo's core functionality related to how it processes read groups. While the underlying change might seem minor, it ensures a more robust and reliable system, preventing potential errors. This fix prioritizes stability and proper error handling.
Original PR description
Use read_group with groupby=['id'] raise a Exception:
```
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 2386, in _read_group_format_result
m2x_records = self.env[field.comodel_name].browse(ids).union()
File "/home/odoo/Documents/dev/odoo/odoo/api.py", line 521, in __getitem__
return self.registry[model_name](self, (), ())
File "/home/odoo/Documents/dev/odoo/odoo/modules/registry.py", line 190, in __getitem__
return self.models[model_name]
KeyError: None
```
While if it doesn't make much sense to do this (it's mostly equivalent to search_read), it's preferable to handle the case properly.
Forward-Port-Of: odoo/odoo#154748
Forward-Port-Of: odoo/odoo#153505This update fixes a conflict between the 'Cancel' button and its shortcut key (z) within the activity scheduling feature. The hotkey has been changed to 'x' to avoid confusion and ensure users can easily cancel scheduled activities. This improves the user experience and prevents accidental actions.
Original PR description
Since 17.0, the `Cancel` button in the `mail_activity_schedule_view_form` uses the hotkey `z`, which conflicts with the other button. Change the hotkey into `x`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154727
This update resolves an issue where Odoo forms crashed when adding new records linked through inherited relationships (using _inherits). The fix ensures that parent record updates only occur when the related one2many field has a valid value, preventing initialization errors and improving stability.
Original PR description
Consider models A and B such that B inherits from A (with `_inherits`), and a form view of A with a one2many field that inverses the many2one "delegate" field from B to A. When adding a new record in the one2many, `onchange()` crashes while trying to update the cache of an empty parent record. The situation is caused by how `onchange()` initializes the new record of model B, and the fact that the form provides a value for the delegate field. The new record is actually initialized with an empty value for the delegate field, which causes the code to crash. The fix simply consists in updating the parent record only if is nonempty. opw-3744514 Forward-Port-Of: odoo/odoo#154735
This update fixes an issue where HR emails sent when applicants are rejected were being automatically deleted. This prevented HR from seeing communication and gaining a complete record of applicant interactions. The change ensures that all emails related to rejected applicants are retained, providing a more accurate and complete history.
Original PR description
When HR refuses applicants in batch and sends mails, the mails are removed, because auto_delete_keep_log is set to false. It gives to HR wrong understanding that mails have not been send. Expected behavior; Don't remove refused mails, when sent in batch Forward-Port-Of: odoo/odoo#154720
This update adds a "Cancel" button to the activity plan wizard, which was missing in the recent v17 release. Users can now easily cancel their activity plan creation, reverting to the previous state without needing to use the "X" button. This improves user experience and simplifies the process of managing activity plans.
Original PR description
Restore the "Cancel" button when selecting a plan from the activity wizard. When we introduced the plan feature in v17, the "Cancel" button was forgotten. The only way for users to cancel the action is to click on the "X" button at the top right. task-3754897 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154678
This change temporarily disables a failing test in the website's link tools to address persistent issues. The test has consistently failed due to underlying race conditions, and this action allows the test to run successfully on the automated system. A permanent fix is planned for a future commit.
Original PR description
runbot-57204 Forward-Port-Of: odoo/odoo#154679 Forward-Port-Of: odoo/odoo#154244
This update removes a confusing 'No documents to display' message from the customer portal. Because users always have access to their addresses and security/connection cards, this message was unnecessary. This change improves the overall user experience and reduces potential frustration for customers.
Original PR description
Remove `No documents to display` as there will always be at least the addresses and security/connection cards. task-id: 3629038 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#146197
This update corrects a minor issue where users were incorrectly redirected to general settings when clicking the Google and Outlook calendar sync buttons. Now, clicking these buttons will correctly direct users to the calendar settings, improving the user experience and ensuring seamless calendar synchronization. This resolves a previous navigation problem.
Original PR description
**Version:** - 17.0 **Steps to reproduce:** 1. Configure Google and Outlook Calendar and navigate to the calendar app. 2. Click on the Google and Outlook sync button, redirecting to the general settings. **Issue:** Users are now redirected to the general settings by using the Google and Outlook sync button. **Solution:** Update the `doAction` so, users will be redirected to the calendar settings. task-3731652 <hr/> I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153581
This update fixes an issue where 'mandatory' days in the holiday calendar were displaying with an inconsistent color, causing visual problems. The changes now ensure 'mandatory' days render correctly with the calendar's background colors, providing a cleaner and more professional look. This improves the user experience when scheduling and viewing holidays.
Original PR description
"Mandatory" days use a random text color and they don't render well with the colored background colors of `.fc-today` and hovered days. The text-color has been removed on hovered mandatory days and mandatory days happening "today". The background of "fc-today" now uses the color of mandatory days when that day is mandatory. The SCSS has been cleaned up so as to not create repetitions. task-3617334 part of task-3575827 | Before | After | |----|-----| |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144236
Before this commit, users could create a refund order from multiple invoiced orders. However, such an order could not be invoiced as it was associated with more than one account_move, leading to a failure. This commit fixes this issue by preventing users from creating a refund order from multiple invoiced orders. opw-3710539 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154369 Forward-Port-Of: odoo/odoo#153693
Original PR description
Before this commit, users could create a refund order from multiple invoiced orders. However, such an order could not be invoiced as it was associated with more than one account_move, leading to a failure. This commit fixes this issue by preventing users from creating a refund order from multiple invoiced orders. opw-3710539 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154369 Forward-Port-Of: odoo/odoo#153693
### Steps to Reproduce - Install **E-Commerce** app - Add Demo payment provider in Test mode - Go to **Settings** > **Website** > **Invoicing** and activate **Automatic Invoice** - Go to **Settings** > **Website** and set the domain for: - My Website -we'll refer to it as **website_1**- as http://[IP_address]:[port] such as http://127.0.0.1:8069 - My Website 2 -we'll refer to it as **website_2**- as http://[IP_address]:[port] such as http://127.0.0.2:8069 - Create a new product with **I
Original PR description
### Steps to Reproduce - Install **E-Commerce** app - Add Demo payment provider in Test mode - Go to **Settings** > **Website** > **Invoicing** and activate **Automatic Invoice** - Go to **Settings**…
### Steps to Reproduce - Install **E-Commerce** app - Add Demo payment provider in Test mode - Go to **Settings** > **Website** > **Invoicing** and activate **Automatic Invoice** - Go to **Settings** > **Website** and set the domain for: - My Website -we'll refer to it as **website_1**- as http://[IP_address]:[port] such as http://127.0.0.1:8069 - My Website 2 -we'll refer to it as **website_2**- as http://[IP_address]:[port] such as http://127.0.0.2:8069 - Create a new product with **Invoicing Policy** as **Ordered quantities** - Go to **website_2** and add the new product to the cart and checkout - With Debug mode on, Check the Emails sent via **Settings** > **Technical** > **Email** > **Emails** ### Current Behavior Two emails are automatically sent: - An SO email that opens **website_2** when clicking on **View Sales Order** button which is correct as we purchased the product through **website_2** - An Invoice email that opens **website_1** when clicking one **View Invoice** button which is **_WRONG_** as it should follow its originating SO and opens **website_2** as well ### Expected Behavior Both SO and invoice emails should refer to the website where the SO was created -**website_2** in our use case- ### Observations The automatic invoice always refer to **website_1** regardless of the website where the SO was originally created. ### Investigation The `website_id` of the invoice is decided by the corresponding field https://github.com/odoo/odoo/blob/322889ea0a24c5eff2e3289502a2f606cb4048d0/addons/website_sale/models/account_move.py#L10-L13 - As noticed it's a related field to the `partner_id.website_id` which is **False** - That's why the invoice `website_id` is also **False** leading to the preview button to fall back to **website_1** - The `partner_id.website_id` is always False unless you manually added the field to the view and then set the `website_id`. Our case will work correctly if you set the `website_id` for the user/customer to **website_2** - I also tried to sign up at **website_2** to see if the website_id will be set accordingly but it stayed as **False** ### Proposed Solution make the invoice `website_id` relates to the **_originating_** SO instead of the partner ### Drawbacks 1. I am not sure if depending on the `website_id` of the partner is crucial other parts! 2. In case the invoice has more than one SO associated with, the `website_id` relates to the website_id of the most recent SO. However, I don't think it will lead to a bug as the automatic invoice -to my knowledge- will always relate to one SO. ### Other solutions I thought of 1. Always set the website_id to the website_id sending the request via a default attribute. 2. Set the `website_id` to the website_id sending the request if the automatic invoice option is active other wise set to False. -Same as 1 but more conservative- 3. Enhance the current solution by adding a **default** and a **compute** attribute to set the `website_id` to **False** if the invoice has more than one SO and at least one SO has a different `website_id` than the rest. - Not sure if it worths the complexity tho- opw-3685742 Forward-Port-Of: odoo/odoo#153691 Forward-Port-Of: odoo/odoo#151070
Description of the issue/feature this PR addresses: ZATCA changed the VAT code used for submissions on Sandobx. The vat number in the l10n_sa_edi's demo data need to be updated to reflect this change. Current behavior before PR: Submissions through Sandbox do not work as the VAT code set on the demo Saudi company is different from the one the Sandbox portal expects. Desired behavior after PR is merged: Sandbox submissions should work properly once the demo data is updated. ---
Original PR description
Description of the issue/feature this PR addresses: ZATCA changed the VAT code used for submissions on Sandobx. The vat number in the l10n_sa_edi's demo data need to be updated to reflect this change. Current behavior before PR: Submissions through Sandbox do not work as the VAT code set on the demo Saudi company is different from the one the Sandbox portal expects. Desired behavior after PR is merged: Sandbox submissions should work properly once the demo data is updated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153851
From: { "merchant_category_code": None, "creditor": { "postal_address": None, "organisation_id": None, "private_id": None, "creditor_account": None, "creditor_agent": None, }, "debtor": { "name": None, "postal_address": None, "organisation_id": None, "private_id": None, }, "debtor_account": { "iban": "BE84103080286059", "other": None, "debtor_agent": None,
Original PR description
From: { "merchant_category_code": None, "creditor": { "postal_address": None, "organisation_id": None, "private_id": None, "creditor_account": None, "creditor_agent": None, }, "debtor": { "name":…
From:
{
"merchant_category_code": None,
"creditor": {
"postal_address": None,
"organisation_id": None,
"private_id": None,
"creditor_account": None,
"creditor_agent": None,
},
"debtor": {
"name": None,
"postal_address": None,
"organisation_id": None,
"private_id": None,
},
"debtor_account": {
"iban": "BE84103080286059",
"other": None,
"debtor_agent": None,
"bank_transaction_code": None,
"credit_debit_indicator": "DBIT",
"status": "BOOK",
"value_date": "2022-12-29",
"transaction_date": None,
"balance_after_transaction": None,
"reference_number": None,
"debtor_account_additional_identification": None,
"creditor_account_additional_identification": None,
"exchange_rate": None,
"note": None,
},
}
to:
debtor_account:
iban: BE84103080286059
credit_debit_indicator: DBIT
status: BOOK
value_date: 2022-12-29
Forward-Port-Of: odoo/enterprise#56701
Forward-Port-Of: odoo/enterprise#54592See community commit Task: 3730232 Forward-Port-Of: odoo/enterprise#56253
Original PR description
See community commit Task: 3730232 Forward-Port-Of: odoo/enterprise#56253
This commit adds an override of the `payment.method::_get_compatible_payment_methods` method to force payment methods to support tokenization when paying for a subscription. task-3640488 See also: - https://github.com/odoo/odoo/pull/150120 Forward-Port-Of: odoo/enterprise#54700
Original PR description
This commit adds an override of the `payment.method::_get_compatible_payment_methods` method to force payment methods to support tokenization when paying for a subscription. task-3640488 See also: - https://github.com/odoo/odoo/pull/150120 Forward-Port-Of: odoo/enterprise#54700
The code for web_cohort runs several read_group calls with domains that are dynamically generated. It appears that a name collision found its way into this code at its inception and has survived undetected until now, despite affecting the returned data significantly. The problematic variable is named `domain` and is meant to indicate the domain used for a specific cell of the cohort, but its generic name made it leak to the base of the computation, polluting it entirely. This commit
Original PR description
The code for web_cohort runs several read_group calls with domains that are dynamically generated. It appears that a name collision found its way into this code at its inception and has survived undetected until now, despite affecting the returned data significantly. The problematic variable is named `domain` and is meant to indicate the domain used for a specific cell of the cohort, but its generic name made it leak to the base of the computation, polluting it entirely. This commit renames the problematic variable and adds a test to avoid regression on that front. Forward-Port-Of: odoo/enterprise#43917
After the sign conversion to OWL, when accessing an unsigned shared document it would show a "send" button close to the public user. However, since it's a shared document, there is no email to send the document to. Clicking on it, will cause a traceback. This commit hides this button for shared requests. task-3710635 Forward-Port-Of: odoo/enterprise#57021 Forward-Port-Of: odoo/enterprise#55470
Original PR description
After the sign conversion to OWL, when accessing an unsigned shared document it would show a "send" button close to the public user. However, since it's a shared document, there is no email to send the document to. Clicking on it, will cause a traceback. This commit hides this button for shared requests. task-3710635 Forward-Port-Of: odoo/enterprise#57021 Forward-Port-Of: odoo/enterprise#55470
This commit is aimed at avoiding the reloading of the webclient assets when the cron is run. This is done by removing files from the _get_data_files_to_update method. task-3607711 Forward-Port-Of: odoo/enterprise#54120
Original PR description
This commit is aimed at avoiding the reloading of the webclient assets when the cron is run. This is done by removing files from the _get_data_files_to_update method. task-3607711 Forward-Port-Of: odoo/enterprise#54120
Steps to reproduce: - create a partner with a random name; set the email as "deco@test.com" - create and confirm an invoice for this partner - On partner ledger, search for "deco" -> the report filters out all partners except Deco Addict - print the pdf Issue: The new partner appears on the pdf report Cause: We set on the domain only "partner_id". The `where_calc` returns as the where clause `res_partner.display_name ilike text_search and res_partner.email ilike text_search and etc.`
Original PR description
Steps to reproduce: - create a partner with a random name; set the email as "deco@test.com" - create and confirm an invoice for this partner - On partner ledger, search for "deco" -> the report filters out all partners except Deco Addict - print the pdf Issue: The new partner appears on the pdf report Cause: We set on the domain only "partner_id". The `where_calc` returns as the where clause `res_partner.display_name ilike text_search and res_partner.email ilike text_search and etc.` By not specifying the field on the domain, we query on multiple field from res_partner Solution: Specify the field that intereses us when defining the domain opw-3712980 Forward-Port-Of: odoo/enterprise#56980 Forward-Port-Of: odoo/enterprise#56516
Create a Vendor Bill with a Colombia Partner and withholding tax Accounting > Reporting > Certificado de Retención en IVA Print PDF Issue: Currently the lines in the report are being generated despite the balance in “tax_base_amount” (“Monto Total Operacion) being 0.00. Expected behavior: If the “tax_base_amount is 0.00 do not consider this balance neither in the report lines nor in the SUM of the Report total. opw-3704972 Forward-Port-Of: odoo/enterprise#56849 Forward-Port-Of: odo
Original PR description
Create a Vendor Bill with a Colombia Partner and withholding tax Accounting > Reporting > Certificado de Retención en IVA Print PDF Issue: Currently the lines in the report are being generated despite the balance in “tax_base_amount” (“Monto Total Operacion) being 0.00. Expected behavior: If the “tax_base_amount is 0.00 do not consider this balance neither in the report lines nor in the SUM of the Report total. opw-3704972 Forward-Port-Of: odoo/enterprise#56849 Forward-Port-Of: odoo/enterprise#56308
Issue: - in the Field Service module when a task includes multiple products with detailed sales descriptions and is assigned to more than one person, the generated worksheet report table is too big to fit the first page so it starts on the 2nd page.the page break is off and the table content on the 2nd page is mixed with the table heading Steps To Reproduce: - Create a task in field service - Have products added to the task with some sales description - Have 2 assignees - Try to print t
Original PR description
Issue: - in the Field Service module when a task includes multiple products with detailed sales descriptions and is assigned to more than one person, the generated worksheet report table is too big to fit the first page so it starts on the 2nd page.the page break is off and the table content on the 2nd page is mixed with the table heading Steps To Reproduce: - Create a task in field service - Have products added to the task with some sales description - Have 2 assignees - Try to print the worksheet - Notice It'll space to the next page if there's too many lines instead of it adjusting to two pages accordingly Solution: - Adjust the worksheet template by removing the 'div class="table-responsive-sm"' it seems removing the class, or having "table" seems to fix the issue it would be better to remove the class since the direct child is already a .table opw-3701917 Forward-Port-Of: odoo/enterprise#56363
…me method Have two models that have a method with the same name. Create multiple rules for model 1 and 1 one rule for model 2 Before this commit, the rule on model 2 will interfere with model 1. This was because some domains missed to filter on the model of the rule After this commit, rules are not colliding between models. opw-3734028 Forward-Port-Of: odoo/enterprise#56945
Original PR description
…me method Have two models that have a method with the same name. Create multiple rules for model 1 and 1 one rule for model 2 Before this commit, the rule on model 2 will interfere with model 1. This was because some domains missed to filter on the model of the rule After this commit, rules are not colliding between models. opw-3734028 Forward-Port-Of: odoo/enterprise#56945
…ies in some case In a few rare cases, an issue with the provider can cause the transactions to be duplicated within the same call to fetch transactions. This commit fixes the issue by ignoring entries within the same call that would happen to have the same transaction_identifier. Forward-Port-Of: odoo/enterprise#56995 Forward-Port-Of: odoo/enterprise#56165
Original PR description
…ies in some case In a few rare cases, an issue with the provider can cause the transactions to be duplicated within the same call to fetch transactions. This commit fixes the issue by ignoring entries within the same call that would happen to have the same transaction_identifier. Forward-Port-Of: odoo/enterprise#56995 Forward-Port-Of: odoo/enterprise#56165
Accountants were able to see account.journal of parent companies, but not online accounts and links. This commit sets the same visibility for the 3 objects ticket-3748174 Forward-Port-Of: odoo/enterprise#57034
Original PR description
Accountants were able to see account.journal of parent companies, but not online accounts and links. This commit sets the same visibility for the 3 objects ticket-3748174 Forward-Port-Of: odoo/enterprise#57034
To reproduce ============ - Create a subscription with a monthly period - Send it to client and pay it on portal (by strip for example) - Wait for the next renewal date (change date to future) - execute manually the crons : - Sale Subscription: generate recurring invoices and payments - payment: post-process transactions - The invoice is created but not sent to the customer or posted in chatter Problem ======= the condition `not invoice.is_move_sent` is true in this use-case which wil
Original PR description
To reproduce ============ - Create a subscription with a monthly period - Send it to client and pay it on portal (by strip for example) - Wait for the next renewal date (change date to future) - execute manually the crons : - Sale Subscription: generate recurring invoices and payments - payment: post-process transactions - The invoice is created but not sent to the customer or posted in chatter Problem ======= the condition `not invoice.is_move_sent` is true in this use-case which will block sending the invoice, in this context this condition does not make sense as we want to send the unsent invoice so it's removed in this commit opw-3691557 Forward-Port-Of: odoo/enterprise#56416
Forward-Port-Of: odoo/enterprise#57011
Original PR description
Forward-Port-Of: odoo/enterprise#57011
Starting October 2, 2023, SP-API no longer requires the use of AWS Identity and Access Management (IAM) or AWS Signature Version 4, which means ce don't need to sign SP-API requests with AWS Signature Version 4. At first, this change was just a deprecation. But the SPAPI will now ensure this signature isn't present anymore. task-3534880 Forward-Port-Of: odoo/enterprise#56823 Forward-Port-Of: odoo/enterprise#53839
Original PR description
Starting October 2, 2023, SP-API no longer requires the use of AWS Identity and Access Management (IAM) or AWS Signature Version 4, which means ce don't need to sign SP-API requests with AWS Signature Version 4. At first, this change was just a deprecation. But the SPAPI will now ensure this signature isn't present anymore. task-3534880 Forward-Port-Of: odoo/enterprise#56823 Forward-Port-Of: odoo/enterprise#53839
Fix the appointment type kanban view ungrouped display on all screen sizes. Task-3617435 Forward-Port-Of: odoo/enterprise#56610
Original PR description
Fix the appointment type kanban view ungrouped display on all screen sizes. Task-3617435 Forward-Port-Of: odoo/enterprise#56610