This update corrects a typo in an internal accounting method description. It does not change how the software works, but it improves code clarity for future maintenance.

Description of the issue/feature this PR addresses: fix typo on docstring of _get_last_sequence method

Current behavior before PR: Typo on docstring

Desired behavior after PR is merged: fixed typo on docstring




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

This update corrects a typo in an internal documentation note for an accounting sequence method. It does not change how the product works, but improves clarity for developers maintaining the accounting code.

Description of the issue/feature this PR addresses: fix typo on docstring of _get_last_sequence method

Current behavior before PR: Typo on docstring

Desired behavior after PR is merged: fixed typo on docstring

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

Steps to reproduce the bug: - Let's consider a bank journal BJ with manual numbering activated - Create a customer payment CP using BJ as journal and confirm CP - Create a vendor payment VP using BJ as journal, select Check as payment method - A Check Number with 0001 is automatically assigned to VP - Confirm or save VP Bug: An error was raised saying that: The following numbers are already used: 0001 PS: When creating the customer payment, a check number was assigned to CP ev

Steps to reproduce the bug:

- Let's consider a bank journal BJ with manual numbering activated
- Create a customer payment CP using BJ as journal and confirm CP
- Create a vendor payment VP using BJ as journal, select Check as payment method
- A Check Number with 0001 is automatically assigned to VP
- Confirm or save VP

Bug:

An error was raised saying that:

The following numbers are already used: 0001

PS: When creating the customer payment, a check number was assigned to CP even if
customer payment has nothing to do with check numbers

opw:2415170

Forward-Port-Of: odoo/odoo#63174

Create an event as follows: - Recurrent - Repeat every 1 Months - Until End date <far in future> - Day of Month Day of Month First Monday An exception will raise opw-2412598 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#63590

Create an event as follows:

- Recurrent
- Repeat every 1 Months
- Until End date <far in future>
- Day of Month Day of Month First Monday

An exception will raise

opw-2412598

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#63590

