Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 734 of 796  Not logged in ELOG logo
IDup Date Icon Author Author Email Category OS ELOG Version Subject
  69271   Wed Dec 2 22:13:52 2020 Reply Harry Martinharrymartin772@gmail.comQuestionLinux2.9.2-2475Re: Duplicate entries

 

David Pilgram wrote:

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.

Harry Martin wrote:

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.

David Pilgram wrote:

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.

 

Harry Martin wrote:

I find that I can reply to a message ("original" message, if you will) without doing anything to the reply message (the "copy" of the original message, if you will).  If I then submit it, it gets saved as a new message, identical to the one I replied to.

I read through the options at the end of the docs.  I did not see anything about a way to suppress identical messages, or a way to force the user to make some kind of change to make the reply different from the original.

David Pilgram wrote:

I've seen exact;y this effect, even though I have branching = 0 in my config file - so ordinarily no chance to have two
 replies to an entry.  My pointer aka mouse (I'm on Linux) is a bit dodgy, and sometimes disconnects/reconnects, so in effect gives a very fast double click.  I've always assumed that was the cause of the problem.  The two replies have incremental IDs, and both those IDs are listed in the "Reply to" header section of the entry.  I'm not sure how this overcomes the branching = 0 detail, though.

That is what I have assumed, but if others see this on occasion, perhaps it's got a different cause.

Alan Grant wrote:

Periodically (rarely) on manually adding a record into Elog it generates a duplicate record with its own incremented ID and I don't know why. I just delete the duplicate in the meantime but would like to know if anyone else has seen this and whether their is a answer/fix for it. Thanks.

 

 

 

 

 

 

  69272   Wed Dec 2 22:45:16 2020 Question Harry Martinharrymartin772@gmail.comQuestionLinux | Windows | Mac OSX | All | Other3.1.3length of condition names

The documentation describing the use of conditionals uses a single character (letter or number) for names of conditions.  I don't see any update/change to that rule anywhere in the docs.

I have been using multi-character condition names successfully.   I find these are easier to use since they can be more descriptive of each condition.   It works, but I am concerned I may be doing something that might not be supported going forward.   (It is simple enough to change these, but I'd prefer to know if this practice is acceptable.)

Thank you, again, for this fine (and, may I add, fun?) tool.  I'm having a good time with it!

  69273   Thu Dec 3 01:51:49 2020 Reply Harry Martinharrymartin772@gmail.comQuestionLinux | Windows3.1.3Re: Options <...> vs ROptions <...>

Same problem here, in version 3.1.3.   It would be very nice if this worked.

Wolfgang Bayer wrote:

According to section "Syntax of elogd.cfg" of the "Administrator's Guide" Options <attribute> = <list> and  ROptions <attribute> = <list> should be the same. But there is a litle difference, because choosing an entry of the Options-pull-down menu causes a reload of the entry mask while choosing a ROption-radio-button the entry mask is not reloaded. This causes a problem using conditional attributes. The condition is only paid attention to in case of Options but not in case of ROptions. In my case I would like to use ROption, as it is faster to set a radio button than to choose an item in a pull-down menu, but I can't as I have also to use conditional attributes. Is there any solution?

 

  69274   Thu Dec 3 01:53:59 2020 Reply Harry Martinharrymartin772@gmail.comBug reportWindows2.7.7-2246Re: Change / List Change doen't work anymore?

Stefan Ritt wrote:
Yepp, the documentation was wrong. I fixed it.

Stefan


Thank you.
  69275   Thu Dec 3 09:57:20 2020 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux | Windows | Mac OSX | All | Other3.1.3Re: length of condition names

You can easily use multi-character conditionals, up to 256 chars.

Harry Martin wrote:

The documentation describing the use of conditionals uses a single character (letter or number) for names of conditions.  I don't see any update/change to that rule anywhere in the docs.

I have been using multi-character condition names successfully.   I find these are easier to use since they can be more descriptive of each condition.   It works, but I am concerned I may be doing something that might not be supported going forward.   (It is simple enough to change these, but I'd prefer to know if this practice is acceptable.)

Thank you, again, for this fine (and, may I add, fun?) tool.  I'm having a good time with it!

 

  69276   Thu Dec 3 09:58:44 2020 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux | Windows3.1.3Re: Options <...> vs ROptions <...>

For conditional attributes, you have to use Options, not ROptions. Maybe I will implement that one day, but only if I will have plenty of time...

Harry Martin wrote:

Same problem here, in version 3.1.3.   It would be very nice if this worked.

Wolfgang Bayer wrote:

According to section "Syntax of elogd.cfg" of the "Administrator's Guide" Options <attribute> = <list> and  ROptions <attribute> = <list> should be the same. But there is a litle difference, because choosing an entry of the Options-pull-down menu causes a reload of the entry mask while choosing a ROption-radio-button the entry mask is not reloaded. This causes a problem using conditional attributes. The condition is only paid attention to in case of Options but not in case of ROptions. In my case I would like to use ROption, as it is faster to set a radio button than to choose an item in a pull-down menu, but I can't as I have also to use conditional attributes. Is there any solution?

 

 

  69278   Thu Dec 3 19:11:38 2020 Question Illam Pakkirisamyillam@senseeker.comInfoWindowsELOG V3.1.4-a04How to increase TEXT_SIZE to address entry text limit

Hi,

I'm trying to increase the entry text constraint but not sure how to do this.  Couldn't find it in the documentation or may be I missed it.  Appreciate your help.

Thanks.
Illam

 

  69279   Fri Dec 4 02:03:56 2020 Reply Harry Martinharrymartin772@gmail.comQuestionLinux | Windows | Mac OSX | All | Other3.1.3Re: length of condition names

Could we update the doc for this?

Stefan Ritt wrote:

You can easily use multi-character conditionals, up to 256 chars.

Harry Martin wrote:

The documentation describing the use of conditionals uses a single character (letter or number) for names of conditions.  I don't see any update/change to that rule anywhere in the docs.

I have been using multi-character condition names successfully.   I find these are easier to use since they can be more descriptive of each condition.   It works, but I am concerned I may be doing something that might not be supported going forward.   (It is simple enough to change these, but I'd prefer to know if this practice is acceptable.)

Thank you, again, for this fine (and, may I add, fun?) tool.  I'm having a good time with it!

 

 

ELOG V3.1.5-fe60aaf