When there is a quote template set on a sale order,
the email sent by default is the email
`Sales Order - Send by Email (Online Quote)`,
and this since 5153b2d281.
Therefore, there is no point to override the content of the
email template `Sales Order - Send by Email` to set
the quotation link in the email template, since this is not
this email which is being used for sales order with an
online quotation template.
Nevertheless, the link to the email quotation must be
put in the `Sales Order - Send by Email (Online Quote)`,
so the customer can access his online quotation directly
from the confirmation email, as it was designed and done
in the override of the `Sales Order - Send by Email`.
opw-657060
Displaying these amounts should be done according to what is specified
in the used language. ec29736801
broke this by redefining the format_currency_no_symbol function inside
of the function itself for some unknown reason.
Although we now use round_di instead of round_pr most of the time, there
shouldn't be any change in behavior because the POS manually calculates
the currency.decimals from currency.rounding.
opw-656565
This commit splits the changes which affect the product_id and the
changes which affect the product quantity. The main reason is that a
product change should trigger the recalculation of the price unit,
while a change in the quantity should not trigger product-specific data
recalculation (such as the name or the taxes).
The original issue was the following:
- set a supplier for a product with a minimum quantity larger than 1.0
- create a PO for this supplier and this product: since the minimum
quantity is not met, no tax is set on the line.
- change the quantity to the minimum quantity of the supplier
- the tax is set on the line, but a warning pop up confuses the user by
asking if it is necessary to discard the line since Odoo and the user
changed the same line.
This commit prevents this warning, and moreover it will set the taxes on
the product right away.
Bonus: if you change the product of an existing line, it will not keep
the privious quantity/price values, which was the case before.
opw-656729
This commit introduces the suggestion of a minimum quantity for the
chosen vendor. The minimum quantity is suggested only if the quantity on
the line is zero. It still allows the user to set a quantity smaller
than the minimum quantity for the given vendor.
opw-654300
Before this, setting up the discount on a pos_config was a bit
confusing. Although iface_discount was enabled by default on the
pos_config, the discount button would not show up in the actual POS. The
reason for this is that the discount button only shows up when a
discount product has been set, and there is no default for that.
So in order to make things a bit clearer the following has been done:
- Group discount related options together
- Only show discount product and default percentage field when using discount
- Rename 'Discount percentage' -> 'Default percentage'
- Default iface_discount to False (because a discount_product_id has to
be manually set anyway)
- Make discount_product_id required when discount is enabled
- Only allow discount_product_id candidates that have available_in_pos set,
because the POS frontend only loads those products
When inputting a payment, you can toggle between positive and negative
amounts by pressing the minus key. We use a string representation of
what the user inputs and then parse it to a float to do calculations. So
what can happen is that you can type in an amount of "-" or you can have
a payment of "-2" and do one backspace. Both of these would trigger the
problem because "-" is not a number.
Better message management, linked to the validation feature added in v9
- post a "new post to see" message only when the post is validated
- post a "new post to validate" message when the post has to be validated.
This message is sent only to followers having sufficient karma.
`partner_id` is not the `supplier` of the stock move,
this is the destination address:
`Optional address where goods are to be delivered,
specifically used for allotment`.
The supplier would be a related to the `partner_id`
of the `picking_id`.
Nevertheless, displaying the `supplier` in the `stock.move` list
is not useful. You should use the pickign list for that matter.
opw-656985
Closes#9219
Remove forum creator as follower of the forum. Indeed this means that generally
the website admin will be follower of all posts of this forum. Which is
probably not really necessary.
Indeed portal and public users may have to read internal subtypes to perform some
check in the code. However the rules do not allow them to read those internal
subtypes. We have to read some subtypes as sudo then.
- Deduplicate default website definition
- Remove hardcoded english values
- All active languages enabled in the website by default
- Default website language = default database language
This reverts commit ab303435d3.
Changing a feature one week before freezing a new saas, without review,
without spec, without testing, does not seem to fit the R&D process.
This commit will be set in a branch, tested and reviewed accordingly.
When all the products need to be reserved before doing the picking,
the pack operations were not shown, but still created.
This is not necessary (and did not work as it tried to reserve according to
existing pack operations), as you will need to reserve again when there is
sufficient stock to put the picking in available state and then
the pack operations will be generated and made visible.
When clicking on customize theme button or going on an url which
contains the theme=true option, the theme customization modal failed to
be launched as we did not wait for website to be ready.
The legend of the graph when there was too much items in it could
prevent user to see a part or even the whole graph.
On non-mobile device, move the Pie Chart legend to the right, thus if it
overflows the char is still visible and we can toggle the seen top
legend item.
Otherway, the legend on top is hidden when :
- there is more than 25 legend items and the device has width < 768
- there is more than 50 legend items and the device has 768 <= width < 992
- there is more than 75 legend items and the device has 992 <= width < 1200
- there is more than 100 legend items and the device has 1200 <= width
Since this is based only on the number of legend items but legend items
could have variable name lengths, there will still be edge case where
the legend obstruct the graphical data display.
In this situation the current way to cope with this further filter the
displayed data.
opw-653445
The old api on_change_product_id function in model 'sale.order.option'
doesn't receive the order_id to compute correctly the price unit for
suggested products. The new api _onchange_product_id function has exactly
the same logic as on_change_product_id and this function receives the order_id.
Then the new one can replace the old one. But to keep the compatibility with partners
who overwrite this old function, it is kept in the code.
This bug was introduced by 5047f4e, this commit defined the product_uom_change function
which called on_change_product_id. This commit was applied in saas-6.
The onchange calls in the views have be removed because all the new api onchange are called
even if they were still there.
opw:656494
When a PO is imported, convert the prices in the currency of the
invoice. Moreover, an onchange on the currency will recalculate the
prices if necessary.
opw-656762
The field `product_qty` contains the normalized quantity, while
`product_uom_qty` contains the actual requested quantity in the UoM of
the PO line.
opw-654318
When editing the email template with the wysiwyg,
`Greater than` & `lower than` are automatically escaped
to > & <, screwing up the jinja2 condition.
This change in the condition makes this Jinja2 condition
compatible with the wysiwyg.
opw-654270
The read_group function bypasses some restrictions, and in this case
was counting the "image", "image_small" and "image_medium" attachments
of the products, thus resulting in wrong attachment counts.
I changed it to a search_count which is cleaner, simplifies the code
a lot and, more importantly, returns the right values.
Before this, we would compute taxes based on quantity * price. In
account.tax (used by the POS backend) however taxes are computed on a
rounded (based on currency precision) quantity * price. This would cause
issues as orders in the backend would have a different total price as
calculated in the frontend.
An example that used to trigger the problem:
Order with orderline with product with price of 5, excluded tax of 21%
and a quantity of 0.985. This would cost 5.96 in the frontend and 5.97
in the backend.
Aaron Bohy