This commit makes the clear button of the toolbar always visible
even if no style is applied.

Since the display is controlled by the css, we removed the concerned
style.

Task-3459819

closes odoo/odoo#132606

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

Changes in default can be bothersome, embed a full baseline
configuration for reliability.

closes odoo/odoo#27926

Signed-off-by: Pierre Masereel <pim@odoo.com>

Bug:
When printing DDT documents for a delivery with a pricelist applied, the
total value shown comes from the product's original price and not the
modified pricelist price.

Setup:
- install `sale_management` and `l10n_it_stock_ddt`
- have a product P with a price A
- create a pricelist that where P has a price B

Steps to reproduce:
- activate DDT report printing
- create a quotation set the pricelist you created and the product P
- validate the quotation
- go to the associated delivery and validate it
- print the DDT report

You should see that the price mentioned on the DDT report does not
account for the pricelist. (price A is shown, instead of B)

opw-3171295

closes odoo/odoo#133639

X-original-commit: 9bdb0ed2
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>

If leads are created using live chat, users without CRM rights cannot
access the visitors list anymore because the lead/opportunity
information is not available to them.

This commit limits the display of `lead_count` to the
`sales_team.group_sale_salesman` group.

In 14.0, the column still appeared without the `lead_count` value
displayed, but clicking on it raised a traceback.

Steps to reproduce:
- Install `website_crm_livechat`
- Login as Mitchell Admin
- Send a message in the live chat
- Go to Discuss
- Answer the livechat message with `/lead New`
- Go to Settings / Users / Marc Demo
- Remove the Sales rights
- Logout
- Login as Marc Demo
- Go to the Website / Reporting / Visitors page

=> The page could not be reached and an access right error message was
generated.

opw-3475301

closes odoo/odoo#133933

X-original-commit: dcb53f42
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

If sales, inventory, project and renting are installed and product
configurator is enabled, when user adds one storable product and
confirms the order and adds one service product after the traceback
appears caused by reading properties of undefined variable parentList.

opw-3324320

closes odoo/odoo#131210

Signed-off-by: Valeriya Chuprina (vchu) <vchu@odoo.com>

I missed a critical issue in #133708: various users had discovered
they could already fix description issues by adding an XML declaration
to their document which is very cool (though technically not really
valid).

What is a lot less cool is that lxml gets *extremely* unhappy when
asked to parse *strings* with an encoding declaration, raising a
ValueError, so the purported fix breaks on any module which does that,
which seems to include a lot of OCA modules.

Gate the encoding guessing by bailing if the document has an XML
declaration, in which case we just assume the author knows what
they're doing and we leave them alone. For extra safety, check the
encoding declaration in ascii and utf16. Could also have checked for
BOMs, but lxml seems to not care about them overly much (in fact it
seems to prefer them decoded which is odd).

closes odoo/odoo#133919

Reported-by: @rezak400
X-original-commit: 51d37560
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

The context in the list controller sets active_id as active_ids[0] which
means the default function will only check the first sale order's order
lines to calculate the default

Now it checks the active_ids first to see whether there are multiple
selected

closes odoo/odoo#133635

Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

Apparently `lxml.html.document_fromstring` (and possibly other
`lxml.html` loaders) parses byte-strings as latin1 regardless of their
actual encoding, maybe because python2, maybe because there's a super
legacy html4 parser underlying it.

Either way that means ever since loading
`static/description/index.html` files was added 10 years
ago (4bf6a7ea) `_get_desc` has been
loading these files in latin1 rather than the utf8 most people would
expect.

Add an explicit decoding phase to try and load html description files
in UTF8. Fall back to latin1 in case there are description files which
are genuinely in latin1, or even just some random-ass broken stuff
which very much isn't utf8 (the extended-ascii encodings -- of which
latin1 is one -- will happily accept and mangle any input as every
byte value is valid, utf8 is a lot more structured).

Closes #127846

closes odoo/odoo#133740

X-original-commit: 4dbc3b00
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Before, when instatating the interfaces if there was an error inside
Odoo could stop. This PR prevents that and simply avoids instantiating
the interface which causes the error.

closes odoo/odoo#133791

Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>

When sending a mailing we make sure to preserve comments (in particular
so that MSO comments can be read by Outlook). However this was not the
case when testing a mailing using the Test button in the form view.

task-3488162
opw-3290548
opw-3479234

closes odoo/odoo#133754

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

