Just to see how it behaves currently, as we are going to fix some unwanted
changes. Notably

  * setting user_id to the same value as before should not update the
    date_open value;
  * setting stage_id to the same value as before should not update the
    last stage update value;
  * triggers generate chain update of those fields (changing team_id
    changes user_id that changes date_open, ...);

Task-3515225

Part-of: odoo#144848

Before this commit:
  * when a user changes 'user_id' to set the same previous 'user_id', the
    assign date 'date_open' is updated but it should not as the responsible
    did not change;
  * when a user changes the salesperson 'user_id' of a crm lead, it triggers
    a recompute of 'team_id' that triggers a recompute of 'stage_id' that
    updates  'date_last_stage_update' even if the stage does not change, which
    happens frequently when changing leads within a given team (new assign,
    salesperson on holidays, ...)
  * when merging opportunities, 'user_id' can be set on the main opportunity
    which triggers a recomputation of both 'date_last_stage_update' and
    'date_open' as explained in above points;

Reason:
The 'date_last_stage_update' field depends on 'stage_id' which depends on
'team_id' which depends on 'user_id'. As a result, when 'user_id' changes,
'date_last_stage_update' also updates.

Moreover those fields are implemented using editable stored computed fields
which are triggered everytime a value is given to those fields, even when
the same value is given.

After this commit:
'date_last_stage_update' and 'date_open' will only update when there are
real changes.

Task-3515225

Part-of: odoo#144848

'date_open' is the date when a user is assigned to a lead / opportunity. It
should not be set when converting a lead to an opportunity, as those two
flows are different. Only setting a responsible should update it.

Task-3515225

Part-of: odoo#144848

date_open should not be set when there is no user_id set. Let us be coherent
so that we can see the effect of assigning users that updates the date_open
field.

Task-3515225

Part-of: odoo#144848

Before this commit:
  * when a user changes 'user_id' to set the same previous 'user_id', the
    assign date 'date_open' is updated but it should not as the responsible
    did not change;
  * when a user changes the salesperson 'user_id' of a crm lead, it triggers
    a recompute of 'team_id' that triggers a recompute of 'stage_id' that
    updates  'date_last_stage_update' even if the stage does not change, which
    happens frequently when changing leads within a given team (new assign,
    salesperson on holidays, ...)
  * when merging opportunities, 'user_id' can be set on the main opportunity
    which triggers a recomputation of both 'date_last_stage_update' and
    'date_open' as explained in above points;

Reason:
The 'date_last_stage_update' field depends on 'stage_id' which depends on
'team_id' which depends on 'user_id'. As a result, when 'user_id' changes,
'date_last_stage_update' also updates.

Moreover those fields are implemented using editable stored computed fields
which are triggered everytime a value is given to those fields, even when
the same value is given.

After this commit:
'date_last_stage_update' and 'date_open' will only update when there are
real changes.

Also fix 'date_open' update when lead is converted into an opportunity.
'date_open' is the date when a user is assigned to a lead / opportunity. It
should not be set when converting a lead to an opportunity, as those two
flows are different. Only setting a responsible should update it.

Task-3515225

closes odoo#144848

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

Steps
-----
1. Have Resellers module installed
2. Connect with a portal user who doesn't have any opportunities but should be
able to create one.
3. On the portal page, the user cannot create an opportunity as the opportunities
tab is the only way to access the "Create opportunity" button and this tab is not
displayed if there are no existing opportunities.

Fix
---
We always display the opportunities tab on the portal for users who can create
opportunities.
Note: the fix for 17.0 is different as portal_docs_entry was modified.

opw-3809571

closes odoo#159670

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

Backporting: 1e24b15

When importing a UBL file, Odoo expects the UBL specific namespaces to
be in the root element of the file. This is not always the case as these
namespaces could exist in every element in the file. When a file is
formatted this way, Odoo cannot extract the necessary data from it
because it is missing the necessary namespaces. To cover this case we
use the lxml.etree.Element.find function instead, and pass in the UBL
specific namespaces to successfully extract the data.

task-3657563
opw-3839398

closes odoo#161653

X-original-commit: ac607fe
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>

If the "generic" routes (i.e., the ones created from the master data)
are company-specific, the user won't be able to create a new company
anymore.

