"Slow script" problem posting/editing from Safari -- browser hangs, times out, posted by Michael Kelsey on Wed Apr 11 18:14:35 2018
|
Hello! The CDMS collaboration is using e-Log as one of it's issue tracking systems. In the last few months, I have noticed a problem
when either creating or editing entries from my usual Safari browser (currently 11.1 on MacOSX 10.13.4): The [Submit] button triggers
a spinning beach ball, with no connection to our e-Log server, and after several minutes, Safari complains the the page had to be reloaded, discarding |
Re: "Slow script" problem posting/editing from Safari -- browser hangs, times out, posted by Michael Hibbard on Thu Apr 12 14:13:18 2018
|
I dont' have a solution, but I just wanted to bring more attention to your post. I too am having the same issue with the ELOG system and the Safari
browser. I have noticed that ELOG is most stabel and function on the client end from the IE browser. A few weeks ago I also had to switch from using ELOG
on the client end from Safari to Firefox. |
Re: "Slow script" problem posting/editing from Safari -- browser hangs, times out, posted by Stefan Ritt on Sat Apr 14 08:50:40 2018
|
I'm not 100% sure, but I believe it should work without the
while (in_asend);
So can you please remove that line (it's in src/elogd.c) and recompile elogd and test it? |
Re: "Slow script" problem posting/editing from Safari -- browser hangs, times out, posted by Michael Kelsey on Sun Apr 15 08:03:21 2018
|
Thank you for your suggestion, Stefan! The sysadmin who handles our e-Log server implemented your suggestion earlier today (Saturday). I
have been able to successfully create and modify e-Log entries with Safari since then. Since the "slow script" issue has been intermittent
in the past, I plan to continue testing and monitoring for the next day or so. Nevertheless, it appears that removing the waiting loop has alleviated |
Re: "Slow script" problem posting/editing from Safari -- browser hangs, times out, posted by Stefan Ritt on Mon Apr 16 08:19:16 2018
|
Ok, I removed the code from the official code now.
A bit background: The "autosave" mechanism in elog saves regularly the current content in a "draft" message, so that the
data does not get lost if the browser for example crashes. The saving is done asynchronously via some AJAX call. This call takes some time, since it's |
"Drop attachments here..." only functional in IE, posted by Michael Hibbard on Thu Apr 5 06:00:09 2018
|
Hello, the "drop attachments here..." feature is very useful, especially when I have multiple files. I can drag them all over in one operation,
however I have noticed that this feature only works well in the IE browser.
It does not work reliably in Safari/Chrome/Firefox. I have tired in both 3.1.3 and 3.1.2. I also have the same symptom on the Demo log book of |
Create past Elog entry., posted by Michael Hibbard on Mon Apr 2 23:31:51 2018
|
Hello, Sorry if this has been addressed elsewhere, but I could not find info.
I am wanting to submit a new elog entry (that should have been) for a past date, to predate log entrys currently in my system.
I assume I must manually create a new .log file. What ID# should I assign to this entry? Should I sub-increment (i.e 33.1)? I presume the |
Re: Create past Elog entry., posted by David Pilgram on Tue Apr 3 09:39:07 2018
|
Hi Michael,
Elog purists, look away now.
There is an "official" way to do this, which is to have fields for entry date (so can be in the past), but the yymmdda.log file will |
Re: Create past Elog entry., posted by Michael Hibbard on Tue Apr 3 22:34:49 2018
|
Thank you David, Andreas. Very useful forum.
David
Pilgram wrote:
Hi Michael, |
Re: Create past Elog entry., posted by Andreas Luedeke on Tue Apr 3 10:19:07 2018
|
David answered the question already.
I would distinguish if this is a once-in-a-year event, where you are willing to edit the logfiles as an administrator to fix it -
or
if it happens more weekly, and you want to enable the users to fix it themself.
If it happens once a year and you don't |
New elog setting for large attachments, posted by Stefan Ritt on Mon Mar 26 16:32:43 2018
|
Most mail delivery systems have a maximum size for attachments. In the past, if an elog attachment was larger than this size, the email server refused
to accept this email and no notification is sent. Now one can specify the maximum allowed email attachment size with
Max email attachment size = <n> |
BSOD, posted by Ales Novak on Fri Feb 23 21:27:12 2018
|
Hi,
I have been using elog for a few years and it is a wonderfull software and has been one that I can't go without. So thank you very much for
making it. |
Re: BSOD, posted by Stefan Ritt on Mon Mar 19 16:45:07 2018
|
The dump does not help me much. I need to reporduce the problem in a controlled environment.
Stefan
Ales |
Problem with special character "č", posted by Matej Sedej on Fri Feb 16 09:18:56 2018
|
Hello!
First of all, thank you for this great piece of software! For now it seems to perfectly cover our need to log very basic events, there was a
setting for everything we wanted to set. |
Re: Problem with special character "č", posted by Matej Sedej on Fri Feb 16 09:36:18 2018
|
I see the same problem exists on this board as well. Actuall it appears only the attribute fields are affected. The č character was incorrectly
written to the log file from the subject field above, but correctly from the body text below.
Matej |
Re: Problem with special character "č", posted by Stefan Ritt on Tue Mar 6 15:08:23 2018
|
Actually unicode characters are converted by your browser into HTML code (such as Č) where 268 decimal = 10C hex. elog just writes to file what
it gets from the browser. When an existing elog entry gets shown by the browser, the code is translated back to the character. Why do you care what is
written to the log file? If you use scripts or so to parse your log files, you have to adapt them to correctly decode HTML encoded characters. This is |
Re: Problem with special character "č", posted by Matej Sedej on Tue Mar 6 15:29:38 2018
|
Hello Stefan,
thank you for the reply. The explanation does not solve my problem though.
1) Could you elaborate, why the body text field CORRECTLY writes the character while the |
Re: Problem with special character "č", posted by Stefan Ritt on Tue Mar 6 15:54:23 2018
|
In the attribe filed, HTML code is not allowed for security reasons. If you want to bypass this (on your own risk), put
allow html = 1
into your config file. |
Re: Problem with special character "č", posted by Matej Sedej on Tue Mar 6 16:09:05 2018
|
This tag does not change the behaviour, but I have noticed that I only have the problem in Chrome and Firefox but not in Internet explorer.
Matej
Stefan |
Re: Problem with special character "č", posted by Matej Sedej on Thu Mar 15 09:39:20 2018 
|
To conclude this topic, we sadly can't use the characters č and Č propperly in the application. I have marked the problems in the screenshots
below:
red square - the user name is changed immediately after saving. It is also written into the log file in the |
Re: Problem with special character "č", posted by Stefan Ritt on Fri Mar 16 12:46:09 2018
|
I had time to look at the problem in detail. I found that a &#xxx; sequence is not correctly identified as HTML code, and thus displayed in plain
when used in an attribute. I fixed it in the current git revision and now it looks find in attribute (see attachment). Can you give it a try? Please note
that you need "Allow HTML = 1" in your config file. |
Re: Problem with special character "č", posted by Matej Sedej on Fri Mar 16 14:12:04 2018
|
Great news Stefan! Please pardon my ignorance, but I was not able to "make" it. I have no idea how to run this on Windows where the current
POC log resides. |
Re: Problem with special character "č", posted by Stefan Ritt on Fri Mar 16 14:35:05 2018
|
Easiest is to install the Cywgin environment (www.cygwin.com) and there select the C compiler package which installs also "make".
Matej
Sedej wrote:
Great news Stefan! Please pardon my ignorance, but I was not able |
Re: Problem with special character "č", posted by Matej Sedej on Fri Mar 16 15:39:17 2018
|
Phew, made it, sort of. Had to copy the contents of the mxml folder from an older version, the folder was empty in this git. I also had to change the
SSL to 0 and then it compiled without errors plus I had to copy the cygwin1.dll to the folder to make the service run.
So yes, I can confirm that manually inputting the Č in the attribute field now works correctly. Excellent! This solves the pink problem |
Re: Problem with special character "č", posted by Stefan Ritt on Fri Mar 16 17:51:30 2018
|
Pink problem: Yes the CSV export preserves the html tags, but what to do. CSV files are plain text with 8 bit characters. Unicode characgers have to
be represented with more than one byte. So either HTML encoding or some special escape sequence encoding. If you like the second better than the first,
I'm sure you find some conversion program on the internet. |
Re: Problem with special character "č", posted by Stefan Ritt on Fri Mar 16 18:08:10 2018
|
Special characters in use names should now work in the current version.
Stefan
Ritt wrote:
Pink problem: Yes the CSV export preserves the html tags, but what to |
Re: Problem with special character "č", posted by Matej Sedej on Fri Mar 16 20:54:40 2018
|
That's great, Stefan, it works indeed. I tried fiddling around a bit with different charsets but haven't been succesful yet. I'll play around
some more.
Stefan |
how to insert images inline, posted by Piotr Zolnierczuk on Tue Mar 6 16:59:29 2018
|
Hi,
I recently upgraded elog from 2.7 to 3.1 and have a hard time to insert images inline. The attachements work just fine. I am certain it is something
silly, but I cannot figure it out. |
Re: how to insert images inline, posted by Stefan Ritt on Tue Mar 6 17:28:46 2018
|
Before you click OK on your point 4, click on "Send to Server".
Stefan
Piotr |
Re: how to insert images inline, posted by Piotr Zolnierczuk on Tue Mar 6 17:49:49 2018
|
I did just that. The image was properly send to the server (it appears in the attachement list). However clicking OK still produces "Image source
URL is missing".
What is the URL that refers to an attachment? I've tried 68759/<1> and 68759/1 and even elog:1234/<1> (where |
Re: how to insert images inline, posted by Piotr Zolnierczuk on Tue Mar 6 18:01:30 2018
|
Got it to work. Removed "Preview attachments = 1" from the global section.
Thanks for your help.
Piotr |
User passwords not configurable with loacl passwordfile, posted by KaterKarlo99 on Tue Feb 27 15:11:23 2018
|
Hi!
Tryed windows an linux version. On booth the "Register new User" dialog is not displaying a password line.
so what password is used for the new user? Further the user can't change his password, because he didn't know the old one. |
Re: User passwords not configurable with loacl passwordfile, posted by Stefan Ritt on Tue Feb 27 15:32:30 2018
|
Have you configures user-level access via
password file = anyfile.pwd
Can your elogd server write to that file?
If yes, can you please post your config file? |
Re: User passwords not configurable with loacl passwordfile, posted by KaterKarlo98 on Wed Feb 28 11:38:23 2018
|
Hi Stefan,
thanks for the quick reply.
Yes, i've configured user-level access. Here is my cfg: |
Re: User passwords not configurable with loacl passwordfile, posted by KaterKarlo99 on Mon Mar 5 14:10:52 2018
|
I'm afraid that there is something wrong because each user will be written with the same (hashed) password to the local password file,
irrespective of the given password within the "new User dialog".
So for instance, every user in my password file lokks like this: |
Re: User passwords not configurable with loacl passwordfile, posted by Stefan Ritt on Mon Mar 5 14:29:26 2018
|
What happens when you don't use Kerberos authentication?
KaterKarlo99
wrote:
I'm afraid that there is something wrong because each user will be written |
Re: User passwords not configurable with loacl passwordfile, posted by KaterKarlo99 on Mon Mar 5 14:44:58 2018
|
Yeah!!
That did it! I remove the line "Kerberos authentication" and now it works!
Thanks! |