ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
69411
|
Mon Nov 15 11:48:25 2021 |
| Chris Körner | chris.koerner@physik.uni-halle.de | Bug report | Windows | 3.14 | Re: Restrict edit time = 0 behavior intended? |
Actually this is related to post 68993 from Sebastian Schenk in Jul 2019. Are there any new workarounds I may have missed?
Chris Körner wrote: |
Hi,
I have set the options "Restrict edit time = 24" and "Admin restrict edit time = 0" in [global]. This way can only edit entries for 24 hours while the admin can forever. I now want a single logbook where all users have unlimited time to edit entries. However, setting "Restrict edit time = 0" in this specific logbook behaves differently to the admin setting as it simply sets the time to 0. Is this behavior intended or a bug? I guess a workaround is to specify the edit limitation not in global but in all logbooks seperately.
|
|
69412
|
Mon Nov 15 14:02:42 2021 |
| Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Bug report | Windows | 3.14 | Re: Restrict edit time = 0 behavior intended? |
Hi Chris,
my old entry was related to the admin options of edit time.
The option "Admin restrict edit time" was implemented later, see ab8b98c
As a workaround you should be able to give "Restrict edit time" a ridiculous high number in the specific logbook, which should overwrite the global.
In the documentation is no rule specified for diabling global settings for specific logbooks, as far as i know.
Best wishes,
Sebastian
Chris Körner wrote: |
Actually this is related to post 68993 from Sebastian Schenk in Jul 2019. Are there any new workarounds I may have missed?
Chris Körner wrote: |
Hi,
I have set the options "Restrict edit time = 24" and "Admin restrict edit time = 0" in [global]. This way can only edit entries for 24 hours while the admin can forever. I now want a single logbook where all users have unlimited time to edit entries. However, setting "Restrict edit time = 0" in this specific logbook behaves differently to the admin setting as it simply sets the time to 0. Is this behavior intended or a bug? I guess a workaround is to specify the edit limitation not in global but in all logbooks seperately.
|
|
|
69416
|
Tue Nov 16 15:14:42 2021 |
| Chris Körner | chris.koerner@physik.uni-halle.de | Bug report | Windows | 3.14 | Re: Restrict edit time = 0 behavior intended? |
Hi Sebastian,
thanks for the reply. It is just a bit confusing that these similar settings behave so differently. For me it is no big deal to set the time for every logbook independently instead of [global], but it leaves more room for configuration errors.
Best,
Chris
Sebastian Schenk wrote: |
Hi Chris,
my old entry was related to the admin options of edit time.
The option "Admin restrict edit time" was implemented later, see ab8b98c
As a workaround you should be able to give "Restrict edit time" a ridiculous high number in the specific logbook, which should overwrite the global.
In the documentation is no rule specified for diabling global settings for specific logbooks, as far as i know.
Best wishes,
Sebastian
Chris Körner wrote: |
Actually this is related to post 68993 from Sebastian Schenk in Jul 2019. Are there any new workarounds I may have missed?
Chris Körner wrote: |
Hi,
I have set the options "Restrict edit time = 24" and "Admin restrict edit time = 0" in [global]. This way can only edit entries for 24 hours while the admin can forever. I now want a single logbook where all users have unlimited time to edit entries. However, setting "Restrict edit time = 0" in this specific logbook behaves differently to the admin setting as it simply sets the time to 0. Is this behavior intended or a bug? I guess a workaround is to specify the edit limitation not in global but in all logbooks seperately.
|
|
|
|
69444
|
Sun Dec 12 01:18:46 2021 |
| Anthony J Krishock | ajkrishock@gmail.com | Question | Windows | latest | Dump screenshot to new elog entry |
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 |
69445
|
Sun Dec 12 08:12:57 2021 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Question | Windows | latest | Re: Dump screenshot to new elog entry |
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
|
|
69446
|
Tue Dec 14 19:16:57 2021 |
| Alan Grant | agrant@winnipeg.ca | Question | Windows | 3.1.4 | Log4j exploit |
Is there any potential impact/concern with the Log4j exploit in Elog applications?
|
69448
|
Tue Dec 14 21:55:16 2021 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | 3.1.4 | Re: Log4j exploit |
ELog does not use the Log4j library so no issue there. If you run a web server like Apache in front of ELog, you however have to check if you use log4j there.
Alan Grant wrote: |
Is there any potential impact/concern with the Log4j exploit in Elog applications?
|
|
69449
|
Thu Dec 16 08:23:22 2021 |
| Sergio Navarrete | sergionavarrete@gmail.com | Question | Windows | 3.1.3 | Re: Logfile not registering entry numbers? |
It seems that the latest Windows binary still predates this fix. Will there be a new installer soon? Thanks for your support.
Stefan Ritt wrote: |
I finally found some time to fix that bug. Was just that the log file hat #0, the bug should not have had any ohter side effects. Now the logfile is fine.
David Pilgram wrote: |
As a regular elog (ab)user, I have seen this behaviour from time to time. So far as I recall, the cause actually is that a normal entry is looking for the entry in the "Reply to" field of the normal entry in the yymmdda.log file. When that entry does not exist, then I see a duplicate line of an entry with entry "#0", in emboldened black type. I did have a screenshot, but cannot find it for now.
A quick (relative term, that) search usually finds the entry which references the missing "Reply to" line, and editing that, all is well. I'm not sure how this can happen, but it does. NB, I'm still on elog 2.9.2 so I don't know how the draft facility works and possibly enhances the possibility of this issue.
Note that this is different to the case (rather more frequent) where the entry in the "In reply to" field is missing. This causes elog to go into a continuous loop and only the strongest measures ("kill -9 xxxx in linux) will break this out. This can happen more frequently as if you delete a thread with a large number (>40?) of entries, elog crashes, but more importantly, hasn't finished the job. Clicking on the remenents of the thread (which are usually the later entries) causes the endless loop.
Andreas Luedeke wrote: |
It looks like you've found a bug in ELOG. I've checked my elog.log and see that all NEW entry lines show "#0".
I've looked into the code: the message is written before the new entry is submitted, and only then the entry ID is defined.
For new entries one would need to make the logging print line later - but that would blow up the code.
The message IDs are correct for saving drafts and editing entries. I'll discuss with Stefan if that should be fixed.
Andreas
Sergio Navarrete wrote: |
I have configured a logbook with the logfile on, but when a user replies to an entry the line logged goes
Date Time [User@IP] {Logbook} NEW entry #0
How can I make the #0 be the real entry number for the reply?
|
|
|
|
|