I'm trying to use gmail to send password recovery e-mails, I get this error when I submit the email address.

"Error sending Email via "smtp.gmail.com": 5.7.0 Must issue a STARTTLS command first. 2sm5111524agd.34"

Any help or insight would be appreciated.

Ed... 

gmail uses TLS (Transport Layer Security) for the mail communication, which is currently not supported by elog. 

Hi Stefan,

I don't know if anyone else would be interested or need this...

If you have an Roption, and it is not required (maybe...) or have a preset attribute, it is possible to make an
entry and have replies without any of the attributes in that Roption being selected.

However, once an attribute in that Roption has been selected, it is not possible to go back (editing) to the
condition before one was selected on that entry (so far as I can tell).  

Is a way of cancelling all the possible attributes in an Roption practical?  Would others want it?  It is
possible with options, as there is a "please select" which can be used to cancel whichever attribute in the
option that has been selected.

Regards,  David

> Hi Stefan,
> 
> I don't know if anyone else would be interested or need this...
> 
> If you have an Roption, and it is not required (maybe...) or have a preset attribute, it is possible to make an
> entry and have replies without any of the attributes in that Roption being selected.
> 
> However, once an attribute in that Roption has been selected, it is not possible to go back (editing) to the
> condition before one was selected on that entry (so far as I can tell).  
> 
> Is a way of cancelling all the possible attributes in an Roption practical?  Would others want it?  It is
> possible with options, as there is a "please select" which can be used to cancel whichever attribute in the
> option that has been selected.
> 
> Regards,  David

The easiest to achieve this is to define another option. Assume you have the three options

One, Two, Three

and you want to "unselect" them. So just add a fourth option like

Unspecified, One, Two, Three

so if you do not want any of the "One, Two, Three", just click on "Unspecified" and you get what you want.

> > Hi Stefan,
> > 
> > I don't know if anyone else would be interested or need this...
> > 
> > If you have an Roption, and it is not required (maybe...) or have a preset attribute, it is possible to make an
> > entry and have replies without any of the attributes in that Roption being selected.
> > 
> > However, once an attribute in that Roption has been selected, it is not possible to go back (editing) to the
> > condition before one was selected on that entry (so far as I can tell).  
> > 
> > Is a way of cancelling all the possible attributes in an Roption practical?  Would others want it?  It is
> > possible with options, as there is a "please select" which can be used to cancel whichever attribute in the
> > option that has been selected.
> > 
> > Regards,  David
> 
> The easiest to achieve this is to define another option. Assume you have the three options
> 
> One, Two, Three
> 
> and you want to "unselect" them. So just add a fourth option like
> 
> Unspecified, One, Two, Three
> 
> so if you do not want any of the "One, Two, Three", just click on "Unspecified" and you get what you want.

This is sort of what I do now, I just wondered if there was a way of clearing that would leave the field completely
blank in the YYMMDDa.log file.

Thanks.

When adding a log entry containing a datetime field using the IE7 browser a Javascript warning is displayed - see the attachment.  This is due to a change in the naming of the "seconds" field of a datetime entry (made in version 2143) not being propagated to the code that generates the Javascript that checks the supplied values.

Suggested patch follows.

Change "s%d" to "c%d" in lines 9675 and 9678.

Showing lines 9675-9680 below, change from:

               rsprintf("  if (document.form1.s%d.value == \"\") {\n", i);
               sprintf(str, loc("Please enter second for attribute '%s'"), attr_list[i]);
               rsprintf("    alert(\"%s\");\n", str);
               rsprintf("    document.form1.s%d.focus();\n", i);
               rsprintf("    return false;\n");
               rsprintf("  }\n");

to:

               rsprintf("  if (document.form1.c%d.value == \"\") {\n", i);
               sprintf(str, loc("Please enter second for attribute '%s'"), attr_list[i]);
               rsprintf("    alert(\"%s\");\n", str);
               rsprintf("    document.form1.c%d.focus();\n", i);
               rsprintf("    return false;\n");
               rsprintf("  }\n");

Regards,

Richard Stamper

This is absolutely correct, even the right fix. I put that into the distribution. Thanks a lot. 

Thumbnail size = 0

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. 

 Thanks for looking at the suggestion - it was only a 'nice to have', whereas elog is an essential!

regards

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.

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

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.

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. 

This must be related to the unknown cookie "style". There was some work recently on elog to make it robust against unknonw cookies. The latest modification was on version 2192, and you probably have an older version. I made a release elog276-2.exe for you. Try it and let me know. You can also just delete your cookies in Firefor and it should be fine, but it's better not being able to crash elog. 

It's here. 

Ah, the GET /nor/elog.rdf gave me somt hint: Your Firefox browser checks the RSS feed of elog regularly. If the logbook is empty, the routing producing the elog.rdf file went into some kind of infinite loop, but this only happens on an empty logbook. If fixed this and updated the 276-2 file just now, so try again.

Thanks for your help