We do this in a separate commit so that the diff of the next ones will
still be readable.

task-59011

While licence is technically correct, it is not used in America
Change only the label as the key is used at other places (e.g. app store)

closes odoo/odoo#35350

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

Remove or move significant HTML attributes on <t> tags

`<t>` is not rendered, so we lose `class`, `role`, `itemprop`, `content`
etc. significant HTML attributes.

In other cases, the `<a>` tag can contain redundant HTML attributes,
which don't make sense (e.g. `href="#"`).

closes odoo/odoo#35391

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

This feature branch adds a new way to add products to SOs/POs: the grid (or matrix) entry.

When selecting a product template compatible with this mode, a dialog will open with a matrix of
available variants and a number input for each of those. Once all quantities are input, closing the
dialog will generate the lines for all the selected variants.

When more than 2 attributes are present, the matrix is organized by using the first attribute values
as X-coordinates and will then combine all other attribute combinations as Y-coordinates. This
allows to have potentially huge matrices, although this could be difficult to visually parse by users.

If the feature is enabled (the feature is installed independently in sale and/or purchase), this will be
the default entry mode for products in purchase orders when multiple variants are available - it's an
all or nothing situation. In sales orders, the product template can be configured to switch from the
product configurator mode (to select a single variant when adding the product) to the grid mode (to
select multiple variants at once).

The grid can be re-opened from an existing line (or by creating a new line with the same product)
and will repopulate with the current quantities of the order, allowing quick massive edition of the
complete set of lines for that product.

Task 1871560

closes odoo/odoo#34746

Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>

- Integrate authorize.net with new accept.js
- convert XML format requests to JSON

Task 2025821

closes odoo/odoo#34733

Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>

[MOV] sale -> product : product variant creation based on combination of product.template.attribute.value

part of product_configurator logic moved to product to be accessible in purchase even if p_configurator isn't installed.
And adapt configurator to be extended by matrix

task- 2025821

add accept js of authorize.net to make s2s flow pci compliance

after clicking on pay now button, one popup display with card inputs
    popup is provided by a authorize with all validation facilities
    After submitting details, payment flow is
    - get the temp token information from authorize
    - create a token with that temp token information in odoo
    - make a request to authorize for charge
    - after successful request, payment will be charged for that card

task- 2025821

- convert XML format request to JSON
- remove refund method from the request, as there is no use of it,
   we will never validate card as authorize.net validate card by itself,
   so there is no case for the refund
- verify token while creating it
- make verify validity field invisible in case of authorize

task- 2025821

Remove states according to new address format

No need to keep states that's why they have been remove.

From Module:
Belgium(l10n_be)
Germany(l10n_de)
Poland(l10n_pl)

Purpose :
========
Uniformity for define all state in base.

Specification :
===========
Move states from localization to base module

Localization modules:
China(l10n_cn)
Costa Rica(l10n_cr)
Dominican Republic(l10n_do)
Ethiopia(l10n_et)
Ireland(l10n_ie)
Netherlands(l10n_nl)
Turky(l10n_tr)
Vietnam(l10n_vn)
Romania(l10n_ro)
United Kingdom(l10n_uk)

that it is not a problem to put all these states in base, because the current csv only takes 0.34 s to be loaded

Related to task #1967713
Closes #32767

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

closes odoo/odoo#35404

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

Some picking where created with Chicago picking type without
explicitely setting Chicaco as company.
This result using the test user company which is San Francisco

Task : 2039900

closes odoo/odoo#35449

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

Removes the "Assign Owner" button from picking form view. Now, the stock
move lines owner is set when the picking is validated (if the owner
field is set of course).
The stock move line field owner_id is also hidden for incoming pickings.

Task #1860575

closes odoo/odoo#34986

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

The action was not used anymore after removing action menu on
https://github.com/odoo/odoo/commit/ea66192276921be1bafe73255fa77c55f3e10ac7#diff-14cac61c7c687d0e5f4eeeb3edeb4b4aL896-L902



closes odoo/odoo#35315

Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>

All activity filters are now invisible in the corresponding search views.

These filters were only used by activity redirection (when clicking on
the activity item in the systray) so we hide them to reduce the noise
for the user.

"My Activity" filter has also been removed, its corresponding domain is
now directly set in the action where it was used.

Task 2036392

Before this rev. `invisible` filters in the search view were not
considered at all.

Now the filters are still invisible from the user POV, but they are
still accesible via context and can be applied on search.

Related of task 2036392

Revision on https://github.com/odoo/odoo/commit/ff7ea6b654175e3138f5f36d2e5b4214cebef499



Due to some git conflicts, it duplicated history tests and removed
the previous test 'input not cleared on unresolved message_post rpc'.

closes odoo/odoo#35502

Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

The widget no longer exists, we can clean this

closes odoo/odoo#35496

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

Before this commit, Pickings button was always visible in manufacturing
order form view.
Now, it will be only visible if the MO has at least one picking.

