Consider seeing this code in a view. It seems a little long, and may be a candidate for refactoring. Lets see how we can make it better.
One way to rewrite this is to make it as short as possible, ie, store all the complexity in a helper function. In my opinion, this isn't really ideal for the following reasons:
Same complexity, new location. The complexity was simply moved from one part to another, instead of broken down into more easily-understandable chunks.
Tight coupling. The method
custom_message_for is too tightly coupled. To test this, you will need to create a mock event, with a mock ticket, with a mock custom message.
I would prefer this to be written as a helper that takes in a string, such as so. The view code may be a little longer, but you get these advantages:
Simple and obvious. The method
format_message is simple and its purpose is immediately obvious.
Understandable at a glance. Glancing at the view code, it's apparent how the message is being derived.
Easy testing. It can be easily tested—just need to pass it a string.
Another way to implement this is with a presenter, which may not be a bad idea either.