In this bug, when a order is out of stock, it can be validated if gift card is used as the sole method of payment. This happens when a product gets out of stock while it is on customer's cart. The other payment methods fail successfully but if gift card is used, the order can be validated.

To reproduce:
1- Create a product and add quantity on stock.
2- Uncheck `Conitnue Selling` in `Out-of-Stock`
3- Publish the product on the website
4- Create a gift card
5- Add the product to the cart using portal user
7- Using admin user, set the quantity to less than ordered quantity
8- Using portal user, proceed to payment, and use the gift card. Then checkout.
9- As you see, the order is validated

The issue is because `_check_cart_is_ready_to_be_paid()` which is supposed to check the stock, is only called inside `shop_payment_transaction()`.
However, when checking out with gift card, this method is not called.
To solve the issue, we can call `_check_cart_is_ready_to_be_paid()` also inside payment validate flow. However this only be called when a gift card is used solely. (The case `order.amount_total` is 0)

opw-4941658


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

Forward-Port-Of: odoo/odoo#222306

When creating a unbuild order for non storable product, it will generate two stock.move.line going form Stock>Production.

** Steps to reproduce **

- Create an untracked product (is_storable = False).
- Create a BOM (the components don't matter).
- Create a manufacturing order & produce it for the untracked product.
- Unbuild the manufacturing order.
- Manufacturing Order> Unbuilds>(Select the Unbuild (UB/...))>Product Moves
- Two move lines are created from stock to production for the untracked product when only one should have been created.

** Cause of the issue **

Clicking on unbuild, will launch a call of the action_unbuild method. During this call,
the moves of the unbuild for the final product of the MO are created and confirmed here:
https://github.com/odoo/odoo/blob/7dd7351d492babdfb7c671960c5e90755fbc2233/addons/mrp/models/mrp_unbuild.py#L181-L182
https://github.com/odoo/odoo/blob/7dd7351d492babdfb7c671960c5e90755fbc2233/addons/mrp/models/mrp_unbuild.py#L187-L188
During this confirmation process and since the product is not storable, (hence move should by pass reservation) therse moves will be assigned and the related move line created:
https://github.com/odoo/odoo/blob/e4d9ef3f39bd62a8db6854270b4cf6a35936b8d4/addons/stock/models/stock_move.py#L1759-L1762
https://github.com/odoo/odoo/blob/7dd7351d492babdfb7c671960c5e90755fbc2233/addons/stock/models/stock_move.py#L1581-L1583
However, in the rest of the action_unbuild call, since we don't expect the move to be assigned by the action_confirm we create and associate manually a second move line to our unbuild move:
https://github.com/odoo/odoo/blob/de2216ae52cee40d0851b4b8c0b71cb7e1d5ec89/addons/mrp/models/mrp_unbuild.py#L196-L198

** Observation **

During this commit
https://github.com/odoo/odoo/commit/7dda6bb92715ea25b2818a62fec5e646f3678b81#diff-31912cb536cbf184f8f475ccdfb5e42c30796a3f0430eea35751519434a67ba8L156
An "if condition" was removed that allowed untracked product to skip the manual assignation, since they already been assigned during consume_move._action_confirm().
This fix reintroduce the condition, for all move with their quantity updated.

Which resolve the issue for non stored product since their quantity is updated during _action_confirmation>_action_assign

Additional issue:
The same happen with by-products if they are non storable, the first move line is also created during the first confirmation,
but the manual creation of the second move line and the commit that erased the "if condition" are different since by-product are not in finished_moves:
https://github.com/odoo/odoo/commit/79d9dd7f15371aa7293a4af0b0ebd193aa80e2be#diff-31912cb536cbf184f8f475ccdfb5e42c30796a3f0430eea35751519434a67ba8L202
opw-4830965

X-original-commit: https://github.com/odoo-dev/odoo/commit/b2cadeaa52a6209d2f95e6b9c0043a36477bf31e

Description of the issue/feature this PR addresses:
This pull request adds  `l10n_ar.partner.tax_billing` on the `l10n_ar_partner_tax` model, granting read, write, and create permissions (but not unlink) to users in the `account.group_account_invoice` group.

Current behavior before PR:
Only users with administrator access rights on the Accounting module could modify the "Perceptions / Withholdings" Section on the "Accounting" tab of the partners.
<img width="1236" height="673" alt="image" src="https://github.com/user-attachments/assets/92b42973-2b01-4019-8e23-5e3cbf5111a4" />


Desired behavior after PR is merged:
Users with invoicing rights can modify the Accounting module could modify the "Perceptions / Withholdings" Section on the "Accounting" tab of the partners. This is needed to properly create the invoices with the perceptions / withholding that apply, for example in cases where by default all partners are set with perceptions, but some depending on their activity are not taxed. In that case, the user that created the partner needs to be able to modify the field by putting a 0% aliquot or deleting the perception line on the contact. 




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

**Steps to reproduce**
- Automatically approved attendances.
- Create an attendance and save it.
- Note the "Extra hours" displayed.
- From the form view, change the check in or check out and save it.
- Issue: "Extra hours" are 0. Expected: they should be the same as "Worked extra hours", as the user has not manually modified the field.

**Cause**
Issue since cc81bb59f87540cf4dd8da65510417d8023ef65b The problem is that a 0 value for `overtime_hours` was computed for the `NewId` record used during edition in the interface. This meant `validated_overtime_hours` was also set to this value https://github.com/odoo/odoo/blob/cc81bb59f87540cf4dd8da65510417d8023ef65b/addons/hr_attendance/models/hr_attendance.py#L171 and sent on save, which meant the value was not further recomputed in `_update_overtime`.
https://github.com/odoo/odoo/blob/cc81bb59f87540cf4dd8da65510417d8023ef65b/addons/hr_attendance/models/hr_attendance.py#L408

**Change**
We avoid a recomputation of `validated_overtime_hours` in the interface (which wasn't useful anyway, it was set to 0) to avoid it being interpreted as a manual change by the user.

opw-5003488

This commit fixes two bugs related to the "Sign in" in button of the registration form.

First bug:
------------
If there is more ordered seats than available seats, an error modal is displayed with a "Sign In" button. This button shouldn't be present. On click, a 500 error is triggered. Now, the button does not appeared on this modal.

Reproduce:
Check "Mandatory" for "Sign in/up at checkout" in the settings. In the event form, add a limit of 1 available seat and add two tickets with each one 1 seat. With a public user, on the website page of the event, click on "Register" to open the registration modal. In the tickets form, select the maximum number of registrations for each tickets. The error modal with the "Sign In" button should appear. Clicking on this button trigger the 500 error.

Second bug:
----------------
The "Sign in" button is displayed even if the tickets have no price. So the label of the button is wrong because public users are not redirected to the checkout. Now, the "Confirm Registration" button is displayed in this case.

Reproduce:
With the same settings as for the first bug, create an event without tickets. Order a registration with an public user. Click on the "Sign In" button of the attendee details form. The confirmation page appears instead of the sign in page.

task-4797022

This commit reverts [1], [2], [3], and [4]. (It actually results in
minimal changes since those commits were already removing parts of
each other.)

Issue before those commits:
1. Setup a auto-fifo category and two storable products (a component
   and a finished product)
2. Receive one compo at 10, then one at 25
3. Produce two MO with one finished product
4. Unbuild the second one

Error:
- For the component, we just use the value of the consumed
  components: IN 1 @ 25
- For the finished product, we process it as a classic out. Reminder,
  we are in FIFO: OUT 1 @ 10

As a result, thanks to the unbuild, we have created
- A over-valuation of the stock (+15)
- An outstanding balance of the "Cost of Production"

This is why [1] has been merged. However, it brought some other
issues, cf [2], [3] and [4]. Unfortunately, it still has some issues
- After the above use case, the difference between the debit and the
  credit of the stock valuation account is no longer the sum of the
  remaining values of the layers
- Adding some landed costs on MOs will lead to a traceback when
  undbuilding
- The over-valuation of the stock (that was already present before [1],
  cf above) is still present

Following some discussions with R&D and the product owners, we have
decided to start over from scratch, which means:
- Revert all commits
- Try another approach (if so, the new PR will be linked to the PR
  related with this commit)

[2], [3], and [4] are partially reverted: the tests can remain, as
they were only failing due to a sequence of changes.

[1] https://github.com/odoo/odoo/commit/84dda968146d2f3743ab7fc516300e50780725e3
[2] https://github.com/odoo/odoo/commit/49565cdd9007ac66a3b835dc073777e2e6c48f2c
[3] https://github.com/odoo/odoo/commit/3a69456a291da593748475c86e7efc6234019e47
[4] https://github.com/odoo/odoo/commit/fb30cde9a320c245cf1321c9dc2ea2e67a53d0a0

OPW-5036574

Forward-Port-Of: odoo/odoo#225728

**Steps to reproduce:**
1. Install the module `quality_control`.
2. Go to **Products → select any product → Quality Points (smart button)**.
   * Create a new Quality Point that applies to *all products*.
3. Open any product form.
   * Verify that the *Quality Points* smart button shows the created point and the correct count.
4. Archive the Quality Point.
5. Reopen the same product form and check the *Quality Points* smart button again.

**Observed behavior:**
- The archived Quality Point is still counted and shown in the smart button.

**Root cause:**
- During the refactor from raw SQL (`get_sql` + `cr.execute`) to the ORM query builder (`query.add_where(SQL(...))`), one outer bracket was dropped. [ref](https://github.com/odoo/enterprise/pull/66290/commits/a6362bc07eac7640f68d145a0f6a14a81f499913#diff-2ffdc2ffc25417076b580b772447514c7e9d8b3e2d2fff2d3100721eb5ccbaf4L542-R561)
- This changed the operator precedence, causing the `active = true` condition to no longer properly apply when combined with the OR block.
- As a result, archived Quality Points bypass the filter and are still counted.

**Solution:**
- Fix the missing bracket in the `query.add_where` SQL expression so that the `active` condition is always enforced before evaluating the OR block.

opw-5046289

Currently, an error occurs when user tries to select any measure in cohort view.

Steps to replicate:
- Install `sale_management` and `web_studio`.
- Open the Sales app and turn on studio mode.
- Under the Views tab, turn on cohort view.
- Under the Measures field, select any value and observe the error appearing in the terminal.

Error:
`ValueError: Invalid aggregate method 'None' for 'create_date:None'`

Cause:
- The Measure field dropdown in the Cohort Editor was mistakenly assigned the choices of `dateFields` [1] instead of `measureFields`.

- This allowed users to select incompatible field types (e.g., date/datetime), which lead to error in aggregation behavior in the cohort view.

Solution:
- Corrected the choices of Measure field to `measureFields`.

- Also added a condition to allow only those fields that have an aggregator
  (for some fields like `sequence` that dont have an aggregator).

- Also removed context field from arguments [2] in the rpc call as function doesnt need it [3]
  (This shows warning on runbot as well).

[1]: https://github.com/odoo/enterprise/blob/d8539dff5f3dcecfeb99fd7fc22a6915aaa02c4b/web_studio/static/src/client_action/view_editor/editors/cohort/cohort_editor_sidebar.xml#L30

[2]: https://github.com/odoo/enterprise/blob/bf9510e152279418200cb0becb6b637c19b02d4e/web_studio/static/src/client_action/editor/new_view_dialogs/new_view_dialog.js#L87

[3]: https://github.com/odoo/enterprise/blob/bf9510e152279418200cb0becb6b637c19b02d4e/web_studio/controllers/main.py#L805

sentry-6781792463

Forward-Port-Of: odoo/enterprise#91599

## Issue:
Creating multiple suggestions sequences for differents Workorder in Manufacturing Orders that are added aside BoM defined WorkOrder cause an issue with a Traceback error

## Cause:
In the method `add_check_in_chain()`, the `point.sequence` cause issue because the check can have multiple points
https://github.com/odoo/enterprise/blob/e85d11f9b3bf07a55e5365adac7370955a149566/mrp_workorder_plm/models/mrp_workorder.py#L58-L66
That the case because multiple quality checks sequences are created when the operation_id is False
That's unexpected because PLM isn't made to suggest WorkOrder additions and Suggestions to New WO, but only Suggestions to existing operations

So we avoid to create `quality.point` when there is no operation_id

## Information:
To get the Traceback, you need to install Quality_control because this module will copy the QC to the MO including the one with operation_id set to False

## Steps to reproduce:
Quality_control and plm need to be installed
- Enable Work Orders in Settings
- Create a Product with a BoM
- Create a MO for the Product
- Add an extra WO
- In the Shop Floor, Mark as Done the BoM's WO
- On the Extra WO, click Gear Icon > Update Instructions > Improvement Suggestion > Add a Step
- Insert a Title and Propose Change
- Duplicate the MO and redo the Shop Floor steps to get the Traceback

opw-4874108

### [PERF] l10n_pe_edi: Avoid OOM during installation

### Description:

Installing `l10n_pe_edi` on large databases with many moves and move lines could cause out-of-memory (OOM) errors. This happens because several stored fields need to be computed at installation.

### Fix:

This fix adds the columns via SQL, preventing Odoo from computing and populating the field for all existing records. This reduces memory usage and avoids installation failures.
____
### [FIX] l10n_pe_edi: Fix error during post-init hook

### Description:

During installation, the `l10n_pe_edi` module's post-init hook attempts to update tax groups, setting the new `l10n_pe_edi_code` field. This can cause an error if a tax group doesn't exist and needs to be created, because the name field is missing in the list of values given to the `_load_records` function.

### Fix:

This fix filters the tax groups to only update existing ones. This prevents `_load_records` from trying to create new groups, which avoids the installation error.

___
### Reference:

opw-4982181

When a payment token is set on a subscription, running the Post-process transactions cron for recurring invoices will trigger a traceback.

Steps to reproduce the error:
- Install ``sale_subscription`` and ``l10n_mx`` modules
- Set up Mexican company and switch to it.
- Set Demo payment provider for Mexican Company
- Create a user A > set the address on the partner of that user A> set payment token in  payment methods via portal >
- Create a new subscription > Add any Subscription product > Set Recurring Plan
  In Other Info Tab, Set Payment Token > Confirm
- Set the Next invoice date to Today > Set delivered quantity of product
- Run the cron ``Sale Subscription: generate recurring invoices and payments``
- Run the cron ``Payment: Post-process transactions``

Traceback:
``AttributeError: 'bool' object has no attribute 'get'``

https://github.com/odoo/enterprise/blob/fff9ad7999d4ff13adf899b2517e750a36c1261a/sale_subscription/models/sale_order.py#L1267-L1269
In the [commit](https://github.com/odoo/enterprise/commit/7c5fd63729c16fb6b9b69ae1e7fa4d9cda2f4733), ``_generate_and_send_invoices`` method is called with
``from_cron=automatic``, where ``automatic`` is set to ``True`` because
the transaction is created during the subscription invoicing cron,
However, ``from_cron`` should only be used when ``sending_data`` is set on the move,
and the ``sending_data`` is only assigned by the ``account.move.send.batch.wizard``.

https://github.com/odoo/odoo/blob/0b34d9dc072c73ed208e287140c97f72dc487b15/addons/account/models/account_move_send.py#L57-L58
Here, ``sending_data`` will be False.
So, it will lead to the above traceback.

sentry-6849994436