normal mode: Importing only regular/basic fields from source file
advanced mode: Importing any related fields from source file(i.e. if detected pattern in header like '<relational_fieldname>/<fname>')
- Rename following checkbox "Show all fields for completion (advanced)" in "Show fields of relation fields (advanced)"
- If the import file contains a column with a field of a relation field, show the column label in the preview, even if "Show fields of relation fields (advanced)" is not checked > to make it less confusing when importing advanced files (e.g. products with attributes)
This is a backport of 1ba4fbe640, which was performed due to several
tickets mentioning confusion with the new import system.
The css clear was using jquery ui class for enterprise which now may
not be available on the given part. This commit replace it with class
defined in account_reconciliation.
With this the style could have issues such as not displaying the
congratulation message after reconciliation.
fixes#14743
Each qty of a line in the BOM Structure report must be computed in
the uom of its BOM line.
Example:
With 2 products: A, B
BOM A: 100 kg of A is produced by 5t of B
So 1kg of A needs how many t of B ?:
In the code:
qty_per_bom = 100 kg expressed in the uom of B => qty_per_bom = 0.1t
qty = 1 kg expressed in the uom of B => qty = 0.001t
l.product_qty = 5t
qty of B = (l.product_qty *qty)/ qty_per_bom = 0.05t
opw:697502
Due to an error introduced when migrating the module at new API
at commit a4e57ea16c limited attendances
having date_from and / or date_to were not correctly taken into
account.
Tests have been added to avoid regression.
Commit d861cdc1c4 introduced the tax group feature. The tax line
details were removed from the printed invoice in favor of the tax group.
However, it requires that all tax groups are correctly defined in the
localization, otherwise the printed invoice doesn't show the required
tax details.
The correct fix, which is the complete definition of the tax groups,
will be done for the upcoming v11 version. In the meantime, this simply
introduces back the tax details table.
In multi-company:
- Create 2 companies A and B
- Set the superuser on company B
- Set the website on company A
When a SO is generated from the eCommerce, it is defined on company B,
while it should be on company A.
opw-695253
from odoo#14848
Those subscribed to the department of the employee didn't get notified when
the employee encoded a leave.
It was due to the department_id not being given as value in create when the
employee made the leave.
This is because there's a group group_hr_holidays_user on that field in the
view, so only when they created a leave the followers would be added correctly
(as department_id was given as value in create).
This commit also remove the useless subscribe_followers method.
With Company A (Warehouse Wa) and Company B (Warehouse Wb)
When making inventory adjustments for Warehouse Wb in company A,
the inventory lines displayed must only be the lines of the company A in
the Wb.
In this way, the user avoids confusion with the adjustments he is creating.
opw:697182
When making an inventory adjustments in multi company, the company field
must be set according to the location_id set. In this case, it avoids creating
by default different inventories for the same warehouse.
opw:697182
This is related to revision dfcc0c40b1
If the invoice line provided the amount currency, but
set to False, the amount_currency must be computed anyway
opw-702045
When selling in a foreign currency,
A double currency rate change, one in each way, was applied when creating the good cost
move line of the invoice, which leaded to some precision loss when the decimal accuracy was
set with a number of digits greater than the currencies digits rounding
e.g.
Product cost price: 52.56422
CAD to USD rate: 0.7383
The product cost price is always in the company currency
while `_anglo_saxon_sale_move_lines` always returned the price
in the currency of the invoice. A first conversion rate was applied
from the company currency to the invoice currency.
52.56422 * 0.7383 = 38.808163625999995, rounded to 38.81
Then, when validating the invoice, and creating the move line,
the price was then converted again, to the company currency,
as the debit/credit of a move line is always in the company currency:
38.81 / 0.7383 = 52.566707300555336, rounded to 52.57
The cost price of the product in the good cost move line was therefore
set to 52.57, insteaf of 52.56, because of this precision loss.
With this revision, we avoid to do the currency rate conversion
two times, in both ways, to avoid the precision loss.
opw-702045
Before this commit there was an error when we chose a monthly recurrence
with "Day of Month" of type "Day of" because the code expect them to be
set. In any case they are required field so if they are not field we
should just ignore it.
opw-702852
If website_sale_delivery is installed, when we choose same invoice
address as shipping or another one, a new set of country/state are
displayed.
It is done since if we are using the invoicing address as shipping, the
address must be in the allowed shipping countries and states.
This was solved for some instances with 164b8ed01a but failed in other
instances.
With this fix the two state select tags have references to their own
options which allow us to have it alright for the several possibilities.
opw-693127
In the report "Leaves by Department", the start/end dates of the
holidays are computed based on the UTC datetime stored in the database.
This makes the report inconsistent with what is displayed in the
interface.
opw-702202
For first comments on a product in the ecommerce we would not
have the star rating displayed till a page refresh, and the star widget
would not be reset after posting.
Also in other situations, we would get a 0 star widget when posting
comment without rating, but after a refresh the widget would dispappear.
With this change the new comment get the same stars as when refreshed.
opw-702608
The product quantity in Orders Analysis must be expressed in the uom
of the product like in the Sales Analysis. In a POS order line, the uom
is always expressed in the uom of the product.
Closes#14599
opw:696927
The where_clause needed a "AND" to work.
The where_clause didn't contain allias for "account_move_line" so when
injecting a condition with "account_move_line" it crashed.
opw:702538
The field `purchase_count` is described as '# Purchases' (which is an
integer), so the user should expect the number of POs associated to the
product, not the quantity ordered as it is the case before this commit.
opw-697815
In ff56304f58 a solution was tried to have message posted from
backend livechat linkified for visitor in frontend. This was
forward-ported when it should not have been and introduced issues
including:
- `href="{link}"` would become `href="<a href="{link}">{link}</a>"`
- if html entities such as the ones for U+00A0, and entities <, >,
', " or ` were next to the link, the entity would be linkified
too (up to the ;)
This happen because utils.linkify function is to be used with text
content and not html which was the case in this instance.
opw-693457
opw-702410
This reverts commit 1c60a631df.
The fix was done to conciliate 83956d4 and ff56304f5 but ff56304f5 was
forward-ported erroneously and introduced other issues.
opw-702410
When the user clicks on "Run Reordering Rules", it might create
procurements. However, the cron "Run mrp scheduler" will also create
procurements and might already be running in the background. Therefore,
we need to make sure that both actions don't run concurrently.
Note that the same check is done for the wizard "Run Schedulers".
opw-695607
The field resource_type in mrp.workcenter tree view must be invisible because
this field was not available in the form view before f9f4bba
Adding resource_type in the form view had no business case.
opw:698183
Haresh Shyara