This project has moved. For the latest updates, please go here.

2.5 Release

Jun 19, 2015 at 10:27 PM
Edited Jun 19, 2015 at 10:27 PM
Do you have a projected release date for 2.5? It looks like there are some significant changes. I will need to make a number of changes to fit my clients needs and don't want to have to do everything twice.
Jun 19, 2015 at 10:46 PM
The beta is due June 30th, with a final release on July 30th.

The next two releases are mapped out on GitHub. See the milestones page for dates. There is also a longer-range roadmap on the GitHub wiki here. If you have the extension installed, you can also view the burn down and task boards. Now that the core back-end re-write is done, I don't expect any more significant delays in release dates. The project is running along an agile cadence now. Any future slowdown in project velocity will result in a smaller release with fewer features, but should not result in any significant delay in release dates.
Jul 2, 2015 at 11:10 PM
Thanks. Can't wait that long.
I'm not really a .Net guy but am doing what is needed for my client.
Only agents will have access to the application. Most tickets will be created from outside the system using data from an insurance tracking system I wrote and will hopefully be rewriting. At this point in my development, I have a VB script that will generate the tickets, create any need users, and add appropriate comments. This all happens outside of the TD and seems to be working.
The next piece is to send out notifications when these tickets are created. I'd like to use TD functionality to do this if possible but like I said I'm not really a .Net guy and haven't figured out how to do this.
Jul 3, 2015 at 8:59 AM
If you are running TicketDesk 2.1, and want to keep all your customizations outside of Ticketdesk, then your best bet to send email would be to directly write to the Ticket Event Notifiactions table. The TicketDesk web application monitors this table on a timer, and when it sees an entry that is ready for delivery it then generates the email content and sends the message. All you have to do is fill in the fields telling it what ticket, what ticket event, and to whom the message should be send. There should be one entry per user that will be notified. If you want to send broadcast notifications, make sure you set the NotifyUserReason to "HelpDesk".

This will not be so easy in TD 2.5 though. Email delivery there are handled by a completely isolated sub-system. Like TD 2.1, TD 2.5 uses views to generate the HTML email content, but the new push notification delivery sub-system is designed to be completely independent (no web dependencies, and no direct awareness of the calling application's data or business domains). So in TD 2.5, the caller (the web app) will generate the content for the email message up-front, then passes it to the push notification system when it schedules the message for delivery.

To get TD 2.5 to deliver messages created entirely outside of the TicketDesk web application itself, you'd need to populate the push notification tables AND include the generated (and serialized) message content as well. This would not be trivia from an entirely external application.

It would be easier to just add a custom controller to the web application that lets external applications create a new ticket by just doing an HTTP POST with the necessary data. The code for it would be very similar to the TicketController's New action method, but some attention would need to be spent on how you create new user accounts, and making sure that the creation process is executed within the context of the new user (you'd need to supply a custom SecurityProvider and pass it to the TdDomainContext). Not trivial still, but the up-side is that TicketDesk would create the ticket exactly the same way it does when you use the UI form, including enforcing the same business rules, creating the push notifications, etc.

If you are planning to use TD 2.5, let me know and I'll prototype up management controllers that would let external callers create tickets and users. In a few releases, TD will be getting a full set of REST APIs, but having a few external APIs sooner isn't a bad idea, at least for some of the more common operations like creating new tickets.
Jul 3, 2015 at 2:30 PM

Thanks for the prompt reply. Since I need to have the initial version ready to go live by Aug. 1, I am using 2.1. I suspected that the notification table was the key. Sounds like what you suggest will work. Where in the application will I find the notification process in case I need to tweak that process?

Jul 3, 2015 at 6:27 PM

I will need to create custom body content for my generated tickets.

Here is what I am considering doing. I will create a new table, EmailTemplates, that will hold templates (plain text only) which I will manually create for now. The templates will look something like the sample below. I will add a column, TemplateID, to the Notifications table to indicate the template to use for the email. If it is null, the normal email body will be created. If not null, I will generate the body using the template.

Does this sound feasible?

**** Sample Template ****

Note: CertificateID is a custom column I added to the ticket table


The ACCORD form <<CertificateID>> has been selected for an audit by The City of xxxxxx. You are required to provide documentation in the form of policies to support this Certificate of Insurance.

For detailed instructions please visit use the link below or call 999 999-9999.

Instructions :<< CertificateID>>.

Thank You,

City of XXXXXXX – Risk Management Department

Jul 3, 2015 at 9:28 PM

