I just checked the current installatin, and just found one MIME-Version in the header, even with attachments:

MIME-Version: 1.0
--------------717E3059287C82F12BC14941
Content-Type: multipart/related;
  boundary="------------4543EB0E5AAC14B461D70512"

No idea where your second header comes from, but sometimes I have seen some SPAM filters adding things to headers.

Stefan

Hi,
  I'm using elog 3.1.3 and I have an elogbook with an attribute with name 
Attributes = Author, CO2 Temp [deg], ...

If I add this attributes to quick list, 
Quick filter = Author, CO2 Temp [deg]

it does display on web page, but the search fails with "ERR_TOO_MANY_REDIRECTS" if I leave the default value in the corresponding quick filter box.

My understanding is that the presence of a "[]" in the default search value is the reason for failure and if I remove them the search works fine.

Is there a workaround?

I don't want to change the attribute name, since I do have quite a large number of entries in the elogbook, and I'd like to keep the attribute in the quick search if possible.

Thanks,
  Stefano

No, there is no quick workaround. The only way is to go through your logbook files manually (or with a script), and replace all occurrences of that attribute.

Stefan

Hello,

I am using Elog v3.1.1. When entries contain embedded images, these images are attached to the email notifications but are not properly displayed in the body of the email.
Is it expected?
For example, with an image file myimage.png the email source code contains <img alt="" height="150" src="190208_143305/myimage.png.png" width="200">
Maybe the email should make use of the Content-ID of the attached image?

Your observation is correct. The mailer inside elog should scan all email bodies and replace all <img> tags correctly. I put that on my todo list.

Stefan

Hello,

Somehow when replying to a log entry, a log entry was created that was referring to itself. How this happened, I have no idea. The effect was that each time this enty was loaded, the elogd started to hang, going to 100% load and not responding to any http requests anymore. This problem can be reproduced by manually creating such a self-referencing log entry (see attachment). The problem entry that leads to the crash can be made by editing any elog entry and adding a line "Reply to: X" and a line "In reply to: X" where X is the MID of this entry.

1) Maybe it is possible to add a check when writing files that ensure, that is a log entry does not reference itself.
2) Maybe when loading files are preparing the thread view, elogd can detect cycles and abort.

First, thank you so much for elog;
after using it for about 3 years, it has proven really handy and reliable.

When there is a very long URL in a message in "plain" encoding,
and this message is displayed in a list of messages,
a very long scrollbar appears at the bottom (same "scroll width" as the URL)
and some tabs and and dropdowns (filters) are unreachable without scrolling.

This does not happen if

• the message is displayed in single message page
• the message has a ELCode encoding

The exact version used is
0b9f7ed0 Merge branch 'develop'

There are no relevant instructions in elog.css for .messagelist,
and I did not find any obvious fix in the source code.

submissions via the elog - program can overwrite entries even if the user has no edit rights