Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 315 of 807  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
ID Date Icon Author Author Emaildown Category OS ELOG Version Subject
  68767   Fri Mar 16 17:51:30 2018 Reply Stefan Rittstefan.ritt@psi.chBug reportWindowsELOG V3.1.3-fd7Re: Problem with special character "č"

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.

Orange problem: No clue how C is converted to E. Maybe depends on the encoding of your browser? There is a elog option "charset = xxx" with which you can play.

Matej Sedej wrote:

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 then. Any similar solutions for the red and orange ones?

Thanks,
Matej

Stefan Ritt wrote:

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 to "make" it. I have no idea how to run this on Windows where the current POC log resides. blush 

Stefan Ritt wrote:

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.

 

 

 

  68768   Fri Mar 16 18:08:10 2018 Reply Stefan Rittstefan.ritt@psi.chBug reportWindowsELOG V3.1.3-fd7Re: Problem with special character "č"

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 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.

Orange problem: No clue how C is converted to E. Maybe depends on the encoding of your browser? There is a elog option "charset = xxx" with which you can play.

Matej Sedej wrote:

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 then. Any similar solutions for the red and orange ones?

Thanks,
Matej

Stefan Ritt wrote:

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 to "make" it. I have no idea how to run this on Windows where the current POC log resides. blush 

Stefan Ritt wrote:

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.

 

 

 

 

  68770   Mon Mar 19 16:45:07 2018 Reply Stefan Rittstefan.ritt@psi.chBug reportWindowsV3.1.3-fd7f1e2Re: BSOD

The dump does not help me much. I need to reporduce the problem in a controlled environment.

Stefan

Ales Novak wrote:

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. smiley

After about a year, I upgraded to the latest version. I noticed that it causes the system to crash. It doesn't seem to happen that often. 

I have installed this on 2 machines, one Windows 10 and one on Windows 7. Over the last week I got one BSOD on each OS. 

The elogs have different configs and logbooks. One is a simple elog that doesn't have any attachments or anything funky. Just straight text.

Please see attached a screenshot of the Memory.DMP which has happned seconds after an schedule restarted the elog service on my PC. 

I will keep monitoring and see if will happen again. But I thought I log it here anyway.

Thanks.

Cheers.

Ales.

 

  68771   Mon Mar 26 16:32:43 2018 Idea Stefan Rittstefan.ritt@psi.chInfoAll3.1.2-0914a6New elog setting for large attachments

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>

where <n> is the number of bytes. If an email attachment is larger than <n>, the attachment is not sent with the email notification, but rather replaced by a link to the elog server for that attachment. By clicking on the link in the email notification, a browser will then open and download the large attachment. For each each elog installation, the admin has to figure out what the maximum attachment size of their SMTP server is, and then put this number into the elogd.cfg setting  above. For most installations, the default of 10 MB will just work fine.

Stefan

  68780   Wed Apr 11 11:55:47 2018 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux3.1.3Re: problem with chkeditor

Can you post a picture here?

Andrea Mazzolari wrote:

Hi All,
I just installed elog latest version. I can see that my chkeditor (HTML encoding) is pretty simplified with respect to the version i can see there. Why this ? For example, it does not offer the possibility to upload images.

Could you please help me ?


Thank you
Andrea

 

  68783   Sat Apr 14 08:50:40 2018 Reply Stefan Rittstefan.ritt@psi.chBug reportMac OSX3.1.3Re: "Slow script" problem posting/editing from Safari -- browser hangs, times out

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?

Stefan

Michael Hibbard wrote:

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.

Michael Kelsey wrote:

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 all of my edits, uploads, whatever.  This used to be occasional, but in the past month it has become routine, such that the only way I can edit or create entries is by launching a different browser entirely (Firefox), just for e-Log editing.

Now, I am also seeing the same problems with Firefox, but at the "occasional" level.  The difference is that Firefox produces some diagnostic information, which is why I'm posting here.  When the browser hangs, after a short while Firefox produces a "Warning: unresponsive script" drop-down box:

Warning: unresponsive script

A script on this page may be busy, or it may have stopped responding.  You can stop the script now, open the script in the debugger, or let the script continue.

Script: http://titus.stanford.edu/cdms…/SuperSim/681?cmd=Edit&steal=1:30

[] Don't ask me again

[Debug script]                       [Stop script]     [Continue]

