closes odoo/odoo#54227

Related: odoo/enterprise#11742
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>

On res.partner.bank, we check that:
- l10n_ch_postal contains a valid postal number
- l10n_ch_isr_subscription_chf contains a valid ISR subscription number
- l10n_ch_isr_subscription_eur contains a valid ISR subscription number

ISR subscriptions numbers are postal numbers but starting with 01 or 03.
Those codes are reserved to ISR issuance.

When the bank account on a Vendor Bill is detected as
an ISR Issuer, check the reference is actually an ISR.

The 27 digits ISR Reference is error prone when typed by hand
and an error at this stage would break the payment process later.

This is required to avoid batch payment error with SEPA.

We prefer using the pretty form xx-yyyyy-z of a postal account.
The Swiss users will identify it more easily.

We always want to auto fill the field l10n_ch_postal when possible from
acc_number, which includes only 2 cases of filling acc_number:

1. a 9 position postal account number
2. an IBAN from PostFinance which includes clearing 09000

Original prs: Closes #51645, #51544, #51560

closes odoo/odoo#54455

X-original-commit: f8a3ec438e3b5fa56305db729a78304aec7a6716
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Josse Colpaert <jco@openerp.com>

1. Create a new location of type internal in WH/Test
2. Create a new product P with availability of 100.0 in WH/Stock
3. Create a new transfer from WH/Stock to WH/Test with 50.0 units of P,
   Put in Pack and Validate
4. Create a new transfer from WH/Test to WH/Stock/Shelf 1 using the
   previous package, Validate and Unpack
5. Repeat steps from 3 and 4
6. Create a new transfer from WH/Stock/Shelf 1 to Customer with 100.0 units of P
7. Review stock quant from the location WH/Stock/Shelf 1

2 quants of the same product in the location WH/Stock/Shelf 1: one
negative with -50.0 and another positive with 50.0

The step 4 creates 2 quants of 50.0 units, which are reserved at step 6.
However, when validating the transfer 100.0 units are taken from one of
the quants.

To prevent this situation, we run the quant vacuum process after
unpacking. This will merge the 2 quants of 50.0 and prevent any future
negative quant creation. We also clean zero quants, although this is not
mandatory to fix our use case.

Closes #53535
opw-2283707

closes odoo/odoo#54431

X-original-commit: f7168311
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Issue

	- Install "Studio" and "Contact" apps
	- Edit with Studio the Contact Kanban View
	- Add field under city/country

	Field appears only if no city is set.

Cause

	The new field has as anchor the 5th <li> with the field country
	who will appear only if not city is set. However, in case there a city
	AND a country, the 6th <li> will appear instead of 5th (the target one).

Solution

	Let only one <li>, one country and one city field but with the right conditions.

opw-2288545

closes odoo/odoo#54423

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Before this commit, the default active favorite filter was determined by
its ID given by the control panel. These IDs start at index 0, meaning
that if a condition checks for the value of such an ID, it could be
false even though the ID and its filter exists.

Now the indexation starts at 1 to avoid such problems.

closes odoo/odoo#54435

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

The payment.transaction type field allows filtering some potential
payment methods down the line of a transaction being created; e.g. if a
subscription product is present in a quote, the payment's type should be
`form_save` to save the payment token for future use on the subscription
that will be created at confirmation.

The transaction that got created by sale flows did not set the type of
the transaction correctly, and this value was not propagated to the
rendering values of the acquirer. It now is.

This is necessary as part of task 2275051, where we need to know which
payment methods to enable in Stripe depending on a need for tokenization
or not (since some methods are not tokenizable).

closes odoo/odoo#54426

X-original-commit: 09dbbd77
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>

- bancontact (be; eur)
- eps (at; eur)
- giropay (de; eur)
- p24 (pl; eur, pln)

X-original-commit: 1b7da6d0

taskId 2285655

closes odoo/odoo#54299

Related: odoo/enterprise#11726
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

closes odoo/odoo#52337

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

This commit handles 2 things:

1) the merging of the `py_utils.context()` into the evaluation context
returned by `BasicModel._getEvalContext` to access the same time-related
keys,

2) the addition of 2 new keys into the `py_utils.context` (thus
transmitted to the basic model): `today` (an alias for the already
present `current_date`) and `now` which represents the current date and
time value.

Task 2269697

