Re: email message id, posted by David Pilgram on Wed Jan 13 10:51:24 2010
|
| Stefan Ritt wrote: |
|
| george papalexis wrote: |
|
We noticed some elog email messages were not showing up in our inboxes at random. What we believe is happening is when a elog entry is created it is assigned a message id that the mail servers will use. If a message is edited that same message id is used and some mail servers involved will ignore the duplicate message id. We have also noticed when a elog entry is deleted the next entry created will assume the deleted entry message id and just like above the email will be ignored since it has a duplicate message id.
|
The message ID is part of the "user data" of the email, not of the standard email header. So the mail servers "do not know" about the message ID, which make it strange that double messages are filtered. Nobody else reported this problem before. Maybe is it related to your SPAM filter? Can you check if the double entries are classified as SPAM in your case?
|
Hi Stefan,
I seem to recall this behaviour on this forum. I was writing an entry, and due to mis-typing, submitted the entry before I had finished. So I edited it, but there was only the one email sent. I thought that this was how the thing was supposed to work. To try it now, I am going to submit this, then edit the entry a little further, and we can all see if one or two emails are generated. |
|
Re: email message id, posted by Stefan Ritt on Wed Jan 13 11:00:57 2010
|
| David Pilgram wrote: |
|
| Stefan Ritt wrote: |
|
| george papalexis wrote: |
|
We noticed some elog email messages were not showing up in our inboxes at random. What we believe is happening is when a elog entry is created it is assigned a message id that the mail servers will use. If a message is edited that same message id is used and some mail servers involved will ignore the duplicate message id. We have also noticed when a elog entry is deleted the next entry created will assume the deleted entry message id and just like above the email will be ignored since it has a duplicate message id.
|
The message ID is part of the "user data" of the email, not of the standard email header. So the mail servers "do not know" about the message ID, which make it strange that double messages are filtered. Nobody else reported this problem before. Maybe is it related to your SPAM filter? Can you check if the double entries are classified as SPAM in your case?
|
Hi Stefan,
I seem to recall this behaviour on this forum. I was writing an entry, and due to mis-typing, submitted the entry before I had finished. So I edited it, but there was only the one email sent. I thought that this was how the thing was supposed to work. To try it now, I am going to submit this, then edit the entry a little further, and we can all see if one or two emails are generated.
|
Well, I see just one email notification, have you already submitted your second? I tried on the "Demo" logbook here and I got two notifications. This can of course be turned off with the option "Suppress email on edit = 1". Maybe you are using this? |
|
Re: email message id, posted by george papalexis on Fri Jan 15 17:36:54 2010
|
| Stefan Ritt wrote: |
|
| george papalexis wrote: |
|
We noticed some elog email messages were not showing up in our inboxes at random. What we believe is happening is when a elog entry is created it is assigned a message id that the mail servers will use. If a message is edited that same message id is used and some mail servers involved will ignore the duplicate message id. We have also noticed when a elog entry is deleted the next entry created will assume the deleted entry message id and just like above the email will be ignored since it has a duplicate message id.
|
The message ID is part of the "user data" of the email, not of the standard email header. So the mail servers "do not know" about the message ID, which make it strange that double messages are filtered. Nobody else reported this problem before. Maybe is it related to your SPAM filter? Can you check if the double entries are classified as SPAM in your case?
|
Here is the mail log:
Jan 12 13:51:54 techies lmtpunix[3184]: dupelim: eliminated duplicate message to user.jf id <neteng-1067@emich.edu> (delivery)
The message id we are experiancing problems with is in the header;
Message-ID: <neteng-1073@emich.edu>
Thank you for the help.
|
Problem using attribute type , posted by soren poulsen on Wed Feb 17 17:02:38 2010
|
Hi,
This little logbook has a problem:
------------------------
Attributes = Author, Category, Type, Subject, Number
Type Number = numeric
Options Category = General{1}
{1} Options Type = Routine
------------------------
(it was of course more complicated to start with).
When creating a new entry and selecting the Category option, there is a problem with the JavaScript which will populate the Type option.
To avoid the problem, I just comment out the line "Type Number ... "
Is this a bug ?
Thanks for your time
Soren
(P.S. Using a reserved name as an attribute name is maybe not optimal, but it does not seem to be the problem).
|
|
Re: Problem using attribute type , posted by soren poulsen on Thu Feb 18 13:21:15 2010
|
| soren poulsen wrote: |
|
Hi,
This little logbook has a problem:
------------------------
Attributes = Author, Category, Type, Subject, Number
Type Number = numeric
Options Category = General{1}
{1} Options Type = Routine
------------------------
(it was of course more complicated to start with).
When creating a new entry and selecting the Category option, there is a problem with the JavaScript which will populate the Type option.
To avoid the problem, I just comment out the line "Type Number ... "
Is this a bug ?
Thanks for your time
Soren
(P.S. Using a reserved name as an attribute name is maybe not optimal, but it does not seem to be the problem).
|
To overcome this problem it is sufficient to switch language from "Language = french" to "Language = english"
It was a mistake not to include the "global" settings in this bug report.
What probably happens is that something in the French translation (accents ?) disturbs the java scripting.
Soren
|
|
Re: Problem using attribute type , posted by soren poulsen on Thu Feb 18 15:37:07 2010
|
| soren poulsen wrote: |
|
| soren poulsen wrote: |
|
Hi,
This little logbook has a problem:
------------------------
Attributes = Author, Category, Type, Subject, Number
Type Number = numeric
Options Category = General{1}
{1} Options Type = Routine
------------------------
(it was of course more complicated to start with).
When creating a new entry and selecting the Category option, there is a problem with the JavaScript which will populate the Type option.
To avoid the problem, I just comment out the line "Type Number ... "
Is this a bug ?
Thanks for your time
Soren
(P.S. Using a reserved name as an attribute name is maybe not optimal, but it does not seem to be the problem).
|
To overcome this problem it is sufficient to switch language from "Language = french" to "Language = english"
It was a mistake not to include the "global" settings in this bug report.
What probably happens is that something in the French translation (accents ?) disturbs the java scripting.
Soren
|
To use "Language = french" it is necessary to remove or substitute the accent character ' with something else in eloglang.french and then the Javascript code works again.
Soren |
|
Show Attributes, posted by Ulf Helmersson on Wed Feb 24 15:54:40 2010
|
This programing have stoped working, I guess after last update.
Elog is running on Solaris.
Ulf Helmersson
Options Type = Journal Article{1}, Proceeding Article{2}, Book chapter{3}, Book{4}, Patent{5}
{1} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Abbrivated journal name, Volume, First page, Year, Elsevier format, AIP/APS format, IOP format
{2} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Conference name, Place, Country, First page, Year, Month.Days, Volume, Elsevier format Proceeding
{3} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Book Title, Editors, Publisher, Place, First page, Year, Elsevier format Book chapter
{4} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Publisher, Place, First page, Year, Elsevier format Book, IOP format Book
{5} Show Attributes = Type, Logged by, Key words, File, File path, Authors, Title, Patent number, Year, First page, Elsevier format Patent
|
Re: Thread view problem in searches, posted by soren poulsen on Sat Mar 6 20:53:25 2010
|
|
soren poulsen wrote:
|
|
Hi,
When I upgrade from build 2278 to 2282 the thread view changes when performing searches: The thread children are not indented and there are no "thread icons" in the search list (e.g. like the read right arrow for replies).
On the forum site I also note that the thread view is not indented when performing searches.
Does anyone have an idea ?
Soren
|
This seems to be a bug. I reproduced it with a different browser (Opera) with the default ELOG configuration. When I do Find and select Display Threads I have the message icons but the layout is not correct. Also, all message icons are of the "reply" type even if they are new threads.
This concerns only the latest build 2282.
Soren
|
|