How to increase TEXT_SIZE to address entry text limit, posted by Illam Pakkirisamy on Thu Dec 3 19:11:38 2020
|
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

|
Re: How to increase TEXT_SIZE to address entry text limit, posted by Simon Däster on Wed Dec 16 12:41:42 2020
|
Hi Illam
You actually have to change the source code of elog and then recompile. Download the code from https://bitbucket.org/ritt/elog/src/master/, change the value of the variable TEXT_SIZE in the file src/elogd.h
Default ist #define TEXT_SIZE 250000
Illam Pakkirisamy wrote: |
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

|
|
Is there a way to upload a file in custom input?, posted by Satyajit Jena on Tue Dec 15 14:50:55 2020
|
Hi,
I am trying to implement a Custom input forms by following this https://elog.psi.ch/elogs/Contributions/49. Is there a way to also insert an image or files to it? I want to take a snap from the iPad and want that to go as an attachment or attach a file(s) into the form. Is there a way to do that?
Your suggestions are highly appreciated.
Regards,
sjena
|
Re: Is there a way to upload a file in custom input?, posted by Stefan Ritt on Tue Dec 15 15:19:25 2020
|
When you submit a "normal" elog entry, you can click on "Choose file" to add an attachment. On a mobile device, you will then be asked to select a photo from your library or take one with your camera. You can do the same on a custom form. You have to extract the code from the normal submissoin form and program it on your custom page. It needs however some work and might not be straight forward.
Stefan
Satyajit Jena wrote: |
Hi,
I am trying to implement a Custom input forms by following this https://elog.psi.ch/elogs/Contributions/49. Is there a way to also insert an image or files to it? I want to take a snap from the iPad and want that to go as an attachment or attach a file(s) into the form. Is there a way to do that?
Your suggestions are highly appreciated.
Regards,
sjena
|
|
Re: Is there a way to upload a file in custom input?, posted by Satyajit Jena on Tue Dec 15 17:41:57 2020
|
Thanks Stefan,
I am not yet able to figure out how attachment submission is done, I am trying. It would be helpful if you can refer me to some pointer.
With regards,
satyajit
Stefan Ritt wrote: |
When you submit a "normal" elog entry, you can click on "Choose file" to add an attachment. On a mobile device, you will then be asked to select a photo from your library or take one with your camera. You can do the same on a custom form. You have to extract the code from the normal submissoin form and program it on your custom page. It needs however some work and might not be straight forward.
Stefan
Satyajit Jena wrote: |
Hi,
I am trying to implement a Custom input forms by following this https://elog.psi.ch/elogs/Contributions/49. Is there a way to also insert an image or files to it? I want to take a snap from the iPad and want that to go as an attachment or attach a file(s) into the form. Is there a way to do that?
Your suggestions are highly appreciated.
Regards,
sjena
|
|
|
length of condition names, posted by Harry Martin on Wed Dec 2 22:45:16 2020
|
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! |
Re: length of condition names, posted by Stefan Ritt on Thu Dec 3 09:57:20 2020
|
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!
|
|
Re: length of condition names, posted by Harry Martin on Fri Dec 4 02:03:56 2020
|
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!
|
|
|
Options <...> vs ROptions <...>, posted by Wolfgang Bayer on Thu Apr 28 11:20:40 2011
|
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? |
Re: Options <...> vs ROptions <...>, posted by Harry Martin on Thu Dec 3 01:51:49 2020
|
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?
|
|
Re: Options <...> vs ROptions <...>, posted by Stefan Ritt on Thu Dec 3 09:58:44 2020
|
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?
|
|
|
Change / List Change doen't work anymore?, posted by Holger Mundhahs on Thu Sep 17 15:52:36 2009
|
Hello @all,
I'm not sure if this is a bug, but after upgradeing from 2.7.0 to 2.7.7 the Change <attribute> and List Change <attribute> doesn't work anymore. In my .cfg file I've:
In the old ELOG version I've "RIB-Board" as text in the page and the link works well. But now there is the following code generated:
Is the syntax changed from 2.7.0 to 2.7.7? What's the correct syntax for 2.7.7?
Best regards
Holger |
Re: Change / List Change doen't work anymore?, posted by Stefan Ritt on Thu Sep 17 18:32:59 2009
|
Holger Mundhahs wrote: | Hello @all,
I'm not sure if this is a bug, but after upgradeing from 2.7.0 to 2.7.7 the Change <attribute> and List Change <attribute> doesn't work anymore. In my .cfg file I've:
In the old ELOG version I've "RIB-Board" as text in the page and the link works well. But now there is the following code generated:
Is the syntax changed from 2.7.0 to 2.7.7? What's the correct syntax for 2.7.7?
|
For security reasons (XSS or cross site scripting) , HTML code in attributes is not allowed by default. To turn it on (and if you know what you are doing), add following line to your configuration
Allow HTML = 1 |
Re: Change / List Change doen't work anymore?, posted by Harry Martin on Tue Dec 1 02:12:14 2020
|
Stefan Ritt wrote: |
Holger Mundhahs wrote: | Hello @all,
I'm not sure if this is a bug, but after upgradeing from 2.7.0 to 2.7.7 the Change <attribute> and List Change <attribute> doesn't work anymore. In my .cfg file I've:
In the old ELOG version I've "RIB-Board" as text in the page and the link works well. But now there is the following code generated:
Is the syntax changed from 2.7.0 to 2.7.7? What's the correct syntax for 2.7.7?
|
For security reasons (XSS or cross site scripting) , HTML code in attributes is not allowed by default. To turn it on (and if you know what you are doing), add following line to your configuration
Allow HTML = 1 |
I know this is an old, old thread, but I am trying to use this feature in a recent version of elog (3.1.3). Is there any chance this will ever get fixed, or at least made workable? I tried "Allow HTML = 1", but that did not work. I'd like to be able to use this to link directly to carriers to track packages.
Also, the documentation seemed a bit confusing to me:
Quote: | Change <attribute> = <string>
Instead of subsituting an attribute, the original attribute can be kept and just the output formatting can be changed. This can be very handy for constructing HTML links out of attributes. Presume that a company has a telephone book reachable under
http://any.company.com/telbook.cgi?search=<name>
where <name> has to be replaced by a search string. Now one can construct an automatic telephonebook lookup with following options:
Attributes = Name, Telephone, ...
Display Telephone = <a href="http://any.company.com/telbook.cgi?search=$Name">$Name's telephone number</a>
The attribute Telephone is now automatically constructed from the attribute Name and consists of a link to the company's telephonebook. The advantage of this system is if the URL of the telephonebook changes one day, only one statement in the config file has to be changed, while otherways (like with the Subst Telephone = ... option) all entries would have to be changed manually. |
The example seems to be using a different syntax ("Display Telephone") rather than the syntax described by the section header ("Change <attribute>...").
Any update to this information would be greatly appreciated. I'm just looking for a workable solution of any kind. Thank you for your continuing fine work. |
Re: Change / List Change doen't work anymore?, posted by Harry Martin on Tue Dec 1 02:39:45 2020
|
Harry Martin wrote: |
Stefan Ritt wrote: |
Holger Mundhahs wrote: | Hello @all,
I'm not sure if this is a bug, but after upgradeing from 2.7.0 to 2.7.7 the Change <attribute> and List Change <attribute> doesn't work anymore. In my .cfg file I've:
In the old ELOG version I've "RIB-Board" as text in the page and the link works well. But now there is the following code generated:
Is the syntax changed from 2.7.0 to 2.7.7? What's the correct syntax for 2.7.7?
|
For security reasons (XSS or cross site scripting) , HTML code in attributes is not allowed by default. To turn it on (and if you know what you are doing), add following line to your configuration
Allow HTML = 1 |
I know this is an old, old thread, but I am trying to use this feature in a recent version of elog (3.1.3). Is there any chance this will ever get fixed, or at least made workable? I tried "Allow HTML = 1", but that did not work. I'd like to be able to use this to link directly to carriers to track packages.
Also, the documentation seemed a bit confusing to me:
Quote: | Change <attribute> = <string>
Instead of subsituting an attribute, the original attribute can be kept and just the output formatting can be changed. This can be very handy for constructing HTML links out of attributes. Presume that a company has a telephone book reachable under
http://any.company.com/telbook.cgi?search=<name>
where <name> has to be replaced by a search string. Now one can construct an automatic telephonebook lookup with following options:
Attributes = Name, Telephone, ...
Display Telephone = <a href="http://any.company.com/telbook.cgi?search=$Name">$Name's telephone number</a>
The attribute Telephone is now automatically constructed from the attribute Name and consists of a link to the company's telephonebook. The advantage of this system is if the URL of the telephonebook changes one day, only one statement in the config file has to be changed, while otherways (like with the Subst Telephone = ... option) all entries would have to be changed manually. |
The example seems to be using a different syntax ("Display Telephone") rather than the syntax described by the section header ("Change <attribute>...").
Any update to this information would be greatly appreciated. I'm just looking for a workable solution of any kind. Thank you for your continuing fine work. |
I am able to make it work by passing just a plain string constructing the URL. Strange though... before I posted the previous log entry, it didn't work no matter what I tried! Bizarre.
However, it would still be a good idea to update the documentation to clarify things somewhat and bring it up to date with actual usage today. |
Re: Change / List Change doen't work anymore?, posted by Andreas Luedeke on Tue Dec 1 22:57:25 2020
|
Harry Martin wrote: |
Harry Martin wrote: |
Stefan Ritt wrote: |
Holger Mundhahs wrote: | Hello @all,
I'm not sure if this is a bug, but after upgradeing from 2.7.0 to 2.7.7 the Change <attribute> and List Change <attribute> doesn't work anymore. In my .cfg file I've:
In the old ELOG version I've "RIB-Board" as text in the page and the link works well. But now there is the following code generated:
Is the syntax changed from 2.7.0 to 2.7.7? What's the correct syntax for 2.7.7?
|
For security reasons (XSS or cross site scripting) , HTML code in attributes is not allowed by default. To turn it on (and if you know what you are doing), add following line to your configuration
Allow HTML = 1 |
I know this is an old, old thread, but I am trying to use this feature in a recent version of elog (3.1.3). Is there any chance this will ever get fixed, or at least made workable? I tried "Allow HTML = 1", but that did not work. I'd like to be able to use this to link directly to carriers to track packages.
Also, the documentation seemed a bit confusing to me:
Quote: | Change <attribute> = <string>
Instead of subsituting an attribute, the original attribute can be kept and just the output formatting can be changed. This can be very handy for constructing HTML links out of attributes. Presume that a company has a telephone book reachable under
http://any.company.com/telbook.cgi?search=<name>
where <name> has to be replaced by a search string. Now one can construct an automatic telephonebook lookup with following options:
Attributes = Name, Telephone, ...
Display Telephone = <a href="http://any.company.com/telbook.cgi?search=$Name">$Name's telephone number</a>
The attribute Telephone is now automatically constructed from the attribute Name and consists of a link to the company's telephonebook. The advantage of this system is if the URL of the telephonebook changes one day, only one statement in the config file has to be changed, while otherways (like with the Subst Telephone = ... option) all entries would have to be changed manually. |
The example seems to be using a different syntax ("Display Telephone") rather than the syntax described by the section header ("Change <attribute>...").
Any update to this information would be greatly appreciated. I'm just looking for a workable solution of any kind. Thank you for your continuing fine work. |
I am able to make it work by passing just a plain string constructing the URL. Strange though... before I posted the previous log entry, it didn't work no matter what I tried! Bizarre.
However, it would still be a good idea to update the documentation to clarify things somewhat and bring it up to date with actual usage today. |
You are referring here to a Forum entry for an old ELOG version: this will not be changed, since it was for that old version.
If you want some documentation to be updated, then you should show the documentation part that should be updated. |
Re: Change / List Change doen't work anymore?, posted by Harry Martin on Wed Dec 2 00:43:31 2020
|
Andreas Luedeke wrote: |
Harry Martin wrote: |
Harry Martin wrote: |
Stefan Ritt wrote: |
Holger Mundhahs wrote: | Hello @all,
I'm not sure if this is a bug, but after upgradeing from 2.7.0 to 2.7.7 the Change <attribute> and List Change <attribute> doesn't work anymore. In my .cfg file I've:
In the old ELOG version I've "RIB-Board" as text in the page and the link works well. But now there is the following code generated:
Is the syntax changed from 2.7.0 to 2.7.7? What's the correct syntax for 2.7.7?
|
For security reasons (XSS or cross site scripting) , HTML code in attributes is not allowed by default. To turn it on (and if you know what you are doing), add following line to your configuration
Allow HTML = 1 |
I know this is an old, old thread, but I am trying to use this feature in a recent version of elog (3.1.3). Is there any chance this will ever get fixed, or at least made workable? I tried "Allow HTML = 1", but that did not work. I'd like to be able to use this to link directly to carriers to track packages.
Also, the documentation seemed a bit confusing to me:
Quote: | Change <attribute> = <string>
Instead of subsituting an attribute, the original attribute can be kept and just the output formatting can be changed. This can be very handy for constructing HTML links out of attributes. Presume that a company has a telephone book reachable under
http://any.company.com/telbook.cgi?search=<name>
where <name> has to be replaced by a search string. Now one can construct an automatic telephonebook lookup with following options:
Attributes = Name, Telephone, ...
Display Telephone = <a href="http://any.company.com/telbook.cgi?search=$Name">$Name's telephone number</a>
The attribute Telephone is now automatically constructed from the attribute Name and consists of a link to the company's telephonebook. The advantage of this system is if the URL of the telephonebook changes one day, only one statement in the config file has to be changed, while otherways (like with the Subst Telephone = ... option) all entries would have to be changed manually. |
The example seems to be using a different syntax ("Display Telephone") rather than the syntax described by the section header ("Change <attribute>...").
Any update to this information would be greatly appreciated. I'm just looking for a workable solution of any kind. Thank you for your continuing fine work. |
I am able to make it work by passing just a plain string constructing the URL. Strange though... before I posted the previous log entry, it didn't work no matter what I tried! Bizarre.
However, it would still be a good idea to update the documentation to clarify things somewhat and bring it up to date with actual usage today. |
You are referring here to a Forum entry for an old ELOG version: this will not be changed, since it was for that old version.
If you want some documentation to be updated, then you should show the documentation part that should be updated. |
I have been looking at the documentation at https://elog.psi.ch/elog/config.html#attrib. (See the quoted portion, above.) If there is newer documentation, please post a link for it here. Thank you! |
Re: Change / List Change doen't work anymore?, posted by Stefan Ritt on Wed Dec 2 11:51:24 2020
|
Yepp, the documentation was wrong. I fixed it.
Stefan |
Re: Change / List Change doen't work anymore?, posted by Harry Martin on Thu Dec 3 01:53:59 2020
|
Stefan Ritt wrote: | Yepp, the documentation was wrong. I fixed it.
Stefan |
Thank you. |
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 |
|