Before this commit:

If a next activity is "triggered", the discard button is not visible.

After this commit:

Even if a next activity is "triggered", the discard button will visible.

Task-2459645

closes odoo/odoo#66168

Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

The mail signature of an user did not inline the CSS like the body of a
message, so for example icons seemed to work but would not be seen
(unless the mail reader had the same font-awesome system).

With this change we inline the signature too.

On edition there was also an issue since the original icon was saved as
data-class which was stripped: so eg. when editing a mail.message with
working icon, the icons would disappear.

opw-2453912

closes odoo/odoo#66185

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

In some location, a long unbreakable word would cause following columns
to be hidden (depending on size of unbreakable word, font, font size,
...). For example, this happened in the cart summary on payment page.

With this changeset, if not possible otherwise, line break happen inside
the word.

opw-2451496

closes odoo/odoo#66176

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

before this commit: when there is only one page in the notebook tag and
there is a boolean field in form to show/hide that notebook page based on
invisibility attrs, if we toggle boolean field notebook hides, that's OK
but when we toggle boolean field again then notebook page is displayed but
it is not active and due to that content of notebook page is not displayed.

after this commit: when there is only one page in notebook and it has attrs
for invisibilty, when we toggle boolean field to hide/show notebook page
then notebook page as well as content is toggled.

task-2449053

closes odoo/odoo#65318

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

This commit is a backport from bfa73d38
This part of the tour can't work with the new online synchronization
module (account_online_synchronization) due to the fact that we are
using an iframe to display the list of institutions and therefore
those steps won't work within the iframe.

closes odoo/odoo#51988

Related: odoo/enterprise#10803
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>

before this commit: when there is a horizontal scroll in view say for example
kanban view where there are too many columns and user scrolls horizontally and
go to form view by clicking on any record and then come back to kanban view
horizontal scroll is not preserved and user is moved to scroll position 0
this is due to commit: https://github.com/odoo/odoo/commit/19eacf7d23c9413de4430a3422b5ed74b37ef242



after this commit: scrolling horizontally and then go to form view and come
back to previous view will preserve scroll position, we also consider case for
kanban view where there are too many columns and user click on 'Add Column'
user will be scrolled to new column element.

task-2418275

closes odoo/odoo#63933

Related: odoo/enterprise#15511
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

with this commit, we fixes UI glitch on image widget when image is too small,
when hovering over too small image Edit and Delete icon will ne displayed but
it is displayed with glitch, so to avoid that glitch we added min-width to
icons div.

task-2376452

closes odoo/odoo#64391

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

task-2458109

closes odoo/odoo#65970

Signed-off-by: Olivier Dony (odo) <odo@openerp.com>

scenario: open customer form by clicking new customer button and select
image and again click on image which will open file explore, now click
cancel button in file explorer which means we do not want to change
image, it will throw traceback.

traceback should not be thrown if image is not selected from file explorer
which will be fixed with this commit.

task-2412485

closes odoo/odoo#62994

Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

Before this commit, calling do_hide/do_show/do_toggle on a
widget that had been destroyed before being rendered crashed
(because this.$el was undefined).

Obviously, calling those methods in this situation is useless, but
with asynchronous code, it might happen that you call them in an
handler, and they have been destroyed meanwhile.

This commit checks if this.$el is set before accessing it to avoid
the crash.

closes odoo/odoo#65870

Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>

Steps:
- Install studio, website_form
- Go to Settings > Users & Companies > Users
- Click the Studio icon
- On the top bar, click Website
- Click New Form
- In edition mode, click the first label
- Select Customize > Add an Existing Field

Bug:
Traceback here:
https://github.com/odoo/odoo/blob/3ff00944fe6a439bd5d7bddb846206d3d6cac3a0/addons/website_form/models/models.py#L73
KeyError: 'readonly'

Explanation:
Dynamic selection fields don't declare a 'readonly' attribute:
https://github.com/odoo/odoo/blob/3ff00944fe6a439bd5d7bddb846206d3d6cac3a0/odoo/addons/base/models/res_users.py#L1275-L1282



opw:2449356

closes odoo/odoo#65784

Signed-off-by: backspac <backspac@users.noreply.github.com>

Steps to reproduce the bug:

- Install manufacturing app
- Create a product A
- Create a Bill of Materials for product A
- Archive Product A (Only the final product not any of the components)
- Print BOM or Print BOM Structure & Cost

Bug:

A traceback was raised

opw:2447514

closes odoo/odoo#65815

Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

- Install Accounting, Purchases and Inventory;
- Configure cash basis accounting;
- Configure purchases taxes as 'Based on Payment' with 16% of amount;
- Create a new product and configure it as a Storable Product.
- Configure the product category with costing method of the to FIFO and
    the Inventory Valuation to Automated;
- Create a Purchase Order for a stock product with quantity 1,262.84 and
    price unit of 10.37;
- Confirm the Purchase Order;
- Receive product for 1,262.835 (0.005 less than ordered);
- Create the vendor bill from the purchase order for the original
    quantity (1,262.84) and price unit of 10.37;
- Validate the vendor bill and pay it.

Before this commit, the cash basis journal entry was created with an
incorrect amount of 0.05 of Base Tax Received Account.

Now, the cash basis journal entry is created with the amount paid of
13095.65 of Base Tax Received Account

fine-tuning of e25f857e

opw-2411516

closes odoo/odoo#63738

Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: Andrea Grazioso <agr@odoo.com>

Before this commit, only whitelisted fields would be updated on cow views
during a module update.
A field would be whitelisted if he had the same value than the original view,
see it as a heuristic to not write on modified fields.

But `inherit_id` is not that simple, even if the cow view has a different value
than its original view, it doesn't mean it was modified by the user, it is just
because of the cow mechanism that assigned a copied view as inherit_id, which
is just a copy ofthe original one.

We can thus consider `inherit_id` as unchanged and whitelist it if the `key` is
the same.

In practice, it means that cow'd views did not receive the `inherit_id` updates
as in commit https://github.com/odoo/odoo/commit/c8577568a1e39f6692889b3e21652fa3b8df06b2#diff-823e5db841dca1798ff1300e243059a4e1c93343598d2be5a1d1dcd1d2d0c273R537
where `portal.my_account_link` had its `inherit_id` changed from
`portal.frontend_layout` to `portal.user_dropdow`, see https://github.com/odoo/upgrade/pull/2059

:

Considering a module update changing `inherit_id` of D from A to B, the
following use cases are expected. Without this fix, D' never move:

CASE 1
  A    A'   B                      A    A'   B
  |    |                 =>                 / \
  D    D'                                  D   D'

CASE 2
  A    A'   B    B'               A    A'   B   B'
  |    |                 =>                 |   |
  D    D'                                   D   D'

CASE 3
    A    B                        A    B
   / \                   =>           / \
  D   D'                             D   D'

CASE 4
    A    B    B'                  A    B   B'
   / \                   =>            |   |
  D   D'                               D   D'

closes odoo/odoo#64446

Signed-off-by: Christophe Simonis <chs@odoo.com>

closes odoo/odoo#65781

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

Loop inner calls should use mailing not self.

Task ID-2455433

closes odoo/odoo#65724

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

- Install account_accountant, stock_account, purchase & sale_management
- Create a Product (i.e. Product X)
- Edit Product Category:
  * Costing Method: Average Cost (AVCO)
  * Inventory Valuation: Automated
- Create a PO with Product X for 5 quantities at $5
- Receive the Products
- In Inventory > Report > Inventory Valuation, for Product X, we have (qty: 5, value: $25)
- Create a SO with Product X for 10 quantities
- Deliver Products
- Valuation for Product X = (qty: -5, value: $-25) => Correct
- In Inventory > Operations > Inventory Adjustments, create an adjustment for Product X to 0
- In Product X form, update cost to 0 (You may need to remove Vendors from Purchase tab to be able to do it)
- There is no more valuation for Product X => Correct
- Edit Product Category by setting "Costing Method" to "First In First Out (FIFO)"
- /!\ Do not recompute Inventory Valuation via Inventory > Report > Inventory Valuation
- Create a PO with Product X for 10 quantities at $7
- Valuation for Product X = (qty: 10, value: $70) => Correct
- Create a SO with Product X for 7 quantities
- Deliver Products
At this point, Inventory Valuation for Product X is incorrect. The Quantity is 3, which is correct,
but the value is $31, instead of $21 (3 * $7).

With FIFO Costing Method, the valuation of the last SO should be (7 units at $7) = $49.
But here, we have (5 units at $5 + 2 units at $7) = $39.
When the Inventory Adjustment has been made to set Product X to 0, a move of (qty:5, value: $25)
has been made to balance the previous Valuation of (qty: -5, value: $-25).
Values from this move are used during the last SO, but it shouldn't.

It happens because the "remaining_qty" field of the move created for the adjustment
has a value of 5 (the original move qty), instead of 0 (the real remaining qty).
Therefore the quantities from this move are used when running "_run_fifo" method,
although they should have been used to cancel the negative "remaining_qty" (-5) from
the move generated by the first SO.

To prevent this, moves with negative "remaining_qty" should be fixed when an in move is validated.

PS: The issue is also reproducible with FIFO Costing Method from the start,
as long as no Inventory Valuation recomputation is performed once the
inventory adjustment has been made.

opw-2425909

closes odoo/odoo#65250

Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>

This commit makes it so when the bom structure report (Structure & Cost
smartbutton) is opened the product quantity defaults to the BoM's
`product_qty` amount rather than 1.

Steps to reproduce:
- Create/open a BoM
- Set `product_qty` to any value greater than 1
- Click on "Structure & Cost" button.

Expected result: product quantities scaled to the `product_qty`
Actual result: product quantities scaled to Quantity = 1

closes odoo/odoo#64839

Task: 2429885
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

Up to v11 it was possible to search by purchase vendor reference when
we're using the auto-complete function in a vendor bill. With the
refactor of this functionality, this useful feature was lost.

closes odoo/odoo#65265

Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

The function `_get_possible_combinations` generates possibles combinations
 for the product template attribute values (ptav) of each product template
 attribute line (ptal) of a given product template. It used to iterate over
 them using a cartesian product. A combination can be invalid if it
 contains two incompatibles ptav. The problem is that it used to filter out
 invalid combinations after generating them. It's a problem because there
 can be a lot of invalid combinations to filter out before finding a valid
 combination. Even before the first valid combination if the first ptav of
 the two first ptal are incompatible.

The solution brought by this commit is to reject the invalid combinations
 while building them rather than after. It does so by using a cartesian
 product implementation with early rejection. The algorithm tests each
 ptav when incorporating it in a partial combination and if it's
 incompatible, it goes to the next partial combination and thus skips all
 combinations starting with the invalid partial combination.

