Kanban boards now display the number of records in every column, whether columns are folded or expanded and whether a progress bar is shown. This removes inconsistent counts and helps users quickly understand workload distribution across all kanban groups.

Before this commit, there were discrepancies between a kanban view with
or without the progress bar. The kanban view, with the progress bar,
have the count of each group (folded or not). Contrariwise, the kanban
view, without the progress bar, only have the count of the folded groups.

This commit adds a count to all the columns of the kanban view, folded
or not, with the progress bar or without.

opw-[4132389](https://www.odoo.com/web#id=4132389&view_type=form&model=project.task)

A recent change accidentally prevented the Translation Export Wizard from retaining the chosen model when exporting translations for a specific model. This fix restores that hidden value so model-specific translation exports work as expected.

This recent [commit] removed all uncommented invisible fields from views. This lead to the Translation Export Wizard having the exported model_name missing when the export_type is Model

This commit fixes that by re-adding the invisible `model_name` field to the view of the Translation Export Wizard.

[commit]: https://github.com/odoo/odoo/commit/5639ed865c5a3b82bab25b0ecac28c68c02e9306

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

This fix ensures that changes to an employee's home-to-work distance made through a contract are saved correctly and do not revert after recalculation. It helps keep employee travel information consistent for HR and contract records.

The field is compute stored and in contrat there is a related readonly false to this field.

So when we set on the contract, it stores the value, but once recomputed it set back the old value.

So we create an inverse method to store the distance in the correct unit of measure.

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

This fix restores consistent sizing for small buttons in a website header style after a Bootstrap update caused them to appear too large. It also keeps those buttons proportionate when users adjust navigation font sizes in the website editor, improving visual consistency.

Since the update of Bootstrap from 5.1 to 5.3 in commit https://github.com/odoo-dev/odoo/commit/058212e12b5079eba870bde9775fe98f27928935, the font-size of `btn-sm` wasn't taken into account because the font-size of `nav-link` had the priority. This created a layout inconsistency in `header_sales_three` template.

In addition, once the user started changing the font size of the navigation in the Web editor (by triggering the `header-font-size` value), the font size of the small buttons was removed and replaced by the regular font size.

This commit adapts and forces the font-size of small links in the `header_sales_three` template to be always proportional to header font size.


| Before | After |
|--------|--------|
| <img width="650" alt="Capture d’écran 2024-08-16 à 11 00 04" src="https://github.com/user-attachments/assets/a3883f97-9de1-4940-9c40-b1db6dda64dd"> | <img width="549" alt="Capture d’écran 2024-08-16 à 10 58 52" src="https://github.com/user-attachments/assets/6ed2c695-55de-42b3-91e3-e9ae6d77c017"> |






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

Social kanban views now display the number of records in every column, whether or not the progress bar is shown and whether columns are folded. This removes confusing differences between views and gives users a clearer overview of their records at a glance.

Before this commit, there were discrepancies between a kanban view with or without the progress bar. The kanban view, with the progress bar, have the count of each group (folded or not). Contrariwise, the kanban view, without the progress bar, only have the count of the folded groups.

This commit adds a count to all the columns of the kanban view, folded or not, with the progress bar or without.

opw-4132389

SEPA payment files now include only payslips with a wage greater than zero. This prevents unnecessary or incorrect payment entries for employees with no wage due.

SEPA file was generated for payslips even if the wage was 0. It should not be the case.

This fix filters the payslips to generate SEPA file only for those with wage>0.

**Current behavior:** Having a batch transfer with 2+ delivery pickings, opening the choose package wizard and filling out the package type will not accurately display the shipping weight for the whole batch. **Expected behavior:** The weight displayed on the wizard form should reflect the weight of the package plus all product that will be put inside it from the batch. **Steps to reproduce:** 1. Enable packs in settings, create a package type with a base weight of 1 unit and some produ

**Current behavior:**
Having a batch transfer with 2+ delivery pickings, opening the choose package wizard and filling out the package type will not accurately display the shipping weight for the whole batch.

**Expected behavior:**
The weight displayed on the wizard form should reflect the weight of the package plus all product that will be put inside it from the batch.

**Steps to reproduce:**
1. Enable packs in settings, create a package type with a base weight of 1 unit and some product with a weight of 1 unit

2. Create two delivery transfers with some carrier (e.g, local delivery) each with 1 of the created product

3. Add the two pickings to a new batch, on the batch click the `Put in Pack` button and select the created package type

4. Observe that in the form, only one of the products from the batch transfer has been used to calculate the shipping weight

**Cause of the issue:**
In `shipping_weight`'s compute function in the
`ChooseDeliveryPackage` wizard, we don't account for a batch package (like what is done in `action_put_in_pack()` defined on this wizard). Thus, one of the move lines in the batch is not used in the weight calculation.

**Fix:**
Look at the context to see if the user is packing a batch and if so, get all the involved move lines from it.

opw-4077546

Forward-Port-Of: odoo/odoo#177952
Forward-Port-Of: odoo/odoo#177022

When editing a message, the mentions of the original message were lost. The reason is that the channel mentions were not stored with the message in the database. The fix is to parse the body directly before editing and get mentionedChannels from it. follow-up of task-4104895 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177798 Forward-Port-Of: odoo/odoo#176472

When editing a message, the mentions of the original message were lost.

The reason is that the channel mentions were not stored with the message in the database.

The fix is to parse the body directly before editing and get mentionedChannels from it.

follow-up of task-4104895



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

Forward-Port-Of: odoo/odoo#177798
Forward-Port-Of: odoo/odoo#176472

Issue ----- If an image has a width or height of 1, crop_resize will fail if we are trying to resize it to a vertical format (max_height/max_width > 1) if the original image has a height of 1, or to a horizontal format if the original image has a width of 1. This is because the calculated new_w/new_h of the cropped image will be 0. Steps to reproduce ----- The issue typically happens when a mail includes spacer images with a height or width of 1 and they get uploaded as documents and

Issue
-----
If an image has a width or height of 1, crop_resize will fail if we are
trying to resize it to a vertical format (max_height/max_width > 1) if
the original image has a height of 1, or to a horizontal format if the
original image has a width of 1.
This is because the calculated new_w/new_h of the cropped image will be 0.

Steps to reproduce
-----
The issue typically happens when a mail includes spacer images with a height
or width of 1 and they get uploaded as documents and a thumbnail is generated.

An easier way to reproduce in v16.0 (in v15.0 we resize to a square format):
1. Install Documents.
2. Upload an image with a width of 1.
-> Error 500

opw-4053926

Forward-Port-Of: odoo/odoo#177885
Forward-Port-Of: odoo/odoo#176632

* PROPBLEM: since https://github.com/odoo/odoo/pull/173719 we have moved from init to post_init which will make timesheet_task_id of hr.leave.type can't set value because in post_init company.leave_timesheet_task_id will be set * SOLUTION: fill it in post_init instead 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 Fo

* PROPBLEM: since https://github.com/odoo/odoo/pull/173719 we have moved from init to post_init which will make timesheet_task_id of hr.leave.type can't set value because in post_init company.leave_timesheet_task_id will be set

* SOLUTION: fill it in post_init instead

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#177605
Forward-Port-Of: odoo/odoo#177008

No visual bug, just a small coding mistake made with [1]. [1]: https://github.com/odoo/odoo/commit/e2cd6940bd29670ea0e76cd4bb95489a12588f55 Related to task-3957198 Forward-Port-Of: odoo/odoo#178059

No visual bug, just a small coding mistake made with [1].

[1]: https://github.com/odoo/odoo/commit/e2cd6940bd29670ea0e76cd4bb95489a12588f55

Related to task-3957198

Forward-Port-Of: odoo/odoo#178059

### Steps to reproduce: - Enable Multi-Step routes in the settings - Go Inventory > Configuration > Warehouse Management > Warehouses - Enable 2-step manufacturing on your Warehouse - Create 2 storable products: - product P: tracked by SN - product COMP: tracked by lot - Update the "on hand qty" of COMP by creating a lot with 10 units - Create and confirm a manufacturing order for 1 unit of P - Change the qty producing to 1 then assign a serial number to the final product - Validate t

### Steps to reproduce:

- Enable Multi-Step routes in the settings
- Go Inventory >  Configuration > Warehouse Management > Warehouses
- Enable 2-step manufacturing on your Warehouse
- Create 2 storable products: - product P: tracked by SN - product COMP: tracked by lot
- Update the "on hand qty" of COMP by creating a lot with 10 units
- Create and confirm a manufacturing order for 1 unit of P
- Change the qty producing to 1 then assign a serial number to the final product
- Validate the transfer of components from stock to preproduction (The lot is automatically used on this transfer as it is available)

### Expected behavior:

Since the lot of COMP was used in the transfer from stock to preproduction it should be displayed on the raw move of the MO.

### Current behavior:

The raw move is not updated.

Note: if the transfer is validated before we set the qty producing the lot of the component is correctly updated.

### Cause of the issue:

When the `qty_producing` is changed, the '_set_qty_producing' is called in order to adapt the quantities of the MO (produce only one unit and consume accordingly):
https://github.com/odoo/odoo/blob/b26129c1ed6eb4806569e05d90c17dd9aa2e4c02/addons/mrp/models/mrp_production.py#L809-L811 https://github.com/odoo/odoo/blob/37c67ba6d2bef0bdca715619f117c3124ef5d334/addons/mrp/models/mrp_production.py#L1215-L1231 Now, changing the quantity of the stock move of the component to a positive quantity will trigger the inverse method '_set_quantity' of that field to adapt reservation by creating a stock.move.line. Therefore, validating the transfer of components from stock to pre-production will not update the lot of components on the raw move because the computed need will be at 0 here:
https://github.com/odoo/odoo/blob/3097ea49705a1b6319be9677152d65ebe3ce515b/addons/stock/models/stock_move.py#L1689-L1697 and the '_update_reserved_quantity' call will therefore be empty.

follow up of commit d7148a7

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

Forward-Port-Of: odoo/odoo#177894

- Have an one2may or a many2many on a setting (with some data in them); - Edit/toggle any setting; - Click on an action button or navigate to another view; - On the "Unsaved changes" dialog, select "Discard". Before this commit, the `discard` function of the relational model, didn't take into account the initial commands, and replace the x2many with an empty list of commands. The issue is that the settings need to be saved (after discarding the changes) when leaving, throws an action's

- Have an one2may or a many2many on a setting (with some data in them);
- Edit/toggle any setting;
- Click on an action button or navigate to another view;
- On the "Unsaved changes" dialog, select "Discard".

Before this commit, the `discard` function of the relational model,
didn't take into account the initial commands, and replace the x2many
with an empty list of commands.
The issue is that the settings need to be saved (after discarding the
changes) when leaving, throws an action's button. This is done, to
create a res_id, that is most of the time mandatory to perform the
action (see [1])
 So if the `discard` function, empty the x2many, the setting will be
 modified, and the x2many will be emptied.

Now, the `discard` function of the relational model take into account
the x2many initial commands, therefore the x2many setting will stay
unchanged.

[1] : https://github.com/odoo/odoo/commit/9b81ddb993e4d56aba5aae637d160522d3af1d30

opw-4050990
opw-4092267
opw-4100926

Co-authored-by: Aaron Bohy <aab@odoo.com>

Forward-Port-Of: odoo/odoo#178039
Forward-Port-Of: odoo/odoo#177883

**Current behavior:** In the purchase report pivot view, grouping by order does not display the order reference on the row's label. **Expected behavior:** Rows corresponding to a purchase order should be labeled with the order reference (name). **Steps to reproduce:** 1. In the Purchase app, go to Reporting -> Purchase 2. Switch to the pivot view 3. Expand the row to Add Custom Group -> Order 4. See that the reference does not get displayed **Cause of the issue:** When we s

**Current behavior:**
In the purchase report pivot view, grouping by order does not display the order reference on the row's label.

**Expected behavior:**
Rows corresponding to a purchase order should be labeled with the order reference (name).

**Steps to reproduce:**
1. In the Purchase app, go to Reporting -> Purchase

2. Switch to the pivot view

3. Expand the row to Add Custom Group -> Order

4. See that the reference does not get displayed

**Cause of the issue:**
When we select group by for the `order` option, the rows are aggregated via `count_distinct`, so the label for the pivot becomes '1' (as they are grouped by id which is unique).

**Fix:**
Make the order_id field in the view `type=row` instead of `type=measure` so that they do not get aggregated.

opw-4075321

Forward-Port-Of: odoo/odoo#177907
Forward-Port-Of: odoo/odoo#176915

Before this commit the tax grid of the tax was wrong. The value of this tax should be put in the total sales of goods and services in Field C in the tax report. link to documentation: https://skat.dk/erhverv/moms/moms-ved-handel-med-udlandet/moms-ved-handel-med-virksomheder/moms-ved-handel-med-lande-uden-for-eu/moms-ved-salg-af-varer-og-ydelser-i-lande-uden-for-eu task: 4132444 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Po

Before this commit the tax grid of the tax was wrong. The value of this tax
should be put in the total sales of goods and services in Field C in the tax
report.

link to documentation:
https://skat.dk/erhverv/moms/moms-ved-handel-med-udlandet/moms-ved-handel-med-virksomheder/moms-ved-handel-med-lande-uden-for-eu/moms-ved-salg-af-varer-og-ydelser-i-lande-uden-for-eu

task: 4132444




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

Forward-Port-Of: odoo/odoo#177566

Before this commit when being in a branches environment, creating an account group on the main company was not propagated to the account of the child companies opw: 4055582 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173634

Before this commit when being in a branches environment, creating an account group on the main company was not propagated to the account of the child companies

opw: 4055582




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

Forward-Port-Of: odoo/odoo#173634

Currently the amount due of a move was always sent in an email for any type of move. The condition only checked if there was an `invoice_date_due` set. This field is set for any kind of move and default to the creation date of that move. However it only makes sense to show amounts due for invoices, bills, receipts and credit notes. Showing these for miscellaneous moves like the tax closing entry causes users to be confused. The amount displayed is the total amount of the move and not the amou

Currently the amount due of a move was always sent in an email for any type of move. The condition only checked if there was an `invoice_date_due` set. This field is set for any kind of move and default to the creation date of that move.

However it only makes sense to show amounts due for invoices, bills, receipts and credit notes. Showing these for miscellaneous moves like the tax closing entry causes users to be confused. The amount displayed is the total amount of the move and not the amount to be paid to the authorities.

This fix makes sure we only show the amount due in emails for the right move types in order not to confuse users.

Task link: https://www.odoo.com/odoo/project/967/tasks/4042715
opw-4042715

Forward-Port-Of: odoo/odoo#176172
Forward-Port-Of: odoo/odoo#174819

Steps to reproduce: - Install `l10n_ec_website_sale` - Go to website and select the website of the 'EC Company' - Add a product and go to checkout - Save the demo address - Add an address Issues: When adding a new address VAT is not shown when logged in, however it's required by some localization (Ecuador for instance). opw-3921156 Forward-Port-Of: odoo/odoo#168930

Steps to reproduce:
- Install `l10n_ec_website_sale`
- Go to website and select the website of the 'EC Company'
- Add a product and go to checkout
- Save the demo address
- Add an address

Issues:
When adding a new address VAT is not shown when logged in, however it's
required by some localization (Ecuador for instance).

opw-3921156

Forward-Port-Of: odoo/odoo#168930

**Current behavior:** When adding an unplanned move line to a transfer in barcode, if the line is added to an existing move which is a subcontract transfer, it will not take the subcontract location as its source location value. Rather, it will use whatever value is defined on the picking. **Expected behavior:** Use the more precise location defined on the move rather than the picking. **Steps to reproduce:** 1. Create a product with a subcontract BOM 2. Create a receipt for that pro

**Current behavior:**
When adding an unplanned move line to a transfer in barcode, if the line is added to an existing move which is a subcontract transfer, it will not take the subcontract location as its source location value. Rather, it will use whatever value is defined on the picking.

**Expected behavior:**
Use the more precise location defined on the move rather than the picking.

**Steps to reproduce:**
1. Create a product with a subcontract BOM

2. Create a receipt for that product from the subcontractor

3. Open the transfer in Barcode and manually add another line for the same product -> validate

4. In the receipt form, look at the move lines (detailed operations) and group by location to see the discrepancy

**Cause of the issue:**
When creating a move line here, it does not initially get a `move_id` value. Later when the move is written to the line, we would not generally want to override whatever value is on the line already because it (normally) is more precise/was purposely changed later than what value is on the move.

**Fix:**
In the case of lines which are created and then linked to a subcontract move, take the `location_id` of the move rather than whatever value is on the MoveLine.

opw-4007423

Forward-Port-Of: odoo/enterprise#68032

Steps to reproduce: 1) Go to runbot Odoo 16 enterprise and install "l10n_ar_edi" module (Argentinean Electronic Invoicing). 2) Take position on Argentinian company (AR) (Responsable Inscripto) . 3) Create customer electronic invoice and confirm. If there is a response with 503 error (HTTPError: 503 Server Error. Service Unavailable) while connecting to the webservice then it will be raised the error message and this text "Please report this error to your Odoo provider" (but this text is

Steps to reproduce:

1) Go to runbot Odoo 16 enterprise and install "l10n_ar_edi" module (Argentinean Electronic Invoicing).

