Is there a way to merge existing entries from several logbooks into a single logbook? 

Only manually: Add "Move to" to you set of commands via "Menu commands = ...", then select one or more entries, and move them to your target logbook.  

 Got it! Thanks...

Is there a way to require a certain attribute on reply, but not on an original entry?  In some cases info. for these fields only exists on reply.

No. There is only "Preset on reply ..." and "Remove on reply...". You could for example require that attribute, preset it for new entries with some dummy value, and remove that value with "Remove on reply...". Maybe that works. 

My elog server is hosted behind a firewall and I use a VPN client to connect to the network on which it is hosted.  When I'm logged into the VPN emails from elog display fine, but when I'm not connected to the VPN emails display in plain text because the email client is unable to load "default.css" since it's behind a firewall.

Is there a way to include the style information in the HTML email rather than in a separate file that's hosted on the elog server? 

That's a good idea. I will consider that for a future version. 

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.