The client that reported the issue has a product template with about 25
 ptal with an average of 9 ptav. The ptav of the first ptal was
 incompatible with the first ptav of second ptal. It had to build and
 filter out 5.76*10^15 ptav before finding the first valid ptav. If we
 generate 10^6 ptav by second (it's much less) user would get first ptav
 after 182 years. Now it's instantaneous.

opw-2335936

closes odoo/odoo#65089

Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

Because of context:

{'search_default_account_id': [active_id]}

refreshing on the tax audit action could cause an error because in normal
use case we have active_id that is never an account.account id (but for
example an account.tax.report.line).

There doesn't seem to be any use case where that context is useful since
it was introduced in 2017 (81089042), this action is always used with an
overriden context. So this commit is removing it.

opw-2388448

closes odoo/odoo#65698

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

such fields have store=True, but they don't exist in table.

---

https://github.com/odoo/odoo/pull/65232#issuecomment-773298323
https://github.com/odoo/odoo/commit/02417290191c22c9c99e6dc96a572c21f38e64f1



closes odoo/odoo#65535

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

The Lesotho Loti has the symbol M and not L
Example of use:
http://lestimes.com/businessman-xie-in-m27-million-scandal/
http://lra.org.ls/sites/default/files/2020-10/LRA%20Integrated%20Annual%20Report%202019.pdf



Fixes odoo/odoo#62807

closes odoo/odoo#65633

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

Previously, the many2one widget from the web_editor used jQuery's
'.html()' method when inserting a record name into the page. The record
name was not HTML-escaped before this, which may have unexpect result
and break the layout.

This commit fixes that by using the '.text()' method instead.

This bug only affects pages containing a many2one (contact excluded)
at the time of selection and not after the selection.
e.g. on the /event page, changing the category of an existing event
via the website editor

closes odoo/odoo#65610

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

closes odoo/odoo#65590

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

- Install stock
- Go to Inventory > Configuration > Settings and enable "Lots" and "Storage Locations"
- Create a Product tracked By Lots (i.e. Product X)
- Go to Inventory > Operations > Inventory Adjustments
- Create an Inventory Adjustment for Product X:

     Product   |   Location   |   Lot/SN   |   Real Quantity
 -------------------------------------------------------------
    Product X  |   WH/Stock   |   LOT 01   |       20
    Product X  |   WH/Stock   |            |       10

- Validate Inventory
- Go to Inventory > Operations > Transfers and create one:
  * Source Location: WH/Stock
  * Destination Location: WH/Stock/Shelf1
  * Operation Type: Internal Transfers
  * Operations:
    [Product: Product X, Initial Demand: 25]
- Save Transfer, Mark As Todo and Check availability
- Click on list icon of Operation line for Product X to display Detailed Operations
- 20 units of LOT 01 and 5 units without lot have been reserved
- Set LOT 01 for the 5 reserved units without lot and confirm
- Open Detailed Operations again
- There are now 20 units of LOT 01 and 5 units of LOT 01
- Remove the row with 5 units and confirm
- Check availability and open Detailed Operation
- There is now only a row with 25 reserved units of LOT 01
- Unreserve
The following errror is raised:
"It is not possible to unreserve more products of P than you have in stock."

It happens because the system is not able to manage quants with lots and
wihtout lots at the same time. When modifying the move line to 25
reserved units. It's composed of 20 quants with lot and 5 quants without
lot. And when unreserving it will check if there is a quants with 25
units with the lot and if it's not found 25 units without lot. But never
25 units of quants with lots and without lots.

opw-2419444

Close #64497

closes odoo/odoo#65057

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

Follow-up of https://github.com/odoo/odoo/pull/65357



closes odoo/odoo#65470

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

Steps:
- Install mrp, stock
- Go to Inventory > Configuration > Operation Types
- Edit Delivery Orders:
  - Show Detailed Operations: Checked
- Go to Master Data > Products
- Create two products (1) (2)
- Click (1)
- Click the "Bill of Material" smart button
- Create a BoM:
  - BoM Type: Kit
  - Component: (2)
- Go to Overview
- Click Delivery Orders
- Create a Delivery Order:
  - Add (1) with an initial demand of 1
- Mark as ToDo
- Click Edit:
  - Detailed Operations tab:
    - Add (1) with a done quantity of 1
- Validate and create a Backorder

Bug:
Record does not exist or has been deleted.
(Record: stock.move(60,), User: 2)

Explanation:
When confirming a `stock.picking` with `mrp` installed, the action goes
through `action_explode()`.
https://github.com/odoo/odoo/blob/d9ea1d5f054f05197581acf67c8a9c1e6acb8d02/addons/mrp/models/stock_move.py#L154
This action splits the components of the product with a Kit (`phantom`)
BoM instead of manufacturing it. When everything is split, the
`stock.move` unlinks itself because it has been replaced with its
components. `action_explode()` then returns the new components. Trying
to call a method on the unlinked move will result in an error.

This commit replaces the move with the newly generated component moves.

This is safe to do in `stock` because the non-overridden
`_action_confirm()` returns the move it was called on as seen here:
https://github.com/odoo/odoo/blob/d9ea1d5f054f05197581acf67c8a9c1e6acb8d02/addons/stock/models/stock_move.py#L790



opw:2450016

closes odoo/odoo#65462

Signed-off-by: backspac <backspac@users.noreply.github.com>

Steps:
- Edit the current company (1):
  - Country: Switzerland
  - Currency: CHF
- Install l10n_ch
- Go to Invoicing > Configuration > Bank Accounts
- Edit Bank:
  - Bank Account: create a new one:
    - Account Holder: (1)
- Go to Configuration > Journal
- Edit Customer Invoices:
  - Advanced Settings tab:
    - Communication Standards: Switzerland
- Go to Customers > Customers
- Create a new customer (2):
  - Fill in street, city, zip code and country
- Edit (2):
  - Contacts & Addresses tab:
    - Add:
      - Select Invoice Address
      - Contact Name: Keep this field blank
- Go to Customers > Invoices
- Create a new one:
  - Customer: "(2), Invoice Address"
  - Add a product
- Validate it
- Click Print QR-Bill

Bug:
Traceback here:
https://github.com/odoo/odoo/blob/b76e9ef658bde0178fa1660b6ad27b880e91632a/addons/l10n_ch/models/res_bank.py#L129


TypeError: 'bool' object is not subscriptable

Explanation:
The contact name of an address is optional. When nothing is filled in
that field, it returns `False`, hence the error.
Using the commercial company name ensures a name is put in the invoice,
even if the contact doesn't belong to a company.

opw:2447158

closes odoo/odoo#65357

Signed-off-by: backspac <backspac@users.noreply.github.com>

Filling the new column in SQL is dramatically faster than doing it via
the ORM, which iterates over all the records in the table.

The test case is creating a related field for 100+ records with distinct
values.  Setting the field's value was taking more than 100 queries.  It
now takes 3 queries.

task-2449313
opw-2380445
opw-2389376
https://github.com/odoo/enterprise/pull/15910



closes odoo/odoo#65232

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

In a multicompany environment, when a expense is created from the
expense email alias, the expense account is computed with SUPERUSER
context, so depending on the SUPERUSER set company, we could get
a mismatch of expense and employee's company and the account one, wich
causes a subsequent error when trying to post the expense.

closes odoo/odoo#63188

Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

When using the windows installer in French language, the `Hôte` label
used to configure postgresql server does not display correctly.

The LangString documentation does not specify how to use the special
characters but after some tests, specifying a BOM for the nsi file seems
to be the way to go.

closes odoo/odoo#65354

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

Steps:
- Go to Accounting > Configuration > Accounting > Bank Accounts
- Create a new Bank Account
  - "Bank Account" field: create and edit a new one
    - Account Holder: Anyone but your company
- Save

Bug:
Validation Error: The holder of a journal's bank account must be the
company (YourCompany).

Explanation:
The error is not clear enough. Users may be confused because this
validation error appears upon saving a "Bank Account Journal"
(`account.journal`) but is talking about "Partner Bank Account"
(`res.partner.bank`) which is a field of the "Bank Account Journal".

opw:2448183

closes odoo/odoo#65281

Signed-off-by: backspac <backspac@users.noreply.github.com>

closes odoo/odoo#65228

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

We should open the cashdrawer when paying with a non cash payment
method if change should be returned to the customer.

Use case: The customer wants to pay 10€ more with his card to get 10€
in cash in return.

closes odoo/odoo#65246

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

Before this commit, the o_we_selected_image class was not removed from
forum post when saving.

task-2312878

closes odoo/odoo#63071

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

Before this commit, the preview of the dragged snippet didn't work
when moving a dragged snippet from a drop zone to an other drop zone
when there was no space between those drop zones.

It is because, in this case, the over event of the second drop zone is
triggered before the out event of the first drop zone.

task-2312878

closes odoo/odoo#61871

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