looks good. looks like there might be a special case scenario where the 'Select an option' option is actually selected (highlighted in blue) on a sub-level and then one of the parent levels is changed. the highlighted sub-level doesn't get hidden, but is disabled.probably not a big deal, unlikely to be a regular occurrence anyway, but might be worth checking in case it passes another variable through on selection.

cool. will check it out tomorrow. don't have time right now.would never have worked out that fix myself   :(re: hiding dropdowns, what would be ideal is if it only showed the 1st level dropdown, and then expanded to show each sub-level dropdown only once a selection is made that actually requires it. so even if every help topic has at least 3 levels, only the top-level dropdown is shown when the page is first loaded.

dunno about imap/pop3 on godaddy. just wondering about where the mail you're trying to poll is stored, if you have access to that server, can you not try setting up email piping?, that will go to the website api rather than an imap or pop3 port, so it should bypass the whole problem. i assume godaddy will allow your site to send out using smtp, 

yep, that should be possible. i can't give the exact answer myself, i've not looked at the code, but you'll need to look at the code around the check ticket status button, which loads the email/ticket number request page if you're not already logged in. and apply that to the knowledgebase button, but using the page/form loaded by the sign in link rather than the check ticket status link.that might not stop people who have the full url to a faq article though, you might need to add the 'are you logged in' check to the knowledgebase form itself

well, i don't seem to be getting any further with this. looks like i'm gonna have to leave this one to someone with some real programming knowledge.

in the filter actions section, there is a department entry there, are you setting the correct/any department there? or leaving that on default. alert emails, are you on about new ticket alert, or ticket assignment alert?for new ticket alert, i don't think there's much you can do unless you make the team members match the department members.assuming your trying to auto-assign everything, use the ticket assignment alert instead, assigned agent/team should do what you want.assuming you're the admin, you might want to leave yourself enabled (admin email) on the new ticket alert, at least for a while, just in case tickets make it through the system without being assigned, at least someone will know about it and can see them in the ticket list.

looks to work perfectly fine to me, from the client side, the knowledgebase menu item is only displayed once a category AND a FAQ article exists, and is made public.if there is a public category AND a public faq, then a url pointing directly to that faq will work, if there are no public faqs, or there are public faqs, but no public categories, the url pointing directly to the faq will be redirected to the client landing page.  this works for me without the client being forced to login. (using version 1.9.4)

ok, you can't just comment out the line below, if you do, it will not load any custom forms.        $('#dynamic-form').load('ajax.php/form/help-topic/' + value , data); the actual data being returned by 'value' in that line appears to be fine, it matches up with my help topic id's. there doesn't appear to be anything spurious being included.when there are no custom forms it just displays {"media","html"} , i have no idea where it gets this from, they're not in the database, and the strings media and html only appear together in include/mpdf/classes/cssmgr.phpif you do use a custom form, it appears on screen, mangled, like:\n\nAffected Site<\/h3>\n<\/em>\n <\/div>\n <\/td><\/tr>\n\n Website URL::<\/label>

ok. the remaining issue has nothing to do with the contact form being in the same tbody, that said, i still think the contact form *should* be in it's own tbody, which can be achieved by editing include/client/open.inc.php and adding</tbody><tbody>just above these lines:<?php        if (!$thisclient) {            $uform = UserForm:()->getForm($_POST);the issue is being displayed by this bit of code:    <tbody id="dynamic-form">        <?php if ($form) {            include(CLIENTINC_DIR . 'templates/dynamic-form.tmpl.php');        } ?>    </tbody> i've moved it to the end of the table, so it doesn't affect any of the other forms.its being called by this bit of code, in the same file, with the highlighted line being the cause. i've commented the line out, and the issue no longer displays, although i can't confirm that won't cause any other issues. not worked through that part yet.var changeCombo = function(){    var value = $("#cmb_value").val();    var data = $('', '#dynamic-form').serialize();    if(value ==""){        $('#dynamic-form').html("");    }else{        $('#dynamic-form').load('ajax.php/form/help-topic/' + value , data);    }}

absolutely agree, overdue ticket emails should be sent at least everyday. i also think there should be due time reminders sent out as well. so if some work has been scheduled using a ticket, the agent/team can get a reminder alert 10 - 15 minutes prior to the scheduled timei am assuming here that a ticket scheduling work is created with the due date set rather than using an SLA.

yep. getting the same thing myself, just restarted it all with a completely new database, to confirm it wasn't anything else left over from custom forms causing it, but i still get the same thing. even like this, as far as i can tell, creating a new ticket still works without any problems. i tried before with a custom contact form, and it made a complete mess of that, with html tags and symbols showing up all over the place.your custom ticket details part looks ok though, so maybe anything other than a customised contact form may be ok.looking at the code some more, it looks like the help topic drop downs and the contact form are being created within the same tbody /tbody tags, with ticket details and captcha each in their own tbody, i *think*  the help topic part and the contact details part should both be in their own tbody. but i'm in no way, shape or form, a programmer, i've managed to hack it this far, but i think someone with a bit more knowledge than me will need to fix this part.

