A "thematic break"[1] is composed of 3 or more characters (-, _,
or *). The current separator using only 2 characters between the main
body of the PR and the footer / addendum makes it more difficult to
interpret the message.

Update to 3 so e.g. the mergebot can strip the footer.

[1]: https://spec.commonmark.org/0.30/#thematic-breaks



closes odoo/odoo#101072

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

Reproduction:
1. Install eCommerce and accounting
2. Go to Accounting->Configuration->Taxes, add one sale tax 15%, and one
0%. Both taxes are included in the price.
3. Go to Configuration-> Fiscal Position, create a new one “test” which
applies the tax mapping from 15% sale tax to the 0%. Check “Detect
Automatically”, set country group as Europe
4. Go to Website->Orders->Customers, set the country of the portal user,
Joel Willis, as Luxembourg. In Sales&Purchase->Fiscal Information set
the fiscal position as “test”
5. Go to Website->Products->Product Variants, create a new one
“test_tax_prod” with price 110, and sale tax 15%, can be sold, can be
purchased and consumable.
6. Go to Website->Configuration->Attribute, create a new product
attribute “test” with Display Type as Ratio, Variant Creation Mode as
Never. Create a value “a” in its attribute values
7. Go to Website->Products->Products, find test_tax_prod, go to its
variant tab, set attribute as “test” with value “a”, publish this
product
8. Open an incognito tab, login as “portal” pwd: portal, search the
product “test_tax_prod”, set the price list as “public price list”, the
price is 95.65 on the page. Add it to the cart, the price is 110

Reason: When we update the order_line, we should update the price based
on the fiscal position for the no_variant products too. However, based
on the current workflow, the price is computed in method
_website_product_id_change before an order line is created. Thus for
no_variant products, the price is not updated.

Fix:  This issue is fixed in saas-15.3 by rewriting the workflow and
calculating the price through an on_change function here: https://github.com/odoo/odoo/blob/saas-15.3/addons/sale/models/sale_order_line.py#L588-L605

In v13, we don’t have this on_change method to compute the new price, so
a similar price update can be created in the cart update for
website_sale. This fix solution was created here: https://github.com/odoo/odoo/commit/ea259218196b2d9dc71beffea697025580c6d696
However, new price computation issues can happen when combining two
pricelists, here: https://github.com/odoo/odoo/commit/8d6a2ca0f3dcf8f8cf4679da2b3ce582b7826391

Thus the fix is eventually done in _website_product_id_change. Added a
new parameter to force checking the orderlines based on the domain. The
orderline is created but only can be searched based on the domain. This
ensures the price is computed correctly for pricelists and for tax.

Added fiscal position test for no variant product

opw-2856956

Fix by re-writing in saas-15.3: https://github.com/odoo/odoo/blob/saas-15.3/addons/sale/models/sale_order_line.py#L588-L605
First related fix: https://github.com/odoo/odoo/commit/ea259218196b2d9dc71beffea697025580c6d696
Second fix to patch for the first fix: https://github.com/odoo/odoo/commit/8d6a2ca0f3dcf8f8cf4679da2b3ce582b7826391



closes odoo/odoo#99647

Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

Issue :
- `account.move.state` has only 3 possible values cancel, draft, posted
- the wrong value was used

Fix:
- Use the correct value `posted`

OPW-2991389

closes odoo/odoo#100691

Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

Have a tax with tax tags
Create a bank statement line
Reconcile creating a manual operation, add the tax, then remove it and
validate
Check journal entry

The tax tags will be present on the base line even if the tax was
removed

opw-2867395

closes odoo/odoo#94445

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

blocked to their stock inventory records

closes odoo/odoo#100631

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

Only compute the lot values info on stockable or consu (kits) products
on the invoice lines

closes odoo/odoo#100322

Signed-off-by: Adrien Widart <awt@odoo.com>

Currently, When we create an invoice from a sale order containing some notes or sections. The analytic account from the sale order is set on the invoice/move line. During the creation of analytic lines, a line is created from the section/note line.

This commit makes no analytic line is created for section/notes.

Video : 

https://youtu.be/AqyrXEIcKvg



--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

closes odoo/odoo#95786

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

- Due to hefty data the RAM limit gets exhausted.
- The process gets killed due to computed field margin on sale.order.line

To solve the problem:
- We add column margin to DB schema.

Task id: #2950878

closes odoo/odoo#100453

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

When drag and dropping a work order in the Work Orders Planning, the
end time wasn't recomputed. This can make the end time inconsistent with
the duration when the work order spans across a non-working time.

Steps to reproduce:
1. Install Manufacturing
2. Go to Settings > Manufacturing > Operations and enable Work Orders
3. Go to Manufacturing > Master Data > Routings and edit routing
   'Primary Assembly' to last 120:00 minutes
4. Go to Manufacturing > Operations > Manufacturing Orders and create
   one with values:
   - Product: Table Top
   - Plan From: today's date at 11:00:00
