| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
68885
|
Tue Feb 5 08:10:32 2019 |
 | Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 3.1.3 | Re: quick filter not working for attributes with special char |
No, there is no quick workaround. The only way is to go through your logbook files manually (or with a script), and replace all occurrences of that attribute.
Stefan |
|
68900
|
Wed Feb 27 02:34:46 2019 |
 | Xuan Wu | wux@ihep.ac.cn | Question | Linux | 3.1.3 | elog hanged when uploading photo failed |
Hi all,
We came across a problem recently when clicking "Upload" button, then elog hanged and never being accessed. I have checked the elog logs and find that it seems that elog didn't get the path of the picture for some reason. So is it a bug or our operation isn't correct? |
| Attachment 1: log.png
|
|
|
68906
|
Tue Mar 5 20:48:51 2019 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 3.1.3 | Re: elog hanged when uploading photo failed |
The problem is you have some weird characters in your file name R2BLM15 ? ? ? ? ? .PNG which confuses the interpreter. There should not be any special character or blanks in attached images.
Stefan
| Xuan Wu wrote: |
|
Hi all,
We came across a problem recently when clicking "Upload" button, then elog hanged and never being accessed. I have checked the elog logs and find that it seems that elog didn't get the path of the picture for some reason. So is it a bug or our operation isn't correct?
|
|
|
68907
|
Wed Mar 6 05:10:28 2019 |
| Xuan Wu | wux@ihep.ac.cn | Question | Linux | 3.1.3 | Re: elog hanged when uploading photo failed |
That make sense. Is there a way to recovery when hung except restart elogd? On the other hand, whether could prompt for reloading attachment when interpreter detect error but not hang?
Wu Xuan
| Stefan Ritt wrote: |
|
The problem is you have some weird characters in your file name R2BLM15 ? ? ? ? ? .PNG which confuses the interpreter. There should not be any special character or blanks in attached images.
Stefan
| Xuan Wu wrote: |
|
Hi all,
We came across a problem recently when clicking "Upload" button, then elog hanged and never being accessed. I have checked the elog logs and find that it seems that elog didn't get the path of the picture for some reason. So is it a bug or our operation isn't correct?
|
|
|
|
68916
|
Thu Mar 21 16:14:00 2019 |
 | Ben Loer | ben.loer@pnnl.gov | Question | Linux | 3.1.3 | elog.css and lock.png fail to load with top groups |
As the title says, we have our elog running behind an Apache proxy that is also providing authentication. We also have top groups enabled. The first time a user views a top group page with a fresh browser cache, the index is delivered, but requests for elog.css and lock.png are returned with http 302 with location set to the elog root. (I.e., if the server is proxied under server.example.com/logs, the first request for server.example.com/logs/TopGroup1/elog.css returns a 302 with location set to server.example.com/logs// ).
Any subsequent visits return the files fine. The attached screenshot shows the network requests in chrome.
Is this a proxy configuration issue, something we've set wrong in elog, ??
|
| Attachment 1: elog1.png
|
|
|
68924
|
Thu Apr 4 12:12:58 2019 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 3.1.3 | Re: elog.css and lock.png fail to load with top groups |
Looks more like a bug to me. Will investigate.
Stefan
| Ben Loer wrote: |
|
As the title says, we have our elog running behind an Apache proxy that is also providing authentication. We also have top groups enabled. The first time a user views a top group page with a fresh browser cache, the index is delivered, but requests for elog.css and lock.png are returned with http 302 with location set to the elog root. (I.e., if the server is proxied under server.example.com/logs, the first request for server.example.com/logs/TopGroup1/elog.css returns a 302 with location set to server.example.com/logs// ).
Any subsequent visits return the files fine. The attached screenshot shows the network requests in chrome.
Is this a proxy configuration issue, something we've set wrong in elog, ??
|
|
|
68927
|
Thu Apr 11 20:31:55 2019 |
 | Ben Loer | ben.loer@pnnl.gov | Bug report | Linux | 3.1.3 | Can't subscribe email to logbooks in different top groups |
We're running elogd behind an apache proxy server, with Authentication = Webserver. We have top groups configured, but a single shared password file.
If a user is looking at a particular logbook and goes to the Config link, they are presented with a list of checkboxes for email subscription to logbooks in that top group. Clicking "Save" will remove all email subscriptions from all other top groups.
Is there a workaround to this issue?
EDIT: Manually adding an entry for different logbooks in the password file gets clobbered the next time the user logs in. |
|
68928
|
Fri Apr 12 15:43:42 2019 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 3.1.3 | Re: Can't subscribe email to logbooks in different top groups |
Top groups should use separate password files, otherwise things can mess up.
Stefan
| Ben Loer wrote: |
|
We're running elogd behind an apache proxy server, with Authentication = Webserver. We have top groups configured, but a single shared password file.
If a user is looking at a particular logbook and goes to the Config link, they are presented with a list of checkboxes for email subscription to logbooks in that top group. Clicking "Save" will remove all email subscriptions from all other top groups.
Is there a workaround to this issue?
EDIT: Manually adding an entry for different logbooks in the password file gets clobbered the next time the user logs in.
|
|