Before this commit, the 'mounted' method of the ControlPanel in the website dashboard was called twice, when entering the dashboard. It happened because the dashboard updated the ControlPanel before being actually mounted, so mounted was called once when the dashboard was mounted, and once when the update was applied. Ideally, this should not be an issue (this isn't an issue with owl). However, in Odoo, we mix layers of Owl Components and legacy widgets. In these situations, the above

Before this commit, the 'mounted' method of the ControlPanel in
the website dashboard was called twice, when entering the dashboard.

It happened because the dashboard updated the ControlPanel before
being actually mounted, so mounted was called once when the
dashboard was mounted, and once when the update was applied.

Ideally, this should not be an issue (this isn't an issue with owl).
However, in Odoo, we mix layers of Owl Components and legacy
widgets. In these situations, the above scenario isn't properly
handled (and can't be).

As a consequence, in mobile (enterprise), it crashed because an
handler bound in mounted (thus twice) was only unbound once.

This commit avoids the issue by correctly setting the control
panel props before rendering it (the update was actually useless).

opw~2417307

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#63617

the purpose was to make sure that, creating a partner from the quick create kanban card in crm behaves similarly as creating it from the opportunity form view. earlier customer created from the quick create kanban card was not the same, like company type , sales person and sales team as the one created from the opportunity form view. task-id :2409462 Forward-Port-Of: odoo/odoo#62822

the purpose was to make sure that, creating a partner from
the quick create kanban card in crm behaves similarly as
creating it from the opportunity form view. earlier customer
created from the quick create kanban card was not the same,
like company type , sales person and sales team as the
one created from the opportunity form view.

task-id :2409462

Forward-Port-Of: odoo/odoo#62822

In case of RFQ with the "Ask confirmation X day(s) before" set, the email send to the vendor give a link where he (portal user) can change the date_planned of PO lines. But the change wasn't done in the server side because the `_update_date_planned` (of stock_purchase) doesn't call super if there isn't a linked move (none in case of RFQ). Move the call of the super. close #59040 Forward-Port-Of: odoo/odoo#63378

In case of RFQ with the "Ask confirmation X day(s) before" set,
the email send to the vendor give a link where he (portal user)
can change the date_planned of PO lines. But
the change wasn't done in the server side because the
`_update_date_planned` (of stock_purchase) doesn't call super if
there isn't a linked move (none in case of RFQ).
Move the call of the super.

close #59040

Forward-Port-Of: odoo/odoo#63378

STEPS: * install project, website * install translation, but don't apply to website * create a task with Customer that has that language * close the task * open rating request message in ``Settings >> Technical >> Messages`` * click any of the smiles BEFORE: Error to render compiling AST IndexError: list index out of range Template: portal.language_selector Path: /t/t[1] Node: <t t-set="active_lang" t-value="list(filter(lambda lg : lg[0] == lang, languages))[0]"/> AFTER: no

STEPS:
* install project, website
* install translation, but don't apply to website
* create a task with Customer that has that language
* close the task
* open rating request message in ``Settings >> Technical >> Messages``
* click any of the smiles

BEFORE:

Error to render compiling AST
IndexError: list index out of range
Template: portal.language_selector
Path: /t/t[1]
Node: <t t-set="active_lang" t-value="list(filter(lambda lg : lg[0] == lang,
languages))[0]"/>

AFTER:
no errors, page is translated to customer's language, though language selector
shows default website's language

---

opw-2416586

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#63526

PURPOSE In Project/Planning, we display the sum of the allocated time of all of the shifts under each employee. When there are records, this number is rounded to two digits. But with the sample data, there is no rounding so the numbers have 15 digits, which doesn't look good. SPEC always round to 2 digits the sum of allocated time in gantt view TASK 2318503 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#55987

PURPOSE
In Project/Planning, we display the sum of the allocated time of all of the shifts under each employee. When there are records, this number is rounded to two digits. But with the sample data, there is no rounding so the numbers have 15 digits, which doesn't look good.

SPEC
always round to 2 digits the sum of allocated time in gantt view

TASK 2318503



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

Forward-Port-Of: odoo/odoo#55987

When a form view is opened, the first call to `onchange` should always compute fields, even if their dependencies have no default value. Make sure it is the case for main records, and for records inside one2many fields. The latter case was actually not working as expected. Forward-Port-Of: odoo/odoo#63627

When a form view is opened, the first call to `onchange` should always
compute fields, even if their dependencies have no default value.  Make
sure it is the case for main records, and for records inside one2many
fields.  The latter case was actually not working as expected.

Forward-Port-Of: odoo/odoo#63627

When deleting an `account_reconcile_model`, it does not delete the corresponding `account_reconcile_model_line`. Moreover, this may prevent the user from using the l10n_de_skr04 module. To reproduce the error: (Use demo data) 1. Go to Apps 2. Install "Germany SKR04 - Accounting" 3. Change the company - Select "DE03 Company" 4. Go to Settings > Invoicing > Fiscal Localization 5. Change the package - Select "Deutscher Kontenplan SKR04" 6. Save => A validation error is displayed:

When deleting an `account_reconcile_model`, it does not delete the
corresponding `account_reconcile_model_line`. Moreover, this may prevent
the user from using the l10n_de_skr04 module.

To reproduce the error:
(Use demo data)
1. Go to Apps
2. Install "Germany SKR04 - Accounting"
3. Change the company
	- Select "DE03 Company"
4. Go to Settings > Invoicing > Fiscal Localization
5. Change the package
	- Select "Deutscher Kontenplan SKR04"
6. Save

=> A validation error is displayed: "The operation cannot be completed:
another model requires the record being deleted[...]".

When changing for SKR04, the module's installation first deletes some
models, among them: `account_reconcile_model` and later `account_tax`. The
validation error appears on `account_tax` deletion. Since version 14, an
`account_reconcile_model` is composed of `account_reconcile_model_line`
and the latter is linked to `account_tax` (with `ondelete='restrict'`).
Here is the issue: when deleting the `account_reconcile_model` model,
the corresponding lines are not deleted. As a result: later, when trying
to delete all the `account_tax`, since some `account_reconcile_model_line`
are still present in database, it triggers the `ondelete='restrict'`
constraint.

OPW-2416066

Forward-Port-Of: odoo/odoo#63566

Step: - Go to Field Service > Configuration > Settings - Activate Extra Quotations - Go to Configuration > Projects - Click a project (A) - Activate Extra Quotations - Enter a task of project (A) - Click new quotation and save the new quotation - Go back to the task - Click new quotation and save the new quotation once again - Click the "Quotations" smart button - Click one quotation - Cancel it - Go back to the task - Click the "Quotations" smart button Bug: Traceback here: ht

Step:
- Go to Field Service > Configuration > Settings
- Activate Extra Quotations
- Go to Configuration > Projects
- Click a project (A)
- Activate Extra Quotations
- Enter a task of project (A)
- Click new quotation and save the new quotation
- Go back to the task
- Click new quotation and save the new quotation once again
- Click the "Quotations" smart button
- Click one quotation
- Cancel it
- Go back to the task
- Click the "Quotations" smart button

Bug:
Traceback here: https://github.com/odoo/enterprise/blob/3150dcf00cd184c88fbcfa421ba017919a3b106a/industry_fsm/models/project.py#L286
ValueError: Expected singleton: sale.order(25, 24)

Explanation:
The domains between the view and the smart button are different. The smart button was showing "1" but there were actually two sales orders behind it (one of them is cancelled and grayed out). This fix aligns the two domains.
The smart button is now displaying the correct number of sales orders.

opw:2412428

Forward-Port-Of: odoo/enterprise#15397
Forward-Port-Of: odoo/enterprise#15276

STEPS: * create calendar event, add Azure Interior as participant * open mail.mail with the invitation * open accept link in incognito window BEFORE: File "/opt/odoo/custom/src/enterprise/website_calendar/controllers/main.py", line 175, in calendar_appointment_view tz_session = pytz.timezone(timezone) File "/usr/local/lib/python3.5/site-packages/pytz/__init__.py", line 163, in timezone if zone.upper() == 'UTC': AttributeError: 'bool' object has no attribute 'upper' AF

STEPS:
* create calendar event, add Azure Interior as participant
* open mail.mail with the invitation
* open accept link in incognito window

BEFORE:

  File "/opt/odoo/custom/src/enterprise/website_calendar/controllers/main.py", line 175, in calendar_appointment_view
    tz_session = pytz.timezone(timezone)
  File "/usr/local/lib/python3.5/site-packages/pytz/__init__.py", line 163, in timezone
    if zone.upper() == 'UTC':
AttributeError: 'bool' object has no attribute 'upper'

AFTER:

Owner's tz is used

---

opw-2415703

Forward-Port-Of: odoo/enterprise#15377

When changing an employee's contract status to 'Running', if he already has some planning slots based on shift templates, the end date whill be replaced. To reproduce the error: (Need hr_payroll) 1. Go to Planning 2. Click on Add 3. Set the new planning slot PS: - Set employee E - Set shift template ST - For date, select a range of at least 2 days and keep it in mind 4. Publish 5. Go to Payroll > Employees > Contracts 6. Select E's contract 7. Change the status to "new" 8. C

When changing an employee's contract status to 'Running', if he already
has some planning slots based on shift templates, the end date whill be
replaced.

To reproduce the error:
(Need hr_payroll)
1. Go to Planning
2. Click on Add
3. Set the new planning slot PS:
	- Set employee E
	- Set shift template ST
	- For date, select a range of at least 2 days and keep it in
mind
4. Publish
5. Go to Payroll > Employees > Contracts
6. Select E's contract
7. Change the status to "new"
8. Change the status to "Running"
(Steps 7-8 are used to force the status "Running". This change can
appear when creating a new contract for an employee who is already
working for the company, for instance)

=> 2 undesirable behaviours can occur:
- An error message appears "Shift end date should be greather than its
start date"
- Back to Planning, find PS, the end date is different from the one
defined on step 3. The new one is only based on the start date and the
ST's duration.

Because of several `compute` variables, when changing the status of an
employee's contract, it calls the method modified in this commit.
The latter then recalculates the end date of the employee's slots
considering only the duration of the shift template and actually
ignores the defined range of days previously defined.

OPW-2411760

Forward-Port-Of: odoo/enterprise#15344