I was able to do it a little simpler by making a change to EmailTemplateController and my script to create the initial ticket comment. My two custom tickets have are given custom CommentEvents. I also put the appropriate body content into the Comment and use that for the body of the email. Seems to be working but don’t have a SMTP set up yet to confirm.

var commentEvent = notification.TicketComment.CommentEvent;

if (commentEvent.Equals("created the audit ticket") || commentEvent.Equals("created the expiring certificate ticket" )


return notification.TicketComment.Comment;




… existing code


Jul 3, 2015 at 9:52 PM
Sounds like an adventure. Oddly, since you are generating the body content entirely, this would be easier to do in TD 2.5; but you seem to have it mostly worked out in 2.1. If you need to modify the actual sending routines, you'll find them in the domain class library under services. There is a queuing service class and a sending service class that do the actual mail management. Looks like you already have a handle on the content generation and templates part.

For local SMTP testing, I highly recommend Antix SMTP Imposter. Super-useful and tiny little utility for testing apps that want to send email, but without any risk of actually sending emails to real people by mistake.
Jul 3, 2015 at 10:43 PM

Thanks. I appreciate the SMTP recommendation. That is always a problem.

I think I’m in a pretty good place right now for what I need to accomplish in this phase. I’ll let you know how it works out.

You help is greatly appreciated.

Jul 3, 2015 at 10:50 PM
Any time :)

This kind of feedback helps me see how people are using the system, and gives me a better understanding of what capabilities I need to add to future versions.
Jul 3, 2015 at 11:18 PM

I appreciate having what seems to be a well written framework to work with. When I’m a little more knowledgeable about how it works, I’ll offer my $.02 worth on possible improvements based on my experience as a consultant.

FYI – I’m integrating it with TeamViewer and SnapChat to try and create a semi-complete support system. Not sure if it will all work but my client loves the concept and I’m excited about making it happen.

Jul 8, 2015 at 5:01 PM

Looks like I have it working to fit their needs. I’m sure I’m doing things it was never intended to handle but it’s working. Here are the core changes.

There are two monthly scheduled process that use VBscripts to add Tickets, Comments and Notification records to the database. The submitter (a user in the system being supported ) is created in the user and membership tables with no actual access to the system.

When the notifications are created emails with custom content is sent to the “submitter” notifying them of the actions required. The tickets will then be used to track the actions until they can be closed.

Jul 9, 2015 at 6:02 AM
It sounds like a fascinating project. I'm glad you got it all worked out. I don't see anything fundamentally wrong with how you went about achieving the working product you needed. Handling most of the work entirely outside the core system has some significant advantages over customizing the core system itself.
Jul 10, 2015 at 10:01 PM


We’d like to restrict which Comments trigger notifications begin sent out. Where would we make the change to only send out certain CommetEvents. For example, not send for assignment changes but do send for "has requested more information".

Is there a setting for that or do I have to modify the code.

Jul 11, 2015 at 8:44 AM
For that you would have to modify the code.

Each activity provides an opportunity for the user to supply comments (some require comments, many don't). If you wanted to suppress messages for some of those activities, then you should consider only suppressing the messages if the comment is also empty.

I'm still expanding the capabilities of the notification system in TD 2.5, so I'll keep this idea in mind. I just don't know if the additional complexity would be useful to enough organizations to justify adding per-activity behavior settings... especially considering that notifications in 2.5 can have multiple delivery channels as well. Having per activity settings on a per delivery channel basis seems a bit complex, then you add to it that users will have individual settings that override system defaults too.
Jul 13, 2015 at 7:22 PM

It gets more and more complex doesn’t it.

Where in the code should I look to suppress certain activities ( for example take over )?

Jul 14, 2015 at 4:52 AM
I think the best place in 2.1 to make the change would be in TicketService.cs. The GetActivityComment method is also responsible for calling to the notification system to queue the new message --on or around line 947 it calls AddTicketEventNotifications on the Notification service.

In the GetActivityComment method, you have access to the TicketActivity enumeration, which tells you what event you are dealing with... so just a simple "if not activity I deem unworthy, then sent notification".

Something like this:
if(activity != TicketActivity.TakeOver && activity != TicketActivity.TakeOverWithPriority)
     Notification.AddTicketEventNotifications(c, isNewOrGiveUp, notificationSubscribers);
Jul 17, 2015 at 5:00 PM

Thanks. I’ll give it a shot.

Jul 22, 2015 at 5:46 PM

I thought you might find this of interest. I wonder if you are including this functionality in 2.5.