| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
67667
|
Fri Feb 21 13:25:55 2014 |
 | Stefan Ritt | stefan.ritt@psi.ch | Bug fix | All | 2.9.2-2481 | Re: Export entries to XLS or CSV? |
| Andreas Luedeke wrote: |
|
| Jim Tinlin wrote: |
|
| Stefan Ritt wrote: |
|
| Andreas Luedeke wrote: |
|
Yes, you're right: the text field is only exported in XML and Raw mode.
It is questionable how EXCEL should cope with HTML or ELCode output from the text fields.
But I admit that this would be a useful feature for logbooks that only use plain text entries. And it is simple to implement.
I've attached a patch to elogd.c from elog-2.9.2-2081 that adds a third CVS mode 'CSV (";" separated) + Text'.
(This string has not yet been added to the localization.)
As far as I've tested it works fine to import the text to OpenOffice and EXCEL, even with multiple text lines and HTML code in the text.
Of course the spreadsheet programs just display the HTML source.
Stefan, do you think this should be added to the official branch?
 ⇄
Detect language » English
⇄
Detect language » English
|
Hi Jim, can you confirm that this works for you? If so, I'm willing to incorporate the patch into the distribution.
|
Has this been added yet?
I don't have the means to create an executable for Windows, if someone does I can give it a try...it sounds/looks like it will work.
Thanks!
|
Hi Jim, I've incorporated the patch to our production server about a week ago.
I've agreed with Stefan that he'll add it, when it proved to run stable for a while.
Until now it appears to work fine. I think Stefan will add it to the distribution soon.
But I won't touch any Windows systems, you'll need to wait for someone else to compile it for you.
Maybe some skilled Windows user want to give it a try: i've attached the changes in the elogd.c file from v2.9.2-2481,
the modified file can be currently downloaded from http://people.web.psi.ch/luedeke/public/tmp/elogd.c
⇄
Detect language » English
Andreas
⇄
Detect language » English
⇄
Detect language » English
⇄
Detect language » English
|
This patch is now officially in the GIT repository. |
|
67705
|
Wed Sep 17 17:45:18 2014 |
 | Andreas Luedeke | andreas.luedeke@psi.ch | Info | All | V2.9.2-24 | Re: Sort by date prior to 2002 |
| Chris Jennings wrote: |
|
| Chris Jennings wrote: |
|
I have an attribute formatted as a date (but not labeled as date) and is sorted as second priority. The sort works fine until I enter a date older than Jan 1st 2002. When I do this it is sorted as the latest. Is this a bug or simply not designed to use dates this old?
Thanks in advance,
Chris
|
Sorry, my mistake. The cutoff date is anything before September 9th 2001 does not sort.
|
I think I remember that this has been discussed earlier: it is a little bug in elogd.
You can see where it comes from if you type in the little command 'date -d "9-Sep-2001 3:46:40" +%s'
Converted to "seconds of the epoche" (seconds since 1970-01-01 00:00:00 UTC) the date "9-Sep-2001 3:46:40" has one digit more than "9-Sep-2001 3:46:39".
Since elog makes a string comparison, suddenly 1'000'000'000 is less than 999'999'999; therefore the wrong sorting.
Workaround: you can modify your old entries and add a leading zero to all entries where your specific date field starts with a '9'.
Stefan: you should fix it at least well before 20-Nov-2286 18:46:40, when the same bug strikes again!  |
|
67706
|
Mon Sep 22 14:39:10 2014 |
| Stefan Ritt | stefan.ritt@psi.ch | Info | All | V2.9.2-24 | Re: Sort by date prior to 2002 |
| Andreas Luedeke wrote: |
|
| Chris Jennings wrote: |
|
| Chris Jennings wrote: |
|
I have an attribute formatted as a date (but not labeled as date) and is sorted as second priority. The sort works fine until I enter a date older than Jan 1st 2002. When I do this it is sorted as the latest. Is this a bug or simply not designed to use dates this old?
Thanks in advance,
Chris
|
Sorry, my mistake. The cutoff date is anything before September 9th 2001 does not sort.
|
I think I remember that this has been discussed earlier: it is a little bug in elogd.
You can see where it comes from if you type in the little command 'date -d "9-Sep-2001 3:46:40" +%s'
Converted to "seconds of the epoche" (seconds since 1970-01-01 00:00:00 UTC) the date "9-Sep-2001 3:46:40" has one digit more than "9-Sep-2001 3:46:39".
Since elog makes a string comparison, suddenly 1'000'000'000 is less than 999'999'999; therefore the wrong sorting.
Workaround: you can modify your old entries and add a leading zero to all entries where your specific date field starts with a '9'.
Stefan: you should fix it at least well before 20-Nov-2286 18:46:40, when the same bug strikes again!
|
Ok, well before 2286 approaches I fixed that bug and committed it to the GIT repository (master branch).
/Stefan |
|
67709
|
Fri Oct 24 12:51:00 2014 |
 | Stefan Ritt | stefan.ritt@psi.ch | Bug fix | All | ALL | POODLE vulnerability |
