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

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

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?

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

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

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, ??

Looks more like a bug to me. Will investigate.

Stefan

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.