Steps to reproduce:
 1. Create an SO with billable timesheet entries
 2. Create an invoice
 3. If using enterprise, first cancel the invoice and reset the timesheet
  entries back to draft, then set the invoice back to draft
 4. Remove the sale order items from the timesheet entries
 5. Remove the invoice line associated with the timesheet entries

Current behavior:
 - Throws an error since the so_line value from read_group is now
   False and is not subscriptable

Expected behavior:
 - Removes the invoice lines

Fix:
 - Check that the so_line is not False before continuing with the logic

closes odoo/odoo#133748

Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

Current behavior:
When a discount is applied to a product, the receipt shows the price
with the discount applied as the base price.

Steps to reproduce:
- Open PoS
- Add a product to the order
- Apply a discount to the product with the numpad
- Validate the order
- Check the receipt, the base price of the product is the price with the
  discount applied.

(https://github.com/odoo/odoo/assets/32939472/eb0998a7-70a1-432a-8909-868d9307c999

)
The price in red should be 70$ (the price without the 5% discount)

opw-3463745

closes odoo/odoo#133377

Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>

This commit fixes the issue of animations that got trigger by backspacing, pressing enter
and other causes

The cause of the issue was a custom historyRevert event that was only used to
trigger a widgets_start_request event which ended up restarting the options,
which lead to the animation option replaying the animation.

We were not able to pinpoint the use of this particular trigger_up as it does
not seem to serve any purpose anymore. Since its presence does create a bug, we
decided that the best course of action was to remove it. If this commit creates
a regression and the original bug comes back, we will reassess the situation.

Task-2752421

closes odoo/odoo#131026

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

This commit introduces improvements to the order synchronization
mechanism. The changes ensure better error handling and provide a more
reliable and informative synchronization process.

Key Changes:

1. Enhance `_flush_orders` Method
    - The `_flush_orders` method now has additional error handling to
    detect RPC errors during synchronization of multiple orders. If an
    RPC error is detected and multiple orders are being synced, the
    method will attempt to send each order to the server individually.

2. Introduce `_flush_orders_retry` Method
    - This method sends orders to the server one by one and keeps track
    of the synchronization status (successful, RPC error, or other
    errors).
    - It sets the synchronization status to `'connected'`, `'error'`,
    or `'disconnected'` based on the outcome of individual order
    synchronization attempts.

3. Improve Error Handling
    - Enhanced error handling mechanisms to differentiate between
    various types of errors.
    - Synchronization status reflects the type of error encountered.

opw-3389388

closes odoo/odoo#126662

Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>

During 'l10n_eg_eta' server connection when the
'request_response' is not in proper json format then
while decoding 'request_response', the user will face the
'JSONDecodeError Expecting value: line 1 column 1 (char 0)'.
We are keeping the 'blocking_level' as 'error' because the
occurence of this error will prevent the succession of ongoing
operation.

Applying the changes will resolve the issue.

sentry-4220714667

closes odoo/odoo#123637

Signed-off-by: Josse Colpaert <jco@odoo.com>

In Saudi Arabia, the InvoiceLine/ID should not be greater than 6 digits.
Using the move.line_id, this limit can be exceeded.

Simply count the invoice line ids starting from 1 instead.

In master, add a parameter `line_id` to `_get_invoice_line_vals`.

closes odoo/odoo#133640

X-original-commit: 94aac2ed
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>

For some reason, “New” has been translated as “Nieuw” in Bulgarian, but
this is not Bulgarian, this is Dutch.

This commit replaces all occurrences of “Nieuw” with “Нов”, which is the
correct translation for “New” in Bulgarian.

closes odoo/odoo#133621

X-original-commit: 73512e95
Related: odoo/enterprise#46568
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>

Steps to reproduce the bug.

- In website edit mode, add a form snippet to a page.
- Add a "number" field within this form.
- Modify the label of this field in the options and name it "Field 1".
- Add a "text" field to the form.
- In the options of the "Text" field, select "Visible only if" for the
"visibility" option.
- Then, choose "Field 1" and "Is greater than" in the two dropdowns that
follow.
- Enter "10" in the input below.
- Save the page.
- Enter "2" in the "Field 1" input.
- Bug: The text field is displayed, even though it should only be
visible if "Field 1" is greater than 10.

This bug exists since the "conditionally show form fields" feature was
added to Website (in this commit [1]). The bug happened because we were
comparing strings instead of numbers.

