- A user has accounting permission but no employee permission, when that user creates a payment in spending it gives an error that does not have access to the bank_account_id field
- This commit allows the user to read the bank_account_id field when creating a payment

closes odoo/odoo#95714

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

When both a specific inheriting view and a non-specific base view are
written simultaneously, the specific inheriting base view must be
updated even though its id will change during the COW of the base view.

This commit sorts the list of written views in order to first handle the
website-specific ones then the base ones which might change some of the
ids of the already updated view.

Steps to reproduce in 14.0+ (no scenario found in 13.0):
- Create a new website.
- Configure the language selector layout to "Inline".
- Configure the language selector layout to "None".
=> Error notification was displayed and change was not applied.

task-2885882

closes odoo/odoo#96120

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

closes odoo/odoo#96045

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

Part-of: odoo/odoo#96045

[CLA] Individual signature Gordon.md

closes odoo/odoo#96076

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

There was an issue with this fix.

This reverts commit 8ebb44420c3e2dcc0d990d2646486654b4b2955d.

closes odoo/odoo#96211

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

In the `write` method, accessing the `ms_organizer_event_id` field of
`self` leads to an exception if `self` represents several records.

So, the idea of this fix is to set the `need_sync_m` field of all modified
records to `True` when at least a field to sync with Outlook is modified
(see `_get_microsoft_synced_fields()`) and then, at the end of the `write`
method, really patch or delete records that are already linked to Outlook
(that means they already have their `ms_organizer_event_id` field set).

closes odoo/odoo#95834

Signed-off-by: Arnaud Joset <arj@odoo.com>

The product configurator doesn't allow you to use non-integer quantities

Steps to reproduce:
1. Install Sales
2. Go to Settings > Sales > Product Catalog and enable Product
   Configurator
3. Go to Sales > Products and create a product 'Product A' with
   attribute Color and at least two values
4. Create a Quotation and add product 'Conference Chair (CONFIG)'
5. In the product configurator, specify 3.5 as quantity and click on
   'ADD'
6. The total price is wrong
7. Add the optional product 'Chair floor protection' and confirm
8. The quantity of 'Chair floor protection' rounds to 3

Solution:
Parse the quantity as a float instead of an integer (and replace
potential commas to dots in case of different decimal separator), get
the quantity from default_quantity for the rpc call (as it was converted
to an integer because of its type) and convert the quantity to float in
the controllers

Problem:
parseInt was used to retrieve the quantity and the controllers converted
the quantity to an integer. The field quantity of the
SaleProductConfigurator is of type Integer, which rounded the quantity
when opening the configurator.

opw-2896367

closes odoo/odoo#96208

X-original-commit: 96739d2f
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>

_* sale_management,sale_stock

Steps to reproduce:
- Install eCommerce
- Enable at least one more language
- Get an attribute with translations done (creation mode : never)
- Get a product with this attribute
- Go to the shop and add the product to the cart
- Go to the summary page and change the language
- Attributes fields aren't translated

Explanation:
This commit reverts the fix commit 47777ce1a7ee189c9328f53143abe492e861779e
that set the language of this description variants in function
of the order partner lang. We move where the language is added
in the context so that other cases like website_sale still have
the right translations.

opw-2790240

closes odoo/odoo#95258

Related: odoo/enterprise#29564
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

Steps:

Go to Accounting / Accounting Dashboard
click on import button in the Bank category
Select a random csv file and click on upload
A traceback occurs: this._controlPanelWrapper is undefined

opw-2709316

closes odoo/odoo#96105

Signed-off-by: Achraf <abz@odoo.com>

Before this commit, in large database the time to unlink is very long.
Before 500 ms after a few ms

closes odoo/odoo#95639

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

Main
-

[FIX] account: Do not attempt to create cash basis entries on non-cash-basis Company

Explain
-

Chances are that Journal Entries are coming from previous migration and they
could trigger the creation of CABA Journal Entries even when the company at
stake is a non Cash Basis Company.

closes odoo/odoo#94617

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

Steps to reproduce:
	- install approvals
	- in the approvals app go to filters>add custome filter> approval type
Issue:
	- traceback
Cause:
	- When no other module is installed, there is nothing to display under
	the approval type filter. Even if the field is not required,
	the javascript try to access the first element of the selection array
	to auto-fill the menu.
