Adapt the tests after commit
https://github.com/odoo/odoo/commit/47905d21ab65f985291d78cb7ecb78f2f7cdcf67


A down payment is no longer created when a prepaid amount is detected in
a UBL/CII attachment.

closes odoo/odoo#120653

Signed-off-by: Laurent Smet <las@odoo.com>

When l10n_mx_edi is installed and a payment is posted, the move_name field on account.move.line
being a related to move_id.name is not well computed.
That is because posting a move trigger the computed field in a protected mode due to `flush_recorset`.
This mode prevents any computed field to be recomputed twice.
This flush triggers `_compute_name` calling `sequence_mixin`, itself doing another `flush_recorset`.
This extra flush triggers `_compute_l10n_mx_edi_cfdi_uuid` that access to `move.payment_id.reconciled_bill_ids`.
This access to this field triggers its recomputation and then, `_compute_stat_buttons_from_reconciliation` is called.
This method does `self.env['account.move.line'].flush_model()` that force the computation of `move_name` to `/`.
`sequence_mixin` assigns the new `name` to the journal entry but `move_name` is not recomputed due to the
protected environment.

closes odoo/odoo#120411

Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

Previously, a user could link his own expenses to a expense sheet
of someone else.

This would not be allowed upon creation but was allowed when updating
the values of the expense.

This commit add a simple check at the beginning of the write()

closes odoo/odoo#120008

Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>

closes odoo/odoo#119586

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Introduced in 51fd5d3c

closes odoo/odoo#120536

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Before this commit, it was possible for one to post
multiple reviews when all the already posted reviews
had the 'Employee Only' state. A traceback was also
thrown when trying to update an 'Employee Only'
comment. It was also possible to edit a log note.
This commit fixes all these issues.

Task-2810085

closes odoo/odoo#107956

Signed-off-by: Stéphane Debauche (std) <std@odoo.com>

Override the button_draft method, in order to
reset the expense and expense_sheet state
when resetting a move to draft.

Steps:

- Create an expense
- Submit and approve the report
- Post journal entry and register payment
- Reset the JE to draft
-> The expense and expense sheet states
   remain the same as before resetting
   to draft. They should be respectively
   'approved' and 'post'

opw-3279364

closes odoo/odoo#120286

Signed-off-by: John Laterre (jol) <jol@odoo.com>

Portal shows all Sale Orders available for current user. For example, salesman
can see his sales. If such a user can download digital files via product form in
backend, it makes sense to let user download them via SO page on portal.
However, it wasn't the case because /my/download requires product be purchased
by current user [1]. Fix it by checking read access first.

STEPS

