Master event sale ticket name sht #24772
Commits on May 29, 2018
-
[IMP] various: added a method to compute a default name for a SaleOrd…
…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.
-
[IMP] event_sale: compute a consistent description for a SaleOrderLin…
…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.
-
[IMP] event_sale: added constraints, on change and no create/edit fro…
…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.
-
[FIX] event_sale: improved tests to take into account new constraints
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.
-
[IMP] various: renamed methods and improved comments
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.
-
[IMP] event_sale: removed constrains for performance
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
-
[IMP] event_sale: improved sale order line view
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.
-
[IMP] event_sale: updated ticket multiline description
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
-
[IMP] website_event_sale: updated views to show ticket name and event…
… 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.
-
[IMP] website_sale: fix line description multiline
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.
-
[IMP] event_sale: reset ticket on event change
We don't want the user to be able to select a ticket belonging to the wrong event.
-
[IMP] website_event_sale: added ticket on confirmation page
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.
