Possible to submit entries by email to logbook, posted by thorsten kamps on Fri Oct 17 16:59:42 2008
|
Hi, thanks to everyone involved for giving us the elog.
A question:
Is it possible to submit entries to an elog on a remote machine by email?
Thanks, Thorsten |
|
Possible to sort attribute chronologically? , posted by Dennis Seitz on Tue Jan 29 04:25:11 2008
|
Hi,
We've defined a "LastEdit" attribute for some of our logs so that we can indicate that an entry has been revised, and when that was done.
From our config:
Attributes = Last Edit, etc etc
.
.
.
Preset Last Edit =$date
Locked Attributes = Last Edit
Subst on edit Last Edit = $date
This works fine, but when we sort the LastEdit column, the dates are sorted alphabetically. Is there a way to tell Elog to treat this particular attribute
as a date when sorting? |
Possible misuse of email headers Message-Id and In-Reply-To, posted by fbretel on Wed Feb 8 16:38:15 2017
|
Hi,
As mentionned before, we happen to fail to receive email messages related to updates on elog entries at our site. My understanding is that the SMTP header Message-Id MUST be unique for each email message. Whereas all elogd email messages get something like <logbook>-<entryId>@<domain>. See source code. For this header to become unique, there should be a random part in it.
Having the same Message-Id in multiple email messages results in only the first one being delivered on some email systems.
Moreover, elogd sets the In-Reply-To: header in the same manner (<logbook>-<entryId>@<domain>). Which is incorrect because this header relates to email messages, not elog entries, and should contain the email Message-Id of the email message to which it replies, itself handled by the email messaing system. But elogd hasn't received any email messsage in the first place. So I believe this header should simply be dropped.
I think I can provide a pull request on bitbucket for the Message-Id issue, and probably also for the In-Reply-To: if you decide it can be removed.
Cheers |
Possible bug in elogd execute_shell, posted by Nigel Warr on Fri Feb 26 08:38:06 2016
|
I was just playing around with gcc6's new feature for warning about misleading indentation (which can often hide real bugs) and I think it found one in elog-3.1.1-1 at src/elogd.c:22538. Here there is an if statement, which looks as though it should be inside a loop, but it isn't. The code is:
for (i = 0; i < MAX_ATTACHMENTS; i++)
generate_subdir_name(att_file[i], subdir, sizeof(subdir));
if (att_file[i][0] && strlen(shell_cmd) + strlen(lbs->data_dir) + strl$
< sizeof(shell_cmd) + 1) {
strcpy(p, "\"");
strcat(p, lbs->data_dir);
strlcat(str, subdir, sizeof(str));
strlcpy(str, att_file[i], sizeof(str));
str_escape(str, sizeof(str));
strcat(p, str);
strcat(p, "\" ");
p += strlen(p);
}
and the if statment is accessing the loop variable i but it is actually outside the loop. Presumably, there should be some more curly brackets here. gcc6 gave the warning:
src/elogd.c: In function ‘execute_shell’:
src/elogd.c:22538:10: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation]
if (att_file[i][0] && strlen(shell_cmd) + strlen(lbs->data_dir) + strlen(subdir) + strlen(att_file[i])
^~
src/elogd.c:22536:7: note: ...this ‘for’ clause, but it is not
for (i = 0; i < MAX_ATTACHMENTS; i++)
^~~
|
Possible bug in elogd execute_shell, posted by Nigel Warr on Fri Feb 26 08:47:22 2016
|
I was just playing around with gcc6's new feature for warning about misleading indentation (which can often hide real bugs) and I think it found one in elog-3.1.1-1 at src/elogd.c:22538. Here there is an if statement, which looks as though it should be inside a loop, but it isn't. The code is:
for (i = 0; i < MAX_ATTACHMENTS; i++)
generate_subdir_name(att_file[i], subdir, sizeof(subdir));
if (att_file[i][0] && strlen(shell_cmd) + strlen(lbs->data_dir) + strl$
< sizeof(shell_cmd) + 1) {
strcpy(p, "\"");
strcat(p, lbs->data_dir);
strlcat(str, subdir, sizeof(str));
strlcpy(str, att_file[i], sizeof(str));
str_escape(str, sizeof(str));
strcat(p, str);
strcat(p, "\" ");
p += strlen(p);
}
and the if statment is accessing the loop variable i but it is actually outside the loop. Presumably, there should be some more curly brackets here. gcc6 gave the warning:
src/elogd.c: In function ‘execute_shell’:
src/elogd.c:22538:10: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation]
if (att_file[i][0] && strlen(shell_cmd) + strlen(lbs->data_dir) + strlen(subdir) + strlen(att_file[i])
^~
src/elogd.c:22536:7: note: ...this ‘for’ clause, but it is not
for (i = 0; i < MAX_ATTACHMENTS; i++)
^~~
|
|
Possible Formatting bug: Summary view, posted by Steve Jones on Wed Jul 14 22:52:18 2004
|
I've run into a situation where the SUMMARY view of a logbook will extend
beyond the righthand border, thus requiring the user to scroll right. This
does not occur in FULL or THREAD mode. Long lines in the TEXT attribute
appear to be "pushing" the display too far to the right. Limiting the
number of displayed summary lines works unless the first line is too long.
A temporary fix for this is to set summary lines = 0 |
|
Possible Bug: 2.3.7 : Welcome Title = < img src=""> not working, posted by Fred Hooper on Mon May 19 19:14:35 2003
|
Just upgraded (using rpms) elogd from 2.3.5
I am running on RH 7.3
I noticed that my custom start page did not display the Welcome title icon.
It worked fine in prior elogs.
Here's the syntax of the config file:
Welcome Title = <img src="thumb.gif"><p><font size=4 color=white>Elog</font>
Resource dir = /usr/local/elog/
"thumb.gif" is located in /usr/local/elog, and is readable by all.
I also tried the full file name in src=
<img src="/usr/local/elog/thumb.gif"> - same result.
any hints? |
|
Port specification with -p fails under RedHat Linux (2.0.4-1), posted by Joeri Mastop on Mon Jul 15 14:09:30 2002
|
Hello,
I noticed a strange behaviour with Elog 2.0.4 (i386 RPM) in Linux (RH 7.2).
I started Elog out-of-the-box with portnumber 888 ('sbin/elogd -p 888').
It runs just fine, but appears to listen to port 8080, the default! It
looks like the -p option on the command-line is ignored.
Anyone seen similar problems?
Joeri |
|