Before this commit when the filter on the Time Off Dashboard 
is set to "Year" (which is default) and the "Show Weekends" 
filter is toggled, the entire calendar view of the dashboard 
becomes scrambled. It returns to its normal state when the 
page is refreshed.
Also when "Show Weekends" filter is in false state and we 
refresh the page we are getting weekends in calendar view 
of dashboard while the "Show Weekends" filter state remains 
false.

Steps to reproduce :
- Go to Time Off Module
- Click on scale selector and then click on "Show Weekends" filter
- The entire calendar view of the dashboard becomes scrambled

After this commit the calendar view of time off dashboard will 
not be scrambled when we toggle the "Show Weekends" filter. 
Also we will get weekdays in calendar view of dashboard when 
"Show Weekends" filter is in false state and we refresh the page.

Task-4072516

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

### Steps to reproduce the issue:

1. Create a Customer Invoice with two product lines
2. Give a negative price to one of those lines, the total must remain positive
3. Add distinct analytic accounts to each line's analytic_distribution
4. Add a payment term with applicable early discount
5. Confirm and Register Payment
6. Go to the Journal Entry related to the Invoice
7. Check the Invert Tags (developer mode), one of them is set to True, which should not be the case

### Explanation:

In the current situation, `_compute_is_refund` and `_compute_tax_tag_invert` will assign a value to `tax_tag_invert` depending on the `account.move.line.balance`. Because of the distinct analytic accounts, the negative line is separated from the others and because of the logic behind the computes, `tax_tag_invert` is set to the opposite value.

### Fix reasoning:

While `account.payment` are restricted to `account.move` with the same direction, `account.bank.statement.line` are not. In the current case, the affected lines all have `tax_ids` values. Thanks to this, we can use `account.tax.type_tax_use` independently of the line's balance to differentiate in and out transactions and assign `tax_tag_invert` consistently.
We must also consider the case where `account.bank.statement.line`. To target the Early Payment Discount lines, we will separate them from the other values using `display_type`.

opw-3989174

Forward-Port-Of: odoo/odoo#180797
Forward-Port-Of: odoo/odoo#170499

Steps to reproduce:
- Time off > Configuration > Time off types > New
- Set 'Requires Allocation' to 'No Limit'
- Takes leaves of this type
- Set 'Requires Allocation' to 'Yes'
- Approvals > Allocations > New > Select your time off type
- Edit validity period to start after the leaves you took
- Confirm > Click on the newly created allocation
- Displays -X remaining out of Y

The allocations try to cover leaves taken before the requirement was changed, when we'd expect leaves taken under No Limit mode not to require any. This is problematic because it can happen with past leaves as well, which we cannot get rid of on production databases.

Since Odoo does not track which allocation requirement mode leave are taken under nor the date and content of edits to that parameter, we cannot tell apart leaves of the same type when distributing allocated days. Tracking either would certainly require edits to the model which rules out stable versions, so instead the edits to allocation requirement should be restricted in favor of creating new time off types when we want to switch that parameter.

opw-3919886

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

Forward-Port-Of: odoo/odoo#180773
Forward-Port-Of: odoo/odoo#180566

Avoid sending more emails than necessary at events

We want to make sure that in all mails sent from the calendar event, the recipients are only the ones we want and avoid sending them to 'indirect' followers. 

Examples use case:
- Subtype Notes with Default checked.
- Several Attendees set (including several users).
- Each invitation email must be sent only to the corresponding attendee, no one else.
- Each event reminder email must reach only the corresponding attendee, no one else.