IMPORTANT SECURITY ANNOUNCEMENT
Recently the POODLE vulnerability has been announced: http://en.wikipedia.org/wiki/POODLE
ELOG is prone to this vulnerability if it runs directly the SSL protocol and can be accessed from the internet. If ELOG runs behind an Apache proxy, and the Apache server has been correctly configured (disabled the SSLv23 protocols), ELOG is safe as well.
To fix this vulnerability, ELOG needs to be recompiled after the attached patch has been applied. This prohibits ELOG to fallback to the insecure SSLv2 & v3 protocols and only use the safe TLSv1 protocol.
If you do not know how to recompile ELOG, please do not run ELOG directly accessible from the internet until the next binary release has been published.
/Stefan Ritt |
| Attachment 1: elogd.patch
|
diff --git a/src/elogd.c b/src/elogd.c
index fac34f8..13c619f 100755
--- a/src/elogd.c
+++ b/src/elogd.c
@@ -2342,7 +2342,7 @@ int ssl_connect(int sock, SSL ** ssl_con)
SSL_library_init();
SSL_load_error_strings();
- meth = (SSL_METHOD *) SSLv23_method();
+ meth = (SSL_METHOD *) TLSv1_method();
ctx = SSL_CTX_new(meth);
*ssl_con = SSL_new(ctx);
@@ -28902,7 +28902,7 @@ SSL_CTX *init_ssl(void)
SSL_library_init();
SSL_load_error_strings();
- meth = (SSL_METHOD *) SSLv23_method();
+ meth = (SSL_METHOD *) TLSv1_method();
ctx = SSL_CTX_new(meth);
if (getcfg("global", "SSL Passphrase", pwd, sizeof(pwd))) {
|
|
67752
|
Fri Jan 16 13:41:18 2015 |
 | Eoin Butler | eoin.butler@cern.ch | Request | All | - | Configure default time range in 'Find' |
Hello,
We have a very large elog database, and executing a 'Find' on the whole range takes several minutes, locking other users out of the elog for that time. It would be very nice if there could be an option to set the default value of the 'search last ...' option on the find page. Thanks in advance! |
|
67753
|
Fri Jan 16 14:29:58 2015 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | All | - | Re: Configure default time range in 'Find' |
Have you tried in the "Find" page to set a start date, or select "Show last: Month". This shoudl speed up searching quit a bit.
| Eoin Butler wrote: |
|
Hello,
We have a very large elog database, and executing a 'Find' on the whole range takes several minutes, locking other users out of the elog for that time. It would be very nice if there could be an option to set the default value of the 'search last ...' option on the find page. Thanks in advance!
|
|
|
67754
|
Mon Jan 19 11:09:31 2015 |
| Eoin Butler | eoin.butler@cern.ch | Request | All | - | Re: Configure default time range in 'Find' |
Yes, this works, but users inevitably forget to select "last week" or whatever, and just leave it blank, which means their search unintentionally takes a long time. It would be much better if one could configure it to default to something "fast".
| Stefan Ritt wrote: |
|
Have you tried in the "Find" page to set a start date, or select "Show last: Month". This shoudl speed up searching quit a bit.
|
|
|
67755
|
Mon Jan 19 17:17:32 2015 |
| David Pilgram | David.Pilgram@epost.org.uk | Request | All | - | Re: Configure default time range in 'Find' |
Hi there, In the "Find" page, I changed the default of the "Show last" drop down box in the Entry Date section from the (unstated) "All time" to "Day", and added back in an "All Time" option at the very bottom. This gives a default of searching the last day, and one has to think and select the period of time to search back on.
I did this on my 2.9.2-2475 version, recompiled and it works. Two lines of code changed and even my cr*ppy coding was up to the task. I don't know if Stefan would want to put this into the Master copy (I'll forward the changes if you want Stefan, but it's pretty easy if I can do it), but if you can edit and recompile (Eoin) I can tell you which to lines for immediate functionality. Back up everything first, though!
| Eoin Butler wrote: |
|
Yes, this works, but users inevitably forget to select "last week" or whatever, and just leave it blank, which means their search unintentionally takes a long time. It would be much better if one could configure it to default to something "fast".
| Stefan Ritt wrote: |
|
Have you tried in the "Find" page to set a start date, or select "Show last: Month". This shoudl speed up searching quit a bit.
|
|
|