* in backend create SO with digital product (customer must be different from
current user)
* create invoice and register a payment
* navigate to portal  (without using customer's token),
* open SO, click download on digital product

[1]: https://github.com/odoo/odoo/blob/1a24477fab4dd323cf94c010321d8942fb2c1a01/addons/website_sale_digital/models/account_invoice.py#L14-L22



opw-3144600

closes odoo/odoo#112639

Signed-off-by: Morgane Demesmaeker <edm@odoo.com>

In the website menu editor and in the studio menu editor, the user can
drag & drop the elements that constitute the menu of his website/app.
Users can also put a menu into another menu to create a sub-menu. For
the website, we allow two levels of menu but not more. For studio we
allow 5 levels of menu. When the user starts to drag an item, dropzones
can be drawn on the prohibited level (3 in website, 6 in studio) while
he can't create this level of menu. This commit adds a css rule to hide
those forbidden dropzones.

task-3251032

closes odoo/odoo#117300

Signed-off-by: loco-odoo <loco@odoo.com>

	Currently `report.stock.quantity` has a field defined in it called `move_ids`:
	`move_ids = fields.One2many('stock.move',readonly=True)`

	This virtual field has no corresponding inverse field so when performing a search_read on the model, it fails
	in fields.py when trying to do:	`inverse_field = comodel._fields[inverse]`

	In addition, this field is apparently not used anywhere in the source code and not queried in the SQL View.

	This means the model can never be search_read by default.

	Since this field is never used, it isn't stored, and the model is `_auto = False`, removing it won't break any database.

closes odoo/odoo#120048

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

"ValueError: External ID not found in the system: payment.payment_acquirer_
stripe" is generated because the user deleted the Stripe payment acquirer
record and its corresponding model tried to access the record of it.

Steps to produce the error:
1. Install e-commerce
2. Install install 'Stripe Payment Acquirer ' module
2. delete the Stripe payment from payment acquirer
3. Go to the e-commerce dashoboard
4. Click Set Payment
5. select Credit card (via Stripe)
6. enter any secret and Publishable key
7. click apply

This commit solves the above issue by preventing the deletion
of the payment acquirer if it has a external reference.

sentry-4041178833

closes odoo/odoo#119140

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

Purpose:
The purpose of this commit is to change the current behavior of days to close
graph generating from customizable desk demo data.

Specification:
For the opportunities, the day_close field is a compute field depending upon the
date_closed field. For the customizable desk demo data, the date_closed field
pre-existed, due to that customizable desk opportunity was not won or lost but
the graph report was generated.
so, this commit fixes the current behavior for customizable desk opportunity.

Task-3278039

closes odoo/odoo#119292

Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

The pdf viewer sometimes displays the sidebar when we open the pdf

Solution:
Add `pagemode=none` to the url when opening a pdf in attachments

opw-3193516

closes odoo/odoo#120330

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Wrong date, the tax change happens between 31.12.2023 and 01.01.2024.
Translation files were already correct.

closes odoo/odoo#120312

Related: https://github.com/odoo/odoo/pull/113001


Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>

The edi attachment (for every format in `account_edi_ubl_cii`) contains
a tag indicating whether the invoice is fully/partially paid.

Before this fix, when this tag was filled, a down payment section was
created on the invoice. For a fully paid invoice, the resulting amount
was then 0, so the invoice was marked as "Paid".

This was wrong. The correct amounts need to be kept on the invoices.
This fix no longer creates a down payment, instead a message is logged
in the chatter.

task-3264843
opw-3248200

closes odoo/odoo#118610

Signed-off-by: Laurent Smet <las@odoo.com>

Before this commit:
Files that should be ignored in the manifest but aren't (js library for example)
it can happen that files have huge lines, the regex to substract the
comments will overuse memory.
For example, a file of 13M with a line of more that 8M characters, the
memory consumptions peak at 1.7G

The results might be different, but it's an acceptable compromise

closes odoo/odoo#120120

X-original-commit: 0e56e4a7
Signed-off-by: Thibault Francois <tfr@odoo.com>

closes odoo/odoo#120015

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Swiss taxes retrieved by module update (and the update of taxes it triggers)
need to be active, even if the template data was set to inactive.

closes odoo/odoo#113001

Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

When we were updating taxes from templates in a multilang localization,
newly created taxes were not translated in languages of the localization.
We also need l10n_lu migration script to be run in `end` instead of `post`
to have translations loaded.

Related: #108667
Part-of: odoo/odoo#113001

The tax with xmlid vat_0_import was missing its repartition
lines which caused validation errors.
This PR adds empty repartition lines to fix this problem.

Part-of: odoo/odoo#113001

If a tax is an aggregation of its sub-taxes it makes sense to have no
repartition line. This PR relaxes the validation in that case.

Part-of: odoo/odoo#113001

Switzerland changes its rates at the beginning of next year,
this change already has some implications on client's flow so
we add them to the localization so they can coexist with old rates till
the end of the year.
Changes:
- Added new taxes (2.5% -> 2.6%, 3.7% -> 3.8%, 7.7% -> 8.1%)
- Added tax fiscal positions to match those taxes
- Added tax groups
- Adds migration script to l10n_ch to apply those changes

Task: 3162286
Part-of: odoo/odoo#113001

When installing l10n_eu_service without a localization installed, a line fails
in the get_oss_tags function of res_company, thus halting the installation
and returning an error.

This fail is due to the function relying on the company in self having its
'chart_template_id' set, when this is not always the case.

Adding a failsafe to that function allows the installation of the module to
proceed in the event that the chart_template_id is not set.

opw-3291118
opw-3289913

closes odoo/odoo#120077

Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>

On Debian based systems, the `tzdata` package is maintained to reflect changes
in timezones and there is no need to upgrade the `python3-tz` package.
On the other hand, for those who are using `pip` and thus our `requirements.txt`,
the package needs to be up to date. By unpinning it in the requirements.txt:

- new installations based on pip will be up to date
- older installations based on pip can easily upgrade
- debian based installations have to maintain the tzdata package
- mixed installs like on runbot will rely on Debian tzdata

closes odoo/odoo#117527

Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

Since this commit [1], the option to set the background color for
snippets in the footer has been removed. However, this should not affect
the snippets in the "All pages" popup, which is also located in the
footer.

This commit fixes that by showing the background color option for popup
snippets in the footer.

Steps to reproduce the bug:

- Drop a popup.
- Set the "Show On" option to "All pages".
- Drop a text block in the popup.
=> The text color is white over a white BG (because it is in the footer
and the footer text is white).

[1]: https://github.com/odoo/odoo/commit/00f70f7936d37ec1c7c26065b2126045337e2825



task-3102275

closes odoo/odoo#111681

Signed-off-by: Benoit Socias (bso) <bso@odoo.com>

Before this commit, modifying the "bg_filter" of a snippet would also
affect its child snippets (for example, if a Carousel snippet had a
"bg_filter" that contained another snippet with its own "bg_filter").

To reproduce the bug:

- Drop a "Tabs" snippet on a page.
- Add a background image to the snippet and apply a background filter to
it.
- Drop a "Text" snippet in one of the tabs of the "Tabs" snippet.
- Add a background image to the "Text" snippet and apply a background
filter to it.
- Change the color of the background filter of the "Tabs" snippet.
- Bug: the background filter of the "Text" snippet is also changed.

task-3102275

Part-of: odoo/odoo#111681

Steps to reproduce:

- Go to a website page > Add a 'Form' block > Add a new 'Selection'
field.
- Go to the page (in 'edit_translations' mode) > The selection field
options are not translatable.

The goal of this commit is to make the select options translatable
by adding an intermediate `.o_translation_select` element.

This element will handle option's text translations from the linked
`<select/>`. The final values are copied to the original element
right before save.

opw-3233360

closes odoo/odoo#117519

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

Deleting a kit BoM will lead to an error if the kit is in the middle
of a sale process

To reproduce the issue:
1. In Settings, enable UoM
2. Create a product category PC:
   - AVCO
   - Auto
3. Create three storable products P_kit, P_01, P_02
   - UoM of P_01: `m`
   - UoM of P_02: `kg`
4. Create a BoM:
   - Product: P_kit
   - Type: kit
   - Components:
     - 1 x P_01
     - 1 x P_02
5. Create and confirm a SO with 1 x P_kit
6. Force the delivery
7. Delete the BoM
8. Create and confirm the SO's invoice

Error: a traceback appears "ValueError: Expected singleton: uom.uom..."

Because of the configuration, when posting the invoice, we compute
the COGS. During that process, we need the average price of P_kit
https://github.com/odoo/odoo/blob/640907ec1852c4e477957c865549a87d3ae840dd/addons/sale_stock/models/account_move.py#L133
We give to that method the components' SMs. In
`_compute_average_price`, since we don't find a BoM, we will bypass
the mrp override
https://github.com/odoo/odoo/blob/419e42132d9526e9d98c2126158d4f88716d17c4/addons/mrp_account/models/product.py#L48-L50
As a result, it leads to
https://github.com/odoo/odoo/blob/640907ec1852c4e477957c865549a87d3ae840dd/addons/stock_account/models/product.py#L680-L684
Where we will have the candidates of all components (i.e., several
different products). But that method is not designed for such a
situation. This is the reason why, when calling `_consume_all`, it
will fail:
https://github.com/odoo/odoo/blob/858d24a611c4c8af0dcae82a6eb4077e391398ed/addons/stock_account/models/stock_valuation_layer.py#L85


We try to get the rounding of the product, but there are actually
two of them (the two components) -> singleton error

OPW-3218141

closes odoo/odoo#119944

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

Before this commit, on a blog page with the "regular cover" and "read
next article" options enabled, the image in the "read next article"
block would shrink when the text was too long.

Steps to reproduce the bug:

- Go to a blog page (e.g. "Sierra Tarahumara").
- Enable the "regular cover" and "read next article" options.
- Enter edit mode.
- Scroll down the page.
- Enter a lot of text as the title of the "read next article" block.
- Bug: As the text increases, the width of the image decreases.

opw-3267842

closes odoo/odoo#119852

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

Before this fix the payment engine was ignoring the billing address
for sale orders in when processing payments.
After this fix the billing address will be used in the payment details.

opw - 3212748

closes odoo/odoo#118358

Signed-off-by: Horacio Tellez Perez (hote) <hote@odoo.com>

A previous commit[^1] added the shipping address in case the `sale`
module is installed. But it didn't manage the case where that module
is not installed.

opw-3199710

[^1]: bd5071ac

closes odoo/odoo#119557

Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>

Since commit [1], when we are in the `/shop/cart` page and if a language
selector is in the header, a cart popover also appears when hovering the
languages. This happens because the `websiteSaleCartLink` widget
selector also targets the cart links inside the language buttons.

This commit solves this issue by excluding the language selectors from
this widget selector.

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



opw-3288727

closes odoo/odoo#119685

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

This revision follows
- odoo/odoo@5e81850ea64b533f0576c919a427820554096284
- odoo/enterprise@e484b4da0c8b70225e91cc66b64ac1b3a0bcc685

Before this commit, links scrolling to an anchor with a special
character did not work and displayed a traceback. The issue was that to
check that the anchor is valid, we don't need to check that the anchor
is a valid url as we have been doing since these commits [1], [2]. But
we only need to check if the jQuery selector is valid to correctly
target the element to which the page must scroll.

Indeed, the anchor widget returns stuff like 'ok%C3%A9%25' when typing
'oké%' wich is not valid jQuery selector. It has to be encoded to
'#ok\\%C3\\%A9\\%25' to be valid and that's what this commit does.

We also changed the way to display a new anchor to the user in this
commit. Before, we showed the anchor unencoded in a notification and now
we show it encoded. That way, if the user copies the anchor from the
notification, it's the real anchor.

Also, this commit detect if the success URL of the redirect of a from is
the current page to perform a scroll to the anchor instead of a
redirect. To make this comparison, we needed to add the url code of the
language of the current page to the session info.

Also, before this commit, the page froze when we clicked on the "submit"
button of a form that redirected to an anchor that did not exist.

[1]: https://github.com/odoo/odoo/commit/0abfaeda96c2eaa868cc7fc5fa1926dfa90fc420
[2]: https://github.com/odoo/odoo/commit/b492bde6a121be1c15ed90ce0827fcfd72a12f5c



task-2172312

closes odoo/odoo#82059

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Steps:
Say 3 existing tasks :
t0 (from which the recurrence has been created), t1, t2;
and t4 (not created yet).
When you change t0, t4 is updated as expected.

Issue:
But when you change t1, t4 doesn't take it into account.

Cause:
`ProjectTaskRecurrence._create_next_task` takes
`recurrence.task_ids[-1]` as template to create the next occurence.
Yet ProjectTask is ordered by "priority desc, sequence, id desc".
All occurrences being likely to have the same priority and sequence,
we the result ordered by id desc. So `recurrence.task_ids[-1]` has the
smallest id and so it is the oldest one.

Fix:
Take the task with the max id.

opw-3237168

closes odoo/odoo#118979

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

When converting a lead to an opportunity and merging with existing
opportunities, the list view showing opportunities is very tiny.

This is caused by the field not having the correct colspan, as its label is
hidden with the "nolabel" attribute.

This commit fixes it by assigning a colpan of 2.

Task-3179173

closes odoo/odoo#119215

Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>

[FIX] stock_account: prevent stock account update on product change when using manual stock valuation

If the category of a product is using manual stock valuation, when changing the product on an invoice line,
the account should not be set to the `property_stock_account_input_categ_id`. It should be the case only if
we use automatic/real-time stock valuation.

opw-3226536

closes odoo/odoo#119535

Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>

The tax 21% ISP actually behaves like a normal 21% tax
(it gets reported in the same lines, ...)

But the reason for its existence is that in case of the
fiscal position Revendedor ISP...  it gets mapped to the
0% ISP tax (which needs to be 0)

Before, if you would however send a 21% ISP tax to the SII,
it would be set as ISP and you would get an error telling
that the tax rate should be 0 in case of ISP.  (but now, it
will be reported as S1 and not trigger the error)

See also discussion in
https://github.com/odoo/odoo/pull/119339#issuecomment-1519720558



closes odoo/odoo#119603

Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

## Bug

When sending an invoice to a recipient who is not the customer, they are
unable to view the invoice in the customer portal and are prompted to
log in.

## Steps to reproduce

1. Create and validate an invoice
2. Click on the Send & Print button, then add a recipient who is not the
   customer associated with the invoice.
3. Proceed to send the invoice.
4. Access the email that was sent to the added recipient (who is not the
   customer)
5. Using an incognito or private browsing window, open the link
   `View Invoice`

=> you should see that you are asked to log in, instead of being
directed to the customer portal.

opw-3114579

closes odoo/odoo#118766

Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>