Commit [1] introduced the bug by relying on the fact an element with
id=top is in the edited DOM. As the website header can be disabled, this
induced a crash as soon as the header was indeed disabled. Also, the
editor is not meant to edit the website only so we cannot rely at all
on the presence of a #top element.

[1]: https://github.com/odoo/odoo/commit/6df67a28c2f113572acd4a3db19ab6b1bd37e7da



closes odoo/odoo#54409

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

Before this commit, defining a extension of a template by using the
combination of directives 't-name' and 't-extend' ignored potential
extensions that could have been defined beforehand.

For instance, let's assume the following templates.
```xml
<t t-name="a">
    <div><span>1</span></div>
</t>
<t t-extend="a">
    <t t-jquery="span" t-operation="replace">
        <span>2</span>
    </t>
</t>
<t t-name="b" t-extend="a">
    <t t-jquery="div" t-operation="append">
        <span>b</span>
    </t>
</t>
```
Rendering template "b" displayed "1b" whereas we would expect "2b".

Moreover, when the extended template is itself an extension of
another template:
```xml
<t t-name="a">
    <div><span>a</span></div>
</t>
<t t-name="b" t-extend="a">
    <t t-jquery="div" t-operation="append">
        <span>b</span>
    </t>
</t>
<t t-name="c" t-extend="b">
    <t t-jquery="div" t-operation="append">
        <span>c</span>
    </t>
</t>
```
Rendering template "a" displayed "a", template "b" displayed "ab",
but template "c" displayed "ac", whereas we would expect "abc".

With this commit, other extensions done to a template are kept when
a new extension is defined. It relies on the templates order, and
takes into account all extensions that have *already* been defined.
This is exactly how the new qweb inheritance mechanism (using
't-inherit' and 't-inherit-mode') behaves.

closes odoo/odoo#54315

Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

Issue

	- Install "Accounting" and "Account Analytic Defaults".
	- Create an Analytic Tag and use the distribution (eg.: 60/40)
	- Create an Analytic Defaults for a specific partner.
	  with the Analytc tag just created.
	- Create a bill, select the the same partner as the Analytic Defaults and
	  add a new Invoice Line with a price (eg.: 1000).

	The tag is applied to the payable account, which is
	wrong and it leads to an analytic inconsistency.

Solution

	Apply analytic tags only on move lines not excluded from invoice tab.

opw-2269757

closes odoo/odoo#54410

X-original-commit: 6e0bb7a24cad46891c80ddc384311dd81eca1e82
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>

closes odoo/odoo#54406

X-original-commit: 4279335fa5378efaea71cec634361e94d670fd82
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>

Create four promotion programs:

if the order > 1500 than 10% discount
if the order > 1750 than 15% discount
if the order > 2000 than 20% discount
if the order > 2500 than 25% discount

Take a product with a price of $300 and add 5 to cart > the 10% discount
is correctly applied.
Add 1 more product (6) > it should now qualify for 15% discount, but it
stays at 10%
Add 1 more product (7) > it (correctly) gets the 20% discount
The 25% discount does not get applied until 11 of the product is in the
cart, even though it should qualify at 9
If you then decrease the quantity, the right discount will
sometimes display.

This occur because when the order amount change and the new total is
used to match the right promo the previously applied discount is not
removed from the amount.
This occur as side effect of
1d59785 in which the amount has to be
kept in order to avoid discount line removal on cart update.

opw-2285656

closes odoo/odoo#54400

X-original-commit: 28c099e6d5b02518b6b5a0be66b2b74a57f0c936
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

description for tax templates in account_tax_data.xml is not showing a "friendly" customer description for several taxes.
It's common to be requested for changes and being forced to help customers to replace the current tax label by understandable descriptions.
This PR improves that description and makes it easier to understand.

closes odoo/odoo#54402

X-original-commit: f8d55c8e4559264c68155a4a8e3151f6aa045037
Signed-off-by: Josse Colpaert <jco@openerp.com>

Go to eshop with public user
Add items in cart
Checkout, reach shipping and billing address page
Fill the form
Add a coupon

Page will refresh and added content will be lost
This will prevent user from adding a coupon when a form needs to be
filled

opw-2287428

closes odoo/odoo#54396

X-original-commit: 4ed42845624e39c66222cda81f307236a6d5a483
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

*mail,point_of_sale,web_editor,website

In the tests, required services are deployed for each test
independently. There is no need to have, in additon, all services
deployed globally. Worse, it could conflict and lead to unexpected
results.

