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

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

It would be nice if elogd would recognise the whole of this as a link
http://support.microsoft.com/default.aspx?scid=kb;en-us;138354 rather than 
just the first bit.

Has been fixed in revision 1.492.

> Has been fixed in revision 1.492.

Thanks, Stefan.

When creating new logbooks, I will create a single entry to test the  
configuration. After revising the configuration I want to delete that  
single entry and create a new one based on the revised config.  
  
elogd will crash every time upon deleting that single entry with an  
xrealloc error. Here are the syslog entries leading up to the crash:  
  
Oct  9 08:09:41 obstin8 elogd[20614]:  
GET /Support/1?cmd=Delete&nextmsg=0&confirm=Yes HTTP/1.1^M Connection:  
Keep-Alive^M User-Agent: Mozilla/5.0 (compatible; Konqueror/3.3; Linux)  
(KHTML, like Gecko)^M Referer: http://localhost:8080/Support/1?cmd=Delete^M  
Accept: text/html, image/jpeg, image/png, text/*, image/*, */*^M  
Accept-Encoding: x-gzip, x-deflate, gzip, deflate^M Accept-Charset:  
iso-8859-1, utf-8;q=0.5, *;q=0.5^M Accept-Language: en^M Host:  
localhost:8080^M Cookie: urem=0; upwd=dDRubjNyBDI=; unm=mstolove  
Oct  9 08:09:41 obstin8 elogd[20614]: xrealloc: not enough memory  
  
This is on a Slackware 10 box using kernel 2.6.7. Elogd is accessed  
directly, not through an Apache proxy.  

This problem has been fixed in revision 1.491 and will be published in version
2.5.4-6.

We are trying to use ELog on Windows XP with Protection on individual log 
book and we unable to login after creating users even if we give correct 
user name and password login screen reappears. We are able to log in to the 
Elog when we use windows 98 Client we are running Elog on Windows XP and 
without password protection on logbook it is working fine with windows 98.

For win xp clients we are using winxp sp 1, ie 6.1 using a proxy server

> W

> >

> > > We are trying to use ELog on Windows XP with Protection on individual log 
> > > book and we unable to login after creating users even if we give correct 
> > > user name and password login screen reappears. We are able to log in to the 
> > > Elog when we use windows 98 Client we are running Elog on Windows XP and 
> > > without password protection on logbook it is working fine with windows 98.
> > > 
> > > For win xp clients we are using winxp sp 1, ie 6.1 using a proxy server
> > 
> > First, upgrade to 2.5.4-5 (if you haven't done so). If the problem persists,
> > please start elogd on the server with the "-v" flag, capture the screen output
> > and send it to me by email so that I can have a look. Please send also your
> > elogd.cfg file.
> > 
> > - Stefan
> 
> Mr. Stefan
> 
> Following is elogd.cfg file text:
> 
> [global]
> port = 8080
> Main Tab = Home
> Protect Selection page = 1
> 
> [Daily Log]
> Password file = pwdfile
> Self register = 0
> Login expiration = 0
> Admin user = user
> Logout to main = 1
> Theme = bubbles
> Comment = Daily Call tracking and Issue Solving
> Attributes = Author, Type, Category, Subject
> IOptions Author = icon6.gif, icon7.gif
> Options Type = Routine, Software Installation, Problem Fixed, Configuration, Other
> Options Category = General, Hardware, Software, Network, Other
> Extendable Options = Category
> Required Attributes = Author, Type
> Page Title = ELOG - $subject
> Reverse sort = 1
> Quick filter = Date, Type

Mr. Stefan

We tried installing elog on another pc with almost the same configuration and are 
able to run it without any problems now.

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

No big deal - I looked at the code and you did a much more thorough job than I
would have done. Appreciate all of the hard work -- this product is masterful!

> 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 am getting the following error message with version 2.5.4-4 when I try to
add a new entry to a log book.

Attachment file "" empty or not found

If I add the following line to me elogd.cfg I do not get the error, but will
not be able to use attachments.

Enable attachments = 0

I recently upgraded from version 2.2.5 which did not have the problem.  I
did not see anything in the changelog referencing this type of change to how
attachments are handled.

I there something I need to set in the config so that an attachment is not
expected every time a new entry is made?

That problem has been fixed in 2.5.4-5

There are too many <table> tags when displaying a singel entry.  E.g.
in http://midas.psi.ch/elogs/Config+Examples/1 the row 'Configuration Name'
is not aligned with the others (see attachment).

Looking at the HTML one sees that there are <table> tags for each row
which should not be there:

<tr><td><table width="100%" cellpadding=0 cellspacing=0><tr><td nowrap
class="attribname">Author:</td><td class="attribvalue">
Stefan Ritt&nbsp</td>
</tr></table></td></tr>

> There are too many <table> tags when displaying a singel entry.  E.g.
> in http://midas.psi.ch/elogs/Config+Examples/1 the row 'Configuration Name'
> is not aligned with the others (see attachment).

The <table> tags are there on purpose. As you can combine several attributes
into one line (see this forum for example), it's necessary to make an
independent <table> for each line. This causes the shifting as you noted
correctly. To avoid this, simple increase the width of the attribute name field
in the CSS file. Edit <elo>/themes/default/default.css, find the section with
".attibname" and change the width from 150px to 200px, such as

.attribname {
  width:200px;
  background-color:#CCCCFF;
  border:1px solid #0000FF;
  border-top:1px solid white;
  border-left:1px solid white;
  padding:3px;
}

I tried this with http://midas.psi.ch/elogs/Config+Examples/1, and it wroked
fine (see attachment). [I had to increase the text size a bit in my browser to
reproduce the initial problem]

> > There are too many <table> tags when displaying a singel entry.  E.g.
> > in http://midas.psi.ch/elogs/Config+Examples/1 the row 'Configuration Name'
> > is not aligned with the others (see attachment).
> 
> The <table> tags are there on purpose. As you can combine several attributes
> into one line (see this forum for example), it's necessary to make an
> independent <table> for each line. 

Couldn't one include the extra <table> tag only when there is really more than
one attribute per line.  All other lines could then be aligned properly.

To increase the width is not really a solution, since this depends on the
text size used.  See attachment with really big text.

> Couldn't one include the extra <table> tag only when there is really more than
> one attribute per line.  All other lines could then be aligned properly.

Sure one can do a lot of things if one has enough time and not tens of other
requests on the wishlist which really concern some functionality and not just
cosmetics.

> > Couldn't one include the extra <table> tag only when there is really more than
> > one attribute per line.  All other lines could then be aligned properly.
> 
> Sure one can do a lot of things if one has enough time and not tens of other
> requests on the wishlist which really concern some functionality and not just
> cosmetics.

Ouch!
And just to add insult to injury, the same <table> structure doesn't even look the
same between, say, IE6.0 and FireFox 0.9!!

Stefan, keep up the good work!

> > > Couldn't one include the extra <table> tag only when there is really more than
> > > one attribute per line.  All other lines could then be aligned properly.

I added that code in revision 1.471.