Fixes odoo/odoo#86216
When printing qweb report use the current company.
For example, the company logo printed was always from user company
default instead of the current company.

closes odoo/odoo#86220

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

Part-of: odoo/odoo#86220

THe price shown on the order line was not taking into account the
quantities ordered.

closes odoo/odoo#85846

Taskid: 2678064
X-original-commit: f9243560
Signed-off-by: Kevin Baptiste <kba@odoo.com>

This commit aims to allow assigning tags to the taxes
created by the OSS feature by providing the xml_id of their
report.line in the eu_tag_map.py file.

Before this commit:
In l10n_be, the taxes created by OSS (l10n_eu_services) didn't set
the tag +47 on invoice_repartition_lines nor +49 on
refund_repartition_lines.
This make the VAT report for Belgium wrong.

After this commit:
Taxes created by OSS for a company using the belgian CoA will get
their tags set properly and thus will the taxes impact the
belgian tax report correctly.

task: 2770182
ticket: 2768622

Community-PR: https://github.com/odoo/odoo/pull/85607



Design choices:
This fix is currently solving the issue for l10n_be but we have
no doubt that it will be raised for other EU countries too.

In order to provide the tags, we decided to be consistent with
what as been done regarding the tax mapping. Thus we decided to
create and maintain a simple mapping file and to test it.

several other methods were explored:
- create a global variable and update it from all localization
modules. This method would work but is ugly and error prone.

- create a templating method and override it from localization
modules.
The problem is where to set the root of the template method?
The naïve solution would be to create a bridge module between
l10n_eu_services and l10n_be but that would lead to an explosion
in the number of bridge modules which we don't want.

In order to keep things simple and generic, we could put the
template method directly into the account module. But it is kind
of ugly because account shouldn't know anything about the oss
feature and it would encourage such a leaky design to happen
again in the future.

closes odoo/odoo#86295

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

Improves l10n_eu_services code readability

Part-of: odoo/odoo#86295

The smartbutton for the number of hours in the attendance smart button
on employees and user did not use the right widget and could display
invalid data like '1.8 hours last month'.

TaskId-

closes odoo/odoo#86247

X-original-commit: 230f9185
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

Description of the issue/feature this PR addresses:

In odoo payment the cc_expiry.maxlength is limited to 7 characters

https://github.com/odoo/odoo/blob/75785db4c8d0c0be9fb7b8dfc2cd7b8209181c21/addons/payment_test/views/payment_test_templates.xml#L19 https://github.com/odoo/odoo/blob/75785db4c8d0c0be9fb7b8dfc2cd7b8209181c21/addons/payment_ingenico/views/payment_ingenico_templates.xml#L54

Current behavior before PR:

