Duplicate entries, posted by Alan Grant on Thu Mar 16 15:15:34 2017
|
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 Thu Mar 16 16:11:02 2017
|
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 04:07:57 2020
|
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 15:57:25 2020
|
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 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.
|
|
|
|
|
|
|
Placeholders in Python API, posted by Florian Feldbauer on Wed Nov 25 15:10:34 2020
|
Hey all,
In the configuration of the Elog one can use
Preset Author = $long_name
Preset Author Email = $user_email
to have predefined values for the Author and Author Email fields when creating a new entry via the web interface.
Is it also possible to use these placeholders when creating a new entry via the Python API?
Cheers,
Florian |
Style <attribute> and Cell Style <attribute> on the same row, posted by David Dunne on Tue Nov 17 12:10:07 2020
|
Query
(FYI, OS = FreeBSD, Elog Version as showing on logon box = V3.1.4-)
Is it possible to use both Style <attribute> and Cell Style <attribute> on the same row?
For example, have a Logbook containing several Attributes and display a subset of those attributes in Summary Mode. Two attributes are of interest for this query which are part of the attributes displayed in Summary Mode, attributes ‘Assign Line’ and ‘Service’
If the ‘Attribute Assign Line = Assign 1’ then shade all cells in that row #808080
but if the ‘Attribute Service = 1600’ always shade that cell #7A5776
Config file includes
Style Assign Line Assign 1 = background-color:#808080
Cell Style Service 1600 = background-color:#7A5776
The result is the row gets shaded #808080 if ‘Assign Line = Assign Line 1’ but fails to shade the Service cell colour #7A5776 if it equals 1600
Extract from HTML source for the ‘1600’ cell when both conditions are correct shows both background-color values are present and the cell is styled the first value listed (which is Style Assign Line Assign 1 = background-color:#808080 but I always want #7A5776 for cell Service when it is of value 1600)
.
<td class="list2" style="background-color:#808080" style="background-color:#7A5776"><a href="../Daily/1">1600</a></td>
Thank you,
David |
Create entry from command line - override Date?, posted by David Wallis on Tue Oct 27 16:00:03 2020
|
I'm converting our on-call logbook, with 25 years of history, to elog. Is there a way to override the current date/time for the Date field with the creation date/time of the original logbook entry? |
Re: Create entry from command line - override Date?, posted by Stefan Ritt on Tue Oct 27 16:15:26 2020
|
You have to manually manipulate the logbook files YYMMDDa.log where you find the date at the top like:
MID@$: 1
Date: Wed, 02 Sep 2020 15:38:09 +0300 <==== change here !!!!
Author: Stefan
Type: General
Category:
Subject: CURL test
Attachment:
Encoding: plain
========================================
Text body
|
Re: Create entry from command line - override Date?, posted by David Wallis on Tue Oct 27 16:37:07 2020
|
Hi Stefan, thanks! Does the Date field need to be the first field in each entry? I can see adding a "termpory" field called "Orig Date", upload the old entries, then edit the file(s), delete the Date field, and rename Orig Date to Date. Will that work?
Stefan Ritt wrote: |
You have to manually manipulate the logbook files YYMMDDa.log where you find the date at the top like:
MID@$: 1
Date: Wed, 02 Sep 2020 15:38:09 +0300 <==== change here !!!!
Author: Stefan
Type: General
Category:
Subject: CURL test
Attachment:
Encoding: plain
========================================
Text body
|
|
Re: Create entry from command line - override Date?, posted by Stefan Ritt on Tue Oct 27 16:49:53 2020
|
"Date" must be on the first line on each entry and it must be named "Date".
Stefan
David Wallis wrote: |
Hi Stefan, thanks! Does the Date field need to be the first field in each entry? I can see adding a "termpory" field called "Orig Date", upload the old entries, then edit the file(s), delete the Date field, and rename Orig Date to Date. Will that work?
Stefan Ritt wrote: |
You have to manually manipulate the logbook files YYMMDDa.log where you find the date at the top like:
MID@$: 1
Date: Wed, 02 Sep 2020 15:38:09 +0300 <==== change here !!!!
Author: Stefan
Type: General
Category:
Subject: CURL test
Attachment:
Encoding: plain
========================================
Text body
|
|
|
Re: Create entry from command line - override Date?, posted by Andreas Luedeke on Tue Oct 27 17:07:00 2020
|
You could transform your entries into the ELOG file format (either XML or CSV) and then use the import function. That would upload the correct dates from your entries.
If you use the "Orig Date" trick you've proposed, you'll see that datetime fields are stored as seconds of the epoch (since 1.1.1970). Not so easy to copy and paste them, but you can convert them with a script.
Cheers, Andreas
David Wallis wrote: |
Hi Stefan, thanks! Does the Date field need to be the first field in each entry? I can see adding a "termpory" field called "Orig Date", upload the old entries, then edit the file(s), delete the Date field, and rename Orig Date to Date. Will that work?
Stefan Ritt wrote: |
You have to manually manipulate the logbook files YYMMDDa.log where you find the date at the top like:
MID@$: 1
Date: Wed, 02 Sep 2020 15:38:09 +0300 <==== change here !!!!
Author: Stefan
Type: General
Category:
Subject: CURL test
Attachment:
Encoding: plain
========================================
Text body
|
|
|
Re: Create entry from command line - override Date?, posted by David Wallis on Tue Oct 27 17:45:29 2020
|
Hi Andreas,
Thanks for your input! After a little testing, it appears that if I make "Orig Date" the first field, it will fall under the Date field in the logbook file. I can then do a global delete of Date:, and replace Orig Date: with Date:, leaving it as the first field in the entry. Then I can delete the Orig Date field.
Andreas Luedeke wrote: |
You could transform your entries into the ELOG file format (either XML or CSV) and then use the import function. That would upload the correct dates from your entries.
If you use the "Orig Date" trick you've proposed, you'll see that datetime fields are stored as seconds of the epoch (since 1.1.1970). Not so easy to copy and paste them, but you can convert them with a script.
Cheers, Andreas
David Wallis wrote: |
Hi Stefan, thanks! Does the Date field need to be the first field in each entry? I can see adding a "termpory" field called "Orig Date", upload the old entries, then edit the file(s), delete the Date field, and rename Orig Date to Date. Will that work?
Stefan Ritt wrote: |
You have to manually manipulate the logbook files YYMMDDa.log where you find the date at the top like:
MID@$: 1
Date: Wed, 02 Sep 2020 15:38:09 +0300 <==== change here !!!!
Author: Stefan
Type: General
Category:
Subject: CURL test
Attachment:
Encoding: plain
========================================
Text body
|
|
|
|
Re: Create entry from command line - override Date?, posted by Andreas Luedeke on Tue Oct 27 21:59:03 2020
|
Hi David,
correct. And in addition you will need to convert "Orig Date" from seconds-of-the-epoch into a properly formated date string (see example below from Stefan) ...
Andreas
David Wallis wrote: |
Hi Andreas,
Thanks for your input! After a little testing, it appears that if I make "Orig Date" the first field, it will fall under the Date field in the logbook file. I can then do a global delete of Date:, and replace Orig Date: with Date:, leaving it as the first field in the entry. Then I can delete the Orig Date field.
Andreas Luedeke wrote: |
You could transform your entries into the ELOG file format (either XML or CSV) and then use the import function. That would upload the correct dates from your entries.
If you use the "Orig Date" trick you've proposed, you'll see that datetime fields are stored as seconds of the epoch (since 1.1.1970). Not so easy to copy and paste them, but you can convert them with a script.
Cheers, Andreas
David Wallis wrote: |
Hi Stefan, thanks! Does the Date field need to be the first field in each entry? I can see adding a "termpory" field called "Orig Date", upload the old entries, then edit the file(s), delete the Date field, and rename Orig Date to Date. Will that work?
Stefan Ritt wrote: |
You have to manually manipulate the logbook files YYMMDDa.log where you find the date at the top like:
MID@$: 1
Date: Wed, 02 Sep 2020 15:38:09 +0300 <==== change here !!!!
Author: Stefan
Type: General
Category:
Subject: CURL test
Attachment:
Encoding: plain
========================================
Text body
|
|
|
|
|
Re: Create entry from command line - override Date?, posted by David Wallis on Tue Oct 27 22:24:18 2020
|
Hi Andreas,
It was actually easier than that. The time stamps in the old system were in epoch format, so when I created the new record, (my conversion program was written in Python), I simply formatted that value in the format Stefan pointed out below, and defined the Orig Date field as text. Then I was able to munge the logbook file with 2 global editor commands, and it worked perfectly. Thanks again!
Andreas Luedeke wrote: |
Hi David,
correct. And in addition you will need to convert "Orig Date" from seconds-of-the-epoch into a properly formated date string (see example below from Stefan) ...
Andreas
David Wallis wrote: |
Hi Andreas,
Thanks for your input! After a little testing, it appears that if I make "Orig Date" the first field, it will fall under the Date field in the logbook file. I can then do a global delete of Date:, and replace Orig Date: with Date:, leaving it as the first field in the entry. Then I can delete the Orig Date field.
Andreas Luedeke wrote: |
You could transform your entries into the ELOG file format (either XML or CSV) and then use the import function. That would upload the correct dates from your entries.
If you use the "Orig Date" trick you've proposed, you'll see that datetime fields are stored as seconds of the epoch (since 1.1.1970). Not so easy to copy and paste them, but you can convert them with a script.
Cheers, Andreas
David Wallis wrote: |
Hi Stefan, thanks! Does the Date field need to be the first field in each entry? I can see adding a "termpory" field called "Orig Date", upload the old entries, then edit the file(s), delete the Date field, and rename Orig Date to Date. Will that work?
Stefan Ritt wrote: |
You have to manually manipulate the logbook files YYMMDDa.log where you find the date at the top like:
MID@$: 1
Date: Wed, 02 Sep 2020 15:38:09 +0300 <==== change here !!!!
Author: Stefan
Type: General
Category:
Subject: CURL test
Attachment:
Encoding: plain
========================================
Text body
|
|
|
|
|
|
MEG style elog configuration, posted by Daniel Kohl on Sun Oct 25 06:26:49 2020
|
Hello,
I'm new to elog software and I could not find a solution to my configuration issue. I would like to setup a configuration file similar to MEG experiment's elog.
https://elog.psi.ch/elogs/meg/
I'm interested in creating similar to the structure: "General", "Collaboratoin", "Sub-groups (with sub-sub groups "Software", "Hardware" etc). I cannot tell if this was created by using Top Group feature.
Can someone explain how this design structure can be achieved?
Thanks,
Daniel |
Re: MEG style elog configuration, posted by Stefan Ritt on Mon Oct 26 11:42:53 2020
|
It was done using the "groups" feature:
https://elog.psi.ch/elog/config.html#groups
Stefan
Daniel Kohl wrote: |
Hello,
I'm new to elog software and I could not find a solution to my configuration issue. I would like to setup a configuration file similar to MEG experiment's elog.
https://elog.psi.ch/elogs/meg/
I'm interested in creating similar to the structure: "General", "Collaboratoin", "Sub-groups (with sub-sub groups "Software", "Hardware" etc). I cannot tell if this was created by using Top Group feature.
Can someone explain how this design structure can be achieved?
Thanks,
Daniel
|
|
Field values dependent on other selections, posted by Anthony Krishock on Tue Oct 20 02:34:46 2020
|
All,
I would like to know if there is a way in elog to populate a field based on the value of another field. What I want to do is have a field with a few selections (a menu) and another text field that populates based on what I select from the menu.
Is this possible? |
Re: Field values dependent on other selections, posted by Stefan Ritt on Tue Oct 20 08:24:20 2020
|
Look in the manual under "conditional attributes"
Stefan
Anthony Krishock wrote: |
All,
I would like to know if there is a way in elog to populate a field based on the value of another field. What I want to do is have a field with a few selections (a menu) and another text field that populates based on what I select from the menu.
Is this possible?
|
|
Re: Field values dependent on other selections, posted by Anthony Krishock on Wed Oct 21 02:27:43 2020
|
Thanks for your suggestion. Right now, my log is configured as follows:
Options Eyepiece = Pentax{a}, TeleVue{b}, Meade{c}
{a} Options Pentax = 5mm, 20mm, 30mm
{b} Options TeleVue = 7mm Nagler, 10mm Radian, 24mm Panoptic
{c} Options Meade = 8.8mm UWA, 14mm UWA, 26mm QX
If I select "Pentax", I would like the other two options to be unavailable. Instead, all three options are shown. Can I mask the other unused options?
Stefan Ritt wrote: |
Look in the manual under "conditional attributes"
Stefan
Anthony Krishock wrote: |
All,
I would like to know if there is a way in elog to populate a field based on the value of another field. What I want to do is have a field with a few selections (a menu) and another text field that populates based on what I select from the menu.
Is this possible?
|
|
|
Re: Field values dependent on other selections, posted by Andreas Luedeke on Fri Oct 23 15:10:54 2020
|
Instead of using three different options you could use the same:
Options Eyepiece = Pentax{a}, TeleVue{b}, Meade{c}
{a} Options Form = 5mm, 20mm, 30mm
{b} Options Form = 7mm Nagler, 10mm Radian, 24mm Panoptic
{c} Options Form = 8.8mm UWA, 14mm UWA, 26mm QX
It makes more sense.
But it is as well possible to supress attributed in the edit from. See
Show Attributes = <list>
Attributes present in this list are shown in the single entry page. Omitting attributes can make sense for attributes which are automatically derived from other attributes via the Change <attribute> command.
Show Attributes Edit = <list>
The same as Show Attributes , but for the entry form.
You just have a different <list> for each conditional case {a} {b} {c}.
Anthony Krishock wrote: |
Thanks for your suggestion. Right now, my log is configured as follows:
Options Eyepiece = Pentax{a}, TeleVue{b}, Meade{c}
{a} Options Pentax = 5mm, 20mm, 30mm
{b} Options TeleVue = 7mm Nagler, 10mm Radian, 24mm Panoptic
{c} Options Meade = 8.8mm UWA, 14mm UWA, 26mm QX
If I select "Pentax", I would like the other two options to be unavailable. Instead, all three options are shown. Can I mask the other unused options?
Stefan Ritt wrote: |
Look in the manual under "conditional attributes"
Stefan
Anthony Krishock wrote: |
All,
I would like to know if there is a way in elog to populate a field based on the value of another field. What I want to do is have a field with a few selections (a menu) and another text field that populates based on what I select from the menu.
Is this possible?
|
|
|
|
From command line: "command Submit not allowed", posted by David Wallis on Tue Oct 20 15:08:17 2020
|
I'm running Elog version V3.1.4-ba84827 on Red Hat Linux 7.9. As part of migrating from an older in-house logbook to Elog, I need to upload all the old logbook entries. However, when I attempt to do that with the "elog" command line tool, I'm getting the error "command Submit not allowed.
I read through a similar report from 2015 (entry #68149), but none of the potential causes seem to be at play here. The logbook is using PAM authentication, and I can log in to the web interface using the same credentials I'm using from the command line. The other case mentioned a dis-allowed encoding format, but my logbook is configured to allow all formats.
This is the command line I'm using:
/usr/local/elog/bin/elog -v -h logbook.aps.anl.gov -p 8081 -l On_Call -x -n 2 -a Date='10/19/2020 01:02' Author="David Wallis" Title='Test Upload' Status='Open' System='On-Call' -u 'wallis' '*****' "This is a test message" |
Re: From command line: "command Submit not allowed", posted by David Wallis on Tue Oct 20 17:50:50 2020
|
Update: I tried switching the logbook to no authentication reqiured, and still get the "command Submit not allowed" response.
David Wallis wrote: |
I'm running Elog version V3.1.4-ba84827 on Red Hat Linux 7.9. As part of migrating from an older in-house logbook to Elog, I need to upload all the old logbook entries. However, when I attempt to do that with the "elog" command line tool, I'm getting the error "command Submit not allowed.
I read through a similar report from 2015 (entry #68149), but none of the potential causes seem to be at play here. The logbook is using PAM authentication, and I can log in to the web interface using the same credentials I'm using from the command line. The other case mentioned a dis-allowed encoding format, but my logbook is configured to allow all formats.
This is the command line I'm using:
/usr/local/elog/bin/elog -v -h logbook.aps.anl.gov -p 8081 -l On_Call -x -n 2 -a Date='10/19/2020 01:02' Author="David Wallis" Title='Test Upload' Status='Open' System='On-Call' -u 'wallis' '*****' "This is a test message"
|
|
Re: From command line: "command Submit not allowed", posted by Stefan Ritt on Tue Oct 20 18:02:42 2020
|
"submit not allowed" you typically get if there is a "guest menu" for read-only access and you are not logged in. I never tried the elog program with PAM authentication, but you said that your turned authentication off. What I would do is to strip down your elogd.cfg to a very simple form until the elog utility works, then figure out which configuration makes the trouble.
Stefan
David Wallis wrote: |
Update: I tried switching the logbook to no authentication reqiured, and still get the "command Submit not allowed" response.
David Wallis wrote: |
I'm running Elog version V3.1.4-ba84827 on Red Hat Linux 7.9. As part of migrating from an older in-house logbook to Elog, I need to upload all the old logbook entries. However, when I attempt to do that with the "elog" command line tool, I'm getting the error "command Submit not allowed.
I read through a similar report from 2015 (entry #68149), but none of the potential causes seem to be at play here. The logbook is using PAM authentication, and I can log in to the web interface using the same credentials I'm using from the command line. The other case mentioned a dis-allowed encoding format, but my logbook is configured to allow all formats.
This is the command line I'm using:
/usr/local/elog/bin/elog -v -h logbook.aps.anl.gov -p 8081 -l On_Call -x -n 2 -a Date='10/19/2020 01:02' Author="David Wallis" Title='Test Upload' Status='Open' System='On-Call' -u 'wallis' '*****' "This is a test message"
|
|
|
Re: From command line: "command Submit not allowed", posted by David Wallis on Tue Oct 20 18:26:26 2020
|
Hmmm... I added "New" to the Guest menu list, and the button showed up for a guest user. But when I submitted the new ticket, I got the message Error: Command "Submit" is not allowed for user ""
Stefan Ritt wrote: |
"submit not allowed" you typically get if there is a "guest menu" for read-only access and you are not logged in. I never tried the elog program with PAM authentication, but you said that your turned authentication off. What I would do is to strip down your elogd.cfg to a very simple form until the elog utility works, then figure out which configuration makes the trouble.
Stefan
David Wallis wrote: |
Update: I tried switching the logbook to no authentication reqiured, and still get the "command Submit not allowed" response.
David Wallis wrote: |
I'm running Elog version V3.1.4-ba84827 on Red Hat Linux 7.9. As part of migrating from an older in-house logbook to Elog, I need to upload all the old logbook entries. However, when I attempt to do that with the "elog" command line tool, I'm getting the error "command Submit not allowed.
I read through a similar report from 2015 (entry #68149), but none of the potential causes seem to be at play here. The logbook is using PAM authentication, and I can log in to the web interface using the same credentials I'm using from the command line. The other case mentioned a dis-allowed encoding format, but my logbook is configured to allow all formats.
This is the command line I'm using:
/usr/local/elog/bin/elog -v -h logbook.aps.anl.gov -p 8081 -l On_Call -x -n 2 -a Date='10/19/2020 01:02' Author="David Wallis" Title='Test Upload' Status='Open' System='On-Call' -u 'wallis' '*****' "This is a test message"
|
|
|
|
Re: From command line: "command Submit not allowed", posted by Stefan Ritt on Tue Oct 20 18:40:05 2020
|
Giving up. Send me your config file and I will debug it.
Stefan
David Wallis wrote: |
Hmmm... I added "New" to the Guest menu list, and the button showed up for a guest user. But when I submitted the new ticket, I got the message Error: Command "Submit" is not allowed for user ""
Stefan Ritt wrote: |
"submit not allowed" you typically get if there is a "guest menu" for read-only access and you are not logged in. I never tried the elog program with PAM authentication, but you said that your turned authentication off. What I would do is to strip down your elogd.cfg to a very simple form until the elog utility works, then figure out which configuration makes the trouble.
Stefan
David Wallis wrote: |
Update: I tried switching the logbook to no authentication reqiured, and still get the "command Submit not allowed" response.
David Wallis wrote: |
I'm running Elog version V3.1.4-ba84827 on Red Hat Linux 7.9. As part of migrating from an older in-house logbook to Elog, I need to upload all the old logbook entries. However, when I attempt to do that with the "elog" command line tool, I'm getting the error "command Submit not allowed.
I read through a similar report from 2015 (entry #68149), but none of the potential causes seem to be at play here. The logbook is using PAM authentication, and I can log in to the web interface using the same credentials I'm using from the command line. The other case mentioned a dis-allowed encoding format, but my logbook is configured to allow all formats.
This is the command line I'm using:
/usr/local/elog/bin/elog -v -h logbook.aps.anl.gov -p 8081 -l On_Call -x -n 2 -a Date='10/19/2020 01:02' Author="David Wallis" Title='Test Upload' Status='Open' System='On-Call' -u 'wallis' '*****' "This is a test message"
|
|
|
|
|
Re: From command line: "command Submit not allowed", posted by David Wallis on Tue Oct 20 20:44:03 2020
|
I've been able to work around this by completely turning off authentication, and adding New to the Guest menu list.
One additional question: since I'm uploading historical logbook entries, is it possible to set the entry creation date via the command line? It seems that elogd is overriding the attribute "Date".
David Wallis wrote: |
Hmmm... I added "New" to the Guest menu list, and the button showed up for a guest user. But when I submitted the new ticket, I got the message Error: Command "Submit" is not allowed for user ""
Stefan Ritt wrote: |
"submit not allowed" you typically get if there is a "guest menu" for read-only access and you are not logged in. I never tried the elog program with PAM authentication, but you said that your turned authentication off. What I would do is to strip down your elogd.cfg to a very simple form until the elog utility works, then figure out which configuration makes the trouble.
Stefan
David Wallis wrote: |
Update: I tried switching the logbook to no authentication reqiured, and still get the "command Submit not allowed" response.
David Wallis wrote: |
I'm running Elog version V3.1.4-ba84827 on Red Hat Linux 7.9. As part of migrating from an older in-house logbook to Elog, I need to upload all the old logbook entries. However, when I attempt to do that with the "elog" command line tool, I'm getting the error "command Submit not allowed.
I read through a similar report from 2015 (entry #68149), but none of the potential causes seem to be at play here. The logbook is using PAM authentication, and I can log in to the web interface using the same credentials I'm using from the command line. The other case mentioned a dis-allowed encoding format, but my logbook is configured to allow all formats.
This is the command line I'm using:
/usr/local/elog/bin/elog -v -h logbook.aps.anl.gov -p 8081 -l On_Call -x -n 2 -a Date='10/19/2020 01:02' Author="David Wallis" Title='Test Upload' Status='Open' System='On-Call' -u 'wallis' '*****' "This is a test message"
|
|
|
|
|
Re: From command line: "command Submit not allowed", posted by David Dunne on Wed Oct 21 03:08:21 2020
|
FYI, I had problems a few weeks ago trying to get the command line elog working, blamed everybody and everything but myself.
In my case it was command line syntax errors and eventually got it going as part of a nightly script
While testing I ran the Elog Server from the command line in verbose mode to see if that helped determine the problem.
On the server end the logbook uploading to is set for Plaintext
# Set entries to TEXT Only format
Default encoding = 1
Allowed encoding = 1
Elog server authenication is standard built in to elogd, no PAM, no LDAP, no Kerberos
Below is what works for me, I’ve replaced my Elog Server Hostname, Elog Username & Password used to connect to the server with generic.
Elog Server version = elog-3.1.4-2
# Log details in Elog Server
/usr/local/bin/elog -h HOSTNAME -p 80 -l Backups -u USERNAME PASSWORD -a Backup=NightlyBackupScript -a Hostname=$HOST -n 1 -x -m /tmp/elog.nightly.script.$TIMESTAMP
I've been caught out in the past having a very old version of the elog command line talking to a recent Elog Server build or Encoding not matching
David Wallis wrote: |
I've been able to work around this by completely turning off authentication, and adding New to the Guest menu list.
One additional question: since I'm uploading historical logbook entries, is it possible to set the entry creation date via the command line? It seems that elogd is overriding the attribute "Date".
David Wallis wrote: |
Hmmm... I added "New" to the Guest menu list, and the button showed up for a guest user. But when I submitted the new ticket, I got the message Error: Command "Submit" is not allowed for user ""
Stefan Ritt wrote: |
"submit not allowed" you typically get if there is a "guest menu" for read-only access and you are not logged in. I never tried the elog program with PAM authentication, but you said that your turned authentication off. What I would do is to strip down your elogd.cfg to a very simple form until the elog utility works, then figure out which configuration makes the trouble.
Stefan
David Wallis wrote: |
Update: I tried switching the logbook to no authentication reqiured, and still get the "command Submit not allowed" response.
David Wallis wrote: |
I'm running Elog version V3.1.4-ba84827 on Red Hat Linux 7.9. As part of migrating from an older in-house logbook to Elog, I need to upload all the old logbook entries. However, when I attempt to do that with the "elog" command line tool, I'm getting the error "command Submit not allowed.
I read through a similar report from 2015 (entry #68149), but none of the potential causes seem to be at play here. The logbook is using PAM authentication, and I can log in to the web interface using the same credentials I'm using from the command line. The other case mentioned a dis-allowed encoding format, but my logbook is configured to allow all formats.
This is the command line I'm using:
/usr/local/elog/bin/elog -v -h logbook.aps.anl.gov -p 8081 -l On_Call -x -n 2 -a Date='10/19/2020 01:02' Author="David Wallis" Title='Test Upload' Status='Open' System='On-Call' -u 'wallis' '*****' "This is a test message"
|
|
|
|
|
|
Re: From command line: "command Submit not allowed", posted by David Wallis on Wed Oct 21 15:14:13 2020
|
Hi David, thanks for your input!
This logbook has been around for almost 10 years, and has evolved from file-based authentication, to LDAP, and finally to PAM (that can use any of local password files, LDAP, and Active Directory), and I'm thinking that might be the root of this problem. There are old account entries from the file-based days, with passwords, that match the AD usernames. I'm wondering if elogd is trying to use the password in the password file, rather than via PAM. I don't remember the old passwords, so I can't check, and I've run into problems trying to change the passwords. I'm wondering if there's a way to generate a new password from the command line, that would allow me to test the theory.
David Dunne wrote: |
FYI, I had problems a few weeks ago trying to get the command line elog working, blamed everybody and everything but myself.
In my case it was command line syntax errors and eventually got it going as part of a nightly script
While testing I ran the Elog Server from the command line in verbose mode to see if that helped determine the problem.
On the server end the logbook uploading to is set for Plaintext
# Set entries to TEXT Only format
Default encoding = 1
Allowed encoding = 1
Elog server authenication is standard built in to elogd, no PAM, no LDAP, no Kerberos
Below is what works for me, I’ve replaced my Elog Server Hostname, Elog Username & Password used to connect to the server with generic.
Elog Server version = elog-3.1.4-2
# Log details in Elog Server
/usr/local/bin/elog -h HOSTNAME -p 80 -l Backups -u USERNAME PASSWORD -a Backup=NightlyBackupScript -a Hostname=$HOST -n 1 -x -m /tmp/elog.nightly.script.$TIMESTAMP
I've been caught out in the past having a very old version of the elog command line talking to a recent Elog Server build or Encoding not matching
David Wallis wrote: |
I've been able to work around this by completely turning off authentication, and adding New to the Guest menu list.
One additional question: since I'm uploading historical logbook entries, is it possible to set the entry creation date via the command line? It seems that elogd is overriding the attribute "Date".
David Wallis wrote: |
Hmmm... I added "New" to the Guest menu list, and the button showed up for a guest user. But when I submitted the new ticket, I got the message Error: Command "Submit" is not allowed for user ""
Stefan Ritt wrote: |
"submit not allowed" you typically get if there is a "guest menu" for read-only access and you are not logged in. I never tried the elog program with PAM authentication, but you said that your turned authentication off. What I would do is to strip down your elogd.cfg to a very simple form until the elog utility works, then figure out which configuration makes the trouble.
Stefan
David Wallis wrote: |
Update: I tried switching the logbook to no authentication reqiured, and still get the "command Submit not allowed" response.
David Wallis wrote: |
I'm running Elog version V3.1.4-ba84827 on Red Hat Linux 7.9. As part of migrating from an older in-house logbook to Elog, I need to upload all the old logbook entries. However, when I attempt to do that with the "elog" command line tool, I'm getting the error "command Submit not allowed.
I read through a similar report from 2015 (entry #68149), but none of the potential causes seem to be at play here. The logbook is using PAM authentication, and I can log in to the web interface using the same credentials I'm using from the command line. The other case mentioned a dis-allowed encoding format, but my logbook is configured to allow all formats.
This is the command line I'm using:
/usr/local/elog/bin/elog -v -h logbook.aps.anl.gov -p 8081 -l On_Call -x -n 2 -a Date='10/19/2020 01:02' Author="David Wallis" Title='Test Upload' Status='Open' System='On-Call' -u 'wallis' '*****' "This is a test message"
|
|
|
|
|
|
|
Upload attachment with py_elog, posted by Bruno Schuler on Tue Oct 20 16:05:40 2020
|
Hello,
How can one add an attachment to a new or existing entry with py_elog?
E.g. if I want to upload an image.
Thanks for the help! |
|