Task #2047626

closes odoo/odoo#35455

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

On the manufacturing order form view, the 'update' button to change
the production quantity doesn't give the current mo id to the wizard.
That means 'active_id' is used.
The issue is 'active_id' may refer to another object (a bom or
a workcenter for instance).

This commit fills the default_mo_id key in the context before calling the wizard
to ensure the correct production order is used in the wizard default get.

Task : 2043136

closes odoo/odoo#35453

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

from f5e99060, a scrap order was unlink
when clicking the discard button in the insufficient quantity wizard.
This lead to a access error when the wizard was closed on the scrap order
form view. The form view was reloaded on a deleted record.

This commit adds a context key that prevent the unlink if the scrap order
was validated from the scrap form view

Task : 2043136

Follow up of 344614b5

If base64_source is falsy, we don't need to check the other parameters.

closes odoo/odoo#35489

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

Currently, only 6 digits after decimal point is stored in database and for some currencies
it may require to have more digits after decimal precision to correctly convert rates,
like MXN -> USD currency. So, we allow maximum digits to be stored in database.

On the view side, wherever rate is editable(form or tree view), we show 12 digits
after decimal point and on list view, we truncate limit it to 6 digits.

Also, a bug is fixed for web where 'digits' attribute for float field on list view isn't considered.

Also, we have to remove a test case statement which only checks for 6 digits for a float number.

task: 2024668
closes: #34279

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

closes odoo/odoo#35232

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

Update invoice report to add id attribute in vat label and tax lines
elements in order to to be able to make clear/save inherit of this
report in Argentinian localization

Before this commit modifying/extending the information was difficult
After this commit, the id can be used for efficient xpath

    <xpath expr="//t[@id='inv_tax_id_label']" position="attributes">
    <xpath expr="//span[@id='line_tax_ids']" position="attributes">

This package point to first package found in `upgrades_paths` or
fallback to alias of legacy `odoo.addons.base.maintenance.migrations`.

closes odoo/odoo#32650

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

This commit adds a new way to use upgrades scripts folders
whithout needing to symlink them to an hardcoded path.

The folders specified in --upgrades-paths is then being used by
migration.py to find and execute migrations scripts per module
specified in the -u CLI option.

The folder needs to have the following structure:
- <upgrades_paths folder 1>
	- <module1 name>
		- <version1>
			- <script1>
			- <script2>
			- ...
			- <scriptn>
		- <version2>
			- <scripts>
	- <module2 name>
		- <versions>
			- <scripts>
	- ...
- <upgrades_paths folder 2>
	- ...

Update odoo/tools/config.py

Co-Authored-By: Olivier Dony <odony@users.noreply.github.com>

Task 2041208

1. I create a product with fifo and real_time valuation (make sure the invoicing policy is 'delivered' and make it available in pos).
2. set the cost of the product to be 5.0 and sale price to be 10.0.
3. I update its inventory and set 5 items. -> total valuation of 25.
4. I change the cost of the product to 1.0.
5. I update again the quantity to 10, making the valuation of the product to 30.0.
6. I configure point of sale to allow invoicing.
7. Open a pos session then sell 7 items of the product (invoice the order).
8. Since the product is fifo, this means that the cost of goods sold is 5 * 5.0 + 2 * 1.0 = 27.0.
9. The correct expense account line should have balance of 27.0.
10. The correct output account line should have balance of -27.0

Followp of https://github.com/odoo/odoo/pull/35335


There was missing the part when an invoice is created from the POS
When the invoice is created from action_pos_order_invoice, it only contains invoice_line_ids. The stock valuation lines are present when the account.move is posted through addons/stock_account/models/account_move.py post method. That method requires _stock_account_get_anglo_saxon_price_unit to give the average unit price if it comes from a pos.order, just like it does when a sale.order.

closes odoo/odoo#35379

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

The main aim of the present refactoring is twofold:

- simplify the code that was largely complexified at the time of the
introduction of comparisons in the pivot view (Time Ranges menu),

- factorize the method expandHeader and _loadData that were too much complex.

Along the way, the pivot model structure has been simplified
and many tests have been added.
Performances in mobile mode have been improved by avoiding
unecessary operations due to useless column groupbys in that
mode.
It should now be easier to understand and modify the pivot view in future.

Co-Authored-By: Aaron Bohy <aab@odoo.com>

closes odoo/odoo#33615

Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>

An implicit call to toString was made for the
groupbys values in the function used to
group records in _mockReadGroup.
Consequently, the values false and 'false' were
mixed and the corresponding records put in the
same group.

math_utils is a small library that exports two
functions:

    - cartesian: allows to compute the cartesian
                products of any numbers of arrays
                while preserving the internal
                structures of their elements.
    - sections: returns an array with all
                the initial sections of the
                array passed as parameter.

And use CamelCase in label

Closes odoo/odoo#29010
Closes odoo/odoo#29092

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

This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.

Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.

closes odoo/odoo#35439

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