If I use the [Debug script] button, the call stack shows "onclick 681:1" -> "chkform 681:30", and the line-by-line traceback shows the chkform function:

16   var in_asend = false;
17
18   function chkform()
19   {
20     if (last_key == 13) {
21       var ret = confirm('Really submit this entry?');
22       if (!ret) {
23         last_key = 0;
24         return false;
25       }
26     }
27
28     if (autoSaveTimer != null)
29       clearTimeout(autoSaveTimer);
30     while (in_asend);               <=== This is the stuck line
31     submitted = true;
32     return true;
33   }

I presume that in_asend is supposed to get changed from false to true asynchronously, by some other parallel communication with the server. But that doesn't seem to be happening.

Does this look like an issue with the e-Log distribution? Or is there a configuration issue with our e-Log server which we could improve?

 

 

  68786   Mon Apr 16 08:19:16 2018 Reply Stefan Rittstefan.ritt@psi.chBug reportMac OSX3.1.3Re: "Slow script" problem posting/editing from Safari -- browser hangs, times out

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 a round-trip to the elogd server. If the user hist "submit" during such a save, the second save might be issue before the first one has been finsihed. That's why I had a "while (in_asend)" in the code, where in_asend gets set to true when the AJAX call is started and false when it completes. Now JavaScript is not really multi-threading, so having a loop "while (in_asend)" can actually prevent the AJAX request to complete. This might have been different when I implemented that feature, which is the reason that it worked before. Without that code, it can now happen that a second HTTTP POST is sent before the first request finishes, but I guess this should not be a problem, since both requests come sequentially to the elogd server and are executed one after the other. So in worst case the elog entry text is just saved twice.

Michael Kelsey wrote:

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 my problem.

  -- Mike Kelsey

Followup Sunday 15 Apr (U.S. Pacifiic time):  I think your suggestion has solved my problem.  I've been able to create and modify e-Log entries through our server multiple times over the weekend.  There have been no hangs, timeouts, or lost content.  Thank you very much for your response!

Stefan Ritt wrote:

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?

Stefan

Michael Hibbard wrote:

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.

Michael Kelsey wrote:

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 all of my edits, uploads, whatever.  This used to be occasional, but in the past month it has become routine, such that the only way I can edit or create entries is by launching a different browser entirely (Firefox), just for e-Log editing.

Now, I am also seeing the same problems with Firefox, but at the "occasional" level.  The difference is that Firefox produces some diagnostic information, which is why I'm posting here.  When the browser hangs, after a short while Firefox produces a "Warning: unresponsive script" drop-down box:

Warning: unresponsive script

A script on this page may be busy, or it may have stopped responding.  You can stop the script now, open the script in the debugger, or let the script continue.

Script: http://titus.stanford.edu/cdms…/SuperSim/681?cmd=Edit&steal=1:30

[] Don't ask me again

[Debug script]                       [Stop script]     [Continue]

If I use the [Debug script] button, the call stack shows "onclick 681:1" -> "chkform 681:30", and the line-by-line traceback shows the chkform function:

16   var in_asend = false;
17
18   function chkform()
19   {
20     if (last_key == 13) {
21       var ret = confirm('Really submit this entry?');
22       if (!ret) {
23         last_key = 0;
24         return false;
25       }
26     }
27
28     if (autoSaveTimer != null)
29       clearTimeout(autoSaveTimer);
30     while (in_asend);               <=== This is the stuck line
31     submitted = true;
32     return true;
33   }

I presume that in_asend is supposed to get changed from false to true asynchronously, by some other parallel communication with the server. But that doesn't seem to be happening.

Does this look like an issue with the e-Log distribution? Or is there a configuration issue with our e-Log server which we could improve?

 

 

 

 

  68789   Wed Apr 18 12:30:51 2018 Reply Stefan Rittstefan.ritt@psi.chQuestionWindows3.1.1Re: Email Config

SMTP host = ...

as written in the documentation!

Automatic email after expiration is not possible.

Stefan Werler wrote:

Hi,
I´m new in ELOG,
Can u explain me how i config the Mailing?
in my Configuration i do have not the ability to set an Email Host/Server. or i didn´t find it....

I have to use ELOG as ticket system, is it possible to send an email automatically after expiration of a period?

 

ELOG V3.1.5-3fb85fa6