5. Save, mark as todo and plan the manufacturing order
6. Go to Manufacturing > Planning > Planning by Workcenter and trigger
   the day view
7. Move the work order to 8 am
8. The work order still lasts for 3 hours (according to its start and
   finish time) even though its expected duration is 2 hours

Solution:
Recompute `date_planned_finished` when we move a work order in the
planning (`date_planned_start` and `date_planned_finished` are passed in
values), and recompute `expected_duration` when we extend it (only one
of them is passed depending on the way we extend the work order).
(`duration_expected` is never passed in values when we manipulate a work
order through the planning)

Problem:
`date_planned_finished` wasn't recomputed when moving the work order in
the planning

opw-2893622

closes odoo/odoo#97805

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

To reproduce:
Video: https://drive.google.com/file/d/1bAh7KA_5UhhIrr-qF5A5gOVWhk3_9clj/view


 1. Have multi-language website
 2. Event with one ticket
 3. Reload page and click the "Register" button
 -> in some cases there is a traceback
 `/event/great-reno-ballon-race-2/registration/new: Function declared as capable of handling request of type 'json' but called with a request of type 'http'`

 Reason of the issue:
 As the button "Register" in the form is defined with `type="submit"` it will send the form as plain HTTP if clicked.
 This behavior is modified in the JavaScript to prevent this default behavior.
 However, if the button is clicked before the JS load, the HTTP behavior is used which does create the above traceback (as the `registration/new` route accept only `json` type).

 Solution proposed:
 Prevent the button default behavior and make it deactivated and let the JS activate it when it is ready

 Note on stability:
 As JS code and XML view is modified, this fix was thought so that the JS won't have an impact if the view isn't updated.
 There is theoretically no way that the XML view would be updated without the JS being updated (except manual modification in the view or rollback on the version revision after performing a module update on odoo.sh). If it was the case then the button will be deactivated until the user change the number of ticket.

 OPW-2946706

closes odoo/odoo#98091

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

What is done in start should be undone in the destroy.

closes odoo/odoo#100387

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

Steps to reproduce:
- create and send a quotation
- make a failed payment (through cutomer preview)
- create and send a second quotation to the same customer
- make a succesful payment this time
- redirect takes to the wrong quotation (failed one)

Bug:
polling the processed payments initially returns both transaction
but the following polls only returns the rejected payment
(introduced in [1] processed transactions are filtered out)
since there's only a single transaction, redirect takes to it

Fix:
if there's only a single succesful transaction (regardless of the rest)
it means the current payment was successfull so we redirect to it

opw-2954162

[1]:https://github.com/odoo/odoo/pull/31741/commits/7612659565ee24f1c878b81e6c86b5780fbd5a3d



closes odoo/odoo#99969

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

In this commit, we add data of amortizations accounts and correct the
accumulated amortization accounts (now they are of the fixed asset
type) to be consistent with the Argentine chart of accounts.

For each accumulated amortization account we have an expense type
amortization account.

closes odoo/odoo#97534

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

Following the steps that changed every quantity in a matrix, the next
step was triggered after at least one sale order line's quantity was
changed. Due to the number of lines created, one of the so lines was
sometimes not updated before the next step, which produces an error in
the final sale_count.

In order to check the total and ensure every line was updated, we set
the partner sooner in the tour, which in turn sets the pricelist used to
get the price of each line. Thus allowing a check on the subtotal.

Backport of commit-af1e67aa2c6c676479ee4ea73106bcabd20c621e

closes odoo/odoo#100273

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

Steps to reproduce:
- Create a transfer and choose whatever operation
- Enable detailed operations option for the operation
- Check availability and set quantities
- Cancel the transfer then Go to Product Moves

Current behavior:
- todo filter is broken, it shows canceled moves

Desired behavior:
- Show only moves that are assigned or waiting

- Task id: #2981249

closes odoo/odoo#100265

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

On October 3rd 2022 the Google OOB authentication flow will stop working.

From that date on, this module will stop working since it uses the
access_token obtained in the `google_drive` module to create the requested
spreadsheet inside the user's own Google Drive account.

Instead we will display instructions to the users to allow them to
manually create the requested document.

task-2977578

closes odoo/odoo#99988

Signed-off-by: Kevin Baptiste <kba@odoo.com>

Cookies should be used internally by the web UI. The server-side is not supposed to be aware of it at all.

Reverts:
https://github.com/odoo/odoo/pull/88745

Based on https://github.com/odoo/odoo/pull/93812


discussion. It has been decided to revert the fix to avoid further unattended behaviours.

closes odoo/odoo#100075

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

The comment was introduced alongside its related line with [1].
The line was removed with [2] but its comment was not, leading to
confusion now.
Instead of removing it in master, might as well remove the confusion in
lower version..

[1]: https://github.com/odoo/odoo/commit/3542a27f9c4c44472184bbedc348ad646d46f20a
[2]: https://github.com/odoo/odoo/commit/0effbe3ca628460b9a0c257ea0bd6060c3eeb253



