set product_product_16 and product_product_24 (computer case and graphic card)
invoice policy to 'order' instead of 'delivery'.
They are among the first displayed when filling the field and it's more
convenient to have them with 'order' invoice policy when doing a demo run.
As portal features are now managed using website this commit removes last
chunks of code (python, views, security tules) still remaining. Those were
probably forgotten when moving portal to website.
* [MOV] sale and invoice portal related code from portal_sale to
website_portal_sale. Security rules and website related stuff should
indeed be located in website_portal_sale.
* [MOV] sale and invoice standard code to sale and account. Adding customer
as follower is a standard feature for sale orders and invoices.
* [IMP] website_portal_sale does not depend from portal_sale anymore but sale
and other portal / website addons
This code seems to add recipients of an email to the sale order followers.
However currently the custome of a sale order is already automatically
added in the followers. Adding other recipients should not be
something completely custom in sale order, moreover by overriding
mail_mail methods.
People should add followers when necessary and should avoid adding
too many people automatically. When you send an email to other people
than the customer those will be added as followers when replying.
When the quotation is sent by email it is still in draft state. However right
after sending it will move to sent state. This state allows the customer to see
it in its website portal. Let us then use a convenient context key used when
sending quotations by email to force the use of website address for quotation
link contained in the email.
_rec_name in mass mailing is source_id which is an integer, it does not accept
a char value.
Instead specify the `name` value, which will create a utm.source.
Closes#13765
Move the code to manage the case of 'adding an attribute with only one value
should not recreate product' before to select the existing variants.
Before this commit,
When you create 1 new product.template, it create 1 variant.
When you add an attribute with only one value, it update the existing and
create a duplicate variant.
After this commit,
Only the existing variant is updated, and there are no more duplicated variant.
The fix:
We update the variant if only one value before to select the existing variant.
Thus, the updated variant is compared with the matrix and not duplicated.
This commit closes#13757
when extending these methods with the new api, the context is a frozendict
so we need to copy before mutating.
this patch was made by searching for key addition to context and calls to the
update() method on the 8.0 addons, and checking if a copy was made before in
the method.
Before the migration to the new API of this code, the context was
not propagated to the update_notification call.
This is now the case, which is unfortunate since the context of the
cron action has an 'active_test'=False key, which causes the ping
to count user differently when the cron is triggered from the form
view.
This commit adds explicit ('active','=',True) domain to ensure we
only count active users when pinging.
Using the read method should generally pass a single id as a list
due to the new API inheritance of the read method. If an attempt
is made to use the new API, the result is inconsistent.
Following 4f0ca6d9Closes#13678
The validation_date was using the creation_date value in the follwing scenario:
1. create a new order with a few lines (creation_date=t1)
2. reload the page, `init_from_JSON` uses validation_date=t1
3. validate the order at t2, ignored due to already stored value
creation_date must be kept for tracablity reasons (e.g. pos_blackbox_be)
Fixes https://www.odoo.com/groups/59/20542134
The field in stock configuration group_stock_adv_location is toggling
the group "stock.group_adv_location". There was a typo which was using
on the form view of purchase.requisition the group
"stock.group_stock_adv_location" instead.
opw-690804
keyur gajjar