This commit ensures services are no longer deployed globally in
tests. It turns the module 'web.env' into a declarative module with
no side-effect, by moving the service deployment to main.js, which
isn't added to the tests page.

Task 2287397

closes odoo/odoo#53817

Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

Go to Payments view
Select multiple confirmed payments, click on Actions>Send receipt by
email

Only for the first payment will be sent an email.
This occur because in composition mode 'comment' (the default)
mail composer sens the mail to a single record
Adding a duplicate action to handle multi send
Updating translation accordingly

opw-2278971

closes odoo/odoo#54108

X-original-commit: 11fd7687047b2c17e9464e8415087d9a9fcf58a8
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

The workorder opening wizard view need a footer to be closed when
clicking on a button.

Task : 2278147

closes odoo/odoo#54364

Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>

Support for the "allow exports" group was implemented by checking the
group in init(), which is sync. Move that check over to willStart
instead.

Also add a default mock for user_has_group (makes it so it always
replies that the user doesn't have the group), and override that
specifically for the group we're interested in in the export tests, so
those tests have access to the Export action / option.

closes odoo/odoo#54254

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

Issue

    - Install Employees & Dashboard
    - Add employees to kanban
    - Dashboard
    - Hover an employee picture

    There is only the picture visible
    on the page, the remaining space is white.

Cause

    I found several issues.

    1. The pictures are not shown on hover in employees
        But they are on dashboard.

    2. $attach = all `.content` and on dashboard there is
        2 `.content` so the flyout is append 2 times

    3. The move method is trigerred on hover too, it hides
        the flyout if we are not in it. But with attachToTarget
        we are not in it so it's hidden all time.

    4. If everything above is solved, the image is shown but
        not at the correct position because the flyout base
        position is not top 0, left 0

Solution

    1. Reduce the minimum required size to 128px
    2. use closest instead of parents
    3. Don't hide if we have the option attachToTarget
    4. Calculate the flyout offset and replace it correctly
       and set it to position fixed to handle scrolling

OPW-2291493

closes odoo/odoo#54333

X-original-commit: 2c6d692ee40c97d2ae63da64db7623702948407e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>

- Create a product P, tracked by lot
- Add some stock with a lot
- Create an outgoing picking
- Set 10 units of P
- Set 2 done, Put in Pack
- Unreserve

An error occurs: 'It is not possible to unreserve more products of P
than you have in stock.'

It happens because the `lot_id` is removed from the copied
`stock.move.line`.

Commit eac8c06e makes sense for incoming pickings, but
not for internal or outgoing transfers.

opw-2288208

closes odoo/odoo#54355

X-original-commit: ed738fb56ffe84f3af08b84e429db916a5e560b6
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

opw-2294930

The tax amount not included in price should be computed in the remaining
balance, even if not included in price.

closes odoo/odoo#54356

X-original-commit: 6a6aefdfac472421b9cf6de043682a6cdc131d85
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

The fact that led_status.sh was still running when performing the
`git reset --hard` made it impossible to remount the filesystem in RO
mode, due to a `mount point is busy` error.

Instead of starting the led_status_sh script from rc.local, we make it
a service so it can be easily restarted when an update is performed.

closes odoo/odoo#54353

X-original-commit: 2ad99d3b
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Signed-off-by: Antoine Prieëls <aprieels@users.noreply.github.com>

When we group by date with DST change within a range, we could get a
reocrd inside two date range grouping, or inside no grouping.

This is because we computed range just with [+ 1 month], so we possibly
had these ranges (in UTC):

- October 2019 : [('datetime', '>=', '2019-10-01 02:00:00')
                  ('datetime', '<', '2019-11-01 02:00:00')]

- November 2019 : [('datetime', '>=', '2019-11-01 01:00:00')
                   ('datetime', '<', '2019-12-01 01:00:00')]

So a record on 2019-11-01 01:30:00 would be both inside October and
November.

This happen because the DST is removed on happen on 27 October 2019 and
this was not taken into account when computing the end of the range.

With this changeset, for the given example aboth, we will have:

- October 2019 : [('datetime', '>=', '2019-10-01 02:00:00')
                  ('datetime', '<', '2019-11-01 01:00:00')]

Added test without the change fails with "AssertionError: Lists differ"
because:

- "Q1 2019" finished on 17:00:00 instead of 16:00:00
- "Q3 2019" finished on 16:00:00 instead of 17:00:00

opw-2278829
closes #54056

closes odoo/odoo#54345

Note: maxDiff added for test to work in 13.0
X-original-commit: af5d03de
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

The function check_with_xsd has been deprecated for more than 3 years.
Docstring is now compliant with PEP 257

closes odoo/odoo#54338

X-original-commit: 29938397
Signed-off-by: Josse Colpaert <jco@openerp.com>

Search the xsd files from in the database.
To enable this option, the Environment should be passed to the optional
`env` parameter. Both the XSD root and the XSD imported by the root and
the recusrively imported files will be searched in the database.

X-original-commit: 06a35f2e

The label of some buttons is updated on-the-fly, and the code which
does that was actually altering the structure of the button widgets
instead of just the labels' text. This code should be made more robust
in master.

closes odoo/odoo#54324

X-original-commit: 5eb25c482eeaf68e30fd9f5b2fbe889f9b53c954
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

In Sales, in Payment Link generation wizard, when entering manually the total of the quotation
as Amount, it can happen that the Validation Error asking to set an Amount smaller than the total
is triggered.

opw-2287794

closes odoo/odoo#54309

X-original-commit: a7034b75
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

The custom 'to consume' widget wrap the classic float widget into a
<span> tag to add a non editable part to display. The issue this commit
fix is the following: the float widget element is this.$el in
_renderEdit. Appending it to a new element make it loose its link to the
DOM. The custom widget is totally blank.
This commit clone this.$el before surrounding it by the new span

Task : 2278147

closes odoo/odoo#54042

X-original-commit: 01bb1fce77cce3d54cd969e643b7c720673f2b22
Related: odoo/upgrade#1451
Related: odoo/enterprise#11645
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

This commit bring together sanity check functions called during
production order validation in a separated method. Other modules will
override it to add other sanity checks.

Task : 2278147

X-original-commit: e11f8da6674e9a21ab61d0aa67ef1797752273e2

If the consumption wizard is triggered in a workorder (via 'Mark As Done
And Close MO'). We would like the confirm button redirect to the
workorder list view afterwards.

Task : 2278147

X-original-commit: 55e2a4d16d3a56b8f509d2d67a344c53d62474b6

The Table (MTO) production hasn't its finished moves created in the demo
data. This lead to the impossiblity to mark as done the production
order.

Task : 2278147

X-original-commit: d6e20db6f6b372707a67ec63d71a1c2737511765

Duplicate a BoM with operations and some BoM line consume in specific
operation. The operations are well duplicated but the 'consume in
operation' field still point to the original BoM's operations.

This commit search for the operation to replace based on the name and
the workcenter_id.

Task : 2278147

X-original-commit: 4c6d445dfd561a236b1b171ccbcc2ff2b6236640

Consuming all the components for only a part of the finished product
will ask the manufacturing user to create a backorder. Confirm it will
fail as there are no component left to consume to produce the
remaining quantity of finished product. This commit only confirm
backorders that still have some quantities to consume.

Task : 2278147

X-original-commit: 51c9281d715e27143955c7b9b51f60b22e672f52

This commit makes some changes in the production order views
as well as in the workorders one. This commits make sure there
is now only one form view left for the mrp.workorder model.

This commit take part of the MRP refactoring
(69c48add)

Task : 2278147

X-original-commit: 8b389ab3601cf5ed9328b7ce55ee91d54aa70150

Issue

	- Accounting > General ledger
	- Have 2-3 lines in the table
	  I added filters to have them
	- Toggle optional columns: (...) on the right

	There is an y scroll but you can't scroll
	more than half of the scrollbar.

Cause

	The cause is that the dropdown height is greater
	than the table height.

Solution

	Use data-display: static this way the element doesn't
	scroll with parent scroll and scrolling is working
	as expected on the dropdown

OPW-2291531

closes odoo/odoo#54320

X-original-commit: 9afd7b7e
Signed-off-by: Jason Van Malder (jvm) <jvm@odoo.com>

Commit [1] merged a debug console.log. This commit removes it.

[1]: https://github.com/odoo/odoo/commit/6df67a28c2f113572acd4a3db19ab6b1bd37e7da

Part of https://github.com/odoo/odoo/pull/54311



closes odoo/odoo#54311

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

Commit [1] introduced at least 2 linter errors, which this commit is
fixing.

[1]: https://github.com/odoo/odoo/commit/6df67a28c2f113572acd4a3db19ab6b1bd37e7da

Part of https://github.com/odoo/odoo/pull/54311