[1]: https://github.com/odoo/odoo/commit/2dcbfecf3c10687a2cd3af36335d5be70c904fce



opw-3449900

closes odoo/odoo#133579

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

This reverts [this commit]. Indeed, [this commit] was too restrictive on
the visibility dependencies and blocked the creation of some conditions.

Example:
- Add a form on the website.
- Add two fields and rename them (by "test" for example).
- Change the visibility of the first one and set it to "Visible only if
Your Name is equal to Boule"
- Change the visibility of the second one and set it to "Visible only if
Your Name is equal to Bill"

-> The field "test" will be visible if "Your name" is "Boule" or "Bill".

[this commit]: https://github.com/odoo/odoo/commit/acb4a2764ca31a856d452e788afe4cb99d7d54af



closes odoo/odoo#133011

Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>

When posting again an account move related to an expense, the sheet's
state and the expense's state won't be updated

To reproduce the issue:
1. Create an expense
   - Paid By: Company
2. Create the related report
3. Submit to manager, Approve, Post Journal Entries
4. Open the related journal entry
5. Reset & Post

Error: States of both expense and sheet are incorrect (sheet:
"Posted" instead of "Done", expense: "Approved" instead of "Paid")

The state of the expense depends on the one of the sheet:
https://github.com/odoo/odoo/blob/1c517b6e67127971f343ffac0a4c29d684c8c13e/addons/hr_expense/models/hr_expense.py#L141-L153

The state of the sheet is manually written, each time the user does
an action. For instance, when posting the journal entries from the
sheet, we update the state of the sheet (which will change the state
of the expense, as shown in the above `compute`)
https://github.com/odoo/odoo/blob/1c517b6e67127971f343ffac0a4c29d684c8c13e/addons/hr_expense/models/hr_expense.py#L642-L643
https://github.com/odoo/odoo/blob/1c517b6e67127971f343ffac0a4c29d684c8c13e/addons/hr_expense/models/hr_expense.py#L1164-L1165

Same thing will happen when resetting the AM to draft:
https://github.com/odoo/odoo/blob/f6a13938f904f275b0360507b7ec987ef3bc2ddc/addons/hr_expense/models/account_move.py#L16-L20



But here is the issue: nothing updates the expense/sheet states when
posting again the AM

OPW-3322836

closes odoo/odoo#131060

Signed-off-by: Josse Colpaert <jco@odoo.com>

Description of the issue/feature this PR addresses:
In project module, if milestone name is long then name is overflowing.

Current behavior before PR:
milestone name is overflowing when name is too long.

Desired behavior after PR is merged:
when milestone name is long it would show with '...' format.

Fix:
add some bootstrap class so that long name should be formatted in '...' .

task-3217427

closes odoo/odoo#116811

Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

Description of the issue/feature this PR addresses:
when logged in user name is too long then it take whole header to display it
name.

Current behavior before PR:
whole header is occupied when username is long.

Desired behavior after PR is merged:
when username is long it would show with '...' format.

Fix:
some property is added in oe_topbar_name class to display the  username in short
and '...' format

task-3217427

Part-of: odoo/odoo#116811

There were 2 errors fixed by this commit:
1. The form registry fields added in [1] and [2] in Odoo 13 had a
   `string` attribute translated with `_t()` while now it should be
   translated with `_lt()`. It was surely working in Odoo 13 but not
   anymore. It's not worth investigating to be sure.
2. The IMP done at [3] added a lot of fields but all of those forgot the
   `_t()`/`_lt()` translation.

Note that:
1. A fix to replace `_t` by `_lt` was done at [4] but it was badly done
   as it was not targetting the correct version... and only fixed one of
   many occurences.

[1]: https://github.com/odoo/odoo/pull/32565
[2]: https://github.com/odoo/enterprise/pull/4063
[3]: https://github.com/odoo/odoo/commit/617eba941785aa680edb826e14b0009637d60dee
[4]: https://github.com/odoo/odoo/commit/2be83cae7bcda369ed5bc7806aef845c6c76e687



opw-3471873

closes odoo/odoo#132975

Related: odoo/enterprise#46206
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Somehow, there is not .pot file for this module while there is a
translated term.

A proper investigation wasn't made, but here is the history:
- The "Project" translatable term was added in JS with commit [1] in
  April 2019 as an IMP in master so there was no addition in the `.pot`
  file, as expected.
- The `.pot` file was added by a `[I18N] export saas-12.4 terms` commit
  at [2] in Augustus 2019.