i can't get any further with this. i'm not sure if some custom forms / lists that i was playing around with before is causing some issue. i deleted all custom forms, but can't delete some custom lists because it say's they're in use by custom forms?!?looking at it, it looks like when the final option is selected, it's trying to call a dynamic form, which is being returned null values, when i don't believe if should be even calling it. i've deleted some of the custom form / list stuff i found still lurking in the database, but may have missed stuff.i'm now going to try going back to a new clean install and re-applying the mod and see how it works on that.in the meantime, once it's working fully, i'd like to see only the 1st drop down list, with the others only showing up, if required, once a selection in the parent drop-down has been made. the created page code shows the inactive drop-downs as disabled, anyone know how to make it so they're hidden?<select name="topic2" disabled="" class="cmb" id="cmb2" style="width: 300px; float: none;">                                         </select>

finished changing class.topic.php  tried creating new help topics, worked fine. tried creating a new ticket as a client, that worked as  well.i've gone 3 levels deep on the topics,  select a topic with only 1 level i get{"media","html"}   after the contact details,selecting a topic with 2 levels of depth, i get the same after selecting the 2nd level topic.selecting a topic with 3 levels of depth (no spaces in any of the topics), i get the same after selecting the 3rd level topic.getting some really messed up stuff on a selection with a custom form, but that may be related to something else. going to wipe out custom forms and existing help topics and test again. in the meantime, i've attached the modded 1.9.4 files i'm currently using.

[ost.zip](https://forum.osticket.com/assets/files/migrated/FileUpload/47/f314fa0d06c5694dded18dd36325c4.zip)

just tried placing the modded files straight into the 1.9.4 system unaltered, get the same problem powdergeek11 had.going through it all again from scratch, a bit more carefully this time. fortunately it's just a test server, so i can get away with breaking things :)so far, i've modded the 1.9.4 versions of open.php and open.inc.php,  and adding a new help topic can still be done without any problems. a client attempt to open a new ticket loads the part of the page, but obviously doesn't get the selection parts yet.seeing:

Guest User | Sign In

Please fill in the form below to open a new ticket.

as already said. check dns resolution first, forget whether or not there's a response, does a ping pop.gmail.com return a first line like:PING gmail-pop.l.google.com (173.194.78.109) 56(84) bytes of data.64 bytes from wg-in-f109.1e100.net (173.194.78.109): icmp_req=1 ttl=48 time=12.7 ms64 bytes from wg-in-f109.1e100.net (173.194.78.109): icmp_req=2 ttl=48 time=12.6 mssee the ip? if it's not returning an ip, then there's a dns problem somewhere.try pinging the ip rather than the name, if that works, then again, it's a dns issue, you can set your pop/imap server using the ip instead of the name, it'll get you up and running, but it's not the recommended way, and doesn't provide for server failure.if you can ping the ip, but can't telnet to the ports, then there's definitely a firewall/iptable rule somewhere blocking it.  if pinging the ip address fails, you'll need to run a traceroute to that ip, and see where it fails, and start troubleshooting from there. also, it may seem silly, but are you absolutely sure you can't connect?, when trying telnet, does it show a connecting to... message, followed by 'could not open a connection to the host', or do you just get a black window with a flashing white box in the top left corner?if it's the latter, it is connected.

firstly check dns resolution, from the cli on the server with osticket installed:ping pop.gmail.com ping imap.comregardless of whether you get a reply or not, does it resolve an ip address? if not then it's dns. try ping 64.233.167.109 (pop)or ping 64.233.167.108 (imap) or ping 74.125.206.108 (another gmail imap address)if these work the problem is your dns.if these still fail, then there's something wrong with the routing somewhere.try traceroute pop.gmail.com (linux) or tracert pop.gmail.com (windows) and see where that gets to.the last ip you get to before you start receiving a string of asterisks is where the problem is. it's almost certainly going to be a firewall or router, with an outside chance of being a switch.

i've tried it on 1.9.4, i've not copied the files over, i've compared the modded files with 1.9.3 to work out what the changes are, and copied those changes into the 1.9.4 files.no errors being displayed. and no problems creating new help topics.but trying to go in as a client and open a new ticket, i just get an empty page. maybe i'm missing something obvious, but i'm seeing no difference in the open.php from 1.9.3 and the modded file uploaded on sept 5.

at the moment, i think the only alternative is to set up a team, matching the dept. and either have it's own email address, and have anything to that address assigned to that team,or set up a ticket filter to assign it to that team.ok, it's not a new ticket alert, but if it's something new coming in and being automatically assigned, then the ticket assignment alert will effectively be the same thing.

cool.i have a couple of suggestions, some of which i'm sure you're already planning, or have at least considered.having statuses like:  scheduled, client/customer update. where scheduled using the due date, which i believe (not tested it yet) sets out an stale ticket alert, and sets the ticket to overdue using it's own ticket status. i'd like to see the mod ticket status (tstatus) get changed to overdue at the same time. i'd like to see this happen when the SLA period expires as well. (it may already, as i said, i've not tested it yet)when a customer responds, a new message alert is sent out, i'd like tstatus to change the tickets state to client/customer update. so basically it responds to events, rather than having to manually change the status.probably simple enough stuff, just not had a chance to look at the code for it, and i'd imagine most people would want it.

is there any reason for holding onto the previous statuses? ie isActive = 0 in mod_status_assignmentsit would make the table very large quite quickly, especially on a busy helpdesk.i would suggest when updating the ticket status in that table, it then deletes any rows where isActive = 0.i've found that leaving them in there means it displays different statuses for a ticket when ordering by tstatus ASC than it does ordering by tstatus DESC.