Re: Duplicate entries, posted by Harry Martin on Wed Dec 2 17:54:51 2020
|
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.
|
|
|
|
|
Re: Duplicate entries, posted by David Pilgram on Wed Dec 2 18:22:37 2020
|
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.
|
|
|
|
|
|
Re: Duplicate entries, posted by Harry Martin on Wed Dec 2 22:13:52 2020
|
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.
|
|
|
|
|
|
|
Re: Dump screenshot to new elog entry, posted by Andreas Luedeke on Sun Dec 12 08:12:57 2021
|
I am no Windows expert. An option is to write your own application and use the "elog" command to post the output of the application to your ELOG.
There is as well a python library to access ELOG via http: https://github.com/paulscherrerinstitute/py_elog
Anthony J Krishock wrote: |
Hello,
I am interested in finding a preferrably single-click way to capture a screenshot and posting it automatically to a new elog entry . I would be doing this from Windows. Is this possible?
Thanks
|
|
Re: Dual Time display and entry times, posted by Yoshio Imai on Mon Jan 14 13:33:19 2013
|
Depending on whether I understand your requirement correctly, the following solution should work:
- define an additional logbook attribute, say "UTC Date"
- preset it on entry creation and submission with the UTC timestamp (cf. section "Attributes" of the ELog configuration guide):
Preset UTC Date = $utcdate
Subst UTC Date = $utcdate - prevent the attribute from being changed manually by adding it to the
Locked Attributes = < ... > andFixed Attributes Edit = < ... > lists, respectively.
You may also have to add it to theRemove on reply = < ... > list if replies turn out to keep the "UTC Date" value of the original entry.
Regards, |
Re: Dropdown boxes and Moptions, posted by Stefan Ritt on Mon Jun 15 16:44:35 2009
|
Arno Teunisse wrote: |
Hello
I have a config file :
Attributes = Author, Author Email, Category, Customer, server,HPSD_ID, Cust_ID ,Subject , Change Window
; which fields will be shown !!
List display = ID,Author, Category, Customer, server, HPSD_ID, Cust_ID,Subject , Change Window
Type Change Window = datetime
# Type Change Window End = datetime
Options Category = Network , Server ,
Options Customer = Arag{A}, Frieslandbank{B}, Super de Boer{C}, NRE{D}
{A} Options server = arag-lin1,arag-lin2,arag-lin3,arag-lin4, arag-lin5, arag-lin6, arag-lin7
{B} Options server = rc1upas02, rc1upas22,rc1upas03,rc1upas04,rc1uptsm01,rc1upas07,rc1upas08
{C} Options server = xia61031,xia61032 ,xia61033,xia61034,xia61035,xia61036,xia61037,xia61038,xia61039,xia61040,xia61032 ,xia61033,xia61034,xia61035,xia61036,xia61037,xia61038,xia61039,xia61040
{D} Options server = server27,server32,server34 ,server37,server38,server40
Extendable options = Category , Customer,server
Required Attributes = server , customer, Subject, Change window Begin , Change Window End
This works OK, However when I change the {A} Options to {A} Moptions in the above code i get an error which tells me that a required field is not selected. So, with the pull down it works, with Moptions ( select boxes ) it will say that a required field is not selected. Any hints ?
regards Arno
|
Thanks for reporting this bug. I fixed it in SVN revisoin 2213. |
Re: Drop down search list?, posted by Stefan Ritt on Thu Aug 16 15:39:43 2012
|
harley skorpenske wrote: |
I'm having some confusion with configuring my logbook. In the global section of the logbook I have the quick filter enabled, but it is not a drop down list, only an editable text field:

I think it is an attributes issue, but I'm having some trouble making sense of those from the syntax page. Here is my config file:
[global]
port = 8080
usr = vulcanstaff
Max content length = 1073741824
Menu commands = New, Edit, Delete, Reply, Find, Last day, Move to, Copy to, Import, Help
RSS Title = $subject, posted by $author on $entry time
RSS Entries = 10
Quick filter = Date, Subject, Subtext
Use Lock = 1
Reverse sort = 1
Required Attributes = Author, Subject
[Experiment_Logbook]
Theme = default
Comment = Experiment Logbook
Attributes = Author, Author Email, Type, Category, Subject
Options Type = Other
Options Category = Start Up
Extendable Options =Category
Page Title = $Subject
|
You get a drop-down list if you define several options for an attribut, like
Options Category = Start Up, Start Down, Other
The you can select one of the categories from the drop-down list.
|
Re: Drop down search list?, posted by harley skorpenske on Thu Aug 16 15:55:32 2012
|
Stefan Ritt wrote: |
harley skorpenske wrote: |
I'm having some confusion with configuring my logbook. In the global section of the logbook I have the quick filter enabled, but it is not a drop down list, only an editable text field:

I think it is an attributes issue, but I'm having some trouble making sense of those from the syntax page. Here is my config file:
[global]
port = 8080
usr = vulcanstaff
Max content length = 1073741824
Menu commands = New, Edit, Delete, Reply, Find, Last day, Move to, Copy to, Import, Help
RSS Title = $subject, posted by $author on $entry time
RSS Entries = 10
Quick filter = Date, Subject, Subtext
Use Lock = 1
Reverse sort = 1
Required Attributes = Author, Subject
[Experiment_Logbook]
Theme = default
Comment = Experiment Logbook
Attributes = Author, Author Email, Type, Category, Subject
Options Type = Other
Options Category = Start Up
Extendable Options =Category
Page Title = $Subject
|
You get a drop-down list if you define several options for an attribut, like
Options Category = Start Up, Start Down, Other
The you can select one of the categories from the drop-down list.
|
I forgot to mention - this is for searching the logbook. So would the config file look more like this:
[global]
port = 8080
usr = vulcanstaff
Max content length = 1073741824
Menu commands = New, Edit, Delete, Reply, Find, Last day, Move to, Copy to, Import, Help
RSS Title = $subject, posted by $author on $entry time
RSS Entries = 10
Options Category = Date, Subject, Subtext
Quick filter = Date, Subject, Subtext
Use Lock = 1
Reverse sort = 1
Required Attributes = Author, Subject
|
|