2) Take position on Argentinian company (AR) (Responsable Inscripto) .

3) Create customer electronic invoice and confirm. If there is a response with 503 error (HTTPError: 503 Server Error. Service Unavailable) while connecting to the webservice then it will be raised the error message and this text "Please report this error to your Odoo provider" (but this text is not suitable because the odoo provider can`t solve the error. The webservice is not available).

Current behavior:

If there is a response with 503 error (HTTPError: 503 Server Error. Service Unavailable) while connecting to the webservice when the user is trying to confirm an electronic customer invoice then it will be raised the error message and this text "Please report this error to your Odoo provider".

Expected behavior:

If there is a response with 503 error (HTTPError: 503 Server Error. Service Unavailable) while connecting to the webservice when the user is trying to confirm an electronic customer invoice then it will be raised the error message and this text 'The AFIP electronic billing webservice is not available. Wait a few minutes for it to reset and try to validate the action again.'.

Task Adhoc: 37771

Forward-Port-Of: odoo/enterprise#67566
Forward-Port-Of: odoo/enterprise#59983

**Current behavior:** In Barcode, it is possible for a split of incomplete moves to be triggered which leaves the original move with a quantity and demand of zero- effectively generating a superfluous record value. **Expected behavior:** A split should not occur when the original line has `quantity == 0`. **Steps to reproduce:** 1. Create a transfer for 2 units of some product, assign it 2. Open the transfer in Barcode and use the form to add 1 unit 3. Use the back button with

**Current behavior:**
In Barcode, it is possible for a split of incomplete moves to be
triggered which leaves the original move with a quantity and
demand of zero- effectively generating a superfluous record
value.

**Expected behavior:**
A split should not occur when the original line has
`quantity == 0`.

**Steps to reproduce:**
1. Create a transfer for 2 units of some product, assign it

2. Open the transfer in Barcode and use the form to add 1 unit

3. Use the back button within the Barcode app to return to the
     previous action

4. Reopen the transfer, set the quantity on the move to 0 from 1

5. Use the back button to exit the transfer again

6. Open the transfer in the backend to see there is a move with
     a line for 0 / 0 units.

**Cause of the issue:**
We split moves if their quantity is less than demand without
considering it may be zero.

**Fix:**
Reset the move in the case of `quantity == 0`- thus it will no
longer become a split candidate.

opw-4056241

Forward-Port-Of: odoo/enterprise#68884
Forward-Port-Of: odoo/enterprise#68554

Steps: - Install `marketing_automation` and `web_studio` - Open Marketing Automation and studio - Click "Edit Menu" - Click "New Menu" - Set a name - Set Existing Model - Select "Marketing Activity" - Confirm - Try to use this new menu - Traceback This is because a compute is triggered in marketing_activity and we use `literal_eval` on domain fields unsetted. `literal_eval` works only with string https://docs.python.org/3/library/ast.html#a

Steps:
    - Install `marketing_automation` and `web_studio`
    - Open Marketing Automation and studio
    - Click "Edit Menu"
    - Click "New Menu"
    - Set a name
    - Set Existing Model
    - Select "Marketing Activity"
    - Confirm
    - Try to use this new menu
    - Traceback

This is because a compute is triggered in marketing_activity and we use `literal_eval` on domain fields unsetted.

`literal_eval` works only with string https://docs.python.org/3/library/ast.html#ast.literal_eval

opw-4115586

Forward-Port-Of: odoo/enterprise#68920

When filling big numbers (10+ digits) in the input field with Actual Demand/Replenishment activated, the field limits itself to 38% of the cell width, which then crops the number inside. This fix replace the inline-flex by a normal flex, as well as removes the max-width. This way if Actual Demand/Replenishment is activated, it will be shown over 2 lines in the cell. fp-request Forward-Port-Of: odoo/enterprise#68948 Forward-Port-Of: odoo/enterprise#66164

When filling big numbers (10+ digits) in the input field with Actual Demand/Replenishment activated, the field limits itself to 38% of the cell width, which then crops the number inside.

This fix replace the inline-flex by a normal flex, as well as removes the max-width. This way if Actual Demand/Replenishment is activated, it will be shown over 2 lines in the cell.

fp-request

Forward-Port-Of: odoo/enterprise#68948
Forward-Port-Of: odoo/enterprise#66164

[IMP] account_online_synchronization: Show banner when fail connecting to existing account Issue: Sometimes the connection with the bank breaks for some reasons either the user remove the connection from the bank dashboard etc. And when the user press on 'fetch_transaction' in odoo, We will ask him to add the bank again without showing him anything to indicate the reason. Solution: Adding a banner in the widget to report that we are facing an issue connecting to the bank-account and show

[IMP] account_online_synchronization: Show banner when fail connecting to existing account

Issue: Sometimes the connection with the bank breaks for some reasons either the user remove the connection from the bank dashboard
etc. And when the user press on 'fetch_transaction' in odoo, We will ask him to add the bank again without showing him anything
to indicate the reason.

Solution: Adding a banner in the widget to report that we are facing an issue connecting to the bank-account and show it
whenever the user face a problem connecting to existing account through the '_handle_odoofin_redirect_exception'
which handle open the iframe whenever we face an issue connecting to an existing bank account

Task-3355270

odoofin PR:  https://github.com/odoo/odoofin/pull/263

Forward-Port-Of: odoo/enterprise#60184

Before this commit, the salesmen did not had the right group and the test crashed with the following error when the test was run without demo data: ``` FAIL: TestCommissions.test_commission_plan_rules_with_template Traceback (most recent call last): File "/data/build/enterprise/partner_commission/tests/test_commissions.py", line 221, in test_commission_plan_rules_with_template form.sale_order_template_id = so_template File "/data/build/odoo/odoo/tests/form.py", line 326, in __set

Before this commit, the salesmen did not had the right group and the test crashed with the following error when the test was run without demo data:

```
FAIL: TestCommissions.test_commission_plan_rules_with_template
Traceback (most recent call last):
  File "/data/build/enterprise/partner_commission/tests/test_commissions.py", line 221, in test_commission_plan_rules_with_template
    form.sale_order_template_id = so_template
  File "/data/build/odoo/odoo/tests/form.py", line 326, in __setattr__
    self[field_name] = value
  File "/data/build/odoo/odoo/tests/form.py", line 331, in __setitem__
    assert field_info is not None, f"{field_name!r} was not found in the view"
AssertionError: 'sale_order_template_id' was not found in the view
```

runbot task:  70916 and 73195
https://runbot.odoo.com/web/#id=70916&view_type=form&model=runbot.build.error&menu_id=405&cids=1 https://runbot.odoo.com/web/#id=73195&view_type=form&model=runbot.build.error&menu_id=405&cids=1

Forward-Port-Of: odoo/enterprise#68863
Forward-Port-Of: odoo/enterprise#68829

As per section 34(2) of CGST Act 2017, credit notes for invoices from the financial year cannot be included in GSTR after November 30th. With this commit, if any credit note is created after November 30th of the financial year, an alert will be displayed above the report with action which redirects to all those credit notes list so the user can easily remove tax from those credit notes. POT file also added for `l10n_in_reports`. **task**-3915664 Forward-Port-Of: odoo/enterprise#66824

As per section 34(2) of CGST Act 2017, credit notes for invoices from the financial year cannot be included in GSTR after November 30th.

With this commit, if any credit note is created after November 30th of the financial year, an alert will be displayed above the report with action which redirects to all those credit notes list so the user can easily remove tax from those credit notes.

POT file also added for `l10n_in_reports`.

**task**-3915664

Forward-Port-Of: odoo/enterprise#66824

Problem: When the user enable approval rules for confirming purchase orders, the approval message was not being translated to the user's preferred languages. Purpose: Since multiple users can be notified for the approval, it was discussed that translating the message to be in the language of the first user should help with the limitation. It will solve the bug in the case only one user needs to be notified. Steps to reproduce on Runbot: 1. Install Studio and purchase 2. create a purchase

Problem: When the user enable approval rules for confirming purchase orders, the approval message was not being translated to the user's preferred languages.

Purpose: Since multiple users can be notified for the approval, it was discussed that translating the message to be in the language of the first user should help with the limitation. It will solve the bug in the case only one user needs to be notified.

Steps to reproduce on Runbot:
1. Install Studio and purchase
2. create a purchase order without confirming it
3. Go into Studio and edit the "confirm order' button on the PO
4. Add 2 approval rules
- notify User A with notification order 1
- notify User B whose language is not English with notification order 2
5. Confirm the PO and observe the message is sent in English

opw-3932725

Forward-Port-Of: odoo/enterprise#64060