First of all, ELOG has been designed having shift logbooks in mind, so it probably will never be a perfect trouble ticket system. Nevertheless, there are some options which can help in that respect:

• Use attributes Ticket and Status
• Preset Ticket with a running ticket number via
  
  Preset ticket = TCK-#####
  

  This will increment the 5-digit ticket number whenever you create a new ticket, but will not update it when you do a reply

• Use Status to determine the status of the whole trouble ticket chain (initial entry plus replies)

  Options Status = open, closed
  Preset Status = open

• Once a ticked chain is closed, do the following:

  • Go to the threaded list display
  • Click on Select
  • Select the trouble ticket chain
  • Click on Edit
  • Now change Status from "Open" to "Closed"

This will then modify the Status of the whole chain from "Open" to "Closed"

Stefan,

Thanks for this, I had already implemented the Preset Ticket Nr = TT-##### but I didnt use the threaded and Select to close the ticket, very nice tip thanks. I think this program can be have several uses, and working very well. The trouble ticketing will work for us.

Once again thanks for the very speedy support.

Lance

> > > Greetings,
> > > 
> > > Last night we updated to 2.6.5 and now the <ENTER>-key on the "quick filter" searches won't work anymore in 
> > > internet exporer (@windows). I have to use the <TAB>-key now to get the results.
> > > 
> > > The ENTER-key still works under firefox (Windows & linux) and opera (at least under linux, because 
> > > opera@windows refuses to log me on .. whatever) and I would like to see it come back to internet explorer as 
> > > well.
> > > 
> > > Regards,
> > > Willem Koster
> > 
> > ehm... funny enough the quick-filter entry used in this elog does work with IE.  
> > 
> > (we're using ELOG V2.6.5-1844 btw)
> > 
> > update: when we try just one quick-filter it works ok, when we add our second quick-filter it stops working.
> > 
> > Both quick-filters are tekst-searches (just like this forum only has one tekst-search quick-filter).
> > 
> > We suspect that this is an explorer issue and probably not something that can be solved with elog, but ... 
> > maybe .. who knows...
> > 
> > 
> > 
> > update2:
> > 
> > In the source we see:
> > 
> >     <noscript><input type="Submit" value="Search"></noscript> 
> > 
> > If we remove the <noscript> </noscript> tags we get a submit-button, but our problem seems to be solved. 
> > (obviously hacking the source-code is not our primary choice :-)
> 
> The code above is for cases where JavaScript is not enabled. The quick filter text box contains code like:
> 
>   onChange="document.form1.submit()"
> 
> which is some javacode which causes the browser to submit the form after the contents of the text box has changed.
> Now if javascript is turned off, this does not work obviously. So I added the <noscript> section which shows the
> Submit button, so people can click on it. But you are telling me that IE accepts the hit on return (not the click
> on the Submit button) even when JavaScript is off, right? Can you temporarily remove the onChange section and see
> what happens?


Hello,

I installed the latest version (2.7) of ELOG and having the problem that the quick filter only works when hitting the 
enter-key when there is only one free text field (subtext). Whene having two or more free text field you have to use 
the tab-key or click onto the elog icon. We are using Internet Explorer, not tested on Mozilla right now.

Thanks!

Uwe

> I installed the latest version (2.7) of ELOG and having the problem that the quick filter only works when hitting the 
> enter-key when there is only one free text field (subtext). Whene having two or more free text field you have to use 
> the tab-key or click onto the elog icon. We are using Internet Explorer, not tested on Mozilla right now.

I found that this is indeed an Internet Explorer bug, since it works with all other browsers I tested. There is however a
workaround: I added some code to the current version of elog which shows a "Search" button whenever the page is accessed
through the Internet Explorer. Then the behavior of hitting <return> works again. The change is in revision #1970 and will
be contained in the next release.

I fixed this in svn revision #1971. The fix will be contained in the next release. You can test it already in the demo logbook.

Just another thing I would like to admit. We are often using the summary view. Sometimes the summary view shows the text like the following:

This  is just  a test

When using the Full view or clicking on the entry, those html-codes are not shown. Thanks again for the great software!

Uwe

Ok, that's fixed now as well.

Hi Adam,

You might double check your file names vs. HTML tags. It appears in your example above that your HTML tag is requesting a file named: "1n2.jpg" and your image file name is "In2.jpg". Please note that in the first case the file name starts with (1) a numeral one and in the second case the file name start with a capital (I) a capital I.

Greg