- The `.pot` file was removed by a `[I18N] export 15.0 source` commit at
  [3] in September 2021.
  This was probably an error as the "Project" term from this module was
  never removed and always existed since it was added in 2019.

[1]: https://github.com/odoo/odoo/commit/6df3ba8b22ff16e9fd8ad6d87ea55e7eaf13e67b#diff-529f47293f2a178209115a2bc74ce79c5a880e58497a5e9d86ad4d7fd29676baR17
[2]: https://github.com/odoo/odoo/commit/8be6470a826fc6e467a3bef1696d236249ca29f9#diff-29cc1f256a825ea298abd8b7780984bacca6b874c5d139412fed5fb164794cd2R1
[3]: https://github.com/odoo/odoo/commit/63e6807437295519a0f4705fb88644d6d557ca3a#diff-29cc1f256a825ea298abd8b7780984bacca6b874c5d139412fed5fb164794cd2L1

Part-of: odoo/odoo#132975

Issue:
In the project's portal view, if the user is previewing his tasks of a
project with a specific order that is not date or name, and then
goes back to the project list view via the breadcrumb, he is met
with an error 500.

Steps to reproduce:
- Install Project
- With the portal user, go to Project
- Click on a project and sort the task by 'project'
- Go back to the project view via the breadcrumbs.
- Error 500

Cause:
Due to the definition of the url of the breadcrumbs which is
set with `keep_query` which keeps the arguments of the url. The
issue with that is that for the project list view, some of the sort
arguments are not defined, as they are only present in the task view.
So if we sort based on 'project' there is a `KeyError` in the
controller of the project portal view.

Fix:
If the `sortby` is not one of the valid keys, we fallback on 'date'
sorting, which is the behaviour in case when there is no `sortby`
argument in the url. This will keep the `sortby` in the arguments of
the URL, but just ignoring it. This is better UX than having a hard
redirection, because if the user decides to click on a project, the
tasks will be sorted with his previous order specified, which is
usually the wanted behaviour.

Affected versions:
15.0 -> 16.0

opw-3425342

closes odoo/odoo#129016

Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

A new text has been introduced in 863eba62
but not added in the .pot file, this commit fixes this.

closes odoo/odoo#133571

Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>

The inherited field of a custom field cannot be deleted

Steps to reproduce:
1. Install Contacts and Studio
2. Go to Contacts and open any contact
3. Toggle Studio
4. Add a field of any type in the view, remove it and close Studio
5. Go to Settings > Technical > Database Structure > Fields and search
   for `x_studio`

Solution:
Mark the inherited field as manual if its parent field is manual and
allow the deletion of inherited custom field if we also delete its
dependency

Problem:
The inherited field was not marked as custom so it was impossible to
delete it

opw-3093581

closes odoo/odoo#130420

Signed-off-by: Raphael Collet <rco@odoo.com>

The condition to create is wrongly evaluated and does not take into account
the country code and the picking type code. This commit fixes this by
reordering the conditions.

closes odoo/odoo#133161

X-original-commit: 30b00e5c
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>

In stock_production_lot model, there is a field last_delivery_partner_id which is displayed in a Tree View. This fields require to compute ALL the delivery_ids of each LOT, only to display the last_delivery_partner.

This implies a big performance issue for big lots with huge tracability needs in it. The idea is simple, dissociate the computation for delivery_ids, which is only used in Form View and the last_delivery_partner_id which is only used in the Tree View.

I do agree that if both are used in the same view, it would double the computation time. But currently there is a lot of useless computation. Currently the only way to mitigate is by removing the field last_delivery_partner_id in the Tree View, but if client needs that field, it doesn't works.

Benchmark

|Lots/Serial |# Lots | # Delivery | Before PR | After PR |
|:------------:|:---------:|:--------:|
|Lots| 3 | 3  | 0.2723 s |0.0091 s |
|Lots| 4 | 6699 | 307.98 s | 0.0059 s |
|Lots | 13 | 9575 | 569.85 | 0.0036 s |
|Serial | 80  | 80  | 0.30 s | 0.42 s |
|Serial | 150 | 150 |0.39 s | 0.51 s |
|Serial | 7000 | 2000 | 0.50 s/Batch of 1000 | 0.60 s/Batch of 1000|

