Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 248 of 806  Not logged in ELOG logo
ID Date Icon Author Author Email Category OSdown ELOG Version Subject
  69411   Mon Nov 15 11:48:25 2021 Reply Chris Körnerchris.koerner@physik.uni-halle.deBug reportWindows3.14Re: 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 Reply Sebastian Schenksebastian.schenk@physik.uni-halle.deBug reportWindows3.14Re: 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 Reply Chris Körnerchris.koerner@physik.uni-halle.deBug reportWindows3.14Re: 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 Entry Anthony J Krishockajkrishock@gmail.comQuestionWindowslatestDump 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 Reply Andreas Luedekeandreas.luedeke@psi.chQuestionWindowslatestRe: 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 Question Alan Grantagrant@winnipeg.caQuestionWindows3.1.4Log4j exploit

Is there any potential impact/concern with the Log4j exploit in Elog applications?

 

  69448   Tue Dec 14 21:55:16 2021 Reply Stefan Rittstefan.ritt@psi.chQuestionWindows3.1.4Re: 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 Reply Sergio Navarretesergionavarrete@gmail.comQuestionWindows3.1.3Re: 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?

 

 

 

 

 

ELOG V3.1.5-3fb85fa6