> > > > > I only got one email in response to the second entry of this thread, no email was received after the edit of the entry.  The
> > > > > next email received was due to the third entry of this thread.
> > > > 
> > > > Ok, let me try (sorry to all the users who subscribe to this forum for pestering you...):
> > > > 
> > > > 1st reply to your entry.
> > > > 
> > > > 1st reply edited.
> > > 
> > > I got two email notifications, the second one I attached as a screen shot. So I don't know what happened in your case. The problem 
> > > with the proxy is sometimes related to slow internet connections. If the HTML code transported over the internet has some delay 
> > > between packets, the proxy server sometimes drops the connection. I don't know how to fix that in my Apache. If you edit in HTML, 
> > > your browser downloads the JavaScript code and icons for the edit window, which is a lot of data, so the dropping is much more 
> > > likely.
> > Hi Stefan,
> > 
> > I confirm that this is a slow internet line, so that explains the Proxy Error.  
> > 
> > Maybe I should just keep my head down on threads where people use html coding ;-)
> > 
> > Did you receive two emails to my entry 66677?  I only received one.
> > 
> > I only received one email to your posting 66680 - the first entry, not the edited version.
> 
> I checked my email server and found that the second message really went though it. But then I realized that there is indeed the "Message-
> ID:" in the email header (which I completely forgot in meantime). So maybe George Paplexis is right in that some mail 
> server/forwarder/receiver ignore a second email if it has the same ID. That would mean however that I have to introduce a "revision 
> number" for elog entries, which gets incremented on each edit and gets attached the the message-ID, so that it becomes unique again. 
> That's quite some work and has to wait a bit.

I had come to the same conclusion about the mail header being the same (see my email to you for full details).  

Sorry to all your subscribers for the email ping pong, although if others did receive two emails on the relivent entries - one original, and
one edited, it would be interesting, if possibly now academic, to know.

I don't understand your questions. Can you please give an example. 

 Sorry for my english. In fact, i found the answer by myself. But I ll explain to you.

in attachement 1, a small part of our ELOG. When I choose FBT in the quick filter "groupe incriminé". Elog respond that there is no entrie found (attachement 2)

But, with the find function, when i select display full entries and FBT in "groupe incriminé", Elog show the entrie ( attachement 3).

I found the answer. In fact, Elog respond no entrie when threaded is selected. I have to choose Full or summary for that working.

sorry

Xavier

Actually what you report is a bug. The filtering does not work in threaded display mode, only in summary and full. I fixed that bug in the current SVN version, so if you download and compile it, you can give it a try. The fix will be contained in the next official release.

 Here is the mail log:

Jan 12 13:51:54 techies lmtpunix[3184]: dupelim: eliminated duplicate message to user.jf id <neteng-1067@emich.edu> (delivery)

The message id we are experiancing problems with is in the header;

Message-ID: <neteng-1073@emich.edu>

Thank you for the help.

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.

Hello,

  I gave it a try. See: https://midas.psi.ch/elogs/Forum/66690

Gabriele

> 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.