To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Enable all companies
3. Inventory > Configuration > Rules:
   - For each Manufacture rule:
     - If its route does not have any company:
       - Set the route's company equal to the one of the rule
4. Create a new company

Error: a Validation Error is raised: "Rule [...] (Production) belongs
to \<new company\> while the route belongs to \<an existing company\>."

Creating a company leads to the creation of the WH and its rules. At
some point, we create/update the global rules. Let's look at the
Manufacture one. We will provide all the required values for its
creation:
https://github.com/odoo/odoo/blob/270d8aa06bb37b4a01f01a7274062e3f88ca2a1c/addons/mrp/models/stock_warehouse.py#L112-L128
As you can see, for the `route_id` field, we try to find a global
route. But here is the issue: in this `_find_global_route`, we will
find the "generic" one thanks to the provided XML_ID. But, step 3,
we set a company on that route. As a result, here, we try to create
a rule for a company X linked to a route that belongs to a company Y,
hence the validation error:
https://github.com/odoo/odoo/blob/dc58d7913131f1f4dbeb0e3337e61e0b21f6f0d9/addons/stock/models/stock_rule.py#L107-L108

OPW-3790512

closes odoo#161820

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

…plates.

Strings within inline templates are not translatable, so we convert
these templates into standard templates so that they can be.

Task-3761551

closes odoo#160238

Signed-off-by: Louis Wicket (wil) <wil@odoo.com>

This commit fixes a bug where the value of an autocomplete with autoselect
could go into an undefined state where the model value doesn't match the
input value but no change is detected. This would happen on escape press,
scroll and more recently due to odoo#159333
on click out. To fix this issue, the commit introduces some change in the
autocomplete behavior so that it will no longer select the active option
on click out (blur) when autoselect is active and instead it will revert
the input value to the one stored into the model. Also applies this
behavior on escape key press and scroll for the before mentioned reasons.

Steps to reproduce:
- Go to CRM form view
- Edit the salesperson name to some non existant one and click out (or
scroll or press escape)

Before the fix, the name was stuck to the invalid one but no change was
detected so we couldnt save it. Before odoo#159333,
click out would select the active option of the dropdown instead (and
launch a dialog for quick create). This is removed because the behavior
is neither intuitive nor practical. After the fix, the name is reset to its
previous valid value instead. This applies to all autocomplete components
with autoselect prop set to true.

closes odoo#161251

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

To reproduce:
- Create 2 lines with the same balance but only one has an analytic_distribution (of 100% on an analytic account).
- Create a transfer of accounts for these
=> The counterpart has a distribution of 100% or no distribution.
Indeed, we simply put the distribution of the last line.

It makes no sense: analytic "balance" is generated and does not reflect the transfer move.
We should make a prorata of the distributions of the lines to transfer.

closes odoo#160965

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

While in practice you would never get this inverse
called with more than one record at a time, it is
still wrong to get the company of self in the loop.
Fixing it to keep good conscience :)

closes odoo#161815

Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>

Steps to reproduce:
1. Go to IoT > Devices
2. Select a device and add the report "Lot/Serial Number (ZPL)"
3. Create a product tracked by lots
4. Purchase 5 units of this product
5. Validate the reception (with a lot)
6. Print labels > Lot/SN Labels
    - Quantity to print: One per unit
    - Format: ZPL Labels

Before this commit:
When printing labels for multiple lots of the same product, the wizard
was incorrectly generating the docids as a `list[list[int]]`. It works
correctly as the ids are joined thanks to JavaScript magic. However,
when sending the report to an IoT device, the ids are sent as-is in
the context, which raises and error when calling `browse()`.

After this commit:
The docids are now generated as a flat list of integers, which is
correct and works as expected.

opw-3850631

closes odoo#161932

Signed-off-by: Tiffany Chang (tic) <tic@odoo.com>

According to https://www.easytax.co/en/countries/greece
the vat number format for Greece is EL123456783
instead of GR12345670.
We also delete the line for country code `el`
from `_ref_vat` dict as we use `gr` for Greece.

opw-3845662

closes odoo#161895

X-original-commit: b97c74e
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>

As of April 1, 2024, the EAS code for Finland should be 0216.
Other address types are not allowed for Finnish end users.

