If a user signs in, and as a previous unfinished
order, it loads it only if the pricelist set on this
sale order is amongs the available pricelists.
Otherwise, he could benefit of prices that
are no longer available.
If a user signed in, the pricelist must be,
in this very specific order:
- the pricelist of its saved cart
except if the cart is no longer valid
(pricelist no longer available or
order no longer draft),
- or, the user specific pricelist,
in other words, the pricelist set by an employee
for this specific customer, if any,
- or, the public user pricelist, if it is available
in the user geolocalization
- or, the first pricelist available
In addition, if the user firstly browses the shop
without being signed in, and then signs it, the pricelist
loaded after the sign in must be the user specific pricelist,
if any, and not the default website pricelist (the public
user pricelist or the first pricelist available)
opw-666620
This revision reverts e5b9f02f7a
The argument `website_pl` must always be the default website
pricelist (the public user pricelist), as stated in this
method documentation:
```
:param int website_pl: The default pricelist used on this website
```
So the difference between the public user pricelist
and a specific user pricelist can be made.
A special pricelist set for a specific customer must
always be amongs the available pricelists.
opw-666620
In a survey question of type `matrix`,
nothing prevents to remove a row from the matrix,
even if there are already answers for this line.
If the case happens, the row is deleted, but
not the answers. The answers are therefore orphan.
The answers should probably be deleted when the
row is removed from the survey, but this is a risky
change, and, even, users might want to keep track
of the answers given even if the line doesn't exist
anymore in the survey.
Therefore, we just handle the case when displaying
the survey results,
we ignore matrix answers for which the row no longer
exists.
opw-666393
During the construction a xml/html_translate content, in case of a wrongly
translated part (e.g. not correctly escaped char or bad xml tag), escape the
translation.
The verification is done during the rendering on the view which is not the most
optimal solution but has the advantage of working on system with some broken
translations and does not requires to reload the translations.
In master version, the verification could be done when loading the .po files.
Suggested alternative descriptions spill out of the boxes if the
description is too long.
PS: same fix as in saas-6 with f7110b46be.
This fix doesn't have to be forwrad ported.
opw:667343
The write-off currency should be the currency of the first
account.move.line, since it is what is assumed in the interface.
Moreover, the sign of amount_currency should match the constrain
_check_currency_amount.
opw-667137
The Purchase module provides a functionality to add pre-filled invoice
lines to an invoice. The issue is that extensions of the accounting
modules might add fields on an invoice line, and one would like to see
these fields populated as well.
This is the case for account_asset, which adds an asset_category_id on
an invoice line. However, the Purchase module is not aware of the fields
added by account_asset, and therefore it cannot populate them.
This fix adds a method, _auto_fill_extra, which is intended to manage
these extra fields.
opw-667162
When writing several times on the same record in the same transaction,
the orm raise a Missing error because the rowcount only gives one
difference.
opw:666470
The `stock.picking`.`state` field is set
to track the change of values
(`track_visibility='onchange'`)
It's supposed to write the state changes
within the picking thread.
It does not work properly for function fields,
as the onchange tracking is designed to work
only with direct user changes, direct
`write` operations on the record, while,
here, the state value changes according to the
picking moves changes, for instance.
To solve this, the tracking changes have to be
hooked within the `create` & `write` methods
of the model on which this function depends on.
Therefore, from now, when changes are
performed in the moves, on the fields that
could lead to the picking state change, we
force the tracking of the picking state.
In addition, we had the `mail_notrack` key
in the context when creating back orders,
to avoid displaying the back and forths
in the state
e.g. when transferring 9 units on 10, the
changes were displayed as below:
Draft -> Waiting availability
Waiting Availability -> Ready to Transfer
Ready to Transfer -> Draft
Draft -> Partially available
Partially Available -> Waiting availability
Waiting Availability -> Transferred
opw-666317
sometimes, the web client receives unsubscribe notification and an extra
notification on that channel. This is then followed by an attempt to
rejoin the channel that we just left. This commit prevents that
situation to occur.
For that, it needs to know the notifications received by the bus in one
batch, not one at a time.
The mail template rendering system use "autoescape" for subject, body,
email_to, ...
Using autoescape is good for the body, but for the subject it means
variables insertions have to be marked as safe.
This commit add another environment without autoescaping enabled for the
subject field.
From https://tools.ietf.org/html/rfc2822:
The "Subject:" and "Comments:" fields are unstructured fields as defined
in section 2.2.1, and therefore may contain text or folding white space.
2.2.1. Unstructured Header Field Bodies
Some field bodies in this standard are defined simply as "unstructured"
(which is specified below as any US-ASCII characters, except for CR and
LF) with no further restrictions.
closes#10547
opw-659231
opw-666801
opw-665863
In most backend views using CTRL+P to use browser printing would only
print an header without the content.
stumbled-uppon-when-checking: opw-659430 opw-660763
Denis Ledoux