Each payment acquirer has its own implementation specificities: some implement a 'payment with redirection' flow and others a 'direct payment flow'; sometimes the 'payment with redirection' flow is even implemented as a 'direct payment' flow through an iframe; one payment acquirer could support webhooks while another does not and relies on another mechanism to fetch payment status updates...

It can be tricky to guess where to look in the code to determine how a payment acquirer is implemented.

On top of that, the online payments ecosystem evolves at a fast pace due to competition, buyouts, and legislation enforcement. Acquirers are thus frequently migrated to new APIs that might differ in implementation from the previous API.

To help figure out the *which*, *why*, *how*, and *when* of payment API implementations, a README.md file is added to the main directory of all payment acquirer modules. They can be browsed in human-readable format on GitHub.

task-2374916

See also:
- https://github.com/odoo/enterprise/pull/56182

Forward-Port-Of: odoo/odoo#156084
Forward-Port-Of: odoo/odoo#153016

User settings is used to store user's preferences, in web we use it to store the home menus apps order and in mail for various settings like push to talk key, discuss sidebar preferences, etc.

Before this commit, the `setUserSettings` method from the user service overrided all the previous key that has not been changed because it kept only the changed keys returned by the backend. Leading to preferences being lost during the session when reordering the home menu apps.

With this commit, we keep the previous keys that have not been changed.

Steps to reproduce:

- Go to the home menu
- In the Owl devtool check the settings object from the user service:
```JavaScript
{
    "id": 1,
    "user_id": {
        "id": 2
    },
    "is_discuss_sidebar_category_channel_open": true,
    "is_discuss_sidebar_category_chat_open": true,
    "push_to_talk_key": false,
    "use_push_to_talk": false,
    "voice_active_duration": 0,
    "volume_settings_ids": [
        [
            "ADD",
            []
        ]
    ],
    "homemenu_config": "[\"mail.menu_root_discuss\",\"room.room_menu_root\",\"calendar.mail_menu_calendar\",\"appointment.main_menu_appointments\",\"project_todo.menu_todo_todos\",\"membership.menu_association\",\"knowledge.knowledge_menu_root\",\"contacts.menu_contacts\",\"frontdesk.frontdesk_menu_root\",\"point_of_sale.menu_point_root\",\"crm.crm_menu_root\",\"sale.sale_menu_root\",\"spreadsheet_dashboard.spreadsheet_dashboard_menu_root\",\"sale_subscription.menu_sale_subscription_root\",\"sale_renting.rental_menu_root\",\"pos_preparation_display.menu_point_kitchen_display_root\",\"account_accountant.menu_accounting\",\"documents.menu_root\",\"project.menu_main_pm\",\"hr_timesheet.timesheet_menu_root\",\"industry_fsm.fsm_menu_root\",\"planning.planning_menu_root\",\"helpdesk.menu_helpdesk_root\",\"website.menu_website_configuration\",\"website_slides.website_slides_menu_root\",\"social.menu_social_global\",\"marketing_automation.marketing_automation_menu\",\"mass_mailing.mass_mailing_menu_root\",\"mass_mailing_sms.mass_mailing_sms_menu_root\",\"event.event_main_menu\",\"survey.menu_surveys\",\"purchase.menu_purchase_root\",\"stock.menu_stock_root\",\"mrp.menu_mrp_root\",\"mrp_workorder.menu_mrp_workorder_root\",\"quality_control.menu_quality_root\",\"stock_barcode.stock_barcode_menu\",\"maintenance.menu_maintenance_title\",\"repair.menu_repair_order\",\"mrp_plm.menu_mrp_plm_root\",\"account_consolidation.menu_consolidation\",\"sign.menu_document\",\"hr.menu_hr_root\",\"hr_work_entry_contract_enterprise.menu_hr_payroll_root\",\"hr_appraisal.menu_hr_appraisal_root\",\"hr_attendance.menu_hr_attendance_root\",\"hr_recruitment.menu_hr_recruitment_root\",\"hr_referral.menu_hr_referral_root\",\"fleet.menu_root\",\"hr_holidays.menu_hr_holidays_root\",\"hr_expense.menu_hr_expense_root\",\"lunch.menu_lunch\",\"im_livechat.menu_livechat_root\",\"data_recycle.menu_data_cleaning_root\",\"approvals.approvals_menu_root\",\"whatsapp.whatsapp_menu_main\",\"iot.iot_menu_root\",\"base.menu_management\",\"base.menu_tests\",\"base.menu_administration\"]",
    "voip_username": false,
    "voip_secret": false,
    "should_call_from_another_device": false,
    "external_device_number": false,
    "should_auto_reject_incoming_calls": false,
    "how_to_call_on_mobile": "ask",
    "is_discuss_sidebar_category_whatsapp_open": true,
    "onsip_auth_username": false,
    "livechat_username": false,
    "livechat_lang_ids": [],
    "is_discuss_sidebar_category_livechat_open": true
}
```
- Reorder an app in the home menu and check again the settings object:
```JavaScript
{
    "id": 1,
    "homemenu_config": "[\"mail.menu_root_discuss\",\"room.room_menu_root\",\"project_todo.menu_todo_todos\",\"calendar.mail_menu_calendar\",\"appointment.main_menu_appointments\",\"membership.menu_association\",\"knowledge.knowledge_menu_root\",\"contacts.menu_contacts\",\"frontdesk.frontdesk_menu_root\",\"point_of_sale.menu_point_root\",\"crm.crm_menu_root\",\"sale.sale_menu_root\",\"spreadsheet_dashboard.spreadsheet_dashboard_menu_root\",\"sale_subscription.menu_sale_subscription_root\",\"sale_renting.rental_menu_root\",\"pos_preparation_display.menu_point_kitchen_display_root\",\"account_accountant.menu_accounting\",\"documents.menu_root\",\"project.menu_main_pm\",\"hr_timesheet.timesheet_menu_root\",\"industry_fsm.fsm_menu_root\",\"planning.planning_menu_root\",\"helpdesk.menu_helpdesk_root\",\"website.menu_website_configuration\",\"website_slides.website_slides_menu_root\",\"social.menu_social_global\",\"marketing_automation.marketing_automation_menu\",\"mass_mailing.mass_mailing_menu_root\",\"mass_mailing_sms.mass_mailing_sms_menu_root\",\"event.event_main_menu\",\"survey.menu_surveys\",\"purchase.menu_purchase_root\",\"stock.menu_stock_root\",\"mrp.menu_mrp_root\",\"mrp_workorder.menu_mrp_workorder_root\",\"quality_control.menu_quality_root\",\"stock_barcode.stock_barcode_menu\",\"maintenance.menu_maintenance_title\",\"repair.menu_repair_order\",\"mrp_plm.menu_mrp_plm_root\",\"account_consolidation.menu_consolidation\",\"sign.menu_document\",\"hr.menu_hr_root\",\"hr_work_entry_contract_enterprise.menu_hr_payroll_root\",\"hr_appraisal.menu_hr_appraisal_root\",\"hr_attendance.menu_hr_attendance_root\",\"hr_recruitment.menu_hr_recruitment_root\",\"hr_referral.menu_hr_referral_root\",\"fleet.menu_root\",\"hr_holidays.menu_hr_holidays_root\",\"hr_expense.menu_hr_expense_root\",\"lunch.menu_lunch\",\"im_livechat.menu_livechat_root\",\"data_recycle.menu_data_cleaning_root\",\"approvals.approvals_menu_root\",\"whatsapp.whatsapp_menu_main\",\"iot.iot_menu_root\",\"base.menu_management\",\"base.menu_tests\",\"base.menu_administration\"]"
}
```

