When a user tries to add a product on an opportunity, the date_order of the
order is added into the context. This value can be False.
When "_compute_price_rule" is called without "date" arguments
(some onchange, compute...) the method method use the context date (in this
case the value is False) or the today date.
The date value is used in an sql request and raise a value exception.
opw-751700
- Use the form builder to send an email
- Customize the snippet to include the subject and the body
- Send a mail
=> The subject is not included in the email
This is because the subject is filtered out and considered as a
blacklisted field.
It happens because `mail.mail` inherits from `mail.message`. The field
property `website_form_blacklisted` is set to:
- `True` for `mail.mail`
- `False` for `mail.message`
Since we go through all inherited models, the property on `mail.mail` is
overriden by the property on `mail.message`.
It is actually not necessary to go through all inherited models, since
in the case of `inherits`, we copy the fields of the inherited model to
the target model. The check is simplified by only checking the fields of
the current model.
Based on work of @nla-odoo
opw-748926
The old release of wkhtmltopdf are no longer published on the download page.
The developer explicitely asks to use the github link
cf: wkhtmltopdf/wkhtmltopdf#3524
wkhtmltopdf/wkhtmltopdf#3521
wkhtmltopdf/wkhtmltopdf#3518
wkhtmltopdf/wkhtmltopdf#3508
Closes#18146
- use datas of all lines, and not only the last lines.
- removed useless 'move_id' field from account.move.line
Was PR #18175. Courtesy of Sylvain Legal
If a user chooses a product that has a blocking error message, the product
is set to False. This is good, but we do not want the following to happen:
The other onchange triggers are called and "product_uom_change"
generates an error because there is no product. (In fact it is
"_compute_price_rule" on "product.pricelist" who raise)
The onchange update the values of the other fields related to the
product (eg for the "name" field where the name of the product that
is canceled by the warning is assigned).
Steps to reproduce the bug:
-Create a tax group TX with two taxes: 15% and 5%
-Create a SO with one line and set TX on it
-Print the SO
Bug:
Only the first tax of TX was taking into account
opw:748923
Before this commit, having an option on a product, the modal had every prices set to the one of the option
This was brought about by commit c8a434306f which was designed for the pricelists and striked prices
After this commit, we keep the intended behavior for pricelists while controlling that options would not mess up the modal
The prices that are displayed are the right ones.
OPW 744943
GH-17342
[FIX] website_sale, website_sale_options:fix the modal of options
Before this commit, the add quantity button were not working at all
This commit corrects the behavior by browsing the dom for anything that looks like a product section
Closes#17353
`parent_id` fields are common in many models, and thus default values
for those fields are sometimes passed in the context.
Because mail.message also has `parent_id` field, it would automatically
use the default when an automatic message was being posted. While of
course, the parent_id value comes from a different model.
This "adoption" by a random "parent message" is unexpected,
not desired, and it can even cause a very surprising AccessError if the
parent message is not readable by the user.
Forcing the `parent_id` value during the creation of an automatic message
avoids this confusion.
One way to trigger the bug was to use the "subtask" stat button to create a
child subtask for a project task (it relies on the parent task ID
passed in the context)
From Pillow 4.2, it is forbidden to save RGBA images as JPEG
( https://github.com/python-pillow/Pillow/commit/e4d6223c944cf44c468cc65a560b94dfcf351a62 )
A crash was occurring when loading demo JPGs as
image_resize_and_sharpen() was silently changing image mode to RGBA.
Now we ensure that we return the original image mode.
We also avoid crashes when converting from PNG to JPG
When xlsx is used, the worksheet name may be longer than 31 chars and
raise an exception.
This fix will troncate the name up to 31 chars and will remove invalid
chars.
Similar patch was already done at 0122c05eff for xlwt
xlsxwriter 0.9.8 has added a parameter worksheet_class=None so adding **kw to be
compatible with installs with the latest version (requirements.txt asks for
version 0.9.3)
Closes#18077
opw-751157
It is for example useful in the form builder with date-kind form field,
the translation of momentjs is done in french.
opw-707986
opw-749544
closes#17103
The wizard to change the produced quantity of a manufacturing order was not
using the current produced quantity as the default value.
This was because the field mo_id was not present in the view (and not in
`fields` in default_get).
Adding the field as invisible to compute the default value for mo_id.
Correct typo in dictory lookup (using `[` instead of `(`)
Closes#17937
opw-749725
Steps to reproduce the bug:
-Create a product tracked by LN
-Create an inventory adjustment to add 10 products with LN A
-Validate it
-Then go in inventory > inventory control > lots/serial numbers > open LN A
-Change the product
Bug:
The LN A tells you you have 10 products X
While in your inventory you see you have 10 products Y
opw:750735
When sorting by price (increasing or decreasing) in the shop,
the products were sorted according to the catalog price(list_price)
and not according to the price(which takes the pricelist into account).
So a better name is given in this patch.
Reason: The field "price" is a computed and not stored field.
Then it's not possible to order the products with it in the orm.
opw:750997
web_editor can be installed without website, thus missing needed CSS
causing e.g the widget sidebar to overlay and hide the mass mailing
content if website is not installed.
This fix implement a simple middle ugly solutions, but doing something
more in stable would be an hassle (for example in 88c2b684 the #wrapwrap
CSS is included in report module).
opw-748975
closes#18005
opw-750892
Avoid to rewrite the `accounts_code_digits` on the company if the value is the same. As all the values are
passed on the res.config creation, the related fields are rewriten on each res_config creation. Rewriting
the `account_code_digits` on the company will trigger a write on all the account.account to complete the
code the missing characters to complete the desired number of digit, leading to a sql_constraint.
The route /shop and /shop/product did not used the same context.
The partner is set in the shop but not in the product page which may lead to a
different pricelist to be applied.
opw-746729
Rev. 8245c1d1d8 introduced a timeout to
avoid lockup situations with wkhtmltopdf's requests on servers with low
numbers of free HTTP workers.
The initial timeout of 500ms was chosen based on average network
latency, but turned out to cause spurious disconnections on congested
networks combined with slow links.
Bumping up the timeout to 2s seems to be a better sweet spot, causing
less spurious disconnections while still recovering reasonably fast from
the wkhtmltopdf lockup situation.
See also these discussions:
- https://github.com/odoo/odoo/commit/8245c1d1d87b443701b161d8d4a42df2b4d13aec#commitcomment-22904347
- PR #12356
- Issue #2114Closes#17998
When opening the reconciliation widget, there are two queries that are done,
The first one is to find a move line that perfectly match the statement line
and is done in SQL for performance issue.
The second one is a search with a domain to find all the lines that could be used
in that reconciliation.
1) There was a mismatch between the two. The domain fetches lines that have a payment_id
while the SQL query does not. Which is inconsistent
2) In some case, we did not find a perfect match on the amount using the SQL query because
of a rounding error. Example is for amount 3,3. In python: 3,3 is represented like this
3,3000000000003 and doing a float_round of that value still returns 3,3000000000003
Since we want to match on an exact amount, using float_repr is needed to fix that error
The old code don't resize correctly if you use params in request.
because if '200' > 500 => return True
Now we force the casting to int to be sure to compare apple to apple.
before: /web/image/<id>?height=100 => don't return an image with height=100px
after: /web/image/<id>?height=100 => return now an image with height=100px
Christophe Matthieu