Before this commit, customers might see a "transaction not found" page
when returning from Adyen Pay By Link Payment Page.

Now, they'll see a "waiting for payment" page if they returned before
the webhook notification or the confirmation of payment if they
returned after the webhook notification.

opw-3006401

closes odoo/odoo#102999

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

The previous link was dead

closes odoo/odoo#101911

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

Fixup of 706db8a7

closes odoo/odoo#102558

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

The implementation of _find_mail_template allow to call it only
on one record at a time.

This was not the case with in _send_order_confirmation_mail.

- Add excplicit constraint in _find_mail_template
- Make sure _send_order_confirmation_mail call the method once per
  record

closes odoo/odoo#102135

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

Customer display does not show the appropriate logo when multi-company is
enabled. The logo shown is always the logo of the default company.

Step to reproduce the issue:
1) Install Point of Sale and set up a second company
2) Put a logo on both companies (different ones)
3) Create a POS session on the newest company (not the default one)
4) In this session, activate Customer Display
5) Launch the session and open the Customer Display
The logo shown is the logo of the default company.

Solution: The issue is that when fetching the logo, we don't include
information about the current company. Thus, we include the logo of the default
company (at url /logo). We can easily specifiy which logo we need via the url
/logo?company={company_id}. As dynamic information cannot be included into a
CSS, we include this into the XML as it is done with other images rendered.
In our case, we don't need to retrieve the logo and map it to base 64 (for
ressources requiring to be logged in) because the logo is a resource available
to anyone.

opw-2745014

closes odoo/odoo#93638

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

closes odoo/odoo#98021

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

Part-of: odoo/odoo#98021

This PR https://github.com/odoo/odoo/pull/97805

 wrongly assumed that
self contained a single workorder. This would raise an error if there
were multiple records in self.

Solution:
Modify calls on `self` to `workorder` (as we already iterate through
them)

closes odoo/odoo#101580

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

Steps to reproduce:

1. change system and admin's time zone to one with a different
date than UTC
2. enable multi-currency in the accounting module
3. add rates for the current date in local time zone and UTC
4. go to settings > currencies
5. the rate for the UTC date is displayed

To fix this, we should use a time zone aware field in `res_currency`.

opw-2945108

closes odoo/odoo#100123

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

closes odoo/odoo#101380

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

- Go to accounting/Report/Invoices Analysis
- Open studio
- enable list view
- empty view

This code bellow compute count_field as `__count` because group_by_no_leaf
is in the context.

But in the basic_model we don't consider this case.

https://github.com/odoo/odoo/blob/5797fd80a63309269f15bcbe4948d4429a53eec2/odoo/models.py#L2293-L2297



opw-2980923

closes odoo/odoo#100869

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

Those constraints are an incorrect leftover from 0a42a9de which removed the size constraints on a
number of core tables including 'name' and 'model' of ir_model_data.

Temporary table tmp_ir_translation_import limits columns size (imd_name and imd_model).
Those columns are only used to match columns 'model' and 'name' in ir_model_data.

But in ir_model_data, columns 'model' and 'name' are VARCHAR, no reasons to restrict the temporary table.

opw-2983422

closes odoo/odoo#101144

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Change 'Invoice date' label on report according move_type

closes odoo/odoo#100851

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

The default value of max_time_between_keys_in_ms in barcode is 55 ms.
The default value of 55 ms is too low and creates an issue for RFID readers.

The default value of max_time_between_keys_in_ms is increased to 100 ms.

task-2996072

closes odoo/odoo#101128

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

Steps to reproduce:
- install sale_management
- enable variant in the setting of sales
- create a second company
- create a product with at least a variant and set the company
  to the active one
- switch to the second company
- create another product and select the same variant
- error on creation

Cause:

 The stored compute is executed as sudo, therefore a value that the user
 has no access may stays in the cache. In subsequent flush we might read
 value from cache when computing some other fields that contain an
 unreadable value for current user.

Solution:

 Flush and invalidate so we don't have unaccessible value in cache in
 this use case.

note: this is not happening in 14.0 and over

opw-2898457
opw-2950290

closes odoo/odoo#96023

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

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>