See also:
[Finland Peppol Authority requirements](https://peppol.org/wp-content/uploads/2023/08/Finland-Peppol-Authority-Specific-Requirements.pdf)
[Finland Peppol Authority website](https://www.valtiokonttori.fi/en/service/the-state-treasury-is-the-finnish-peppol-authority/#for-service-providers_authority-specific-requirements-in-finland)

no task, reported by the Finnish Peppol Authoirty Team

closes odoo#161953

X-original-commit: e732bc2
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>

…endances

closes odoo#159422

See: odoo#158439
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Steps to reproduce the issue:
- Create a storable product “P1”:
    - Route: dropship
    - Vendor: Azure interior and deco addict

- Create a sales order with one unit of P1
- Confirm the sales order

- A purchase order is generated with a dropship-picking
(linked to the SO)
- Create an alternative PO and confirm it

Problem:
The alternative PO is linked to the SO, but the dropship-picking is not
linked. This is because the procurement is not propagated when creating
the alternative PO.

opw-3828132

closes odoo#160354

Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>

No rounding in the query used to map sale.order.line to
the hr.expense, models leads to some records not being able
to be linked together, because of floating point errors.

Adding a rounding to the key price_unit,
and not filtering on price_unit. Then, using the rounded string versions
of the price_unit in the comparisons adds a more reliable approach.

task-3705179

closes odoo#154002

Signed-off-by: William André (wan) <wan@odoo.com>

With a SA company setup
Open a journal entry
Hit 'Reverse Entry' > Reverse
Error: "For Credit/Debit notes issued in Saudi Arabia, you need to
specify a Reason"

This occurs because with SA localization we need to provide a reason for
move reversal but by default the reason field is invisible for journal entries

Backport of odoo@d660fd5

opw-3789732

closes odoo#161936

X-original-commit: 527db37
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>
Signed-off-by: Andrea Grazioso (agr) <agr@odoo.com>

Problem
---------
Because of this PR: 155896, the customer default value for the UBL
export values has been modified from commercial partner to partner.

However, in 16.0, some constraints have been added to verify that some
fields were properly set up before generating the XML. Those
restrictions clash with the said changes.

Indeed:
1 - Create NO company
2 - Set up UBL on invoice journal
3 - Create a new NO customer and set up UBL in the same way
4 - Create an invoicing address for that customer
5 - Create an invoice for with the customer set as the invoice address
set up in step 3.
6 - Send & Print with UBL selected

>> An error is added to the export errors while it should not.

Solution
---------
Use the commercial partner when checking constrains of all fields other
than addresses.

OPW-3848367

closes odoo#160523

Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>

Steps to reproduce the issue:

1. Create a Storable Product and give it a UOM
2. Create an On Hand stock in a certain location
3. Go to Barcode and create a new Internal Transfer
4. Add the Product and with any quantity and click on Confirm (not Validate)
5. Edit the line of the Product (pencil icon), change the quantity and the UOM and click on Confirm
6. Validate the Transfer
7. Go back to the Product and click on the "On Hand" or the "Update Quantity" button
8. The reserved quantity is not null

Explanation:

When you change `stock.move.line.product_uom_id`, `stock.quant.reserved_quantity` (using `product.product.uom_id`) is not changed to reflect the new `uom.uom.factor`. You then have two routes:

- In `stock_barcode`, `stock.move.line.product_uom_id` changes first, `stock.move.line.quantity` change is triggered through `stock.move.line._inverse_qty_done` afterwards.
https://github.com/odoo/enterprise/blob/d04b69ba03877a9b4aae82fb061dca23b1bfc4bc/stock_barcode/models/stock_move_line.py#L58-L61
When calling `stock.move.line._synchronize_quant`, `stock.move.line.quantity_product_uom` will use the new `stock.move.line.product_uom_id` while `stock.quant.reserved_quantity` still reflects the old `uom.uom.factor`.
https://github.com/odoo/odoo/blob/1b0dbb3645ad8b52c5260f1cbbc4f6bdee48461e/addons/stock/models/stock_move_line.py#L421-L422
(e.g.: going from `1 Dozens` to `2 Units` would give you `1.09 Dozens` in `stock.quant.reserved_quantity` instead of `0.17`)

- There is a similar issue in _Inventory > Transfers > Internal_, where `stock.move.line.product_uom_id` changes at the same time instead. In that case, the whole operation will be done using the previous `stock.move.line.product_uom_id`, and changing `stock.move.line.product_uom_id` before changing `stock.move.line.quantity` would cause the same issue as in `stock_barcode`.
(e.g.: going from `1 Dozens` to `2 Units` would give you `2 Dozens` in `stock.quant.reserved_quantity` instead of `0.17`)

Suggested fix:

There is a first check to make sure one of the values has changed, then each one will be assigned through a condition:

- The first one will be `product_uom_id`, with which `uom.uom._compute_quantity` will be called.
- The second condition will be `quantity`, which will be set in a `vals.get` in the `qty` parameter of the compute.

opw-3798046

closes odoo#161973

X-original-commit: 7e4d5c0
Signed-off-by: Quentin Wolfs (quwo) <quwo@odoo.com>
Signed-off-by: Stroobant Paul (stpa) <stpa@odoo.com>

Browse files
Steps to reproduce:
- Install Accounting, l10n_it_edi and Contacts
- Switch to an Italian company (e.g. IT Company)
- Go to Contacts and create a contact from San Marino:
  * Name: SM customer
  * Country: San Marino
  * Street, City, ZIP: [any]
  * Destination Code: [any]
- Create an invoice:
  * Customer: [the created contact from San Marino]
  * Product: [any]
- Confirm the invoice
- Check the generated electronic invoice

Issue:
In the XML, the destination code (i.e. CodiceDestinatario) is the
default one for non-Italian customer (i.e. XXXXXXX).
Also, the VAT number (i.e. IdFiscaleIVA) is the default value for
countries that are not in the European Union (i.e. OO99999999999).
However, since October 2021, San Marino should be handled differently
for Italian electronic invoices.
A specific destination code (i.e. 2R4GTO8) should be used for all
customers from San Marino.

Source: https://www.credemtel.it/fattura-elettronica/fattura-elettronica-san-marino/

Solution:
For customers from San Marino:
- Keep VAT number
- Set "2R4GTO8" as destination code

This is a backport of odoo@15cb8f5

opw-3819054

closes odoo#162073

X-original-commit: 302a7f6
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>

Before this commit:
If an error was sent back from stripe, it will not display in the
dialog box. Only the title of it but an empty content.
This happened as the message in my case was inside the error.
Also took the occasion to add a log in the backend

Example to reproduce: use a $ database when the stripe is set in
euro. It will trigger an error:
The card_present source type with currency usd is not supported in ...

After this commit:
Fallback on the message if the previous value is falsy

opw-3853953

closes odoo#161310

Signed-off-by: Loan Sens (lse) <lse@odoo.com>

…achments

Issue
-----

Report creation for multiple invoices fails (e.g. with <AttributeError: "NoneType" object has no attribute "getvalue">)
when some, but not all, of the invoices across the selection have a previously generated report
as an attachment, and the 'Reload from attachment' option is enabled for the report action.

Steps
-----

 - Enable 'Reload from attachment' from Settings -> Techical -> Actions -> Reports -> invoices.
 - Create 3 invoices without any previous reports as attachments.
 - Select the middle invoice and generate a report (Print -> Invoices). An attachment will be created
   for the invoice.
 - Select the 3 invoices then generate a report (Print -> Invoices).

Cause
-----

When "Reload from attachment" is enabled, the algorithm for creating aggregate reports for a number
of invoices selects only those that don't have an attachment to generate a pdf for. These are copied
into a separate list "res_ids_wo_stream". When the pdfs streams are generated, they're put back into
the return value "collected_streams. However, this was done from the original ids list "res_ids" rather
than the selected one, which resulted in an indexing issue.

opw-3827700
Closes odoo#157975

closes odoo#160670

Signed-off-by: William André (wan) <wan@odoo.com>

The `test_accepting_recurrent_event_*` tests make sure that accepting recurrent events on google side reflect in odoo.
The test was failing because of the following:
when retrieving the invited attendee, the test used `self.assertEqual(event.attendee_ids[1].state, expected_states[i])` assuming that organizer will be at index `0` and invited user at index `1`.
However the list of `event.attendee_ids` is ordered by create_date.
And we create both organizer and attendee with the same command at the same time: `partner_ids=[Command.set([self.organizer_user.partner_id.id, self.attendee_user.partner_id.id])]`
So we might have organizer at index `1` and invited attendee at index `0`. This resulted in the indeterministic behavior of the test.

To fix this issue:
This commit changes how the invited attendee is retrieved, making sure that we always get the right attendee.

fixes runbot-61527

closes odoo#161451

Signed-off-by: Ahmad Almaghraby (alah) <alah@odoo.com>

Steps to reproduce:
- Install POS app.
- Go to POS > Products > Discount & Loyalty
- Create a New program with:
    - Program Type: Loyalty Cards
    - Conditional rules:
        - Minimum Quantity: 2
        - Grant: 1 Loyalty Points per unit paid
- Rewards:
    - Reward Type: Discount
    - Discount: 100 % one Cheapest Product
    - In exchange of 2 Loyalty Points
- Start a new POS session
- Select a Customer
- Add two different products.
- Notice the Loyalty Points of +2 shown. This is Correct
- Click on the Reward button
- Notice how the Loyalty Points are now +3 which is obviously wrong given we only have two products. Basically it's as if the reward line (100% discount) is taken into consideration as the cheapest product.

Investigation:
- Inside `_updatePrograms`, `pointsForPrograms()` are calculated.
- we sum the lines quantities regardless of whether it's a reward line or not https://github.com/odoo/odoo/blob/e5c3ba58964f47cfd41d337e39e1bf25eaa25379/addons/pos_loyalty/static/src/js/Loyalty.js#L906
- By doing so, the reward lines are taken into consideration and the rule is triggerd by skipping this if clause https://github.com/odoo/odoo/blob/e5c3ba58964f47cfd41d337e39e1bf25eaa25379/addons/pos_loyalty/static/src/js/Loyalty.js#L917-L921

opw-3855323

closes odoo#161503

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

**Current behavior:**
Adding an attachment to a mail template record associated with
the survey invite wizard will not cause the attachment to
populate the relevant field when actually sending a new survey
invite email.

**Expected behavior:**
The attachments linked in the email template which is used by
the survey invite wizard will appear in the form when sending a
survey invite.

**Steps to reproduce:**
1. In settings, go to the email templates management page

2. Select the Survey: Invite template and upload some
     attachment

3. Go to the Survey application and click on one of the surveys
     listed, observe the lack of attachments despite having the
     email template with the attachment selected

**Cause of the issue:**
The survey invite wizard never uses its template's attachments
to modify/update its own attachment_ids field.

**Fix:**
Make the attachment_ids field a stored computed field.

opw-3709830

closes odoo#152728

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

Issue:
Discounts are not displayed in DDT

Steps to reproduce:
- create a quotation with a sale line having a discount
- smart button delivery > set qty > validate
- Print

opw-3745866

closes odoo#159325

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

Currently, when you refund an order that was paid with bank, thus not rounded, the refund is rounded wich result in a difference between the original order and the refund.
This also happens when the original order was paid with multiple payments and one of them was not rounded and the other was. The refund will be rounded as one single payment. This also results in a difference between the original order and the refund.

Steps to reproduce:
-------------------
* Setup a rounding method with a precision of 5.0
* Create a product with a price of 138.0
* Open the POS and add the product to the order
* Pay the order with 2 payments, one bank of 55 and one cash that will be rounded to 80.
* Validate the order
* Go in the backend and refund the order
* The refund will be rounded to 135.0

Why the fix:
------------
The new behavior after this fix:
* When refunding the entire original order, the amount to refund should be equal to what the customer paid on the original order (thus taking into account the rounding).
* When doing a partial refund, the amount that should be refunded correspond to the base price of the article(s) selected.

The issue was about the fact that refunds differed in prices compared to the original order. With this fix, there could still be a difference in the prices if a customer comes multiple times to do a partial refund and end up refunding the total order. This difference exists only if the original order was paid with rounding and will be maximum the rounding defined.

Since this is a rare event, we consider this difference to be acceptable.

Post-fixup:
-----------
The function `_get_rounded_amount()` was modified as we are not computing cash rounding when refunding anymore.

opw-3701574

closes odoo#161564

Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Co-authored-by: Robin Engels <roen@odoo.com>

Previously, when the odoo server was running on some Windows
installations, it was possible for javascript files loaded directly from
the static folder of an addon to fail to run because the Content-Type
header was set to text/plain instead of text/javascript. This is because
the mimetypes module from the standard library honors the mimetypes from
the OS, in the case of Windows it reads a key in the registry, which can
be misconfigured to text/plain for .js files.

This commit forces the mimetype of .js files to text/javascript to solve
this issue.

closes odoo#162277

X-original-commit: 9474c99
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>

STEP TO REPRODUCE:
-Install DB with demo data
-Go to see my tasks of Michell Admin and 13 tasks available
-Then go to user profile and hit action 'Assiged Task'
-> No tasks for Michell Admin

SOLUTION is remove the 'search_default' use domain instead

closes odoo#164976

X-original-commit: 352dc3b
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

The date_deadline propagation would update the sale records multiple times depending on some configuration (check example below).
This happens because 'already_propagate_ids' is copied at the beginning of _set_date_deadline (set | set = new set).
So, when a child move propagates to multiple other moves, it is not known by the parent move, which will redo the propagation.

To prevent this, we always keep the same reference for 'already_propagate_ids' (context: 'date_deadline_propagate_ids'). This means that a parent and child move share the exact same Set, and when the child move updates the Set, it also updates the parent Set.
So when a child move propagates, the parent will know which moves have been done.

   MOVES LINKAGE
       Move B
      /   |   \
  Move A  |  Move D
      \   |   /
       Move C

PROPAGATION GRAPHS:
  BEFORE    |  AFTER
------------+--------
    A       |    A
  /   \     |    |
  C   B     |    B
 / \ / \    |    |
 B D C D    |    C
 | | | |    |    |
 D B D C    |    D
------------+--------
    11      |    4     NUMBER OF CALLS

OPW-3904178

closes odoo#164891

X-original-commit: 85ec121
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: David Fesquet (dafr) <dafr@odoo.com>
Co-authored-by: Mathieu Walravens <wama@odoo.com>

Have a numeric field in a form view. The displayed value is
formatted, according to the thousands and decimal separators.
Say the value is 1,240.00. If the user edits the input and types
the same value, i.e. 1240, and then press "Enter", "Tab" or "Shift-
Tab", the value won't be formatted as it should be, because we
detect no change of value (which is true, but the value should
be formatted anyway).

With this commit, the value is always formatted on "Enter", "Tab"
and "Shift-Tab".

Issue spotted by fp

closes odoo#164953

Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>

"Cannot unreserve more than you have in stock" Error.
Prior to this fix, one could edit and change the uom on the stock move line
after reservations were done for an MO.
Therefore you could theoretically reserve 10 grams on the MO, go to the stock
move line in mobile version and change the UOM to kg - reserving 10kg. This
creates a missmatch in the reservation and triggers the unreserve error.

This fix blocks the user from doing so if there are already reserved
quantities on the move line.

OPW-3747596

closes odoo#162432

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

Before this commit:
Any IoT-box syncing to a version 16 (and >) database would not be
able to start odoo service due to the `num2words` missing library.

This is in practice the fault of the IoT as this library is part
of odoo requirement. But to solve it it would need to recreate an
IoT box OS image and asking customers to re-flash their SD card
which is not convenient and time consumming.

After this commit:
Import conditionally num2words

opw-3902183

closes odoo#165067

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

Steps to reproduce:

Create a Service Product with the Invoicing Policy "Based on Milestones"
publish its eCommerce page.
When logged out, click on "Add to Cart" on the product's eCommerce page.
an error message occurs

Bug:
since this commit[1] "delivered_milestones" is only a valid selection
for users with the group "group_project_milestone"

Fix:
compute the field as sudo to avoid acces error but still only allow
the correct group to manually set that value

opw-3892462

[1]:odoo@50ffc33

closes odoo#164714

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

Before this commit:
The attachmentViewer toolbar buttons displayed incorrect colors for
portal users.

The mail module's public assets loaded all components and their SCSS
files. However, the attachment viewer had a separate SCSS file for dark
mode button colors, which was unnecessary for portal users. Removing
it would help fix the bug.

After this commit:
AttachmentViewer toolbar button colors now display correctly for portal users.

task-3872205

closes odoo#163927

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

Some modules may use attachments from mail messages directly.

In that case it may be desirable to at least be able to write
over the name and other non-critical information even if the
attachment is linked to a document.

The restrictions on writing on message attachments is reduced
to only apply to data fields, as those are the only ones that
we really don't want people to change.

Also return True instead of None in the override of `check`
to match the behavior of the parent.

Also reword the error message to convey writing is also forbidden.

Complementary to 4c4e63f

task-3519815

Part-of: odoo#164985

Administrators are technically allowed to delete attachments from any message.

However the UI does not reflect that since [1]

1: 4c4e63f

task-3519815

closes odoo#164985

Related: odoo/enterprise#62223
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Signed-off-by: Renaud Thiry (reth) <reth@odoo.com>

task-3806683

Co-authored-by: Thomas Becquevort (thbe) <thbe@odoo.com>

Commit that introduced the issue: [1]

Issue:
======
The email sent from chatter message isn't correctly formatted.

Steps to reproduce the issue:
=============================
- Go to chatter of any form view
- Open the mail compose modal
- Add a primary link the in the email body
- Send it
- The email isn't formatted in the received email.

Origin of the issue:
====================
The flow goes as follow, we first change the field and then when
clicking send, we first update the value of the editor by
`onWysiwygBlur` , then before the send is done, the field is saved which
will trigger the event `NEED_LOCAL_CHANGES` which will call
commitChanges, but since we already updated the value and we don't have
urgent, nothing will happend and the function `toInline` will never be
called.

Solution:
=========
To not break the old commit behavior and make it reset with disard, we
add another flag `shouldInline` so we can force `commitChanges` and
calculating inline style when saving.

[1]: odoo@3573167

opw-3885368

closes odoo#163323

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

Steps to reproduce:
- create a new spreadsheet
- right click any cell

=> boom `Cannot read properties of undefined (reading 'id')`

Bug introduced by odoo/enterprise@31401c7

opw-3900571

closes odoo#165183

X-original-commit: odoo/enterprise@78218c9
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>

The payment acquirer must always be linked to a single journal, one per company. It's currently an hard constraint we have on the journal.
So after the duplication, both are always linked to the same journal but only one appear on it.
This "fix" is improving that allowing the duplication of an existing acquirer and to be able to link them to different journals or on the same one.

opw-3704407

closes odoo#164208

X-original-commit: 88782d3
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Laurent Smet (las) <las@odoo.com>

In the express checkout flow delivery methods with failed rate
shipment stay still available as a choice for the users.
With this commit only carriers with successful rate will be shown.

opw-3861519

closes odoo#161524

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

defs was imported from lxml.html.clean.defs, where defs is actually
imported from lxml.html

After lxml 5.2, clean is moved into a separate package and def is not
importable from clean anymore.

Simple fix, adapt the import.

Part-of: odoo#165081

Part-of: odoo#165081

closes odoo#165081

Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

The aim of this commit is to fix the view returned
from the expense split wizard

Context:
When splitting an expense, the wizard view returns the expense list view
with "my expenses" a "to report" filters activated. This makes splitting
an expense attributed to someone else return an empty view.

After this commit:
The view now uses a domain that selects the expenses the wizard modified
and/or created

closes odoo#164499

Task-id: 3911134
Signed-off-by: William André (wan) <wan@odoo.com>

…iant

Currently, an error is generated when unarchiving multiple products which have
dynamic attributes & variants.

Step to produce:

- Install a 'Sales' module.
- Navigate to the Sales / Products / Products, And create a product.
- Add a 'Product Name' and save a record, and then add dynamic
Attributes & Variants.
- Repeat the process described in the above step to create another product with
the same configuration as the first one.
-Go to list view of 'Product'. select both products that we made recently
and click on the Action button to archive both products.
- Click on 'Filters' to see the archive product, And select those products
to Unarchive.

ValueError: Expected singleton: product.template(39, 37, 40, 42, 38, 46, 34)

The issue occurs when unarchive multiple products that contain dynamic
attributes & variants. As a result, the system receives multiple product
templates at [1].

link[1]: https://github.com/odoo/odoo/blob/e5635c38810a745f00b106d7a075ae1553de50c7/addons/product/models/product_template.py#L745

To resolve the issue, replace a 'self' with 'tmpl_id' to get a single product
template record instead of multiple.

sentry-5222160918

closes odoo#165108

X-original-commit: 4d1e2a4
Signed-off-by: Meet Gandhi (mega) <mega@odoo.com>

Commit that introduced the issue:
=================================
odoo@e806328

Issue:
=====
when an icon is converted to png it's cropped.

Steps to reproduce the issue:
=============================
- Go to this url: {host}/web_editor/font_to_img/61802/rgb(0,143,140)/rgb(255,255,255)/190x200
- The icon is cropped.

Origin of the issue:
=====================
In this case we are using `top` and `left` as they are the top left
corner of the icon inside the image , but in reality the returned value
is 0 , and the top left corner is represented by `box[0]` and `box[1]`.

Solution:
=========
Use of `box` values instead of `top` and `left`

opw-3865845

closes odoo#165193

X-original-commit: 07de2db
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>

Problem: The arabic_english_invoice report displays product name twice
since the description includes the product name by default.

Solution:The report should only display the description
if the description is not the same as the products' name.
Otherwise, the report should display the products' name in the
same language as the customer.

Steps to Reproduce on Runbot:
1. Install Sales,l10n_sa,l10n_gcc_invoice
2. Switch to SA Company
3. Create a product with sales description
4. Create an invoice with the product from step 3
5. Print the invoice report
6. Observe the product name is displayed twice
7. If Arabic is enabled as a language, the product name will
be displayed three times, with the 3rd being in Arabic.

opw-3768196

closes odoo#157774

Signed-off-by: Quentin De Paoli <qdp@odoo.com>

In production we are encountering an issue wherein the message number is
exceeding the maximum value (255). This results in an error when
converting the integer into its byte value representation.

The solution to this is to reset the message number upon each send.

closes odoo#165242

Task-id: none
Signed-off-by: Daniel Kosky (dako) <dako@odoo.com>

The class doesn't have the post_install tag, and so, is skipped.

runbot-25903

closes odoo#165240

Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>

This commit removes the dead and undeterministic test added by mistake
after an unsucessful merge. This test assumes that the organizer of the
event might always be on the position 0 of the attendees list but it is
not always the case.

Issue from: odoo#164408

closes odoo#165346

Signed-off-by: Arnaud Joset (arj) <arj@odoo.com>

According to MDN:
> Unlike the input event, the change event is not necessarily fired for
each alteration to an element's value.

closes odoo#165347

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

With the conversion of inline templates in [1], a typo was introduced
that changed "screen" to "string". Also the string was escaped and not
displayed correctly.

This commit fixes these issues.

[1]: odoo@5700cc6

closes odoo#164893

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

In this commit, if the user has created a leave request for today and it remains
unvalidated, they can delete it
However, past leave cannot be deleted

Task-3775186

closes odoo#156851

Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>

Steps to reproduce:
- Install Accounting, l10n_it_edi and Contacts
- Switch to an Italian company (e.g. IT Company)
- Go to Contacts
- Create an EU contact with "/" or "NA" as VAT
(e.g. a Germnan contact with a full address)
- Create an invoice:
  * Customer: [the created contact]
  * Product: [any]
- Confirm the invoice
- Process the electronic invoice
- Check the generated electronic invoice

Issue:
1) The country of customer is first computed from his VAT number and
a fallback is made on his country.
It should be the opposite.
2) In the XML, the "IdFiscaleIVA" section is set for customer with "/" (or "NA")
as "IdPaese", but it should not because customer doesn't have a VAT number.
If the XML is sent for validation, it is rejected because of that.

Solution:
1) Backport of odoo#164950
2) Add a condition on "IdFiscaleIVA" node as it is done from saas-16.4

opw-3889051

closes odoo#165365

X-original-commit: a34019c
Signed-off-by: Wala Gauthier (gawa) <gawa@odoo.com>
Signed-off-by: Anh Thao Pham (pta) <pta@odoo.com>