I have an attributes defined as:

 - Attributes = Author, PlannedDate, FunctionalArea, Operation, Category,
HardwareName, Significance, EmailNotify, LastRevision, Subject

I have PlannedDate defined as:
 - Type PlannedDate = date

When I use the following statement:
 - Thread display = $subject, planned for $PlannedDate. Last revised:
$lastrevision

I get the following in my THREADED logbook view:

"Adding new services, planned for 1090519200. Last revised: Thu Jul 15
18:03:52 2004"

Note that the ATTRIBUTE $PlannedDate prints as a (I am guessing) serialized
date and is not formatted.

I'm not sure if this is manifested elsewhere.

Hi Stefan 
YOu have been a great help on the Elog problem solving .
I have another sort of bug , when i have a attribute type as date.
And i have fixed the attribute on reply , i actually get a string of 
number when i reply , and the date becomes not the orginal date in the 
first message.

So the way i work ard is that i did not place the date field in the fixed  
attribute reply which i will run the risk of pple modifying that entry .
Can this be fix?

Thanks 

> > A temporary fix for this is to set summary lines = 0
> 
> Right, that's the only way. I would call this "permanent fix" (;-)

I would too - and it actually produces the output that I wanted to see anyway.

Thanks!

> > Ok, I think I see now.  I was assuming it applied to the entry form as well.
> 
> Well, good idea. I implemented that. Have a look at this forum (just hit reply to this
> entry) and you'll see it. I'm not completely happy with it (at least on small 1024x768
> screens), but it's configurable anyhow. New version under CVS.

Now that creates an interesting display - especially with the icons and radio buttons. 
But it works!

Thanks.

> Is it possible to add a flag in the configuration file, to specify the 
> maximum size of an attachment?

I implemented a "max content length = xxx" flag, which defaults to 10MB. If an
attachment is larger, an error gets displayed. The problem is that elogd can
only send the error message to the browser *after* it received the whole
request, so it has to "drain" the 240 MB first, which could take quite some
time on a slow connection.

Alternatively, I can cut the connection to the browser immediately, since the
HTTP header contains the content length after the first ~500 bytes, but in
that case the browser only shows a message box "Document contains no data"
which gives the user noe clue of what's wrong.

Anyhow the biggest problem of elog in high stress environments is that it's
single threaded. So if someone issues a search in a large logbook, it could
take some time, in which elog cannot respond to other requests. Maybe I will
find time in the future to make elog multithreaded, but certainly not in the
near future.

> Ok, I think I see now.  I was assuming it applied to the entry form as well.

Well, good idea. I implemented that. Have a look at this forum (just hit reply to this
entry) and you'll see it. I'm not completely happy with it (at least on small 1024x768
screens), but it's configurable anyhow. New version under CVS.

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.

> A temporary fix for this is to set summary lines = 0

Right, that's the only way. I would call this "permanent fix" (;-)