Solution:
	Add a check, if empty and not required, do not display it and leave the
	field empty

opw-2895516

closes odoo/odoo#94934

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

After the following steps, snippets overlays are not properly removed
from the DOM:

- In edit mode, drop 2-3 snippets in the page.
- Click on these snippets to activate their overlays.
- Drag and drop a popup in the page.
- Drag and drop a snippet in the popup.
- Move this snippet inside the popup thanks to the move handle button.
- Click on the "eye" button to hide the popup.
- Click on snippets of the page, the overlays are no longer removed when
they should.

It was because since commit [1], it is allowed to define an element
in which '_destroyEditors' destroys the editors but we forgot not to
completely empty the array that contains them.

But anyway, the editors list does not need to be updated in
'_destroyEditors' since commit [2] as it is already done in the
'destroy' method of 'SnippetEditor'.

[1]: https://github.com/odoo/odoo/commit/b7d522e9e7e31ac6bf926aae65e58d9f6cfa8903
[2]: https://github.com/odoo/odoo/commit/2a19a83762c1bc74dd7336378d254ab6da8e3a22



task-2799602

closes odoo/odoo#88290

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

==== Short version ====

Google is deprecating Universal Analytics in July 2023 and Google
Sign-In in March 2023. Google Analytics Embed API is based on Sign-In,
meaning it won't work anymore. It actually already doesn't work anymore
for accounts created somewhere after mid-2020 apparently.
There is no plan for now for Google to allow Analytics 4 dashboard to be
embed in external website.
We therefore can't do anything except warning people about it.
This is about the embed dashboard, not the tracking in itself for which
Odoo is already adapted in Odoo 15.0 for Analytics 4.

==== Detailed version (following short version, read it first)  ====

- Universal Analytics EOL July 2023, see [1].
- It will be replaced by Analytics 4 for which Odoo is already ready and
  actually using it since version 15.0 with [2].
- Google Sign-In EOL March 2023, see [3]. Analytics Embed API was based
  on it, it won't work anymore.
- There is no plan (for now) for Google to allow Analytics 4 to be able
  to be embed in external websites. They seem to just have dropped the
  "feature".
  This was confirmed by Google here [4] and indirectly here [5] in the
  DOC:
  `Note: This API does not support Google Analytics 4 (GA4) properties`
- While the EOL is planed for 2023, the dashboard integration is already
  not working anymore for new accounts.
- Old projects/keys/accounts can still embed their analytics dashboard.
  The threshold seems to be somewhere mid-2020, according to [6].
  It seems to be accurate as my own key from 2018 still works, while my
  keys from 2021 do not.

==== Fix ====

- In stable, warn user about it in their Odoo Analytics dashboard (this
  PR) and also add a warning about that on the doc.
- In master, simply drop the whole google analytics dashboard
  integration and remove the doc about it, see [7].

==== Useful links ====

[1]: https://support.google.com/analytics/answer/11583528?hl=en
[2]: https://github.com/odoo/odoo/commit/78bc86cbeccfc5df16218aee2b0d7c501e5c05b5
[3]: https://developers.googleblog.com/2022/03/gis-jsweb-authz-migration.html
[4]: https://issuetracker.google.com/issues/233738709?pli=1
[5]: https://developers.google.com/analytics/devguides/reporting/embed/v1
[6]: https://support.google.com/analytics/answer/11583832
[7]: https://www.odoo.com/documentation/15.0/applications/websites/website/optimize/google_analytics_dashboard.html



Finally, note that it means that from July 2023 to Octobre 2023, while
Odoo 14.0 is still supported, Google Analytics won't work anymore in
that version as it will still be designed for Universal Analytics and
not Analytics 4.

opw-2710910
opw-2855405
opw-2881515
opw-2892370
task-2790245
task-2820890

closes odoo/odoo#95847

X-original-commit: ca1cc2cb
Related: odoo/documentation#2441
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

When editing database fields via the web editor, their value are not checked.
Thus, stack traces can come up to the front-end user.

Step to reproduce the issue:
1) Install the E-Learning module and connect to the website
2) On the main website (not the backend), go to Courses > Edit
3) Edit the Next Rank treshold with any non integer string (e.g.: coucou)
A stracktrace will be shown upon save.

