Have a few issues here. The big one is that I have some users of our elog books
that are in India, while the server is in USA. When they click on thumbnail images
then press their browser back-button they get a page expired message and are
unable to see what they were looking at before unless they go back to the main
page. Is this an elog problem or something with Apache?

Also when these users in India write messages sometimes we end up with
duplicate messages seconds apart. I'm not sure if they are pressing the submit
button repeatedly or pressing their browser back button. I've suggested they
try not to do that.

Last issue, is there a way to make thumbnail images open in a new window
by default rather then the same window? This would help fix the first issue at
least. Is there some setting to fix the page expiration/time-out issues?

Regards,
Mike

That's strange. Normal pages are set to "pre-expire" (expiration date 1983...) which forces the browser to always load them from the server. This is necessary since someone else could have modified that page and you would look at an old page in your browser's cache. But using this, I never saw a "page expired" message. The browser simply reloads the page. Maybe if the internet connection got lost in between and the browser cannot load the page from the server, you have a problem. Attached pictures have a expiration date of +1 day. So even if you span different time zones, that should be fine. Can they try to access https://midas.psi.ch/elogs/Linux+Demo/14 and see if they get the same problem there? This is my demo setup and resides in Switzerland.

The only way to get two entries is if you submit your entries twice. The same problem exists on some credit card payment sites, which explicitly state "please be patient, don't press submit twice, don't press back". The same applies for elog. 

No, this is not implemented right now. But if nothing else helps, I can add a new option.

 Stefan,

Thanks for writing back so fast. I'll have the folks in India check that link and see if the problem exists there.
I couldn't duplicate the problem here on my end. I'm beginning to think that it's a connection problem. They
tell me that the elog site (our site) is slow for them. It's only capable of 118kb/sec which, coupled with
the distance from USA to India might make things slow. In the USA I found the site to be usable and not that
slow. I'll let you know what they say about the test link.

Mike

 Stefan,

I talked to my associate from India. He tried that link you provided and claims that even on your
site the "page expired" message occurs. Weird eh? Any ideas?

Not much. Since they are the only ones reporting this problem, I'm tempted to attribute this to their local configuration (browser, proxy, etc.). Have they tried different browsers on different machines?

 I think you are right. I suggested those things to them. I believe this issue is closed here.

 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.