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

adding email input functionality

Mar 18, 2011 at 12:31 AM

I see on the roadmap that you have to add email input functionality. 

That is something I need very soon, so I was thinking about trying to work on that.  But I am completely new to MVC.

Do you have any thoughts/designs for that already?  Are you ok with somebody else doing some work on this (the definition of open source, but I am not sure if there is any etiquette involved in getting started).

you can email if you wish at david.chapuis at aerowebtechnology dot com




Mar 20, 2011 at 5:44 AM

You are welcome to give email ticket submissions a try if you want. 

I've given the feature set some thought, but it isn't as straight forward to achieve as it would seem. The ticket creation from incoming email part itself is fairly simple... just check a pop email box from time to time, copy new messages to the details of a new ticket, and it's done.

The complexity though is in how to handle users when all you have to identify them is an email address (and the from or reply to address isn't even trustable). TicketDesk would need the ability to handle anonymous users (identified only by email address). So there are some decisions to make; how much (if any) of the site can those users users see? What actions can they perform to a ticket? How do you handle promoting them to named users; and how is that going to work in AD vs. SQL security environments?

I have ideas on all of those areas of course; but before tackling email submitted tickets I wanted to implement anonymous users, and security for externally facing ticketdesk instances. That also ties into a lot of the enhancements I've planned for the base security system itself (such as custom groups, and more configurable permissions).

So anyway, if you want to code up something to contribute back to the TicketDesk project there are two ways to go about it. You can download the code, work on it on your own, and submit the finished or near-finished code as a patch via codeplex. If the code is solid, I can merge the patch back into the main branch. The other option is to join the development team (which is just me at the moment) and work against the source code directly. I'm fine with that (no doubt I could use all the help I can get) but we'd need to talk offline about exactly what you plan to code up so we don't end up working against each other. If you want to do that, just message me via codeplex and we can discuss it further. 

Jul 5, 2013 at 10:02 AM
I need this feature as soon as possible.

As show your post
"I've given the feature set some thought, but it isn't as straight forward to achieve as it would seem. The ticket creation from incoming email part itself is fairly simple... just check a pop email box from time to time, copy new messages to the details of a new ticket, and it's done."

will you please elaborate something here for me. we are not bothering about the unknown user. we have created one autonomous uuser id and we will hard code it in such a way that what ever come from email we will generate using that account/id only.

What i have with me is i have email reading service which will give me all the details which necessary to raise new ticket, now my concern his how can i call the or whihc component/method shall i call to generate this future ticket or how can i call it from outside?

I appreciate if you could give me a piece of code or something which help me to implement this. What i need is what function should i call and i m little new to .net itself finding it as a little hard to do so.

Thanks in advance.
Jul 6, 2013 at 5:12 AM
kuldipPatel, given what you've described you should have little trouble adding the functionality you want to the system.

Based on your description, I am assuming you have an external application of some sort that is responsible for checking for new email, and all you need it to do is create a new ticket. For the sake of discussion, I will call this application TicketMail. So... to get tickets into TicketDesk from TicketMail, there are two broad approaches you might take:

Option 1: Add a service endpoint to TicketDesk.
In this scenario, the TicketDesk web site would expose a web service endpoint, and TicketMail would just call the endpoint when it needs to add a ticket. This is the simplest way to achieve what you want to do.

Since TicketDesk is an application, you have a very large number of options for what kind of service endpoint you can use. You can add an Asp.Net Web API controller, use a WCF Web Service (which has tons of different endpoint technologies to choose from), or even use an old fashioned web service (*.asmx) file.

I would recommend adding a simple Web API controller. TicketDesk is already an Asp.Net MVC app, and has all the plumbing you need to use Web API, and Web API is much easier to use than most of the other options.

In the web service endpoint you take in the information from the caller, then add a ticket by calling to the TicketService.CreateNewTicket method, which takes a Ticket object as a parameter. If you want to do other stuff after you create the ticket (like add a custom comment, assign the ticket, etc.), there are simple methods in TicketService for each of those operations too.

TicketDesk uses the Managed Extensibility Framework (MEF), so you don't need to manually construct a TicketService instance. In your web service, get an instance of TicketService from the MEF application like this:
var ticketService = MefHttpApplication.ApplicationContainer.GetExportedValue<ITicketService>();
Option 2: Reference TicketDesk.Domain Directly
Reference the TicketDesk.Domain assembly in your TicketMail application (assuming it is a .Net app), and use the API directly.

All of the business and data access code is encapsulated in a class library, and designed for re-use within other client applications. The difficulty with this approach is that you will have to instantiate the services yourself, and your application will have to supply the correct configuration data to ensure that the TicketDesk API talks to the right database. This isn't exactly difficult, but the use of MEF does complicate it some. You don't have to use MEF to use the TicketDesk.Domain services, but if you don't use MEF you will need to supply all the dependencies when you instantiate the objects... which is why I recommend the first approach instead.
Sep 16, 2015 at 11:28 PM

I tried to create my own webapi against the controller like you suggested.... I get An error occurred when trying to create a controller of type 'CustomController'. Make sure that the controller has a parameterless public constructor. I think it is due to DI issue.... Please help.

I inject my controller here ...
public Container GetInitializedContainer(IAppBuilder app)
        var container = new Container();

  container.Register(() => new TdIdentityContext());

My API Controller...

public class CustomController : ApiController
    private TdDomainContext Context { get; set; }
    public CustomController(TdDomainContext context)
        Context = context;


    public async Task<JsonResult> FilterList(
       string listName,
       int pageSize,
       string ticketStatus,
       string owner,
       string assignedTo)

        var uId = Context.SecurityProvider.CurrentUserId;
        var userSetting = await Context.UserSettingsManager.GetSettingsForUserAsync(uId);

        var currentListSetting = userSetting.GetUserListSettingByName(listName);

        currentListSetting.ModifyFilterSettings(pageSize, ticketStatus, owner, assignedTo);

        await Context.SaveChangesAsync();
        var result = await GetTicketListPartials(null, listName);
        return new JsonResult
            JsonRequestBehavior = JsonRequestBehavior.AllowGet,
            Data = result

        //return Json(result, JsonRequestBehavior.AllowGet);

        //return Json(await GetTicketListPartial(null, listName), JsonRequestBehavior.AllowGet);


I get below error message ...

<Message>An error has occurred.</Message>
An error occurred when trying to create a controller of type 'CustomController'. Make sure that the controller has a parameterless public constructor.
at System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create(HttpRequestMessage request, HttpControllerDescriptor controllerDescriptor, Type controllerType) at System.Web.Http.Controllers.HttpControllerDescriptor.CreateController(HttpRequestMessage request) at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__1.MoveNext()
<Message>An error has occurred.</Message>
Type 'TicketDesk.Web.Client.Controllers.CustomController' does not have a default constructor
at System.Linq.Expressions.Expression.New(Type type) at System.Web.Http.Internal.TypeActivator.Create[TBase](Type instanceType) at System.Web.Http.Dispatcher.DefaultHttpControllerActivator.GetInstanceOrActivator(HttpRequestMessage request, Type controllerType, Func`1& activator) at System.Web.Http.Dispatcher.DefaultHttpControllerActivator.Create(HttpRequestMessage request, HttpControllerDescriptor controllerDescriptor, Type controllerType)
Sep 16, 2015 at 11:30 PM
Forgot to include my DI ..

container.Register(() => new CustomController(new TdDomainContext()));
Sep 17, 2015 at 2:20 AM
I think I would need to see more of the code. This looks like TD 2.5 (the initial post is about TD 2.1). Web API uses a different dependency resolver than MVC, and so you have to setup SimpleInjector for web API separately from how it is configured for use with MVC. I haven't actually ever setup WebAPI with TD 2.5 (it is pure MVC currently), so I'm not clear on the exact steps necessary to get that working. I'd start with the simpleinjector docs:

There is also info on using SimpleInjector with OWIN specifically (, but this guide may only be applicable for creating custom OWIN middleware; after a cursory glance, I don't see how exactly how it applies when using Web API, even when using an OWIN host.

If you have code you can put in the cloud somewhere, shoot me a link and i'll run it though a debugger real fast and see what I can do.