closes odoo/odoo#99963

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

Steps to reproduce:
- enable multi currency in settings
- set different rates for multiple days
- create a vendor bill in a different currency
- create a second vendor bill
- fill the second bill using auto complete from the first one

Bug:
the correct currency rate isn't applied unless date is changed when
the source is a vendor bill not a purchase order

Fix:
update currency rate after adding a line with a different currency

opw-2890210

closes odoo/odoo#99640

Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

Small fixup of recent commit [1].

A regular user do not have delete right on iap.account model, hence
creating an access right error. We should allow him to delete accounts
without token so they will be re-created afterwards.

[1]:https://github.com/odoo/odoo/commit/974caef934b7a116b7375f05e047aea15ea960aa



closes odoo/odoo#99817

Signed-off-by: Florian Daloze (fda) <fda@odoo.com>

Search result is not used since switching to implementation with `read_group`.
The line is already removed in v14, but because it may significantly slow down
computation of the `purchased_product_qty` field, we should remove it in v13 too

opw-2971825

closes odoo/odoo#99800

Signed-off-by: Adrien Widart <awt@odoo.com>

closes odoo/odoo#99391

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

Steps to reproduce:

  - Install purchase
  - Go to Settings and activate `Variant Grid Entry`
  - Create a new Requests for Quotation
  - Add a customer and add a product that has a variant min 2 variant
  - Wizard should ask for the variant
  - Select 1 variant by increasing quantity in the grid and confirm
  - Confirm order
  - Add again a product variant with the wizard

Issue:

  Price unit is not set on the new line.

Cause:

  In `_onchange_quantity` (triggered by the purchase_product_matrix
  module), we do not update price unit if order line
  is in state `purchase` or `done`.

Solution:

  Replace condition to not perform `_onchange_quantity` if order line
  has an invoice line.

opw-2956755

closes odoo/odoo#98960

Signed-off-by: Adrien Widart <awt@odoo.com>

Before, when using a cash basis tax in the bank reconciliation widget, the account chosen for the tax line corresponded to the tax transition account. This was wrong: since the entry is already reconciled, we want to use the actual repartition account, as nothing will move this amount from the transition account afterwards.

Indirectly linked to OPW 2865789

closes odoo/odoo#99427

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

closes odoo/odoo#97435

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

Before this patch, when we try to print an invoice without belonging to the group stock.group_stock_user, we get an Access Error.

Doing this patch, we are allowed to print the invoices as we skipped the mentioned ACL.

closes odoo/odoo#74728

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

Steps to reproduce the bug:
- install eCommerce module with assets
- go to any product page
- check the source code with https://validator.schema.org/

Notice that the 'image' and 'url' microdata tags have no base url,
so the engine assumes http://schema.org/

 to be the base url. This
makes certain ad trackers such as facebook pixel unable to detect
the product being sold.

This commit adds the base_url field to both tags so that they are
correctly traced.

opw-2830058

closes odoo/odoo#97215

Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

closes odoo/odoo#99087

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

Currently, when creating an invoice from factur_x XML, the vendor is
identified by sequentially checking (in this order) the following
information :
- VAT number
- name
- email
However, when we generate a factur_x XML, we do not include
the partner's email address. This means that in some cases, two odoo
databases are not able to communicate bills/invoices properly.
This commit brings back a behavior that was unintentionally removed in
https://github.com/odoo/odoo/commit/d25fdafcd8eb4cfef14c2ef7ed8ad7785dd01b55



opw-2909408

closes odoo/odoo#98896

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

closes odoo/odoo#99083

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

Since the accounts without token are useless and could create errors
afterwards, we should delete them and automatically create a new one
with a new token in case force_create is set to True.

closes odoo/odoo#98858

Signed-off-by: Florian Daloze (fda) <fda@odoo.com>

Reverts [this commit] because it modified the format of float numbers in
exported xlsx files and we want to avoid introducing an error or
unwanted behavior in version 13, for which support will soon come to an
end.

[this commit]:https://github.com/odoo/odoo/commit/27ab24214dabfafc652280f680f7a650e7d98d2b



closes odoo/odoo#98975

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

Before this commit, in invoice/bill, when changing
the account of a tax line while having one of the invoice
lines with tax 0%, the tax line was not displayed anymore.

The cause of the issue is that in _recompute_dynamic_lines
method, when setting the tax repartition lines to
recompute, we did not filter the 0 tax. The consequence was
that we had a delta between expected and current taxes,
although the line of tax 0% was not displayed anyway.
By filtering the 0 tax, we have expected taxes == current taxes,
so we do not have delta anymore, therefore no tax line to recompute.

opw-2901833

closes odoo/odoo#97663

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

This commit addresses a screen refresh problem.

closes odoo/odoo#98788

Task: 2961768
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

This PR adds the 'posted' filter by default on the journal items list
view, when coming from an account's form view.

opw-2896728

closes odoo/odoo#98183

Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>