closes odoo/odoo#129363

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Current behavior:
  If you set a specific sale_order_item for an employee on a project, and
  create a timesheet line from the "My Timesheets" menu,
  the sale_order_item will not be the one you selected for this employee.
  This happens because when you create a timesheet line from the "My
  Timesheets" menu, the employee is not set on the timesheet line.
  To fix this we fallback on the user's employee when creating a timesheet
  line from the "My Timesheets" menu.

Steps to reproduce:
  - Make sure you'r logged in as Mitchel Admin
  - Create a service product that create project and tasks
  - Create a sale order with this product
  - Go to the project and set a sale order item for Mitchel Admin in the
    invoicing tab
  - Go to the "My Timesheets" menu and click "Add Line"
  - Select the project you created
  - The sale order item will not be autofilled with the one set on the
    invoicing tab of the project.

opw-3463849

closes odoo/odoo#133478

Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

After eb3dcd60cb88f190d6398d7cadfb7852eecf909c is_html_empty was
accepted in document layout and would no longer cause an error when
using "Configure Document Layout" wizard.

If l10n_de is installed, this caused an error itself in "Configure
Document Layout" because of the content of the external_layout_din5008
that itself use the "company" variable if available (and in the given
case, this is a NewId base.document.layout record).

To fix this issue, this commit backports the 16.0 forward-port of the
referenced commit (5f1ad0c1).

opw-3433583

closes odoo/odoo#133447

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

Don't do it only at install.

closes odoo/odoo#133364

X-original-commit: 5add840b
Signed-off-by: Nicolas Seinlet (nse) <nse@odoo.com>
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>

Since [this commit], it's now possible to edit a media when it's in a
parent that is not editable thanks to `o_editable_media` class.
Unfortunately, these changes make the new class bypass the potential
`data-exclude` defined in the XML option declaration. So if the target
looks like that:
```html
<img class="o_editable_media odoo"/>
```
and the XML option declaration has a `data-exclude=".odoo"`, the option
will still be displayed. This commit corrects the way the
`o_editable_media` class works, so that it only bypasses the
`.o_not_editable` but not the entire exclude.

[this commit]: https://github.com/odoo/odoo/commit/580f1b77ce0b96b7efbf83a0ccdf6979bbf0e904



task-3476644

closes odoo/odoo#132849

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

After this commit, we prevent the slideshow from appearing when clicking
on an "Images Wall" snippet image that has been set as a link.

Steps to reproduce the bug:

- Drag and drop an "Images Wall" snippet onto the page.
- Add some images in the snippet.
- Click on an image within the snippet.
- In the editor text toolbar, click on the "Link" button.
- Set the URL of the link to "/contactus".
- Click on the "Save" button in the modal.
- Save the page.
- Click on the image with the link.
- Bug: The slideshow briefly appears before redirecting to the "contact
us" page.

task-3425624

closes odoo/odoo#133325

X-original-commit: 8b29eabb
Signed-off-by: Colin Louis (loco) <loco@odoo.com>

closes odoo/odoo#133036

X-original-commit: 854923b8
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>

X-original-commit: b9de6fc2
Part-of: odoo/odoo#133036

The closing session popup input for bank payment methods throws an error when no cash payment method is configured.

Steps to reproduce:
 - Configure a shop without any cash payment method and with at least one bank payment method
 - Open a session for that shop
 - Click on the button to display the closing session popup
 - In the popup, change the amount of the bank payment method

An error is thrown.

The fix simply consists in correctly checking if there is a cash payment method.

closes odoo/odoo#132473

Task-id: 3468828
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>

A check was added to prevent importing records with prefixes of existing
modules: https://github.com/odoo/odoo/pull/130825

 . This queries the
known modules, but non-admin users don't have access to that by default,
causing the import to fail for them. Allow the module query regardless
of access rights.

closes odoo/odoo#133326

X-original-commit: e1dcf886
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Merel Geens <mege@odoo.com>

steps to reproduce it:
1. Create a storable product, add a Purchase vendor with
 start date = 20/6/2022 and delay = 56
2. Create another storable product, add the same Purchase vendor with
 start date = 11/01/2023 and delay = 21
3. For both products, add Routes "MTO".
4. Create a SO with those 2 products, and confirm it
5. As you can see, the price of the first product is correctly set
but not the second product

BUG:
This is due of "Order Deadline" (date_order) being set to an old date,
which is before the second product date_order.

FIX:
set max PO date as today

opw-3167094

closes odoo/odoo#132892

X-original-commit: 72a17baf
Related: odoo/enterprise#46177
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>