Cluster related message templates

[lorenzocaum]

Summary The messages system is flexible but a new event organizer may have trouble understanding where to make a change that they want. Once they get past that small learning curve, then they "get it" but initially, it can be confusing.

In looking at the list on a few different sites, I think we could make a small improvement by clustering related message templates. For example, cluster by alphabetical and then by type on creation:

• Registration related
• Ticketing related
• Payments related

Other notes

A common pain point related to this is where do I change the ticket template. It appears on page 2 because of the default pagination limit so I've created another issue for that:

https://github.com/eventespresso/event-espresso-core/issues/723

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[joshfeck]

This needs planning before it can be assigned to a developer.

[joshfeck]

There was a similar ticket in https://events.codebasehq.com/projects/event-espresso/tickets/7747 that mentioned using filters.

As it stands now, the dropdown filter for Message types shows one option for every message type. So it's essentially filtering the list to one type. Maybe we could change the dropdown so it has fewer options, and they're grouped into 4 main types:

• Payments (Payment related messages, including Refund)
• Registrations (Reg. status-related messages, Reg cancelled, Reg declined, & Batch)
• Tickets (Ticket & Ticket Notice)
• Transactions (Receipt & Invoice)

[nerrad]

The message type filter is setup the way it is because the system allows for message types to be associated with more than one messenger. It's not obvious the flexibility this provides because we effectively only have one messenger anyways (email).

Things get tricky here because currently the filter is dynamically generated from the registered message types (which allows it to automatically pick up new registered message types coming from third-party code, add-ons etc).

In order to do the groupings you are suggesting we'd need to either:

1: hardcode them, and just implement a filter so add-ons, third-party code can register their own message type with a "group". 2: introduce a new property to message types that is for registering them with a "group" or "category". Then the filter can still be dynamically generated and automatically pick up registered message types.

I think number 2 would be the better option here, but it would also be the one taking the most time to implement (although I'm not sure whether it would be significantly more time or not).

With either option, there's also the problem of how the resulting query is generated. So there'd have to be some sort of map of "group->message_type conditions" for the query being generated. This might end up making option 2 the better choice as well because then we could have a group/category strategy for the query generator.

[joshfeck]

I'm inclined to close this since it's a small improvement that would require a lot of additional queries.