| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
68092
|
Mon Aug 17 11:28:08 2015 |
 | Philip Leung | philip.leung@cern.ch | Question | Linux | Windows | 3.1.1 | Re: Isolating search urls |
Would there be a simple way to redirect all URLs BUT the ones which trigger searches?
| Stefan Ritt wrote: |
|
For any other filter you need "&<attribute>=", which of course requires the knowlede of all attributes. There is no other "standard" flag in the URL indicating a search.
| Philip Leung wrote: |
|
This only applies to searches which specify that they are searching through the message text though. It would not work for things like quick filter
| Stefan Ritt wrote: |
|
Look for "&subtext=" in the URL
| Philip Leung wrote: |
|
Is there no good way of differentiating search operations from others by URL?
| Philip Leung wrote: |
|
Thanks for the quick response!
It's great to hear that multi-threading is in the works as this has been my main issue with an otherwise very nice piece of software. I do, however, feel like we should be able to get my slightly hacky approach to work to hold us over until you finish.
The idea is to run separate ELOG instances in read-only mode dedicated to these types of requests. I've managed to sync up the logbook indexation of each instance so now, unless there's some statefulness to ELOG that I'm forgetting about, I only need to make sure that requests are forwarded to the right instance.
| Stefan Ritt wrote: |
|
I guess the underlying problem is the long time these requests take and block other users.
I have pretty high on my todo list to convert ELOG into a multi-threaded server which would fix this completely. So if you are patient enough (=months) you might get what you want.
| Philip Leung wrote: |
|
Hello all,
I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.
Does anybody have any suggestions?
Regards,
Philip
|
|
|
|
|
|
|
|
|
68093
|
Mon Aug 17 11:36:49 2015 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | Windows | 3.1.1 | Re: Isolating search urls |
No, no and again: no.
| Philip Leung wrote: |
|
Would there be a simple way to redirect all URLs BUT the ones which trigger searches?
| Stefan Ritt wrote: |
|
For any other filter you need "&<attribute>=", which of course requires the knowlede of all attributes. There is no other "standard" flag in the URL indicating a search.
| Philip Leung wrote: |
|
This only applies to searches which specify that they are searching through the message text though. It would not work for things like quick filter
| Stefan Ritt wrote: |
|
Look for "&subtext=" in the URL
| Philip Leung wrote: |
|
Is there no good way of differentiating search operations from others by URL?
| Philip Leung wrote: |
|
Thanks for the quick response!
It's great to hear that multi-threading is in the works as this has been my main issue with an otherwise very nice piece of software. I do, however, feel like we should be able to get my slightly hacky approach to work to hold us over until you finish.
The idea is to run separate ELOG instances in read-only mode dedicated to these types of requests. I've managed to sync up the logbook indexation of each instance so now, unless there's some statefulness to ELOG that I'm forgetting about, I only need to make sure that requests are forwarded to the right instance.
| Stefan Ritt wrote: |
|
I guess the underlying problem is the long time these requests take and block other users.
I have pretty high on my todo list to convert ELOG into a multi-threaded server which would fix this completely. So if you are patient enough (=months) you might get what you want.
| Philip Leung wrote: |
|
Hello all,
I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.
Does anybody have any suggestions?
Regards,
Philip
|
|
|
|
|
|
|
|
|
|
68094
|
Mon Aug 17 11:52:54 2015 |
| Philip Leung | philip.leung@cern.ch | Question | Linux | Windows | 3.1.1 | Re: Isolating search urls |
Noted. Thank you for your time
| Stefan Ritt wrote: |
|
No, no and again: no.
| Philip Leung wrote: |
|
Would there be a simple way to redirect all URLs BUT the ones which trigger searches?
| Stefan Ritt wrote: |
|
For any other filter you need "&<attribute>=", which of course requires the knowlede of all attributes. There is no other "standard" flag in the URL indicating a search.
| Philip Leung wrote: |
|
This only applies to searches which specify that they are searching through the message text though. It would not work for things like quick filter
| Stefan Ritt wrote: |
|
Look for "&subtext=" in the URL
| Philip Leung wrote: |
|
Is there no good way of differentiating search operations from others by URL?
| Philip Leung wrote: |
|
Thanks for the quick response!
It's great to hear that multi-threading is in the works as this has been my main issue with an otherwise very nice piece of software. I do, however, feel like we should be able to get my slightly hacky approach to work to hold us over until you finish.
The idea is to run separate ELOG instances in read-only mode dedicated to these types of requests. I've managed to sync up the logbook indexation of each instance so now, unless there's some statefulness to ELOG that I'm forgetting about, I only need to make sure that requests are forwarded to the right instance.
| Stefan Ritt wrote: |
|
I guess the underlying problem is the long time these requests take and block other users.
I have pretty high on my todo list to convert ELOG into a multi-threaded server which would fix this completely. So if you are patient enough (=months) you might get what you want.
| Philip Leung wrote: |
|
Hello all,
I am in need of isolating GET-requests referring to long-running, read-only elog functions such as search/filter/sort in our Apache proxy and redirecting them elsewhere. There does not, however, appear to be any easy way of reliably isolating these functions (with the exception of sort) by only looking at the URL.
Does anybody have any suggestions?
Regards,
Philip
|
|
|
|
|
|
|
|
|
|
|
68095
|
Mon Aug 17 16:30:17 2015 |
| John Krautkramer | john.krautkramer@micrel.com | Question | Linux | 3.1.1 | Re: IE 11 - Text Edit Toolbar Not Working |
The issue was IE Compatibility Mode. There were no websites in the list, but the "Display intranet sites in Compatibility View" was checked. Removing this fixed it.
Thanks for the help!
John
| Stefan Ritt wrote: |
|
Also make sure you don't have "Compatibility Mode" turned on in IE11.
See here for example: http://winaero.com/blog/how-to-enable-compatibility-view-in-internet-explorer-11-ie11/
| Andreas Luedeke wrote: |
|
This reply has been written with IE 11 using the embedded HTML editor of ELOG. Therefore it is obviously not a problem of ELOG 3.1.1 with IE 11.
It could be a problem with your ELOG installation or it could be a problem with you IE 11 configuration. Can you use the HTML editor of this forum with IE11? Did you install ELOG 3.1.1 on top of an existing ELOG installation?
There was a recent post in the forum about IE11 and the HTML editor in the Forum. Did you read it?
Cheers, Andreas
| John Krautkramer wrote: |
|
Hi,
I've been exploring elog. I find when using IE 11, the text editor formatting buttons don't work with HTML encoding selected. The entire toolbar is grayed out. It appears to work fine with Chrome. Any ideas or direction to look? elog v3.1.1 is running on RedHat EL5. I've tried the rpm installation, and source code compilation and installation with no change.
Any input would be greatly apriciated!
John
|
|
|
|
|
68098
|
Thu Aug 20 14:23:43 2015 |
| Edmund Hertle | edmund.hertle@kit.edu | Info | All | 3.1.1 | Re: Version 3.1.1 of elog has been released |
There seems to be a small problem with the new "Date/Time format <attribute>" implementation. It works great for the detailed view of a single entry:
But fails to work on the list view (same entry, the Date column is formated as it should):
Relevant config part:
Time format Time Start = %H:%M:%S
Time format Time End = %H:%M:%S
| Stefan Ritt wrote: |
Version 3.1.1, released August 4th, 2015
-
Updated CKEditor to version 4.5.1
-
Implemented "Date/Time format <attribute> = ..."
-
Implemented "Use Email Subject Edit = ..."
-
Replaced "Back" by "Delete" button
-
Fixed many issues with Draft Messages
-
CSS file is now in *addition* to the default file elog.css
-
Added LDAP documentation
-
Added "Logout to URL = ..." option
-
Added description of Apacher server authentication
|
|
|
68099
|
Thu Aug 20 15:52:26 2015 |
| Stefan Ritt | stefan.ritt@psi.ch | Info | All | 3.1.1 | Re: Version 3.1.1 of elog has been released |
Thanks for reportung that bug. I fixed it in revision f828049.
| Edmund Hertle wrote: |
|
There seems to be a small problem with the new "Date/Time format <attribute>" implementation. It works great for the detailed view of a single entry:
But fails to work on the list view (same entry, the Date column is formated as it should):
Relevant config part:
Time format Time Start = %H:%M:%S
Time format Time End = %H:%M:%S
|
|
|
68110
|
Wed Sep 2 20:23:21 2015 |
 | Edmund Hertle | edmund.hertle@kit.edu | Bug report | Windows | 3.1.1 | Attachment Uploaded Time is off by one hour |
