This PR changes the sales and purchase taxes for Cyprus when selling/purchasing within the EU. 
- All sales taxes changed to 0% when selling to country within the EU. 
- All purchase taxes changed to 19% when buying from country within the EU. However, a second tax repartition line is added at -100% of the tax. The tax is effectively applied and deducted at the same time. 
- Redundant taxes were removed like zero rate taxes and taxes with reverse charge.

task-4488340

Current behavior before PR:
- When selling to other EU countries, a 19% sales tax is added to goods and services.
- When buying with other EU countries, a 0% VAT tax is added to goods and a 19% VAT tax is added to services.

Desired behavior after PR is merged:
- When selling to other EU countries, a 0% sales tax is added to goods and services.
- When buying with other EU countries, a 19% VAT tax is added to goods and services, and a second tax repartition line is added at -100% of the tax effectively making it 0.

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

The `s_numbers_charts` snippet had two main issues:
- The progress bar within `s_numbers_charts` visually appeared as 45% on
  initial rendering, despite its actual configured value being 25%. This
was due to a mismatch between its `aria-valuenow` attribute and its
style `width` property. The display would correct itself when the user
manually changed the value.

- A crash would occur when attempting to select the "Label" option after
  dropping the `s_numbers_charts` snippet. This happened because
`s_progress_bar_text` was forgotten during the initial implementation of
`s_numbers_charts` [1].

This commit addresses these problems by:
- Adding the missing `s_progress_bar_text` to the `s_numbers_charts` template.
- Including `s_progress_bar_text` in `_computeSnippetTemplates` to
  ensure that existing databases also receive this fix, as snippets are
stored in the database.
- Adding a check in the `progress` option to prevent the aforementioned crash.

Steps to reproduce the crash:
- Drop the `s_numbers_charts` snippet.
- Click on a progress bar within the snippet.
- Select the option `Label`.
- Hover over "Hide" without any other prior interactions.
- A crash will occur.

[1]: https://github.com/odoo/odoo/commit/6c94fd66c1db75d74588ce670fb6cf1e960cf8bd

# Context :

By design the CRON “Mail Marketing: Process queue” handling the email marketing campaigns is expected to time out for large mailing list. By default it tries to generate and commit batches (default 50) of `mail.mail`
 records while working through the total list of remaining recipients.
See `_action_send_mail_mass_mail` method https://github.com/odoo/odoo/blob/8ff5079b1f5c4df23d56b7f170151408fa7f6f8c/addons/mail/wizard/mail_compose_message.py#L752 In practice, for large mailing lists this will take longer than 15 mins (the default real time limit for CRON jobs) and thus implicitly we expect the worker to time out, re-initiate and continue where it left off.

But since Odoo 18, the new refactor of `ir.cron` tries to penalize jobs that time out too often (>3) and don’t report at least a partial progress
(`_notify_progress()`).
See https://github.com/odoo/odoo/blob/8ff5079b1f5c4df23d56b7f170151408fa7f6f8c/odoo/addons/base/models/ir_cron.py#L361C1-L367C39

