[IMP][account] The option of periods_special should be handle by cont…

[FIX] Journal Entry Lines must use today's date than move.date

[IMP][stock]Fixed transfer when product is twice in picking

[FIX] account_asset: period_id field

Goffin Simon authored Mar 16, 2016 and Luis Ernesto Torres Macías committed Mar 18, 2016

The field period_id didn't exist in model "account.asset.asset"

Closes: #11262

opw:671494

It is not allowed to recompute the depreciations when the asset
is confirmed.

opw:672203

The field period_id didn't exist in model "account.asset.asset"

Closes: #11262

opw:671494

When computing the balance, debit and/or credit, the opening period must
be filtered out. Otherwise, the invoices which are still opened at the
time of the period closing will be counted twice.

opw-670584

When transfering the pack, the priority to the moves in state "assigned"
or partially_available(=true) must be given.

Used case (steps):

-set warehouse with three steps to delivery
-create one product A with qty on hand 10
-create sale order with first line product A by qty 2 and the second line with product A with qty 10
-confirm sale order
-check availability
-transfer pick by qty 10
-transfer pack by qty 10

The pack couldn't be transered

Now the pack is transfered.

Closes: #10764

opw:668682

As its documentation notes[0], Jinja2 only processes unicode template
data (or pure ASCII, which will implicitly decode to unicode).

The scaffolding system would read raw scaffolding data in memory (both
templates and passthrough non-templates), but fail to decode templates
before handing them to Jinja, blowing rendering up if templates
contained non-ascii.

Fix #11331 by always decoding templates from UTF8 before handing them
to jinja. This is backwards-compatible, ascii templates work as they
used to, non-ascii UTF8 templates now work correctly, non-ascii
non-UTF8 templates what are you doing?

[0] http://jinja.pocoo.org/docs/dev/api/#unicode

This reverts commit b955bac1.
The previous behavior was the correct one. However, accounting entries
are missing.

opw-671311

This is equivalent to revisions
- 000ce6a6
- 48ccb199

Before patch (screenshot from runbot):

![](https://cloud.githubusercontent.com/assets/973709/13699411/6fc781b2-e77a-11e5-92fe-1e181f9e6b7f.png)

After patch:

![](https://cloud.githubusercontent.com/assets/973709/13699410/6fc774a6-e77a-11e5-83ab-dd31ccb1c4df.png)

Remove logging unecessary information. While this info is not persistent or
transmited, there is no reason to log it in developper console.

missing and unnecessary terms

When using the left/riht arrow to switch of record
in a form view,
the rendering of the `char_domain` widget was done too
early, before all fields are ready / set, and if the
domain of the previous record could not be applied
on the current record, it leaded to a traceback.

This revision introduce a new deffered,
because I coudln't find one that was doing
what I was looking for:
 - `is_initialized` is a defferred which is
 resolved when the form view has finished
 its rendering for the first time
 - `reload_mutex` is a mutex used only when reloading or
 switch to left/right record.

While the one needed in this case is a deferred
which is resolved when the record has finished
being rendered, wether when its when coming
from the list view to the form view (and it's
not the first time the form view is loaded,
e.g. list view -> form view -> list view -> form view, another record),
or on the switch of left/right record.

opw-671594

Before this patch, the challenges with an end date in the future were closed at
the first cron run.

opw-669995

When a "Drop Shipping" route is used on a product, the origin document
is duplicated on the PO created. This is because in this case,
po_rec.origin and procurement.origin are the same.

opw-671039

Introduced by eefc76fd
Only the supplier taxes of the company set in the procurement
must be set in the PO.

Backport from f5989bc3

opw:671449

When creating work center, a resource.resource record is created.
Then a member of group_mrp_manager is allowed to create resource.resource record.

opw:671218

Edge >=12 throws an error (code 800a025e) when calling the select()
method on an input element that is not currently part of document and
has a non-empty value.

When adding a paymentline a "change:selected_paymentline" event gets
triggered which in turn triggers the focus_selected_line function before
the actual paymentline gets rendered.

opw-671426

[8.0][FIX] Odoo issue:10783, Vauxoo task id:4921, Vauxoo issue id:1387

To reproduce the bug:

- Create a partner.
- Set it state "Alaska".
- Country becomes "United States".
- Set a country for YourCompany, such as Spain.
- Create a partner.
- Set it state "Alaska".
- Country remains blank.

Also, `node.xpath("//field")` was running over every `<field>` in the
view, not just those inside the `<div class="address_format">`. Now it
only traverses the right nodes, which renders every affected view
faster.

When assigning landed costs to products that have already left the
stock, the expense account is used instead of the stock input account.

opw-671311

When duplicating an account voucher, the period was duplicated even if
the Bill Date didn't match with it.

opw:669850

The ir.actions.todo record base.open_menu is used to redirect the user
to a menu after installing a module.

To do so, a new module override the record changing its action (toward a
menu) and setting its state to "open".

But with f7fe753d when one such changed action is removed after
uninstalling a module (or removing the action by any other way) the
base.open_menu would also be removed. Thus thereafter the open_menu will
not work anymore (since type "automatic" is lost).

With this commit, when whenever base.open_menu is removed, instead its
action will be replaced by base.action_client_base_menu which is the
original action.

closes #11224
related to: #11216, opw-660269

When creating thousands of production lots in batch, the
extra call to write() cuts performance in 2, and can be
replaced by an appropriate context when calling super(),
as all the default values are computed correctly.

The only case that could possibly fail is when the product_id
is not passed to the create() call but comes instead from
defaut values (ir.values).
This case is very rare and considered a manual exception
where the expiry dates can be input manually.

[FIX] report, website_report: barcode widget

Denis Ledoux authored Jan 26, 2016 and Luis Ernesto Torres Macías committed Mar 03, 2016

Up to this revision, barcodes set in reports are generated
using the controller `/report/barcode`,
using a `img` HTML tag, e.g. (from `report_location_barcode`)
```
<img t-if="not o.loc_barcode"
     t-att-src="'/report/barcode/?type=%s&amp;value=%s&amp;width=%s&amp;height=%s'
     % ('Code128', o.name, 600, 100)" style="width:300px;height:50px"/>
``

This `/report/barcode` route is set as `auth='user'`, meaning
the route can only be accessed by signed in users.

When wkhtmltopdf prints a report containing such a barcode,
it calls this `report/barcode` route, making sure to pass
the request session in the cookies, so wkhtmltopdf
uses the same session than the one of the user. This is
needed, as only users can access this `report/barcode/` route.

This session is passed in `report.py`, in the method
`_run_wkhtmltopdf`, thanks to the --cookie wkhtmltopdf
parameter.

Nevertheless, if a report is printed through the website
front-end, as public (without a signed in user), the request
session is not associated to a signed in user, and therefore
the route `/report/barcode` refuses the access / redirects
to the login, making it impossible to print a report
containing a barcode without being signed in. This even
if the report is printed as `sudo` through a controller
(as this is the session of the not signed in user which is passed,
not a session associated to `sudo).

Fixes #10621
opw-667797

Closes #9367
Fixes #11180

when using a journal with 'Group Invoice Lines'
and issuing an invoice with foreign currency with more than 1 line
(of the same product, or no product),
the amount currency in the journal item
associated to the merged invoice lines was wrong.

It took into account the `amount_currency` of the first line only,
ignoring the `amount_currency` of the remaining merged lines.

opw-670972
Closes #10375