This project has moved and is read-only. For the latest updates, please go here.

Owner Drop Down

Aug 16, 2013 at 10:33 PM
I am using TicketDesk 2.1 with Active Directory authentication. Who is supposed to show in the owner drop down in the New Ticket tab? Right now I am only seeing users in the Admin role and not the Staff role.
Aug 16, 2013 at 10:43 PM
Normally, you give your help desk users both the staff and submitter roles. Admins would have all three roles.

The "owner" drop down only shows users in the submitter role, and the "assigned to" only shows users in the staff role.

It would be unusual, but there may be cases where you want help desk to be unable to submit or own tickets... in which case you would give them only the staff role, but not the submitter role. And you could, if you wanted, have an admin user that was only in the admin role... in which case they'd be able to access admin tools, but wouldn't be able to do anything useful with tickets at all.
Aug 16, 2013 at 10:46 PM
Edited Aug 16, 2013 at 10:47 PM
For AD environments, it works the same... put staff users in the AD group that you mapped to the submitter role, and also put them in the the AD group you mapped to the staff role. Admins should usually be in all three AD groups.

In theory, you could probably also add the AD staff group as a member of the AD submitter group... but I recommend not doing nested groups if you can help it.
Aug 17, 2013 at 12:12 AM
Ok, that makes sense but I am not seeing the users in the security group I added in the owner drop down. Does this not work if I include a securtiy group as a member of TicketDeskSubmitter group? I added a security group that contains all my sales staff and they do not show in the owner drop down.


Aug 17, 2013 at 7:12 AM
I can't say anything nice about AD... honestly.

When troubleshooting AD issues with TicketDesk there are a few things you should be aware of:
  • TicketDesk should be able to crawl through your AD groups, including sub-groups. However, AD is unusually flexible, and coding direct AD queries is also incredibly obtuse and difficult. The Directory Services namespace in .Net helps some, but under the hood it still uses ADSI, which is one of the worst APIs I've ever encountered. I did my best when I coded the AD integration components, but I cannot 100% guarantee that it will work in every AD configuration. It works on every configuration I've tested it with though. This is why I recommend not using nested groups, and creating separate AD groups specifically for use with TicketDesk. I have had very few reports of problems, other than mistakes in configuring TicketDesk's settings, so my confidence that I got it right have risen somewhat over time. I use ticketdesk with AD in my workplace, and has been much more reliable than I'd have expected.
  • TicketDesk performs background queries against AD for user names, email addresses, and the list of members within the AD groups. The data is cached locally in the SQL database. If you make changes to AD, it can take TicketDesk up to two hours to timeout those caches and re-query for fresh data. If you need to see the changes immediately, be sure to restart the IIS application pool.
  • Queries against AD are slow... very slow. Even if you clear the cache and restart the application, it could take a few minutes for the background caching system to finish gathering all of the information. How long depends on how many users, how many groups, how deeply nested the groups are, and how fast your domain controllers answer the queries. At work, TicketDesk takes between 3 to 10 seconds to get answers from the local network's AD controller, and the entire cache rebuild can take between 2 and 15 minutes (we have about 75 users). This is why ticketdesk uses background processes to fetch and cache this stuff.
  • Exceptions that occur in background threads don't usually make it into the online ELMAH error logs. But they should be in your windows server's application log. Check here to see if you are seeing exceptions that might relate to TIcketDesk's AD queries.
  • For authentication, ticketdesk relies on the standard windows token membership provider. The job of actually authenticating the users is handled at the OS level, and Windows has its own inexplicable cache mechanisms for AD credentials. Sometimes, for reasons that have nothing to do with ticketdesk, changes in AD are not picked up by the OS that is hosting the web site. Usually, the only thing that clears this problem up is a complete windows server reboot, but sometimes this doesn't even do the trick. This voodoo devil magic OS level stuff usually works itself out within a few hours, maybe a day or two. There are ways to force clear the OS cache, but the details behind this are something I leave up to my systems administrator... all I know is that it involves command line utilities and chicken blood. This problem usually only affects logging in for a specific user or two, so it probably isn't related to your issue... but is something you might want to know about.
Aug 17, 2013 at 7:21 AM
Edited Aug 17, 2013 at 7:23 AM
BTW, the difficulties behind traditional AD integration are bad enough to where I do not plan to support this kind of AD integration in TicketDesk 3. Instead, TD 3 will authenticate via ADFS (Active Directory Federation Services). Another option with TD3 will be to use Federated Identity with Windows Azure Access Control Services, which you can be connected to your on-premise ADFS. ACS will act as an authentication relay service.

Either of those options will be a distinct improvement.