Greetings,

I was wondering, is it possible to wrap lines in the config file ? 

I have to add a dropdown lost which is kinda long and typing everything on one line will make ik kinda unreadable.
Somehow wrapping the line so each entry will get on a separate line would make it much better readable. (which
makes less errors).

W.
 

Hello

I have the following in elog.cfg :

Attributes = Author, Author Email, Category, Customer, server, Subject ,  Change Window Begin , Change Window End
List display = ID,Author, Author Email, Category, Customer, server,  Subject ,  Change Window Begin , Change Window End

Type Change Window Begin = datetime
Type Change Window End = datetime

So I want to be able to give a start and end date to the user.  However : If I open a find/Search I see this :

There are for each  Change Window <item>   we get  Start: and End: time entries. Was expecting only one date entrie .

Why is this ? Seems to be a feature of datetime  or am i missing something.

> > Hi Stefan,
> > 
> > I've been slowly moving threads, and twice now so far (and reproducably) had elog crash.
> > 
> > In each case, it is trying to move a thread with more than 24 entries; it copies the first 24 entries, then
> > crashes with "Segmentation Fault".  It does not erase the lock file /var/run/elog.pid
> > 
> > I have got around this by manually copying the entries beyond no 24, then deleting the thread entry by entry.
> > 
> > I am aware that I have an old and limited machine (586, 256MB RAM, running Slack 10), and at first I was
> > "content" to write it off as that; but when it crashed for the second time at exactly the same entry (the
> > twenty-forth) even though the size of the entries would have been significantly different, I wondered if there
> > was some factor within  elog that could affect this.
> > 
> > I've not tried it with Copy to:, but imagine it will also be affected as the only difference with this and Move
> > to: is the deletion of the thread after all the entries had been copied.
> 
> This rings a bell: it's probably related to some internal stack overflow, since the entries are copied 
> recursively. I have an idea on how to fix that, but I need time for that.
Thanks Stefan,  I'll be keeping an eye out on any annoucement about this one!

> Hi Stefan,
> 
> I've been slowly moving threads, and twice now so far (and reproducably) had elog crash.
> 
> In each case, it is trying to move a thread with more than 24 entries; it copies the first 24 entries, then
> crashes with "Segmentation Fault".  It does not erase the lock file /var/run/elog.pid
> 
> I have got around this by manually copying the entries beyond no 24, then deleting the thread entry by entry.
> 
> I am aware that I have an old and limited machine (586, 256MB RAM, running Slack 10), and at first I was
> "content" to write it off as that; but when it crashed for the second time at exactly the same entry (the
> twenty-forth) even though the size of the entries would have been significantly different, I wondered if there
> was some factor within  elog that could affect this.
> 
> I've not tried it with Copy to:, but imagine it will also be affected as the only difference with this and Move
> to: is the deletion of the thread after all the entries had been copied.

This rings a bell: it's probably related to some internal stack overflow, since the entries are copied 
recursively. I have an idea on how to fix that, but I need time for that.

Hi Stefan,

I've been slowly moving threads, and twice now so far (and reproducably) had elog crash.

In each case, it is trying to move a thread with more than 24 entries; it copies the first 24 entries, then
crashes with "Segmentation Fault".  It does not erase the lock file /var/run/elog.pid

I have got around this by manually copying the entries beyond no 24, then deleting the thread entry by entry.

I am aware that I have an old and limited machine (586, 256MB RAM, running Slack 10), and at first I was
"content" to write it off as that; but when it crashed for the second time at exactly the same entry (the
twenty-forth) even though the size of the entries would have been significantly different, I wondered if there
was some factor within  elog that could affect this.

I've not tried it with Copy to:, but imagine it will also be affected as the only difference with this and Move
to: is the deletion of the thread after all the entries had been copied.

Thanks for a great piece of software - it does so much and is (mostly) so simple to use.  However, I do have a suggestion that (for me, at least) would make it even better -

I use elog for a variety of logging tasks but find that, because I want to see as complete a summary as possible, the list page can get very crowded with longer fields wrapping over several lines.  I would like to have more control over the way attributes are displayed here.  Specifically, being able to truncate data (e.g. to show just the first n characters of a description), being able to select a substring (e.g. displaying characters before the '@' character to remove the domain from an email address or displaying characters after the space to remove the day from a date in ddd dd/mm/yy format) and being able to concatenate fields (e.g. to show a reference in a single cell as "Incident 1234" by joining call type and call reference attributes).

regards

Steve

Are your sure about the firewall, because this is the usual reason for that problem. Can you "ping" your server machine from the other machine (like "ping <server>"), maybe you have some network problems.

I need some guidedance on how to access the logbook from another computer. I installed the logbook on a Windows server machine and started the logbook using port 81.

I can connect to the logbook on the same machine, but I can not access it from another machine on the same network.

I already confirm that the windows firewall is not enable.