P
ppetree

  • May 15, 2013
  • Joined Mar 26, 2008
  • 0 best answers
  • This problem was caused because we were logging in using a userid that belonged to a default group and that group could not see tickets from other departments.

    I get that but the admin group was also blocked from seeing departments other than support and I think this default is wrong and will frustrate a lot of people.

  • The userid belongs to a group and the group may not have access to all departments or tickets. Check those settings.

  • We have a duplicatable issue on our system:

    We have two departments that we setup, each has its own email address (billing and abuse), each has its own template.

    We have setup filters on email = billing@domain.com and abuse@domain.com to send those emails to their respective departments.

    A ticket gets sent to the address billing@domain.com and the user gets an email informing them the ticket is generated along with a link that works and this email is from the correct template.

    The helpdesk admin gets an email saying a ticket has been created in that department.

    That ticket simply does not exist in the Tickets tab under open or anywhere else.

    Having checked the ost_tickets table it doesn't exist in the table either... not sure which gremlin is eating them!

    It should be noted that the billing and abuse departments have no employees, these requests will be handled by the general staff, we just wanted to use different templates.

    We have generated 3 tickets for each of these departments with no ticket appearing in the staff panel.

  • You have to change the permissions on the pipe.php file so that it has execute permissions.

  • From experience, you really want to use the pipe filter for incoming emails.

    It's really easy to setup just make sure the filter has execute permission enabled.

    On the outgoing side, the php mail function will send through your smtp server... make sure your DNS has an SPF record and you should be fine.

  • Ahh... the hitch... here's a bug:

    Table 'domain_support.ost_sla' doesn't exist

    EDIT: Some new info on the above error:

    We did run the upgrade script and the tables were created. We have not seen this error on any tickets since the original upgrade how ever we got multiple emails for the ost_sla table and the filter tables.

  • During the upgrade, which went far smoother than we expected, we encountered these problems:

    Upgrade issues:

    On first visit to the staff panel we had two tickets which contained this message: Error fetching ticket thread - get technical help.

    Missing image file: scp/images/logo-support.gif (we copied the one from the 1.6 installation)

    Deleting a ticket while viewing a ticket: the delete confirmation box is off the viewable screen... you have to scroll way down and its located in the bottom left corner. This was in IE9.

    From the main staff panel, if you select multilple tickets and attempt to delete them, you get an error: Unknown or unsupported action - get technical help

    To fix the last problem we found that: Logging out as admin, following open link as a customer and viewing ticket from the customer side, logging out as customer and logging back in as admin and this problem seems to have gone away.

  • Already working on the upgrade. I think they're taking the helpdesk offline tonight.

    But 1.6ST is definately not filtering to the different departments.

    Thanks for your help... great product!!!

  • OK, don't take this the wrong way, I just want to clear this up so that the next person who comes searching for a resolution finds clear information.

    Version 1.6ST has a bug and doesn't filter to the appropriate departments as is documented.

    The solution is to upgrade to version 1.7.

  • I did some more research:

    the wiki says the behavior should be as I expect:

    Routing Incoming Emails

    Setting up your system to accept emails varies from system to system and depends on your personal preference. osTicket currently supports piping (aliases) and POP3/IMAP polling methods for routing incoming emails. Tickets are routed to the department and assigned a default priority associated with the email.

    (Read Wiki)

  • Thanks for your quick reponse. I guess I find it a bit confusing to have an email address assigned to a department and emails that come to that address not be assigned to that department.

    Now, on to fixing the problem.

    I scoured the admin panel and could not find:

    Admin panel -> Manage -> Ticket Filters

    I couldn't find it under Dashboard, Settings, Emails, Help Topics, Staff or Departments.

    Settings has: Preferences, Attachments and API

    Emails has: Email Addresses, Add New Email, Templates, Banlist

    Departments has: Departments, Add New Dept.

    I've been through each of those screens and find no way to manage the filters. I must be missing something.

    Again, this is version 1.6ST and I'm using Email piping.

  • I have three email addressess (support, billing and hr).

    I have three departments (support, billing and hr).

    I have three email templates (support, billing and hr).

    I have configured each department to use the template for that department and each email address is assigned to the correct department.

    If an email is sent to hr@domain.com I would expect osTicket to send an email from the hr template using the hr@domain.com email address.

    What's happening is that any emails sent to hr@domain.com and billing@domain.com are assigned to the support department and get the auto-response from the support department... they are not being assigned to the department associated to the incoming email address.

  • Thanks... I can't believe I missed that! :

    I set it but wont be able to test it until later today.

  • I'm in a small company and we don't (can't) monitor the helpdesk 24x7 so what we want is to receive an email anytime a new ticket gets opened.

    I can't find a way to do that from within the program, does anyone know how to set this up? Is there a mod for this?

  • I have several web sites that I want to support through osTicket and so far that is working fine as I have setup a department for each site, setup email piping for each sites support address and tickets are flowing back and forth.

    Now what I want to do is have knowledge base articles for each site. How would I go about setting this up?

    Thanks,

    Pete

  • Nope. Not new to open source software. Just not used to having a DOA product and no support.

    Snitz... post a question there and get an answer that same day.

    4ice... thanks for the email but I don't go along with the slam in public, make nice in private way of operating.

    I have given everyone here a very valid, indepth explanation of the problem and several other posts admit to the same problem. Apparently this is a new issue and new issues that cause software to be delivered DOA to a large portion of an audience are usually jumped on... at least in my experience.

    It's not about whose software is best, its about what works and what doesnt. You can have the greatest software in the world but if it doesn't work for a specific user base then its of no use to that user base.

    As for building a community, you do that by cooperating. Had someone replied to my 2nd post and said "hey, we're small, it'll take a few days" that would have been one thing but all I get is a response wanting to know what version I had (the only one you can download and the one in whose forum I posted help for).

    Now, if someone wants to take a stab at fixing the problem thats fine but otherwise I'm outta here.

  • Well ppetree, did you ever realize that this is an open source project with constant development. So there is always a possibility of a bug in the system. Furthermore every server is different, it could very well be that your server is configured in a way that it's causing this problem. Because I do believe you have the correct username and password, but I also know there are alot of people who are having no problems whatsoever.

    As for your "24 hours" expectations, did you ever realize that alot of people (who are normally wanting to help you out) have a regular job and therefor not checking your problems out every minute.

    Perhaps it's an idea to have a bit more patience and hopefully there will be a solution of the problem you are having. I've sent a PM to peter, perhaps he has any idea. Because unfortunately I don't know what is causing this.

    Well ppetree, did you ever realize that this is an open source project with constant development.

    Most all software has constant developement.

    So there is always a possibility of a bug in the system.

    Really? I never knew that about software! BTW, most outfits leave the last "golden" available for download and dont' require users to down load "Release Candidates". That's how this industry works.

    Furthermore every server is different, it could very well be that your server is configured in a way that it's causing this problem.

    Could be but without the correct diagnostic tools, appropriate troubleshooting guides, help in the fora etc. it's truly impossible to tell where the problem lies.

    Because I do believe you have the correct username and password, but I also know there are alot of people who are having no problems whatsoever.

    There are three present, all having the exact same problem soooo.... apparently its not all that unusal.

    As for your "24 hours" expectations, did you ever realize that alot of people (who are normally wanting to help you out) have a regular job and therefor not checking your problems out every minute.

    Most products, whether publicly supported or shrink wrap generally try to respond with 24 hours... especially if the install is DOA. It's not an unreasonable expectation. It may not be one you like but its not unreasonable.

    Perhaps it's an idea to have a bit more patience and hopefully there will be a solution of the problem you are having. I've sent a PM to peter, perhaps he has any idea. Because unfortunately I don't know what is causing this.

    Unfortunately I cant tell my boss that he needs to have patience. His words are "if its not working and you cant find the solution move on to a different product. There are too many of them out there to waste time on one that doesn't work."

    Since Peter decided to address my expectation of some sort of help on a DOA product instead of helping diagnose the problem I'll move on to another product.

  • ppetree,

    I would like to second Corey and 4ice on this issue. osTicket forums depends on community members helping each other out, no one is paid to answer every post.

    Your ultimatum is actually laughable in the context of open source software.

    So then its DOA. All I needed to know.

  • 4ice, lets either solve this or pronounce it DOA on win2k3.

  • I didn't realize you we're on a w2K3 server. One fix you may want to try, if you haven't, is this:

    My guess is you may of already tried it though.

    I saw that but didn't try it as I'm not experiencing those problems.

    The above mentioned db UPDATEs to "fix" my userid/pword accomplished nothing.

    If you attempt to logon using an incorrect password you get an 'Invalid login' error message in lieu of the 'Authentication Required message and the login fields are cleared. This indicates the code is differientiating between user supplied data which doesn't match stored data.

    However, if you logon using the CORRECT userid and password it just circles right back around to the logon page with 'Authentication Required' posted... in other words it does nothing. This indicates the code IS indeed matching the userid/password but collapsing after that.

    I inserted a message right below the comment of a similar nature:

    $msg='Now set session crap and lets roll baby!';

    If my error message were displayed that might give one indication that the subsequent code is being executed but nada. On the other hand if the code WERE executed, session variables would be set, index.php would get loaded and it would redirect to tickets.php which would test the session variables and if no match were found an error message would be displayed... and that is also not happening.