But your [$.payment.formatExpiry](https://github.com/odoo/odoo/blob/14.0/addons/payment/static/lib/jquery.payment/jquery.payment.js#L629) can return 9 characters
![Screenshot(20)](https://user-images.githubusercontent.com/35231827/157748056-c4fa8e4a-1504-41a9-afbc-99743e5491fe.png)

We can see in when the user use autofill

https://user-images.githubusercontent.com/35231827/157748925-1778e71d-28a6-4ed5-82ac-989d4e503a24.mp4

Desired behavior after PR is merged:

https://user-images.githubusercontent.com/35231827/157748644-fd530ded-a13f-473d-8410-09eca4c8c961.mp4



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

closes odoo/odoo#86226

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

The issue is simply creating a related stored many2many field, which is
pretty easy to do with Studio.  When creating the field, Odoo crashes
with a traceback caused by ondelete being None on the field.

The source of the bug is the fact that the attribute field.ondelete is
set to a sensible default ('cascade') on non-related fields only.  The
fix consists in setting the default value on the attribute itself, so
that the setup of the field never falls on a case where field.ondelete
is unset.

closes odoo/odoo#86255

X-original-commit: 2bb126c5
Signed-off-by: Raphael Collet <rco@odoo.com>

When having a bank statement line in foreign currency, the writeoff line is display with the right sign but with the amount in company currency.

This is happening in two scenarios :

1 - With a bank journal in foreign currency, and a reconciliation model
with 'rule_type' 'invoice_matching' and 'match_total_amount' at 90 for example.
Create an invoice in the foreign currency for price 100, and create a bank
statement on the journal with a line amount of 90 (payment_ref set with the
invoice name). Then confirm and reconcile -> the writeoff amount is display with
the right currency sign, but in company currency

2 - With a bank journal in company currency, and a reconciliation model
with 'rule_type' 'writeoff_suggestion'. Create a bank statement with a line
with amount X, amount_currency Y, foreign_currency set. Confirm and reconcile
-> writeoff amount is the amount with the foreign currency sign, instead of the amount_currency.

opw-2695846
opw-2731737

closes odoo/odoo#85475

Related: odoo/enterprise#24739
Signed-off-by: Laurent Smet <las@odoo.com>

If applied, this PR will enable button_access for all users and portal_customers, letting them
access the documents directly. The button "View Journal Entries" will appear on the notification
email, and by clicking this the user will be directed to the portal page of the invoice/refund.
All users and portal_customers subscribed to the thread should be able to see this button.

A following refactor by TDE (#82167) has addressed this problem in master (for 15.2).
For stable versions, in this PR, we agreed to keep changes limited to the accounting scope.

Ticket link: https://www.odoo.com/web#id=2645653&model=project.task



opw-2645653

closes odoo/odoo#86214

X-original-commit: de8d1632
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>

closes odoo/odoo#86227

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

Finetuning of #85774
Fixes #86174

closes odoo/odoo#86198

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

Current behavior :
SIPS urls aren't available anymore and lead to a 410 error page

Reason :
URLs have been updated and should be replaced
i.e. previous URL : https://payment-webinit.simu.sips-atos.com/paymentInit
should be replaced by https://payment-webinit.simu.sips-services.com/paymentInit
according to SIPS docs [1]

[1] : https://documentation.sips.worldline.com/en/WLSIPS.317-UG-Sips-Paypage-POST.html#Step-3-Doing-tests-in-the-simulation-environment_



OPW-2780969

closes odoo/odoo#86193

X-original-commit: d2149231
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Claude Thibault (thcl) <thcl@odoo.com>

The following line of code:

    self.env.ref("base.europe").with_context(lang="fr_CA").country_ids

It is executing the following query:

    SELECT res_country_res_country_group_rel.res_country_group_id, res_country_res_country_group_rel.res_country_id FROM res_country_res_country_group_rel, "res_country" LEFT JOIN "ir_translation" AS "res_country__name" ON ("res_country"."id" = "res_country__name"."res_id" AND "res_country__name"."type" = 'model' AND "res_country__name"."name" = 'res.country,name' AND "res_country__name"."lang" = 'fr_CA' AND "res_country__name"."value" != '')
    WHERE 1=1 AND res_country_res_country_group_rel.res_country_group_id IN (1) AND res_country_res_country_group_rel.res_country_id = res_country.id
    ORDER BY COALESCE("res_country__name"."value", "res_country"."name")
    OFFSET 0

With duration: 138.119ms

But it is not needed to spend processing to compute it if it even will not be used if the `vat` is empty

If your website checkout process is creating almost the partners without `vat`
it could have a better performance

closes odoo/odoo#85064

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

The aim of this commit is to correct the compute_all calculation
when it is dealing with an article with 0.00 price and having a fixed
tax included in it.

In this situation, this means the tax is directly taken as an expense
by the company that offers it to its client.

This also solves the situation in which we have a 100% discount because
discount is applied before calling `compute_all` by changing the
unit_price.

Before this commit:
Creating an invoice with a line having a price at 0 or a 100% discount
and a fixed tax price_include resulted in a really weird behavior: the
company had to reimburse the customer for the amount of the tax.
(what a lucky customer :D )

After this commit:
Customer is sad, he only gets the product for free.
The base is calculated as negative, resulting in a debit amount on the base
income line.
The tax is then counterbalance by it.

The form is displaying a negative untaxed amount, a positive tax and the
total is 0.

closes odoo/odoo#85898

Ticket: 2660808, 2637512
Community-pr: https://github.com/odoo/odoo/pull/85747


X-original-commit: 5b45c232
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Brice Bartoletti <bib@odoo.com>

3c71f66bb541fcf31f31e75b60f7825d26109bc4 fixed the fact sometimes the answer of another user than the one we wanted could be loaded when restarting a survey. With this fix, we introduced a check on the partner having created the answer the user was trying to access. It became impossible for a user to access an answer which wasn't his.

While correct in the case we were fixing, this introduced an issue with the /survey/print/ route, which allows any user with the right tokens to visualize the answers of another. We fix this by making sure we don't check the partner when accessing this route, to restore its former behavior.

closes odoo/odoo#85583

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

Create a 21% tax included in price
Create a 6% tax included in price
Create a fiscal position that will replace the 21% tax included by the
6% tax included
Create a customer and assign this fiscal position
Create a product :
Price = 121€
Tax = 21% tax included
Create a SO with this customer and this product
Create an invoice (from scratch) with this customer and this product

SO : the unit price is 100,00€
Invoice : the unit price is 106,00€

Fix by creating a common method to calculate the price_unit

opw-2699793

closes odoo/odoo#85893

X-original-commit: 625486a8
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

Every tax should have at least one tax line.

closes odoo/odoo#86009

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

In `account.move` `_stock_account_prepare_anglo_saxon_in_lines_vals`,
the `partner_id` is set two times, following those PR:
  - odoo/odoo#75038
  - odoo/odoo#84468

closes odoo/odoo#86133

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

Current behavior:
When you use a workcenter with start and stop time in a BoM the start/stop time is applied for each quantity in the BoM report and workorder. For example if you have 3 quantities the start/stop time
will be applied 3 times.

Steps to reproduce:
- Create a product to manufacture (With atleast 1 operation)
- Create a workcenter that has positive Start/Stop time values
- Start and stop time are multiplied by the quantity in the BoM report

opw-2779381

closes odoo/odoo#85677

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

Every tax should have a tax repartition line.

closes odoo/odoo#86021

X-original-commit: 2b39bfd6
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>

Expected Behaviour

When a user goes to his own profile, he has two ways to change his password :
1. through the 'Account security' tab
2. through the 'Actions' > 'Change password' menu in list/form view
Both option should let the user change its password, or one of the two should
not be present

Observed behaviour

While the first one works as expected, the second option gives an error as
the user doesn't have the admin rights

Reproducibility

This bug can be reproduced following these steps:
0. Make sure to have the "Employees" app installed
1. Connect as an employee (e.g. demo/demo on runbot)
2. Click on your name at the top right, go to 'My Profile'
3. Click 'Action' then 'Change password'

Problem Root Cause

There is an override of field_view_get for the res.users model in the hr
module which elevates the user with sudo so that the user may modify their
own user in some capacity. The problem is that by elevating the ACLs of the
user, fields_view_get will also return actions that are not normally
available to the user (e.g. deletion of user profile)

Related Issues/PR

- opw-2735671

closes odoo/odoo#83577

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

Modifying the signature of a method in a children module breaks things,
as other modules not being aware of the change will call super method
without the proper arguments. This also applies to adding new keyword
arguments, as these arguments are not propagated through the super call
chain, and you'll lose the value in the best case, or have a crash in
the worst one.

This overwrite is not only adding 2 new keyword arguments, but also
removing an existing one (`date=None`).

In this commit, a different technique is used to achieve the same
result, using kwargs and propagation them properly to avoid breaking
override on customization modules.

Note:
Override like:
def _create_invoices(self, grouped=False, final=False, date=None):
    // Do custo stuff
    return super()._create_invoices(grouped=grouped, final=final, date=date)

Closes #85269

closes odoo/odoo#85383

Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>

It's currently confusing: the default value is already 'groups', but the create
method is actually giving another default.

task-2749643

closes odoo/odoo#86049

X-original-commit: 6ab7de77
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

task-2789208

closes odoo/odoo#86047

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

Current behavior:
When you access sales tree view of a company, the sales of archived partners are not shown in the list.
But the sales count on the smart button is right.

Steps to reproduce:
- Add a partner to a company
- Create a sale with this new partner and confirm it
- Archive the new partner
- Go on the company contact page
- The smart button will show the number of sales
- Click the sale smart button
- The list is missing the new partner's sales

opw-2774862

closes odoo/odoo#85856

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

Since [1] only floating fixed headers were included in the calculation
of the `dom.scrollTo()`'s offset.
Because of this when a snippet was dropped on the top of a page, the
header being shown but non-floating was not used in the offset
calculation, which made the automatic scroll operation hide the header
partially for headers taller than the requested 50px offset from the top
of the display.

After this commit, any shown header is included in that calculation -
even non floating ones.

Steps to reproduce:
- drop snippets into the page until it has to scroll
- drop a snippet right below the header
=> header was partially hidden upon drop by the automatic scolling

[1]: https://github.com/odoo/odoo/commit/ee47bd9ce0da526ea5b3387a354ab8fbd06cc55f



task-2765820

closes odoo/odoo#84836

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

Before commit, if the 'Receipt' Operation type was archived, the purchase agreements would still use it.
After commit, if stock.picking_type_in record is archived, search for another (non-archived) one.

OPW-2748495

closes odoo/odoo#85983

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

closes odoo/odoo#85904

X-original-commit: f4f833bb
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Wolfgang Taferner <w.taferner@wtioit.at>
Co-authored-by: Andreas Perhab <andreas.perhab@wt-io-it.at>

Every tax should have a tax repartition line even 0% tax

closes odoo/odoo#85964

X-original-commit: 17e3bd58
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Brice Bartoletti <bib@odoo.com>

Messages are copied when duplicating a channel

Steps to reproduce:
1. Install Discuss
2. Write a message in the general channel in Discuss
3. Duplicate the general channel (user demo should be a member of this
channel) and give it another name
4. Connect as demo
5. The new message notification is on the general channel (and it should
be the duplicate channel
6. Mark the notification as read
7. Refresh the page
8. The notification is still there even though it has been marked as
read

Solution:
Do not copy the message of the original channel

Problem:
`channel_message_ids` is copied when duplicating a channel

opw-2731842

closes odoo/odoo#85950

X-original-commit: 9fe1ffbd
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

Purpose
=======

On product list we can see that kits are listed with quantity on hand
equals to the lesser quantity of the kit's components.

When applying the filter **Quantity on hand greater than 0**, the kit
disappears from the list.

The issue is that we compute product quantity from stock.quant, for kits
we don't create a quant beacause it's not a physical product.

Specification
=============
To solve the issue, we extend the method **_search_qty_available_new** from
**stock.product** in **mrp.product**, where we fetch all kits and add the id
of the products that verify the given condition.

opw-2717594

closes odoo/odoo#85930

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

Steps to reproduce the bug:
Go to a work order that is ready or waiting,  try manually changing the scheduled start or end date > save

Problem:
Traceback is triggered because when we modify the date, we check if the start date is before the end date. But we cannot compare a False with a date

opw-2768054

closes odoo/odoo#85403

X-original-commit: e2a1fd1a
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>

Currently, if a liquidity journal has a currency set (e.g. Bank) the amount_currency shows lines according to the journal currency, which is correct. However, if the journal currency is the same as the company currency, the amount_currency shows the amount in the foreign currency that is not in fact held in the Bank.
Should be: follow the same logic for liquidity journals that have the same currency as the company (or set company currency by default) and show amount in journal/company currency.

closes odoo/odoo#85571

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

Steps to reproduce:
===================
- Create a Sales tax
- Archive it
- Go to Sales and create a SO
The archived tax is available for SO line

Cause:
======
Context {'active_test: False'} is defined on tax_id field of SO line
to still display archived taxes on existing SO.
This context is passed to the field in the form view by default, allowing
archived taxes to be selected in SO creation/edition.

opw-2769057

closes odoo/odoo#85915

X-original-commit: 820faf0d
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Anh Thao PHAM <pta@odoo.com>

Add a check to ensure that the repartition lines have at least one tax line.

Reason: the compute_all fonction skips the taxes with no tax lines
because it only loops over the tax repartition lines to fill taxes_vals

closes odoo/odoo#85815

X-original-commit: 0b1e90e4
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>

Before, when sending an invoice for the first time, it would give
a "cannot find savepoint" traceback upon wanting to release it.

We avoid that error by putting less code in the with statement,
so the savepoint gets released a lot earlier while the record
remains locked for the rest of the transaction.

We also put a nice error message if the user can not send at the
moment because another process is already sending.  (might happen
more often in v15)

We also updated the translation .pot as we added a new message
and some messages were missing anyways in the .pot, so we added
those as well.

closes odoo/odoo#85523

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

collections.Set was deprecated since 3.6 and removed at 3.10
https://github.com/python/cpython/blob/3.9/Lib/collections/__init__.py#L62-L65



closes odoo/odoo#85853

X-original-commit: 4c2d3e1b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

Wrong arch caused the following error when user language is not English

ValueError: Không tìm thấy phần tử '<tree string="Liên hệ">' trong giao
diện cha

View name: res.partner.tree.form.inherit
Error context:
 view: ir.ui.view(2867,)
 xmlid: membership.view_partner_tree
 view.model: res.partner
 view.parent: ir.ui.view(115,)

closes odoo/odoo#84508

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