ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
1531
|
Tue Nov 22 11:35:56 2005 |
| Alex H | alex@synergie-inf.com | Bug report | Windows | 2.6.0-beta | Re: Undesirable TAG { } |
Stefan Ritt wrote: | That problem was fixed on June 24th, 2005. So please upgrade to the current 2.6.0-beta5 version. |
Updated ! Thanks |
1535
|
Thu Nov 24 20:08:00 2005 |
| Yoshio Imai | | Bug report | Linux | 2.6.0beta5 | "Logkook dir" in top group [global] section ineffective |
Hi, it's me again!
I have found one possible bug. We have declared top groups for our logbooks; one for administration and one for the shift logbooks. In the [global]-section there is a "Logbook dir"-statement of the form
[global]
Top group Admin = <...>
Top group Shiftlogs = beamtime1,beamtime2,...
Logbook dir = /data/logbooks
Now, in the [global Shiftlogs] section there is another "Logbook dir"-statement to have all associated logbooks in one tree:
[global Shiftlogs]
Logbook dir = /data/logbooks/shift-logbooks
[beamtime1]
Subdir = beamtime1
The problem is, that the manually created subdirectories /data/logbooks/shift-logbooks/beamtimeN are ignored, and the elogd creates new "Subdir"-directories /data/logbooks/beamtimeN (as if the "Logbook dir" statement in the top group [global] section were ineffective). Is this a bug or configuration error from our side?
There are also one question/request (you see that we use the elog extensively now ):
When searching for a particular event in our shift log using the "Find" function, it would often be useful not to go to the single entry, but to the page where that entry resides. This way we can see the whole context of the event. When clicking onto an entry in the "Find" result page, this takes us of course to the single entry, but could you add a function to go to the page instead. Alternatively, is it possible to include a button "Go to page" in the single entry view (it need not even be exactly +/-N entries around, the usual page partition would do)?
Thanks in advance.
Yoshio |
1536
|
Fri Nov 25 14:05:08 2005 |
| Yoshio Imai | | Bug report | Linux | 2.6.0beta5 | Re: "Logkook dir" in top group [global] section ineffective |
OK, I found the note about "Logbook dir" in Stephen Wood's entry (http://midas.psi.ch/elogs/Forum/1101)  |
1543
|
Thu Dec 8 10:32:37 2005 |
| Bertram Metz | bmetz@sbs.com | Bug report | Linux | V2.6.0-bet | Attachments in duplicated entries |
Hi,
the duplicate command duplicates the entry text itself, but it does not duplicate attachments.
If attachments in a duplicated entry are deleted, the original attachment files are deleted as well and cannot be accessed anymore within the original entry.
My suggestion is to copy the attached files too and to use file names of the copies in the duplicated entry.
Kind regards,
Bertram |
1559
|
Wed Dec 21 20:54:11 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | V2.6.0-bet | Re: Attachments in duplicated entries |
Bertram Metz wrote: | The duplicate command duplicates the entry text itself, but it does not duplicate attachments. If attachments in a duplicated entry are deleted, the original attachment files are deleted as well and cannot be accessed anymore within the original entry.
My suggestion is to copy the attached files too and to use file names of the copies in the duplicated entry. |
I chaned it such that attachments are removed from the duplicated entry, which was easier to implement. I hope this is ok as well. The change is in SVN revision 1584. |
1568
|
Thu Dec 22 20:50:57 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.6.0beta5 | Re: "Logkook dir" in top group [global] section ineffective |
Yoshio Imai wrote: | There are also one question/request (you see that we use the elog extensively now ):
When searching for a particular event in our shift log using the "Find" function, it would often be useful not to go to the single entry, but to the page where that entry resides. This way we can see the whole context of the event. When clicking onto an entry in the "Find" result page, this takes us of course to the single entry, but could you add a function to go to the page instead. Alternatively, is it possible to include a button "Go to page" in the single entry view (it need not even be exactly +/-N entries around, the usual page partition would do)? |
I implemented that request. When you click on "list", it takes you to the listing page containing the current entry, which is even highlighted. Have a look at this forum if this is what you like. |
1571
|
Tue Jan 3 17:20:16 2006 |
| Mike | mlmoore@pella.com | Bug report | | V2.6.0 | elogd 2.6.0 crash on password Forgot? |
I have been having a repeatable crash on V2.6.0 everytime someone tries to recover a password using the option from the login screen. See attachment for a jpg of the message.
This is occuring on windows 2003. But I have also tested it on windows XP and it occurs there as well. In addition on XP I did a generic installtion and added the password option to the DEMO application and it fails there as well.
Mike |
Attachment 1: elog-pw-crash.jpg
|
|
1574
|
Wed Jan 4 15:27:31 2006 |
| Yoshio Imai | | Bug report | Linux | 2.6.0 | Re: "Logkook dir" in top group [global] section ineffective |
Stefan Ritt wrote: | I implemented that request. When you click on "list", it takes you to the listing page containing the current entry, which is even highlighted. Have a look at this forum if this is what you like. |
Thank you!
I just installed the latest revision; it is exactly what we need.
I found one problem, however: while linking the binaries for elogd, the linker complained about an undefined reference to forkpty implemented in libutil. I had to add the linker option -lutil to the Makefile target elogd:, then it compiled correctly.
One strange thing (maybe it isn't strange at all) is the following behaviour: when the list view is set to "summary", then the line containing the entry where we clicked "list" is highlighted, however when the list view is set to "full", it isn't. Is this "a bug, or a feature"? 
Thanks for the work from all, and happy new year.
Yoshio |