While `_process_mass_mailing_queue` does use the notify progress method (https://github.com/odoo/odoo/blob/8ff5079b1f5c4df23d56b7f170151408fa7f6f8c/addons/mass_mailing/models/mailing.py#L1167),
 it does so at a higher level or granularity (the `mailing.mailing` records in queue).
But it will never called as long as the CRON keeps timing out while
 processing the mails for the remaining recipients (that get committed by batches).
Which leads to the CRON being flagged as timing out to many times, and
 the `nextcall` date of the job being incremented by it’s default value of 1 day.

So in practice:
- mail marketing starts processing
- will time out 3 times after 15 mins (default real time)
- new system kicks in and increments the next execution date + 1 day
- cron does not run until next day (so no new mail batches created) → artificially low sending rate of the campaign even-though everything is in order

# Proposed solution:

One could argue that the real unit of work is the committed mail records
 done in `_action_send_mail_mass_mail`. So we count the processed
 recipients/mails and call _notify_progress()` before the auto commit
 (which will be active when the method is called during the CRON).
This should ensure that the CRON will not be penalized for timing out too
 often as long as the recipients are defacto being processed by batches.

opw-4633353

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

Before this commit
------------------
if a user had a multi-company setup with a different alias domain set for each company, a multi-company error could happen. It happens when sending a mail with attachment to an accounting journal alias.
The exact conditions required to enable the option to centralise all attachments in Documents for the journal in question.

steps to reproduce:
1. clean DB with documents_account installed
2. create a 2nd company "company 2"
3. create an alias domain for company 1 "alias.company1.com" and another alias domain for company 2 "alias.company2.com"
4. in documents, create a "finance" folder for company 1 (i.e. set the company_id field on the folder) and another folder for company 2
5. configure the settings for both companies so that all attachments are centralized in documents for accounting, in the respective folder for that company
6. create an alias for some journals in company 2 (e.g. vendor-bills@alias.company2.com)
7. send an email with attachment to that alias -> you will get a multi-company error

After this commit
------------------
Sending a mail with attachment to an accounting journal alias creates the account_move as expected. The attachment is parsed as expected.

opw-4727873
opw-4655559
opw-4746321
opw-4766895

<b>Steps to reproduce:</b>

1) Install the Project module and enable debug mode.
2) Go to Configuration > Task Stages in the Project app
3) Try to create a new task stage in form view

<b>Issue:</b>
The Project field is not visible when creating a new task stage in the form view.

<b>Cause:</b>

The form view only shows the `project_id` field if the `user_id` is not set. https://github.com/odoo/odoo/blob/84160b97ca28a8ac641a7a74f024292a6e758033/addons/project/views/project_task_type_views.xml#L46-L48

However, the action context includes `default_project_id=False`, 
which causes the defaulting logic to compute a `default_user_id` (based on the falsy project). 
As a result, `user_id` is set, hiding the project_id field from the form.

https://github.com/odoo/odoo/blob/84160b97ca28a8ac641a7a74f024292a6e758033/addons/project/views/project_task_type_views.xml#L143 https://github.com/odoo/odoo/blob/84160b97ca28a8ac641a7a74f024292a6e758033/addons/project/models/project_task_type.py#L19-L20

<b>Fix:</b>
Add a key in the context to make the user_id as False when creating a new task stage from the Form view.

opw-4767251

Forward-Port-Of: odoo/odoo#210355

Steps to reproduce:
1. Set company warehouse to two-step manufacturing.
2. Create products: X, A, B, C.
3. Add on-hand quantities: A = 10, C = 5.
4. Create a BOM for X with A and B as components.
5. Create and confirm a MO for X in the two-step warehouse.
6. Check product B's forecast report → shows -1.
7. Add a reordering rule for B → forecast shows -1.
8. Edit X’s BOM: remove B and add C instead.
9. Update the MO using the `update_bom` button.
10. Check MO components.
11. Check WH/Preprod transfer → B is still there.
12. Re-check steps 6 and 7.

**Issue**:
In two-step manufacturing, two stock moves are created:
- move1: WH/Stock → WH/Preprod
- move2: WH/Preprod → Virtual/Production

The forecast report uses the company warehouse (WH) as the
location domain and includes move2. It calculates:
  forecast = qty_available - demand = 0 - 1 = -1

The reordering rule uses WH/Stock (its default location) and
includes move1, resulting in the same forecast: -1.

After updating the BOM to remove B:
- move2 is deleted correctly.
- move1 remains on the pre-production transfer.

This causes an inconsistency:
- Forecast report (based on move2) → shows 0
- Reordering rule (based on move1) → still shows -1

We set the product_uom_qty to 0 of the prepoduction moves
so procurement runs with negative qty move and it is merged
with the existing ones in the preproduction picking.
This will make the moves in the preprod picking be 0 and not
deleted to avoid deleting manually added moves from the client
in the preproduction picking.

**Limitation**
The current setup will update the pre_prod_pick moves with
0 demand, but for the post_prod_pick moves there is no pull rule
that will trigger a procurement with -ve old demand to update
the post_prod_pick move leaving it not updated to the bom changes.

This will not be an issue in 18.0+ because of changing to push rules
as the post_prod_pick will not be there unless the MO is done, so
BoM updates will not be needed to be reflected.

opw-4746230

Forward-Port-Of: odoo/odoo#209642

To reproduce the issue, on a Belgian company:

1) Create and post an entry impacting line "Other Appropriations of the Year", typically by using an account prefixed 69 in it.

2) Enable totals below sections in the settings

3) Open the Belgian BS at a date including the move created in 1).

4) Enable 'unfold all' in the report

===> "Other Appropriations of the Year" displays no amount

This happens because this line is considered as having sublines by the engine (has_sublines is True), since it considered a non-zero number of move lines in its computation. The condition that was there before makes it so that in that case, when using unfold_all, the line would have the 'unfolded' key set to True, even though, here, the line has no means of generating any subline (no child lines, nor groupby value). Therefore, the "totals below sections" feature hid the amount of the line, since it was supposed to be displayed in the total line. The total line, however was never added, since no expand function was ever called.

Note that we could avoid doing 'groupby or has_children' in the condition here, to only use 'has_children'. We do that because that's the former behavior, and some engines (custom or standard) don't return any value for has_sublines in some cases, relying on the presence of the groupby field to properly trigger the unfold. This has changed a little in 18.1, with the introduction of a custom engine for the Trial Balance. We'll see what can be done when forward-porting, and if it's not possible, will probably do something in master later on. has_sublines should probably be mandatory everywhere.

opw-4640606

Forward-Port-Of: odoo/enterprise#88359