If I upload an attachment the timestamp of the attachment is set to one hour in the future, as demonstrated with this test attachment being one hour in the future compared to the entry time |
| Attachment 1: elogTest.rtf
|
{\rtf1\ansi\ansicpg1252\cocoartf1348\cocoasubrtf170
{\fonttbl\f0\fswiss\fcharset0 Helvetica;}
{\colortbl;\red255\green255\blue255;}
\paperw11900\paperh16840\margl1440\margr1440\vieww10800\viewh8400\viewkind0
\pard\tx566\tx1133\tx1700\tx2267\tx2834\tx3401\tx3968\tx4535\tx5102\tx5669\tx6236\tx6803\pardirnatural
\f0\fs24 \cf0 test}
|
|
68113
|
Mon Sep 7 12:44:42 2015 |
| Edmund Hertle | edmund.blomley@kit.edu | Bug report | All | 3.1.1 | Creating ELog Links not working properly in HTML Editor |
Hey,
the syntax for creating links to other elog entries has a small issue in the HTML editor. The link will not be created properly if there are whitespaces in the name of the logbook. Using ELCode (or in a simple attribute field) the whitespaces can be replaced by "+", but this does not work in the HTML editor. The work-around would be to use ELCode mark-up instead of HTML.
Example 1 (this should work): elog:Contributions/47
Example 2 (this will not work): elog:Config+Examples/11
Example 3 (will also not work): elog:Config%20Examples/11 |