according to the users guide,

http://midas.psi.ch/elogs/Database/?cmd=New&pType=PC

should create an entry with the type value set to PC, but this doesn't work

> according to the users guide,
> 
> http://midas.psi.ch/elogs/Database/?cmd=New&pType=PC
> 
> should create an entry with the type value set to PC, but this doesn't work

Now it works. Updated elog version under CVS and as a snapshot (see Download Page)

> according to the users guide,
> 
> http://midas.psi.ch/elogs/Database/?cmd=New&pType=PC
> 
> should create an entry with the type value set to PC, but this doesn't work

Thanks!

With the "Preset text = " specified, when re-editing a logbook entry (say to
correct a spelling error) the text of the "Message" is replicated and placed
directly below the original text.

Commenting out the "Preset text = " line prevents this behavior.  this
occurs under both FireFox and IE6.0 clients.

> With the "Preset text = " specified, when re-editing a logbook entry (say to
> correct a spelling error) the text of the "Message" is replicated and placed
> directly below the original text.

That should be fixed since revision 1.370 from Jul 7th, 2004. Please update.

> > With the "Preset text = " specified, when re-editing a logbook entry (say to
> > correct a spelling error) the text of the "Message" is replicated and placed
> > directly below the original text.
> 
> That should be fixed since revision 1.370 from Jul 7th, 2004. Please update.

Thanks!

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.

> I get the following in my THREADED logbook view:
> 
> "Adding new services, planned for 1090519200. Last revised: Thu Jul 15
> 18:03:52 2004"

That should be fixed by the current version. Please update.

> > I get the following in my THREADED logbook view:
> > 
> > "Adding new services, planned for 1090519200. Last revised: Thu Jul 15
> > 18:03:52 2004"
> 
> That should be fixed by the current version. Please update.

Thanks!

I just updated ELOG using the latest elogd.c, and now my Quick Filters seem 
to stop working after the first or second filter attempt. I find that if I 
allow fewer quick filter options it seems to work more consistently. For 
example:

Example 1-
Quick filter = Date
The date filter will work without a problem no matter how many times I use 
it.

Example 2-
Quick filter = Date, Category, Status, Priority
The first filter I use will work, but upon trying a new filter, or just a 
new option in the same filter, all options return to "All Entries" and no 
filter options have any effect on the view.
If I exit the log book, and come back in, it works for the first filter 
attempt, then stops again.

This used to work fine prior to the update. I should also mention that the 
original installation of ELOG was from the Debian package. At that point, 
nothing was where the documentation said it should be (e.g. elogd.cfg was 
called elog.conf and was placed in the /etc/ directory). Everything worked 
fine, so I left it alone. When I recompiled with the newer elogd.c, 
anything that required a path was hosed, so I now have to specify the 
resource directory and the path to the conf file when starting ELOG. I 
don't know why this would affect the Quick Filter, and I'd assume that it 
would just stop working all together. Also, when I recompiled using "gcc -
O -o elogd elogd.c", I received the following warning:

