I'm not sure if this is what you want.

If you want to prevent "accidental" replies being identical to the original message, you can force a situation where the user will be alerted that they have to do something if they really want to make a reply. 

An example.  I have an attribute "Action".  In order to make a reply.  I have set up that I must select an Action attribute every time.  If I forget, I get an error message screen, and can click to go back to the entry and have another attempt (nothing is deleted if you have added to the reply).

In the elog.cfg file, I have the lines

Required Attributes =  Action

Preset on reply Action = 

This hopefully would remind them that they are making a reply to an entry, and either make a reply, or abort the attempt.

I was only commenting on the predicament as I have run into it also.  I have required fields, but short of some sort of "abort" control (curiously missing from the otherwise vast offerings of elog), I don't see any way to ensure that identical replies don't occur in any circumstance that may arise.

My feeling is that an additional option to elog is appropriate, one that disables -- completely -- identical replies to a message.   I am not asserting that this must be done, just that it might be the only truly efficacious way to eliminate this issue.   Again, I was only commenting on it, but I would like to see such a feature implemented in elog.  I believe it can be justified because this would seem, intutitively, to be a potential problem for almost anyone using elog. 

I hope you will receive my response here in the constructive and friendly manner it is intended.

Hi Harry,

I'm just an elog (ab)user, not one of the developers.  My original 2017 reply was to report an issue that was due to hardware, but somehow overcame a configuration flag (no multiple replies to a single entry), which might have been the same problem as the original poster, Alan Grant, was observing, where one real reply mysteriously became two identical ones.  That appears to be different to the issue you have.

There is an "Abort" button; in version 2.9.2 it is "Back" (without a warning), somewhere along the development it because "Delete" (with a warning), but that only covers circumstances where a reply is started by accident/unintentionally and then it is realised.  My previous suggestion certainly would alert the replier that they have to do something - even if only selectiing an "Action" - before the new entry would be accepted,  This suggests that you have a circumstance where the reply being a duplicate of the entry is a real issue, and that neither of the suggestions above would help.  Don't forget, some people may *want* this.

It would be for Stefan and Andreas to put this on the elog wish-list.  I am a little puzzled as to how your problem arises - lazy user? - so perhaps more comment as to how this is occurring will help Stefan and Andreas understand the why.  There is somewhere on this site a page where you can add suggestions for the wish-list, but due to security certificate issues, I can only access the Forum at present and cannot point you to it.

Hi,

I hope I'm not missing the blindingly obvious here, but I have an issue with time and date formats

Extract from my elog.cfg file:


Time format = %a %d %b %y
Date format = %d %b
Thread display = $Ticket: $System, $entry time. ($message id). $status
Preset text = [$date]
Prepend on reply = [$date] \n

I can point to places in the syntax doc where each of these lines are given.

As for the results, the thread display is (for example):

T00001: Computer, Wed 29 Aug 12. (1). Problem

However, what I get at the top of the text box in starting a new entry or replying to a previous one is

[Wed 29 Aug 12]

whereas I expected to get

[29 Aug]

Putting $date instead of $entry time in the Thread display line makes (the by now expected) no difference

I cannot see where I'm going wrong.  

TIA 

David.

OK, I see that $date can work in a different way; if the Thread display uses $date,
then the present timestamp is substituted into the thread display line, rather than the 
date that the entry is entered.  So, for example, in a whole list of entry and replies, the present
date shows on each entry of the thread.  However, the format is still that as defined by
'Time format' rather than 'Date format'.

If nothing else, I cannot really see the point of the 'Date format =' in the way that this all works.

> Hi,
> 
> I hope I'm not missing the blindingly obvious here, but I have an issue with time and date formats
> 
> Extract from my elog.cfg file:
> 
> 
> Time format = %a %d %b %y
> Date format = %d %b
> Thread display = $Ticket: $System, $entry time. ($message id). $status
> Preset text = [$date]
> Prepend on reply = [$date] \n
> 
> I can point to places in the syntax doc where each of these lines are given.
> 
> As for the results, the thread display is (for example):
> 
> T00001: Computer, Wed 29 Aug 12. (1). Problem
> 
> However, what I get at the top of the text box in starting a new entry or replying to a previous one is
> 
> [Wed 29 Aug 12]
> 
> whereas I expected to get
> 
> [29 Aug]
> 
> Putting $date instead of $entry time in the Thread display line makes (the by now expected) no difference
> 
> I cannot see where I'm going wrong.  
> 
> TIA 
> 
> David.

I upgraded my system, including the version of Firefox.

I normally view the topic in Threaded Collapsed mode, right click on the entry I want to reply to, to open a new
Tab.  However, I made a mistake an opened a new Window, as the two 'open' modes in Firefox swapped around.
But no worry, I thought, made my reply as usual.

However, when refreshing the topic afterwards, seemingly randomly distributed throughout the topic were
additional lines, with the latest entry showing up emboldened (but not as a clickable link), and the only
difference being the ID number which showed as 0 (zero).

Deleting the reply only caused the previous reply to show up randomly etc.

In effect, the latest entry is (randomly?) scattered throughout the topic - even in between entries older than
any in that thread, so it's not individial entries in that thread showing up.

The only way to get rid of it was to erase the whole directory, and re-install from backup (which, as it was the
first entry since the new installation, wasn't painful).  It's been fine since - but only so long as I open a
thread in a new tab, and not in a new Window.

I guess the real question is just what is added to some file - perhaps the .cfg file? - that using a separate
window causes this behavioir?  Any whay only as a new window, and given how elog is supposed to work on many
computers, why on this stand-alone computer running two sets of the same browser?

It happened once before at the end of last year during a regression backwards owing to the newer computer
failing and turning back to an older one with older OS and older firefox, where I did the same thing (in
reverse).  As I didn't investigate at that time, I still have the mystery line showing up in that topic.

Sorry this is a bit rambling, but its very hard to describe!

> I upgraded my system, including the version of Firefox.
> [...]
> Sorry this is a bit rambling, but its very hard to describe!

A picture can say more than thousand words.
Can you reproduce this with a simple configuration?
If yes, can you attach the configuration, the *a.log files,
a description of what firefox version you're using and please:
some screenshots of "before" and "after"?

Thanks!
Andreas