Solution: The issue is that there are no validation on the submitted fields,
this can cause stacktraces. A try-catch was used around the parsing of the
input value to catch and properly raise these exceptions to show clean errors.
On top of this, integers were not properly parsed, they were not taking into
account the `thousands_sep` of the user lang (e.g.: 35,000 for 35000).

NB: Generic fix of the following PR [1].

[1]: https://github.com/odoo/odoo/pull/85535



opw-2819392

closes odoo/odoo#96030

X-original-commit: bee998f3
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>

Without this the payment line amount is overridden before the request
is made to Mercury.

When a Mercury payment method is clicked a payment line with the right
amount is created. When a card is swiped it types a sequence like:

%B999000090000009^TEST...

The "typed" numbers are immediately interpreted by NumberBuffer and
will result in the payment line amount being updated to something like
9990000.... When the "barcode" is finished credit_code_transaction()
in pos_mercury will do the request using the amount from the
payment line (swipe_pending_line.get_amount()).

As a result a request is made to Mercury with a huge amount which
results in an error: "Error 1000211: Invalid Field - Purchase Amount".

Luckily NumberBuffer already supports barcodes, so the problem can be
solved by setting useWithBarcode. A small method was extracted to
override this cleanly.

opw-2892608

closes odoo/odoo#95712

Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>

Steps to reproduce:

1- install POS in multicompany env
2- create a customer c from POS UI
3- c doesn't belong to the active company

Bug:
the company_id is not set when the customer is created

Fix:
set comapny_id to current active company for new customers created from
POS

OPW-2881551

closes odoo/odoo#94153

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

Commit [1] adapted the topMenuColor option to the 14.0 editor but
did not await the call to action_demand.

This didn't cause any issue but could lead to race conditions and is
not correct.

It also breaks after [2].

[1]: https://github.com/odoo/odoo/commit/98c8438f5225dbc34b15fc2ed5b9918d537bb71b
[2]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b



task-2687506

closes odoo/odoo#95896

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

When creating an invoice from a repair order, the account mapping of the
fiscal position doesn't apply even though the tax one does

Steps to reproduce:
1. Install Repair and Accounting
2. Go to Accounting > Configuration > Invoicing > Fiscal Positions and
   create a new fiscal position with:
   - Name: 'FP test'
   - Tax Mapping from 'Tax 15.00%' to a new tax 'Tax 10.00%'
   - Account Mapping from '400000 Product Sales' to '450000 Other
     Income'
3. Go to Sales > Products and create a new product 'Product A' with:
   - Product Type: 'Consumable'
   - Customer Taxes: 'Tax 15.00%'
   - Income Account: '400000 Product Sales'
4. Create another product 'Product B' with same values except type which
   is 'Service'
