Re: inactive users, posted by Stefan Ritt on Fri Dec 21 14:59:05 2018
|
Thanks for the fix, I merged it into the current development branch.
Stefan |
quick filter not working for attributes with special char , posted by Stefano Lacaprara on Tue Feb 5 07:31:44 2019
|
Hi,
I'm using elog 3.1.3 and I have an elogbook with an attribute with name
Attributes = Author, CO2 Temp [deg], ...
If I add this attributes to quick list,
Quick filter = Author, CO2 Temp [deg]
it does display on web page, but the search fails with "ERR_TOO_MANY_REDIRECTS" if I leave the default value in the corresponding quick filter box.
My understanding is that the presence of a "[]" in the default search value is the reason for failure and if I remove them the search works fine.
Is there a workaround?
I don't want to change the attribute name, since I do have quite a large number of entries in the elogbook, and I'd like to keep the attribute in the quick search if possible.
Thanks,
Stefano |
|
Re: quick filter not working for attributes with special char , posted by Stefan Ritt on Tue Feb 5 08:10:32 2019
|
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 |
elog hanged when uploading photo failed, posted by Xuan Wu on Wed Feb 27 02:34:46 2019 
|
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? |
|
Re: elog hanged when uploading photo failed, posted by Stefan Ritt on Tue Mar 5 20:48:51 2019
|
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?
|
|
|
Re: elog hanged when uploading photo failed, posted by Xuan Wu on Wed Mar 6 05:10:28 2019
|
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?
|
|
|
|
elog.css and lock.png fail to load with top groups, posted by Ben Loer on Thu Mar 21 16:14:00 2019
|
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, ??
|
|
Re: elog.css and lock.png fail to load with top groups, posted by Stefan Ritt on Thu Apr 4 12:12:58 2019
|
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, ??
|
|