ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
68986
|
Fri Jun 14 11:29:30 2019 |
| Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Bug report | All | 3.1.4 | Find cannot find values with brackets |
For demonstration, I created https://elog.psi.ch/elogs/Linux+Demo/8
The Find search for category aaa(bb) does not give results.
A quick filter corrects the value to aaa\(bb) and delivers results.
I made a simple fix and submitted it as PR to the bitbucket repository. |
68987
|
Fri Jun 14 12:43:04 2019 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | All | 3.1.4 | Re: Find cannot find values with brackets |
I‘m happy to merge the PR after a quick test next week.
Stefan
Sebastian Schenk wrote: |
For demonstration, I created https://elog.psi.ch/elogs/Linux+Demo/8
The Find search for category aaa(bb) does not give results.
A quick filter corrects the value to aaa\(bb) and delivers results.
I made a simple fix and submitted it as PR to the bitbucket repository.
|
|
68993
|
Mon Jul 15 17:35:48 2019 |
| Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Bug report | Linux | 3.1.4 | restrict edit time |
Hello,
I have experienced some inconveniences with the restrict edit time option.
First, it is not possible for admin users to edit an entry after the edit time.
The restrict edit option allows admin users to edit posts from other users,
so I think admins should also be allowed to edit posts after edit time.
As they can edit the config and temporarily disable the restrict edit time option, which is an issue.
Secondly, if a user made a draft and did not submitted it before the edit time runs out,
the draft got stuck as it cannot be edited (and submitted) any more.
Best wishes,
Sebastian |
69044
|
Wed Oct 16 13:20:31 2019 |
| Xuan Wu | wux@ihep.ac.cn | Bug report | Linux | 3.1.3 | Re: elog hanged when uploading photo failed |
Hi all,
I've found a bug in elog. It's all right that uploading an image which file name with special characters. I think it must have something to do with the code like"url_encode(file_enc, sizeof(file_enc)); /* for file names with special characters like "+" */". If I clicked the "Make small/Make larger/Original size/Rotate left/Rotate right" button, the elog server will hang. How it can be fixed? The attached image shows the debug info.
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?
|
|
|
Attachment 1: error.png
|
|
69063
|
Fri Nov 22 02:55:50 2019 |
| John S. Haggerty | haggerty@bnl.gov | Bug report | Mac OSX | 3.1.4 | Trouble on Catalina |
I decided to rebuild elog 3.1.4 in Catalina (MacOS 10.15.1), XCode 11.2.1. As in previous builds, I needed to add to the Makefile pointers to openssl:
CFLAGS += -I/usr/local/opt/openssl/include
LIBS += -L/usr/local/opt/openssl/lib
The make builds cleanly, no errors, no warnings. After make/make install, elogd segfaults immediately. I saw the same behavior with the version in gitlab. I kept my (very) old build and was able to make install it without recompiling and it still works.
I'll crack out the debugger when I have a chance to get more information, but has anyone else seen this problem? |
69066
|
Mon Nov 25 16:25:21 2019 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Mac OSX | 3.1.4 | Re: Trouble on Catalina |
The Makefile is kind of obsolete, I switched to CMake. So the Makefiel is mostly there as backup. To compile elog, do
elog$ mkdir build; cd build
elog/build$ cmake ..
elod/build$ make install
that should also find your openssl library, since CMake is more clever.
I personally have not yet switched to MacOS Catalina, since I have too many 32-bit programs running there and wait until all of these get updated. Only then I will be able to test elog under Catalina.
Stefan
John S. Haggerty wrote: |
I decided to rebuild elog 3.1.4 in Catalina (MacOS 10.15.1), XCode 11.2.1. As in previous builds, I needed to add to the Makefile pointers to openssl:
CFLAGS += -I/usr/local/opt/openssl/include
LIBS += -L/usr/local/opt/openssl/lib
The make builds cleanly, no errors, no warnings. After make/make install, elogd segfaults immediately. I saw the same behavior with the version in gitlab. I kept my (very) old build and was able to make install it without recompiling and it still works.
I'll crack out the debugger when I have a chance to get more information, but has anyone else seen this problem?
|
|
69076
|
Thu Dec 19 16:28:06 2019 |
| Devin Bougie | dab66@cornell.edu | Bug report | Linux | Windows | Mac OSX | All | Other | 3.1.4 | text wrapping broken in firefox |
When creating new logbook entries, recent versions of firefox somehow ignore the message width setting.
For example, configure a logbook with:
Message Width = 76
Message Height = 20
Then, create a new plain text entry that contains very long lines. The text entry box is the correct size, but once you hit submit and view the full display of the message, it is not wrapped properly. The summary display is wrapped properly, but not the full display.
We've only found this to be a problem with recent versions of firefox. Chromium, Safari, and old versions of firefox behave properly. |
69077
|
Thu Dec 19 16:40:10 2019 |
| Devin Bougie | dab66@cornell.edu | Bug report | Linux | Windows | Mac OSX | All | Other | 3.1.4 | Re: text wrapping broken in firefox |
As an example, I created this same entry in the demo logbook using Safari. As you can see there, the message is wrapped at the width that I set the text entry box.
https://elog.psi.ch/elogs/Linux+Demo/9
> When creating new logbook entries, recent versions of firefox somehow ignore the message width setting.
>
> For example, configure a logbook with:
> Message Width = 76
> Message Height = 20
>
> Then, create a new plain text entry that contains very long lines. The text entry box is the correct size, but once you hit submit and view the full display of the message, it is not wrapped properly. The summary display is wrapped properly, but not the full display.
>
> We've only found this to be a problem with recent versions of firefox. Chromium, Safari, and old versions of firefox behave properly. |