Forward-Port-Of: odoo/odoo#155902

Before this commit, if a product had a discount applied in two different orders, it could lead to incorrect calculations in the report For instance, if a product priced at 14.45 had a 30% discount applied, the discounted value would be 10.115, which rounds to 10.12. However, if there were two orders with the same discount, the report calculation would count the quantity of a product with the same discount and calculate the product total amount in one place. This would result in a discounted value of 10.115 * 2 = 20.23, while in the two different orders we had two 10.12 which sums to 20.24.

With this commit, the calculation method has been changed. Now, the product amount total for each line is calculated first, and then the sum of these amounts is used to calculate the total for all of the orders. This change ensures accurate computation of the product total sum when discounts are applied across multiple orders.

opw-3721376

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#156044
Forward-Port-Of: odoo/odoo#155899

Fix race-condition when a directory is created by two processes (python's os.py handles it for all directories, but not for the last one). Happens sometimes when generating assets for the first time (CSS, JS); one of the two times might crash.

Traceback : 
```FileExistsError: [Errno 17] File exists: '/home/odoo/.local/share/Odoo/filestore/brawl-stars/7d'
  File "odoo/http.py", line 2251, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1826, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1847, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1824, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1832, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2057, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 740, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 34, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 30, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/website/models/website.py", line 431, in configurator_apply
    redirect_url = theme.button_choose_theme()
  File "addons/website/models/ir_module_module.py", line 399, in button_choose_theme
    self._theme_remove(website)
  File "addons/website/models/ir_module_module.py", line 375, in _theme_remove
    self.env['theme.utils'].with_context(website_id=website.id)._reset_default_config()
  File "addons/website/models/theme_models.py", line 259, in _reset_default_config
    self.env['web_editor.assets'].make_scss_customization(
  File "addons/website/models/assets.py", line 38, in make_scss_customization
    self.make_scss_customization('/website/static/src/scss/options/colors/user_theme_color_palette.scss', {
  File "addons/website/models/assets.py", line 143, in make_scss_customization
    self.save_asset(url, 'web.assets_frontend', updatedFileContent, 'scss')
  File "addons/web_editor/models/assets.py", line 77, in save_asset
    self.env["ir.attachment"].create(new_attach)
  File "<decorator-gen-292>", line 2, in create
  File "odoo/api.py", line 420, in _model_create_multi
    return create(self, [arg])
  File "addons/website/models/ir_attachment.py", line 23, in create
    return super().create(vals_list)
  File "<decorator-gen-61>", line 2, in create
  File "odoo/api.py", line 421, in _model_create_multi
    return create(self, arg)
  File "odoo/addons/base/models/ir_attachment.py", line 636, in create
    values.update(self._get_datas_related_values(
  File "odoo/addons/base/models/ir_attachment.py", line 277, in _get_datas_related_values
    values['store_fname'] = self._file_write(data, values['checksum'])
  File "odoo/addons/base/models/ir_attachment.py", line 132, in _file_write
    fname, full_path = self._get_path(bin_value, checksum)
  File "odoo/addons/base/models/ir_attachment.py", line 112, in _get_path
    os.makedirs(dirname)
  File "os.py", line 225, in makedirs
    mkdir(name, mode)
```

sentry-4417110945

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#156232

Steps to Reproduce :
- install sales, stock modules
- go to products and create new
- select product type as Event Ticket,Event Booth or Gift Card
- Landed cost boolean is suppose to be visible for a service type product under purchase.

Issue :
- Landed cost boolean is suppose to be visible for a service type product under purchase, But currently it is visible on other type of products specific to other models like event tickets, event booths etc.

Cause:
- In product Module there are two Selection fields like detailed_type and type. The detailed_type Selection field contain service, consumable, event booths, event tickets, storable product  And the type selection field contains service, consumable, storable product
- In xml views for that landed cost boolean the invisible  attribute contains the condition like  type != service, because of this the landed cost boolean is visible for the product type of event tickets, event booths and gift Cards.

Solution:
- if we use detailed_type instead of type selection field, then the landed cost boolean field  will be invisible on other product types.

 task- 3725202

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#156133
Forward-Port-Of: odoo/odoo#153371

Currently the field `Kode Transaksi` can be found inside the accounting tab. This fix will move it under the tax field. `Kode Transaksi` is a field that should be used in the sale flow and is currently unavailabe for sales team.

Steps to reproduce:
-------------------
* Install **l10n_id**
* Create a company with indonesian localization
* Switch to that company
* Creat a contact
* Toggle the checkbox next to `Tax ID`
* Under the `Accounting` tab, you can find `Kode transaksi`. Sales team don't have access to the accounting tab, and thus not to `Kode transaksi` either.

Why the fix:
------------
Technically what we want here is to have the field for `Kode Transaksi` after the `vat` field from this view

https://github.com/odoo/odoo/blob/04593b265b765f7a6ee079f21bad6a1cf0e5d094/odoo/addons/base/views/res_partner_views.xml#L205-L210

Two possible solutions for this fix:
* Fetch the path to `group/group` and put the field inside.
* Fetch the path to the `vat` field and put the field after. This would also require to change the priority of the view starting from saas-16.3 because the `vat` field is being moved in this view:

  https://github.com/odoo/odoo/blob/8ccde3f101cdb6ca41fe29cc5b4252f13745774a/addons/base_vat/views/res_partner_views.xml#L14-L18

  By changing the priority, it would allow for `Kode transaksi` to be place after the `vat_vies_container`. Else it would be inside, which does not make sense inthis case.

opw-3731357

Forward-Port-Of: odoo/odoo#156005
Forward-Port-Of: odoo/odoo#155515

**Steps to reproduce:**
- Create a survey and enable all questions in 1 page
- Add questions. (Minimum 1 Multiple Lines Text Box)
- Test the survey
- Fill the text area with a certain amount of data vertically
- Now, hold the icon to resize the text area block
- It's overlapping with other questions.

**Issue:**

Fixed `height:1px` is applied to Parent div.

**Technical Reason:**

With this commit (https://github.com/odoo/odoo/commit/eaacaf122dff62adcdf885f0ffdcb4a506bded27) the height is applied to the parent div and textarea which is the same for the backend(title of the survey) and frontend. Now backend needs to apply this height to the parent and text area because it has to show all data in the text area but, in the frontend, if we change the height of the textarea then while pressing enter the textarea block increases, and this should not happen.

**Solution:**

So, applying the `h-auto` class to the parent div of textarea. Now, the questions did not overlap with each other.

**Task**-3707415

Forward-Port-Of: odoo/odoo#152182

Current Behavior:
-
Traceback when printing the BOM overview.

Expected behavior:
-
Generates a PDF of the BOM overview even if the information displayed is entirely relevant.

Steps to reproduce:
-
Inventory > Configuration > Products > Attributes

Create an attribute with Variants Creation Mode set to "Dynamically".

Create a new product with this single attribute and multiple values.

Create a BOM for this product with BOM Type set to "Subcontracting".

Print the BOM overview.

Cause of the issue:
-
Creating such a product generates a 'product.template' that is not associated to any variant and hence does not correspond to any 'product.product'. As a result the function `_get_bom_data` can not apply the method `_select_seller` properly in that case. 

Notes:
-
 - There is no error if a variant was manually created for that product.
 - If the Variants Creation Mode set to "Dynamically" a variant is still automatically created to be associated to the product tempalte so that the erro does not rise.

Fix:
-
As the _select_seller method is only defined for product.product and not for product.template, we can not not apply it here. Furhtermore, since the additional informations provided by the override of the method get_bom_data in the the BOM overview will not be relevant without the existence of a variant, we skip this part of the code when the argument of _select_seller is not valid.

opw-3698050
-

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#152275

**Issue Description**:
Currently, the order in which taxes are applied can vary based on the sequence they are entered in the invoice's Taxes field. This inconsistency arises when the tax list is not manually adjusted, leading to each tax having an identical sequence value. As a result, their hierarchy within the `flatten_taxes_hierarchy` function is determined by their input order rather than a defined sequence, causing unpredictable tax calculations. https://github.com/odoo/odoo/blob/56666f8f7858fcbcce466d2240135b35509d2d96/addons/account/models/account_tax.py#L611-L632

A tax sequence should be explicitly defined, and in cases where sequences are identical, organization by tax ID should be enforced.

**Steps to Reproduce**:
1. Navigate to the `Account` or `Invoice` app.
2. Go to `Configuration > Taxes`.
3. Create a new tax with the advanced option `Affect Base of Subsequent Taxes` and specify an amount.
4. Generate a new invoice and add a line item priced at 100.
5. Apply taxes in the `Taxes` column in the following order: 15% followed by the newly created tax, and note the total amount.
6. Repeat step 5, but reverse the order of the taxes.
7. Observe that the total amounts differ between the two sequences.

**Proposed Solution**: 
To ensure that taxes are applied consistently regardless of input order, we will modify the `flatten_taxes_hierarchy` function to add sorting by id. If the sequences are identical, the sorting will depend only on the id, otherwise it will be based on the sequence. This setting ensures a predictable and logical process for applying taxes.

opw-3691765

Forward-Port-Of: odoo/odoo#156031
Forward-Port-Of: odoo/odoo#154167

### Steps to reproduce:
- Install **website_hr_recruitment** module.
- Go to **Recruitment** app.
- Click on **Job Page** button on one of the position cards.
- Click on **Apply Now!** button.
- Click on **Edit** in the upper right corner.
- Remove the LinkedIn Profile, then save.
- Click on **I'm feeling lucky** button to apply the form.
- An error is raised indicating that `Cannot read properties of undefined (reading 'trim')`

### Investigation:
- the linkedin field is grabbed by `const $linkedin_profile = $('#recruitment4');`
- and then is used to check the condition `$linkedin_profile.val().trim() === ''`
- but since the field no longer exists, the `$linkedin_profile.val()` is undefined and hence the error is raised

### The Fix
- The functionality is to allow to apply the form if _**at least one**_ of the **linkedin** or **resume** fields is non-empty
- we a field as empty if it:
	- doesn't exists
	- exists but is value-empty

opw-3754506

Forward-Port-Of: odoo/odoo#155336

Create a sale order having these line values:
- Price Unit   54.45, tax 10% not included
- Price Unit  600.00, tax 10% not included
- Price Unit -500.00, tax 10% not included

Tax total will be:
|name|total|
|---|---|
|Untaxed Amount |154.45|
|Taxes     |      15.44|
|Total    |      169.89|

From the Sales Order create the Invoice

Issue:
Invoice tax totals will be
|name|total|
|---|---|
|Untaxed Amount |154.45|
|Taxes      |     15.45|
|Total       |   169.90|

This occurs because when managing the rounding errors for global
rounding the system 'force' a 1 cent difference on the negative line
that do not need rounding
Example:
Line 1
- current diff: 0.0
- computed tax amount: 5.455
- tax amount + diff: 5.455, after rounding: 5.45
- stored diff for next line: -0.005

Line 2
- current diff: -0.005
- computed tax amount: 60.0
- tax amount + diff: 59.995, after rounding: 60.0
- stored diff for next line: -0.005

Line 3
- current diff: -0.005
- computed tax amount: -50.0
- tax amount + diff: -50.005, after rounding: -50.01

A solution is to not add the diff when the tax line is already rounded

opw-3715229

Forward-Port-Of: odoo/odoo#156016
Forward-Port-Of: odoo/odoo#154861