Example use case in runbot v16 **before** this change.
![ejemplo-antes](https://github.com/user-attachments/assets/f3987730-324f-4699-9e10-f8226cf92657)

Example use case **after** this change.
![ejemplo-despues](https://github.com/user-attachments/assets/f4eb797e-cd06-4fac-8561-479fd51406aa)

@Tecnativa TT50302

Ping @pedrobaeza and @carlosdauden 

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

Forward-Port-Of: odoo/odoo#180164
Forward-Port-Of: odoo/odoo#174494

[IMP] core: jsonb company dependent fields
use jsonb for company dependent fields
1. field type
	before: company dependent fields were non-stored and computed
	now:    company dependent fields are stored fields whose column type is
	        jsonb with the format like '{"1": val1}'::jsonb

2. fallback
	before: fallbacks of company dependent fields were stored in
	        ir_property.value_xxx `WHERE res_id IS NULL`
	now:    fallbacks are stored in ir_default.json_value in the format of
	        jsonfied write format

3. many2one
	a. field.ondelete
		before: only field.ondelete='set null'
		now:    support field.ondelete='set null' and field.ondelete='restrict'
	b. field.index
		before: no index
		now:    default 'btree_not_null' which index (col IS NOT NULL) for all
		        NOT NULL rows
	c. reference exists
		before: checked when get data from ir_property
		now:    cleaned when orm `unlink`. As a side effect, if a model is
		        referenced by a many2one company dependent field, this model
		        cannot have any field.ondelete='cascade' field. The developer
		        must override the `unlink` method to do the logical on delete
		        cascade in the ORM

4. _field_to_sql
	before: not supported for company dependent fields
	now:    can be used by company dependent fields like normal fields to
	        generate reports

https://github.com/odoo/odoo/pull/175627

task: 3954610

Refactoring of the Print & Send:

Why ?
Invoicing communication channels have multiplied with the advent of electronic invoicing.
Clients want to receive PDF and electronic formats (UBL, Factur-X, Factura-e,...) in different ways
(email, peppol, post, ...), depending on the localization and their needs.
Mandatory B2G declarations of invoices are also multiplying.

The current Print & Send allows for that flexibility, but at the cost of becoming:

- quite messy: you have many checboxes that you can chose at the same time with different
meaning (B2B, B2G, sending method,...)
- hard to use in batch: as you can't setup invoice channel by partner, you need to chose
each time you click on Print & Send. Then some magical things happen to apply the right checkbox
to the right invoices.
- technically complicated: because some options are about format, some about how to send, about
one or more invoices.
- the current solution invites the user to "multiply the channels", by clicking everything
and send his invoices to his customers via all the channels possible. This creates a situation
where E-Invoicing creates a mess for accountants that receive the same invoice via multiple sources,
further causing potential duplicates, double payments, etc.

How ?

- Choose ONE channel of communication per partner to send his invoice (by Post, manual (download),
by Email, by Peppol)
- Synchronize mandatory B2G declaration with invoice sending
- Choose if a B2B E-invoice format needs to be generated (UBL, Factur-X, Factura-e,...)
- Make invoice batching sending easy by applying selected defaults, this also mean B2G declarations
will be applied by default if relevant.
- We also added at partner level the possibility the select an invoice report template, as well as
mail templates.

task-4070132

### Steps to reproduce the issue:

1. Create a Customer Invoice with two product lines
2. Give a negative price to one of those lines, the total must remain positive
3. Add distinct analytic accounts to each line's analytic_distribution
4. Add a payment term with applicable early discount
5. Confirm and Register Payment
6. Go to the Journal Entry related to the Invoice
7. Check the Invert Tags (developer mode), one of them is set to True, which should not be the case

### Explanation:

In the current situation, `_compute_is_refund` and `_compute_tax_tag_invert` will assign a value to `tax_tag_invert` depending on the `account.move.line.balance`. Because of the distinct analytic accounts, the negative line is separated from the others and because of the logic behind the computes, `tax_tag_invert` is set to the opposite value.

### Fix reasoning:

While `account.payment` are restricted to `account.move` with the same direction, `account.bank.statement.line` are not. In the current case, the affected lines all have `tax_ids` values. Thanks to this, we can use `account.tax.type_tax_use` independently of the line's balance to differentiate in and out transactions and assign `tax_tag_invert` consistently.
We must also consider the case where `account.bank.statement.line`. To target the Early Payment Discount lines, we will separate them from the other values using `display_type`.

opw-3989174

Forward-Port-Of: odoo/enterprise#70328
Forward-Port-Of: odoo/enterprise#69835

Steps to reproduce traceback:
1. Create an overseas invoice with `IGST 0`
2. Post the Invoice
3. Create GSTR Report for the following month
4. Click on Generate Button traceback:
```py
Traceback (most recent call last):
  File "/home/odoo/odoo/enterprise/l10n_in_reports_gstr/tests/test_gstr1_report.py", line 233, in test_gstr1_export_with_igst_zero
    gstr1_json = gstr1_report._get_gstr1_json()
  File "/home/odoo/odoo/enterprise/l10n_in_reports_gstr/models/gst_return_period.py", line 1114, in _get_gstr1_json
    'exp': _get_exp_json(AccountMoveLine.search(self._get_section_domain('exp'))),
  File "/home/odoo/odoo/enterprise/l10n_in_reports_gstr/models/gst_return_period.py", line 932, in _get_exp_json
    for line_tax_details in tax_details.values():
AttributeError: 'NoneType' object has no attribute 'values'
```

After this commit-
We fix the above traceback and on further investigation it was found that `hsn`, `b2b` and `cdnr` were
missing `zero_rated` base tag in their domain
which we fix in this commit

task-4195917

Forward-Port-Of: odoo/enterprise#70398
Forward-Port-Of: odoo/enterprise#70279

### Issue

Invoices using consumable intra-community taxes are currently counted twice in the EC Sales Report.

### Steps to Reproduce

1. Install `l10n_at_reports`.
2. Switch to an Austrian company.
3. Create and post an invoice using a consumable intra-community tax (e.g., 'UST_017 IGL 0% (ohne Art. 6 Abs. 1)').
4. Open the EC Sales Report.

You will observe that the invoice amount is counted twice.

### Cause

The system groups values in the EC Sales Report by tax tags. A previous commit (odoo/odoo@f937e915dfd64a9b66dd9f7d7e3d19607d088f28) introduced changes to certain taxes (e.g., 'UST_017 IGL 0% (ohne Art. 6 Abs. 1)'), which caused multiple tax tags counted in the EC Sales report to be applied to the same line. This grouping behavior leads to double counting.

### Fix

Repartition lines with the `tax_report_line_l10n_at_tva_line_4_8_tag` also contain the `tax_report_line_l10n_at_tva_line_3_zm_igl_tag`. To avoid double counting, the EC Sales Report now only checks for the latter tag.

opw-4174429

Forward-Port-Of: odoo/enterprise#69941

### Steps to reproduce the issue:

1. Activate Colombian localization
2. Create an Invoice and Confirm
3. Go to _Accounting > Configuration > Journals_
4. Select Customer Invoices, set Nota de Débito to True and Save
5. Go back to your Invoice, its Electronic Invoice Type is now "Nota Débito"
6. Set Nota de Débito to False in the Customer Invoices Journal
7. Return once again to you Invoice, its Electronic Invoice Type did not change

### Explanation:

When the user changes `l10n_co_edi_debit_note` in an `account.journal`, it changes this value for all entries in said `account.journal`, not only the ones in draft state.
https://github.com/odoo/enterprise/blob/9137e5d9f2690bfe375436c83356ebaa4bd7e8c6/l10n_co_edi/models/account_invoice.py#L65
`_compute_l10n_co_edi_type` depending on `l10n_co_edi_debit_note`, it is called and, if the change is from False to True, `l10n_co_edi_type` is changed to a specific value.
https://github.com/odoo/enterprise/blob/9137e5d9f2690bfe375436c83356ebaa4bd7e8c6/l10n_co_edi/models/account_invoice.py#L72-L81
If `l10n_co_edi_debit_note` is set back to False, `l10n_co_edi_type` is not reverted to its previous value and the user can not manually change this field for posted or cancelled entries.

### Fix reasoning:

To avoid such situation from happening, the field will be restricted for journals with entries in a non draft state.

opw-4174980

Forward-Port-Of: odoo/enterprise#70330
Forward-Port-Of: odoo/enterprise#70133

**Current behavior:**
After creating a subscription for a recurring product which
creates a project/task, invoicing the original order and posting
it, then creating the renewal order, if you create a purchase
order for some expensable service product that has an
`expense_policy == 'sales_price'` and attempt to create the
vendor bill for the purchase order, you will get a UserError
about the original sale order being locked.

**Expected behavior:**
Because there is a renewed order which is not locked, the
expense should use that instead of the original subscription
order.

**Steps to reproduce:**
1. Create a recurring service product which is set to create a
     project and task that has an associated analytic account

2. Create a subscription for the product and confirm it, create
     the invoice and post it (locking the order)

3. Renew the subscription, confirm it, create the invoice but do
     not post it

4. Create a service product which can be expensed and uses the
     expense policy of sales price

5. Create a purchase order for the expensable service and set
     analytic distribution on the order line to use the same one
     from the subscription

6. Confirm the purchase order and create an invoice, then try to
     post it -> UserError

**Cause of the issue:**
The original subscription order is found via the shared analytic
account and generates the error because it is now in a locked
state.

**Fix:**
Check if a found order is in the renewed subscription state and
then search for the lowest id order in DB with the originally
found subscription as its origin order- if one exists, use this
record instead of the original order in the
`_sale_determine_order()` mapping.

opw-4061484

Forward-Port-Of: odoo/enterprise#69886
Forward-Port-Of: odoo/enterprise#68820

Sure! Here is a sample GitHub pull request description for the changes related to creating the Chrome extension with the default login functionality:

---

### Pull Request Title

**Add Chrome Extension with Default Login Functionality**

### Description

This pull request adds a basic Chrome extension for AEM, including a default login form with predefined credentials (username: `admin`, password: `admin`). The extension is structured with the necessary files and directories and includes placeholder icons.

### Changes Included

1. **Directory Structure:**
   - Created `aem-chrome-extension/` directory to hold extension files.
   - Created `aem-chrome-extension/images/` directory for icon files.

2. **Files Added:**
   - `index.html`: Contains the HTML structure for the login form.
   - `manifest.json`: Configures the Chrome extension settings.
   - Placeholder icon files (`icon16.png`, `icon48.png`, `icon128.png`).

3. **`index.html`:**
   - A simple login form with fields for username and password.
   - Inline CSS for basic styling.
   - JavaScript to handle login validation (checks for default credentials).

4. **`manifest.json`:**
   - Defined the extension name, version, description, and permissions.
   - Configured the extension's default popup to `index.html`.
   - Included paths to the placeholder icons.

### Testing

1. **Manual Testing Steps:**
   - Load the unpacked extension in Chrome (`chrome://extensions/` -> "Load unpacked").
   - Verify that the login form appears when clicking the extension icon.
   - Test the login functionality with the default credentials (`admin`/`admin`).
   - Check that an alert is shown on successful or failed login attempts.

### Screenshots

*If applicable, include screenshots here to show the extension UI and functionality.*

### Additional Notes

- Placeholder icons are included and can be replaced with appropriate icons.
- Future enhancements could include integrating with a backend for actual authentication, improving UI/UX, and adding more features.

---

### Checklist

- [x] My code follows the style guidelines of this project.
- [x] I have performed a self-review of my own code.
- [x] I have commented my code, particularly in hard-to-understand areas.
- [x] I have made corresponding changes to the documentation.
- [x] My changes generate no new warnings.
- [x] I have added tests that prove my fix is effective or that my feature works.
- [x] New and existing unit tests pass locally with my changes.

---

### References

*Link any related issues, discussions, or other pull requests here.*

---

Please review and provide feedback. Thank you!

---

This template should help convey the purpose, changes, and testing process for your pull request clearly to the reviewers.

### Issue

Invoices using consumable intra-community taxes are currently counted twice in the EC Sales Report.

### Steps to Reproduce

1. Install `l10n_at_reports`.
2. Switch to an Austrian company.
3. Create and post an invoice using a consumable intra-community tax (e.g., 'UST_017 IGL 0% (ohne Art. 6 Abs. 1)').
4. Open the EC Sales Report.

You will observe that the invoice amount is counted twice.

### Cause

The system groups values in the EC Sales Report by tax tags. A previous commit (odoo/odoo@f937e915dfd64a9b66dd9f7d7e3d19607d088f28) introduced changes to certain taxes (e.g., 'UST_017 IGL 0% (ohne Art. 6 Abs. 1)'), which caused multiple tax tags counted in the EC Sales report to be applied to the same line. This grouping behavior leads to double counting.

### Fix

Repartition lines with the `tax_report_line_l10n_at_tva_line_4_8_tag` also contain the `tax_report_line_l10n_at_tva_line_3_zm_igl_tag`. To avoid double counting, the EC Sales Report now only checks for the latter tag.

opw-4174429

Forward-Port-Of: odoo/enterprise#69941