5. Go to Repairs and create a new repair order with:
   - Any Product to Repair
   - Any Customer (once set, edit the customer's fiscal position to 'FP
     test')
   - Invoice Method: 'Before Repair'
   - Parts: add a line of type 'Add' with product 'Product A'
   - Operations: add a line with product 'Product A'
6. Confirm the order, create an invoice and open it: the account mapping
   of the fiscal position didn't apply (it should be '450000 Other
   Income')

Solution:
Apply the fiscal position mapping on the income account of the product

opw-2902056

closes odoo/odoo#95976

X-original-commit: aeedb517
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>

Odoo v14 replaces all non-digit characters on searching by virtual phone/mobile
field. When user types just letters, it led to an sql query with ids of all
leads.

Fix it by replacing non-digit characters first. If there are less than 2
characters, UserError will be raised

Task-2917174
opw-2770521
Closes odoo/odoo#91323

closes odoo/odoo#95835

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

With Calendar and CRM installed:
- Create a lead and a meeting related to that lead.
- Delete the lead.
- Go to the meeting form view from the calendar App.
- Click the Document action button and nothing will take place.

After this commit if you delete the lead, you will no longer be able to the
see the button as document information is correctly reset.

Task-2917174
Closes odoo/odoo#42450
Closes odoo/odoo#47497

Part-of: odoo/odoo#95835

The error message should not be copied for obvious reasons. A new request
should not begin in error state.

CLoses odoo/odoo#43603

Part-of: odoo/odoo#95835

The fake demo email used in our crm_lead demo data is an actual customer's email.

Steps:
  * Install Demo Data
  * Navigate to CRM and activate Leads.
  * See Lead for "DeltaPC: 10 Computer Desks"
  * Issue: Email being used is an active real company's email.

Updating to a more distinctive fake email so actual customers are not
accidentally used in our demo data.

opw-2746911
Task-2917174
Closes odoo/odoo#84225

Part-of: odoo/odoo#95835

Probability is not always given to write, hence date_closed is currently not
always reset. Indeed as it is a computed field it can be updated after stage
update, without being explicitly in values.

In this fix we consider that going out of won stage without any other hints
on probability is like being not won anymore, therefore resetting date closed.

Task-2917116
Closes odoo/odoo#93704
Closes odoo/odoo#93704

Part-of: odoo/odoo#95835

Followup of odoo/odoo@6e46d4cd07e0d8199706fc5eed55b4cd477737f0 and odoo/odoo@1f81d60de66cdbe5bfc8c3ef35ddf23b0772d316

Also fix a test failing with python 3.8. Message-ID is formatted using chevrons.

Task-2917174

Part-of: odoo/odoo#95835

Onchange could also populate the lang field of the lead when updating the
customer.

Partial backport of odoo/odoo@65bb3a5710573a530939341827d1afb0f158c0ba

Task-2917174
Closes odoo/odoo#78715

Part-of: odoo/odoo#95835

When stage is being created, `team_count` was not computed, because it
has not dependencies. This means the "sales team" field is not displayed
which is annoying in multi team environment.

To workaround it a fake trigger is added.

Task-2917174
Closes odoo/odoo#87905

Part-of: odoo/odoo#95835

*: website_form, website_sale

When an unsafe snippet is dropped into a sanitized HTML model field, its
unsafe content gets removed on save.
We need a way to mark snippets as being (in)compatible with
sanitization. It cannot be automatic, as, for example, the snippet
introduced at [1] contains an iframe but is compatible with
sanitization.
In 13.0, we will temporarily set up an automatic mechanism that marks
existing snippets containing forms as being incompatible with
sanitization.
In 14.0 a distinction between full sanitization and form-tolerant
sanitization introduced at [2] is added with this forward-ported commit.

This commit prevents unsafe snippets from being dropped into sanitized
HTML model fields.
The "Form Builder", "Product Search" and "Product Search Input" blocks
are now prevented from being dropped or moved into form-sanitized HTML
fields.

Steps to reproduce (in 13.0):
- Go to a product page
- Drop a "Product Search" snippet into the product-specific section of the
product
- Save
=> The form was removed.

[1]: https://github.com/odoo/odoo/commit/c2e9bd0e60014b6a42931cf300e0f89f8cf7c225
[2]: https://github.com/odoo/odoo/commit/388c222c6c4bb7e2fe3e67009b248359ae0fd3db



task-2829961

closes odoo/odoo#95265

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

The error message now shows that a VAT tax must be added to that line
and that if it is already added, it may be misconfigured. This improves
the functionality since previously it showed that there should only be
one VAT tax and that could generate confusion in some cases

[CLA] add new members to Adhoc CLA

closes odoo/odoo#94457

X-original-commit: 5b057dea
Signed-off-by: Josse Colpaert <jco@odoo.com>

The two modules both implemented the cart update warnings box
incorrectly, and differently (though in part because of later
changes):

- `aria-hidden` has meant `display: none` for a while, so the dismiss
  button would never show up
- the class is alert-dismiss*i*ble, not alert-dismiss*a*ble
- unnecessarily complicated dom manipulation on updating the warning
- wishlist would go and update the cart badge by hand, unnecessarily

Extracted the warnings stuff to its own helper, with a fixed DOM, and
a slightly modified structure so it's possible to update the message
without having to rewrite the entire box content.

Also modified wishlist to update the cart badge via the existing
helper, this way both modules just call

    updateCartNavBar(data);
    showWarning(data.warning);

the same way in the same order, and everything is clear.

Also updated `updateCartNavBar`:

- removed the iteration as jQuery should be able to work on the set
- added the warning message and an icon if the quantity is 0 (could
  not add to cart) as the separate warning may not be available on all
  pages e.g. "recently viewed" product widget can appear anywhere,
  previously was only set through wishlist
- keep reveal of cart quantity ancestor as on some pages it's not
  visible by default (see previous item for user-case)

closes odoo/odoo#95863

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

The module will stop working after the 3rd October 2022, as Google is
disabling their OOB Oauth Flow on that date[1].

The module will not do anything after that date and a warning message is
shown on the settings page to warn users.

[1]: https://developers.googleblog.com/2022/02/making-oauth-flows-safer.html#disallowed-oob



task-2867215

closes odoo/odoo#95823

X-original-commit: bbb9dcbd
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Kevin Baptiste <kba@odoo.com>

For zero percent taxes, when the repartition lines are defined as 0% of
the 0% tax, the DatiReipilogo elements are not generated.

This is because of the recent addition of a filter to the calling of the
_prepare_edi_tax_details inside of the function that generates the
values for the template. The filter specifies that the tax data
retrieved relates to repartition lines with a percentage > 0. This
excludes taxes that are 0% of a 0% tax (which would be the same as a
repartition line of 100% of a 0% tax).

The solution is to change the > to >= so that these 0% tax repartition
lines are included.

A test is created with an invoice with two 0% taxes. One tax has a 100%
tax repartition line, and one has a 0% tax repartition line. With the
fix, there should be DatiReipilogo for both taxes in the xml.

The reverse_charge_invoice tests are also fixed in order to ignore the
invoice name (which will change depending on how many invoices are
posted in the previous tests).

closes odoo/odoo#95816

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

When iot switch between 2 version of odoo we must clean correctly the branch.

Now -dfx erases each and every file in git directory which is not part of repository.
(like drivers and interfaces)

closes odoo/odoo#95667

X-original-commit: c115f9f8
Signed-off-by: Masereel Pierre <pim@odoo.com>

In some case, users use custom `address_format` with keys that do not
exists. This lead to errors in odoo and upgrade process. Avoid
`KeyError` by using defaultdict with `str` value.

upg-361146
upg-361241

```
Traceback (most recent call last):
  File "/home/odoo/src/odoo/14.0/odoo/service/server.py", line 1201, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "/home/odoo/src/odoo/14.0/odoo/modules/registry.py", line 89, in new
    odoo.modules.load_modules(registry._db, force_demo, status, update_module)
  File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 457, in load_modules
    force, status, report, loaded_modules, update_module, models_to_check)
  File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 349, in load_marked_modules
    perform_checks=perform_checks, models_to_check=models_to_check
  File "/home/odoo/src/odoo/14.0/odoo/modules/loading.py", line 227, in load_module_graph
    migrations.migrate_module(package, 'post')
  File "/home/odoo/src/odoo/14.0/odoo/modules/migration.py", line 180, in migrate_module
    migrate(self.cr, installed_version)
  File "/tmp/tmp1bew9m7l/migrations/website/14.0.1.0/post-adapt-footer-data.py", line 69, in migrate
    address = html_escape(partner._display_address(without_company=True))
  File "/home/odoo/src/odoo/14.0/odoo/addons/base/models/res_partner.py", line 950, in _display_address
    return address_format % args
KeyError: 'town_name'
```

closes odoo/odoo#95523

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

The way to have API Key and API Secret has changed to configure a
Twitter application. The guide for this configuration is updated with
this commit.

task-2852404

closes odoo/odoo#95681

X-original-commit: 63d74f03
Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Use orm cached method to improve perf

Same issue in lower versions

closes odoo/odoo#95794

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

closes odoo/odoo#95727

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

Steps to follow:

  - Set your timezone to New York
    In linux for example with: `timedatectl set-timezone America/New_York`
  - Verify that the user timezone is also set to NY
  - Create a reccurent event the 6 july 2022 (a wednesday)
  - In options, check the recurrent box
  - Set repeat to once every week
  - Thursday is the only day checked
  -> It should be Wednesday

Cause of the issue:

  When `_compute_recurrence` is called, `event.recurrence_id` has not
  yet been set
  -> `event.recurrence_id.event_tz` is False
  => Copy the defaults before computing the start date and check the
  timezone of the event itself

opw-2886253

closes odoo/odoo#95110

Signed-off-by: Arnaud Joset <arj@odoo.com>