elogd.c:546: warning: conflicting types for built-in function `logf'

Any suggestions?

Thanks!
Todd

> I just updated ELOG using the latest elogd.c, and now my Quick Filters seem 
> to stop working after the first or second filter attempt.

Can you try if you can reproduce the problem with the current version? I tried
your settings and could not reproduce it. I remember that I fixed some problems
with quick filters, but that was some time ago (Apr 04). If the problem
persists, can you send me your exact elogd.cfg?

> > I just updated ELOG using the latest elogd.c, and now my Quick Filters seem 
> > to stop working after the first or second filter attempt.
> 
> Can you try if you can reproduce the problem with the current version? I tried
> your settings and could not reproduce it. I remember that I fixed some problems
> with quick filters, but that was some time ago (Apr 04). If the problem
> persists, can you send me your exact elogd.cfg?

Recai Oktas replied to me and let me know that I needed to use dpkg to create the 
new Debian package instead of manually compiling it. I reverted to the original 
Debian package to get everything running normally again, but I haven't had a 
chance to try the upgrade again. As soon as I went back to the original elogd 
everything worked fine (no changes to the elog.cfg required). I'm assuming that 
the problem came from attempting to recompile a Debian package install manually. 
Sorry for the bug scare!

Todd

Something to add to the wishlist:

- Type <attribute> = user

This would define an attribute as being of the type "user" which is a list
of login id's as defined in a password file or on the "Login user =" line. 
In a dataentry form the presence of this ATTRIBUTE would result in a
picklist of loginid's and/or fullnames.

Acknowledged. Added your vote to the wishlist.

> Acknowledged. Added your vote to the wishlist.

Thanks!

Just compiled 1.410 and have run into an issue that *may* have been
introduced in 1.393.

Config file directives such as "Welcome title" could be very long strings. 
After compiling 1.410, our "Welcome title" is truncated and, while I haven't
counted the actual chars, I suspect that the truncation happens at 1024
characters.  The procedure 'getcfg' has a declared passed paramater "int
vsize". 

I haven't looked to see if this effects any other large configuration
strings that are managed by "getcfg" but this procedure is perhaps the most
popular one by far in elog.

> Just compiled 1.410 and have run into an issue that *may* have been
> introduced in 1.393.
> 
> Config file directives such as "Welcome title" could be very long strings. 
> After compiling 1.410, our "Welcome title" is truncated and, while I haven't
> counted the actual chars, I suspect that the truncation happens at 1024
> characters.  The procedure 'getcfg' has a declared passed paramater "int
> vsize". 

Actually before 1.393 you got a buffer overflow if any string in the
configuration file was longer than 500 chars, so it's a miracle that your elogd
did not crash on the long Welcome Title. I added the "vsize" parameter to avoid
such crashes. To satisfy your need for a long Welcome title, I increased the
string size for that particular case to 10000 chars. Hope this is enough.

> > Just compiled 1.410 and have run into an issue that *may* have been
> > introduced in 1.393.
> > 
> > Config file directives such as "Welcome title" could be very long strings. 
> > After compiling 1.410, our "Welcome title" is truncated and, while I haven't
> > counted the actual chars, I suspect that the truncation happens at 1024
> > characters.  The procedure 'getcfg' has a declared passed paramater "int
> > vsize". 
> 
> Actually before 1.393 you got a buffer overflow if any string in the
> configuration file was longer than 500 chars, so it's a miracle that your elogd
> did not crash on the long Welcome Title. I added the "vsize" parameter to avoid
> such crashes. To satisfy your need for a long Welcome title, I increased the
> string size for that particular case to 10000 chars. Hope this is enough.

Hmmm, it is a wonder.  Our welcome text was not significantly longer (about 20
chars longer) so perhaps . . . ?

Thanks, will recompile and report back.

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 

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

Yes, I fixed this. Revision 1.412 under CVS, new snapshot for Windows at the
download page.

I did not have the following problem in any snapshot before 23.7.04 .
Actually I do not have a possibility to test the snapshot under an other
system than win xp pro sp 1 (fully pached). 

Using my logbooks as well as the demo logbook works well under older
snapsgots of 2.5.3 as well as long as the "List Display = <attributes>" is
not used!

Using "List Display = <attributes>" produces an ususal output with the text
field content in the first row and a row title of the first 3 letters.

Ex.:
Attributes = Customername, Customeraddres
List Display = Customername, Customeraddres

Output:
¦Cus¦Customeraddres¦

If no record is in the logbook, only the "Cus" is dispalyed! Removing "List
Display = <attributes>" produces a normal output with same logbook!

By the way: Thnak's for the Format in the entry/edit view!!!

> Using "List Display = <attributes>" produces an ususal output with the text
> field content in the first row and a row title of the first 3 letters.

I fixed that problem. Please get the snapshot from July 28th 14:16.

Thank you very much Stefan!!!

Also the horizontal alignement with "Format = 1" looks much better   as before
with standard css files! Really great work!

> > Using "List Display = <attributes>" produces an ususal output with the text
> > field content in the first row and a row title of the first 3 letters.
> 
> I fixed that problem. Please get the snapshot from July 28th 14:16.