> Hello,
>    I feel that the filter result could be confusing and unexpected when "COLLAPSE TO LAST" is enabled: you 
> filter the first entry but you show the last one. What is filtered doesn't correspond with what is shown (look 
> the attached example). 
> 
> I suggest to implement an option to let the user decide which entry (first or last) should be retrieved for 
> filtering (a tentative patch is attached).
> 
> Thank you 
> 
>     Gabriele
> 
> P.S. A similar behaviour occurs when you sort the logbook: it could appear as not sorted because you sort the 
> first entry but the last one is shown.

You are absolutely right. When doing filtering, entries shown or not shown have not much to do with the filter. 
Rather than messing around with first and last entries, I decided to break apart threads completely when doing 
filtering, so the entries are treated as individual entries, just like what you do when filtering in summary mode. 
This gives then consistent filtering results. The modification is done in revision 2282.

Hello,
   I gave it a try using the svn version n. 2283 (12 Jan 2010).  The threaded display can be collapsed only if you don't 
apply any sorting. In the latter case, if you sort in some way ( with "Sort Attributes =" or "sort=" in the url), the 
thread cannot be collapsed anymore.

Also if I apply any filter from the quick filter bar, I cannot collapse the thread anymore (also without sorting). 

As example, these are the numbers of entries I obtain with my logbook :

  http://localhost:8080/mylogbook/?mode=threaded&expand=0     => 75 entries (OK)
  http://localhost:8080/mylogbook/?mode=threaded&expand=0&sort=EventID  =>  445 entries  (WRONG it should collapsed)
  http://localhost:8080/mylogbook/?mode=threaded&expand=0&Interaction=nuCC   => 335 entries 

However (considering the bug fixed for the collapsed thread display), breaking the thread is not a confortable solution. 
I choose to show the logbook in the threaded mode, because I'm interested in grouping the entries in threads. 
In my opinion, this feature is good (and it is my favourite) and should be preserved despite any sorting or filtering. 
This is why I suggest to ask to the user which entries (first or last) better applies for sorting and filtering. 

Ciao

   Gabriele


> You are absolutely right. When doing filtering, entries shown or not shown have not much to do with the filter. 
> Rather than messing around with first and last entries, I decided to break apart threads completely when doing 
> filtering, so the entries are treated as individual entries, just like what you do when filtering in summary mode. 
> This gives then consistent filtering results. The modification is done in revision 2282.

> However (considering the bug fixed for the collapsed thread display), breaking the thread is not a confortable solution. 

Well, but it's the only way which gives you a 1:1 correlation between what you filter and what you see below. If you want to 
see the full thread for an entry which gets shown after you apply a filter, just click on that entry, and you will be taken to 
the single entry display which shows the full thread on top of it. This is the only way I can keep search results consistent, 
so I would rather like to keep it like this.

Is it possible to create a drop down menu for the last 3 days of log entries. Currently we have the last day, month, 3 month, etc.

Reason being, after a weekend most people would like to view the log entries for the last three days. Can anyone help me out here?

It is a good point, and surprised that this particular number of days was overlooked.

It only needs four lines added into elogd.c to achieve this.  Even with my notorious 
c coding, I did it first time, but as I'm on linux, not a great help for you.  Indeed, 
any other arbitary number of days could be added in, if you have the sources and means 
to recompile.

I think windows versions are only updated on version number, not svn number, so it will 
require a request to the great man himself(*) to produce a new version for windows.

(*)Hint; Stefan likes the occasional beer.


<p>
<table width="98%" align="center" cellspacing="1" style="border:1px solid #486090;">
<tbody>
<tr>
<td cellpadding="3px" style="background-color:#486090; font-weidht:bold; color:white;">Paul O'Shaughnessy
wrote:</td></tr>
<tr>
<td cellpadding="10px" style="background-color:#FFFFB0;"><p>Is it possible to create a drop down menu for the
last 3 days of log entries. Currently we have the last day, month, 3 month, etc.</p>
<p>Reason being, after a weekend most people would like to view the log entries&nbsp;for the last three days.
Can anyone help me out here?</p></td>
</tr>
</tbody>
</table>
</p><p> </p>

Hi, Stefan.  When someone using a satellite connection tries to upload an attachment *or* edit a long entry, it fails and they are presented
with an "Internal Server Error."  This is a huge improvement over the previous behavior of crashing elogd, but we were wondering if there is any
hope of improving this further so that one can edit large entries or upload attachments over a slow (in this case, satellite) connection.  Do
you have any ideas or plans on working on this further?  Apparently ELOG is the "only" service this user has trouble with from  home.

Any information you could provide would be greatly appreciated.

Many thanks,
Devin

> It is a good point, and surprised that this particular number of days was overlooked.
> 
> It only needs four lines added into elogd.c to achieve this.  Even with my notorious 
> c coding, I did it first time, but as I'm on linux, not a great help for you.  Indeed, 
> any other arbitary number of days could be added in, if you have the sources and means 
> to recompile.

David send me his modification and I put it into the main source code, so it will be contained in the next Windows 
version.

> I think windows versions are only updated on version number, not svn number, so it will 
> require a request to the great man himself(*) to produce a new version for windows.
>
> (*)Hint; Stefan likes the occasional beer.

Yepp ;-)

> Hi, Stefan.  When someone using a satellite connection tries to upload an attachment *or* edit a long entry, it fails and they are presented
> with an "Internal Server Error."  This is a huge improvement over the previous behavior of crashing elogd, but we were wondering if there is any
> hope of improving this further so that one can edit large entries or upload attachments over a slow (in this case, satellite) connection.  Do
> you have any ideas or plans on working on this further?  Apparently ELOG is the "only" service this user has trouble with from  home.

There was a timeout of 1 sec. in the elogd daemon, which probably is too short for a satellite connection. Unfortunately I have no satellite here 
around to test it, so I "blindly" increased it to 6 seconds in the current SVN version. Please give it a try. You can increase this yourself, its here 
in the code at (Rev. 2291) line 28270:

   FD_ZERO(&readfds);
   FD_SET(_sock, &readfds);
   timeout.tv_sec = 6;            <----
   timeout.tv_usec = 0;
   status = select(FD_SETSIZE, (void *) &readfds, NULL, NULL, (void *) &timeout);

so you can change the 6 to 10 or so. The disadvantage of a large value is the following: Suppose you submit an entry, and in the middle of the 
submission your browser dies (or the user closes it). If you have a timeout of n seconds, the elogd server will wait that time until it closes the 
connection. During this waiting time is cannot respond to other request, so it might look dead. That's why we should not make it too long.

- Stefan