New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Master event sale ticket name sht #24772
Conversation
54f8061
to
b138cd5
Compare
addons/sale/models/sale.py
Outdated
@@ -1265,3 +1262,9 @@ def _onchange_discount(self): | |||
discount = (new_list_price - price) / new_list_price * 100 | |||
if discount > 0: | |||
self.discount = discount | |||
|
|||
def _get_default_name_based_on_product(self, product): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need a method on sale order line for event because the descriptio we need to generate needs not only information from the product but fields from the sale order itself.
addons/product/models/product.py
Outdated
@@ -563,6 +562,14 @@ def get_empty_list_help(self, help): | |||
) | |||
return super(ProductProduct, self).get_empty_list_help(help) | |||
|
|||
def get_default_name_for_sale_order(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
get_product_multiline_description()
addons/event_sale/models/event.py
Outdated
@@ -160,6 +161,36 @@ def _constrains_event(self): | |||
def _onchange_product_id(self): | |||
self.price = self.product_id.list_price or 0 | |||
|
|||
def get_default_name_for_sale_order(self): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
get_ticket_multiline_description()
# we call this to force update the default name | ||
self.product_id_change() | ||
|
||
def _get_default_name_based_on_product(self, product): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
get_sale_order_line_multiline_description(product)
d614b5c
to
25c1255
Compare
…erLine, based on its product I added the method because the code to compute the name was duplicated in several places. This will make it more consistent. Moreover this gives the option for modules to override the method to define a custom name as necessary.
…e based on an EventTicket The description will be the same whether the sale order comes from the front end or the back end. It takes into account the customer language. The default description will be computed as follow: 1. the first line is either the event name (if exists) or the product name (if exists) 2. then the ticket name 3. then (if exists) the product name only if different than the event name (avoid duplicate) 4. and finally the product description_sale (if exists) This makes the default name consitent with what is done for the standard products while adding the info from the event/ticket and also avoiding duplicate info.
…m the sale order line of a ticket The goal of this change is to prevent inconsistent states. The selected ticket must belong to the selected event, the event must be linked to the product, ... Moreover we don't want a user to create a ticket or an event from this view because some fields or relations would not be set correctly from here.
We previously added new constraints to prevent inconsistent states. The selected ticket must belong to the selected event, the event must be linked to the product, ... This change will fix the test to work with those new constraints.
We reviewed my task with AL and found that some things where not very clear at first glance. This commit attempts to improve the method names and the comments.
We reviewed this task with AL and decided to remove these constrains because: - they will be called for every sale order line, even though only very few of them actually have tickets - they only prevent a behaviour that is not possible by using the interface normally
It was possible to select a ticket related to a product before an event was selected. This is typically the case for tickets defined in an event_type but not in an event. The ticket field is now hidden until both the product and the event have been selected. This way we are sure the selected ticket will belong to an event and not an event_type. We also improve here the comments of the related onchange methods.
To compute the ticket multiline description we decided to ignore entirely the product name and the product description_sale because they are considered to be replaced by the ticket name and event name. -> The workflow of creating a new event also does not lead to filling them correctly, as the product is created through the event interface
… name The standard behaviour was to show product name in several places instead of the sale order line description. However, for event tickets, we don't want to show the product name, but the ticket name and event name instead.
The description of the sale order line was displayed on a single line (\n were ignored). It should be displayed over multiple lines. This is now fixed.
We don't want the user to be able to select a ticket belonging to the wrong event.
The ticket name was missing from the registration confirmation page (shown when the ticket is free and/or the user paid with a direct method). This is now fixed.
25c1255
to
2d1a008
Compare
new pr #25819 |
Link to the task: https://www.odoo.com/web?debug#id=1837987&action=333&active_id=1251&model=project.task&view_type=form&menu_id=4720
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr