Re: wrapping long lines in config file, posted by W.Koster on Mon Jun 15 12:57:17 2009
|
| Stefan Ritt wrote: |
What I do is to use an editor with automatic wrapping functions, like the free PSPad editor. It nicely wraps line and indicates that:
|
Hmmm... I have to use vi and was hoping an \ at the end of the line (before the LF) would be supported. |
|
Re: wrapping long lines in config file, posted by Stefan Ritt on Mon Jun 15 16:36:38 2009
|
| W.Koster wrote: |
| Stefan Ritt wrote: |
What I do is to use an editor with automatic wrapping functions, like the free PSPad editor. It nicely wraps line and indicates that:
|
Hmmm... I have to use vi and was hoping an \ at the end of the line (before the LF) would be supported. |
Use a real editor 
I seem to remember that Emacs can be configured for automatic line wrapping. |
Denial of access after failed import using invalid attributes, posted by soren poulsen on Wed Jun 17 03:46:31 2009
|
Hi,
A user tried to import a CSV file, which caused e-log to add a field called "date" to the list of attributes (and then crash). This caused the log-book to be blocked until someone (guess who) would go edit the elogd.cfg file and then trigger a reload.
1. suggestion : E-log should not crash in this case
2. suggestion: E-log should not allow invalid attributes to be added via CSV Import, which causes the log-book to be blocked.
For the time being, I will just "Deny import" (by the way, the doc says it is "Deny CSV import", but I think the syntax is "Deny import". Not really important.
I think this should be quite easy to reproduce.
Thanks a lot
Soren |
Export and save problem with IE7, posted by soren poulsen on Wed Jun 17 22:01:57 2009
|
Hi
Would it be possible to use the "Export to:" function with IE7 on the Forum logbook, and save the logbook.
I can do the export but saving the file with IE7 does not work. Saving the file with Firefox, Chrome, Safari works.
This makes me think that E-log is good and IE7 is bad ?
Soren
|
|
Re: Denial of access after failed import using invalid attributes, posted by Stefan Ritt on Thu Jun 25 12:30:17 2009
|
| soren poulsen wrote: |
|
Hi,
A user tried to import a CSV file, which caused e-log to add a field called "date" to the list of attributes (and then crash). This caused the log-book to be blocked until someone (guess who) would go edit the elogd.cfg file and then trigger a reload.
1. suggestion : E-log should not crash in this case
2. suggestion: E-log should not allow invalid attributes to be added via CSV Import, which causes the log-book to be blocked.
For the time being, I will just "Deny import" (by the way, the doc says it is "Deny CSV import", but I think the syntax is "Deny import". Not really important.
I think this should be quite easy to reproduce.
Thanks a lot
Soren
|
If the CSV file contains a "date" column, elogd tries to interprete the date to the internal format. Now a date can be written in a huge number of variations, and I'm sure I did not cover all. So please send me your CSV file and I will fix the crash. |
|
Re: Formatting list page data, posted by Stefan Ritt on Thu Jun 25 15:02:55 2009
|
| Steve Williamson wrote: |
|
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
|
Something along these lines is however not implemented (and hard to do). The only chance you have is to export your data into a spreadsheet and do the reformatting/report generation there. |
|
Re: Export and save problem with IE7, posted by Stefan Ritt on Thu Jun 25 15:37:14 2009
|
| soren poulsen wrote: |
|
Hi
Would it be possible to use the "Export to:" function with IE7 on the Forum logbook, and save the logbook.
I can do the export but saving the file with IE7 does not work. Saving the file with Firefox, Chrome, Safari works.
This makes me think that E-log is good and IE7 is bad ?
Soren
|
Right 
It seems to be a well known probmel with IE: http://classicasp.aspfaq.com/files/directories-fso/how-do-i-send-the-correct-filename-with-binarywrite.html
So I tried all variations there, but none of them worked. The interesting thing is that it works if you use it locally, but not with the forum (which has an additional "/elogs" in the URL).
|
|
Re: Move to: elog crashes with large no of entries being moved., posted by Stefan Ritt on Thu Jun 25 15:55:04 2009
|
> 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.
I reworked the internal memory allocation, since there was a stack overflow going over 24 entries. It should be now
much better. Give a try to revision 2226. |