> Acknowledged. Added your vote to the wishlist.

Thanks!

> Ok, I added the option
> 
> Tooltip <attribute> = ...
> 
> I apply the HTML "title" tag to the whole table row, so the tooltip appears on the
> whole line, not only the attribute name. I guess this is much more intuitive. Give
> it a try. New version under CVS and available as a snapshot.

I like the implementation, especially with the tooltip popping up anywhere in the
area.  Thanks.

Stefan, would it be ok to add the "minor" revision level to the VERSION
constant?  I've been doing this after I download source just so I can keep
things straight, you keep cranking out versions ;->

EX: 
#define VERSION "2.5.4-4"
BECOMES
#define VERSION "2.5.4-4-1.483" or something like that?

Just a thought.

Thanks

Sorry for that. The idea is that the -4 is the minor number between releases
(mainly for bug fixes and impatient users (;-) ). I accidently overwrote the
-4 version several times when testing a new RPM building scheme, but I promise
to take more care in the future (:-)))

Having the CVS revision in the executable is however a good idea and I will
put it in.

> Stefan, would it be ok to add the "minor" revision level to the VERSION
> constant?  I've been doing this after I download source just so I can keep
> things straight, you keep cranking out versions ;->
> 
> EX: 
> #define VERSION "2.5.4-4"
> BECOMES
> #define VERSION "2.5.4-4-1.483" or something like that?
> 
> Just a thought.
> 
> Thanks

I have the following in a local logbook config: 
 
  append on edit = "\n\n[$date: $short_name]\n" 
 
When I upload an attachment to an entry, it appears like the page is 
getting refreshed in the browser and the 'append on edit' action is called 
again. This results in two appended strings in the text entry, one for the 
initial edit and one for the upload. 
 
Is this by design or an inadvertent result of uploading an attachment? 
 
My preferred handling of this - and perhaps a more intuitive behavior - 
would be to have the append/prepend actions happen once and only once for 
each edit or reply. 
 
BTW Stephan, many thanks for the great program. 

I have the following in a local logbook config: 
 
  append on edit = "\n\n[$date: $short_name]\n" 
 
When I upload an attachment to an entry, it appears like the page is 
getting refreshed in the browser and the 'append on edit' action is called 
again. This results in two appended strings in the text entry, one for the 
initial edit and one for the upload. 
 
Is this by design or an inadvertent result of uploading an attachment? 
 
My preferred handling of this - and perhaps a more intuitive behavior - 
would be to have the append/prepend actions happen once and only once for 
each edit or reply. 
 
BTW Stephan, many thanks for the great program. 

I fixed that in revision 1.496 (see CVS).

> 1) elogd should report quota or disk-full problem:  In case a logbook           
>    entry cannot be saved (quota or disk full) then a message like               
>    'Could not save last entry.  Please contact administrator.' should           
>    be displayed.  Currently nothing happens.  Only the submitted                
>    entries 'vanish'.                                                            

That has been fixed in meantime.

> 4) mark messages as unread/read on a per user basis: The                        
>    implementation of this might be quite involved but it would be               
>    rather useful.  One way would be to add a default attribute 'Seen            
>    by' to each entry, which lists the login names of the users.  Or 
>    files LOGIN_NAME.has_seen can be created which contain the entry 
>    IDs of the viewed entries for each user.

There is an elegant way to achieve this already now: Use an RSS reader (like
SharpReader for Windows or Straw from Linux) and subscribe to a logbook. Then don't
read the entries directly in the logbook, but read them in your RSS reader. Once you
read them, they become automatically marked read.   

> 5) alignment of attribute table (using <td colspan=2> for multi line            
>    stuff): see elog:669 :)                                                      

Has been fixed as well.

> - Use "and" and "or" operands in queries                                        

Elog supports now regular expressions. So for a "<str1> OR <str2>" one can write

<str1>|<str2>

and for a "<str1> AND <str2>" one can write

<str1>.*<str2>|<str2>.*<str1>

Looks a bit complicated, but maybe some day we will get some code which rewrites
"AND" and "OR" as regular expressions.