| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
2187
|
Tue Apr 3 17:55:21 2007 |
 | Yoshio Imai | | Bug report | Linux | 2.6.4-1826 | Re: Multiple ideas for multiple logbooks |
| Stefan Ritt wrote: | Well, you didn't realize, but you were my beta-tester for the keyboard shortcuts  . I didn't yet publish it, so you must have gotten this brand new feature from SVN. |
You should really have told me  . Actually, I found out about the <Ctrl-C> issue while using this logbook.
| Stefan Ritt wrote: | | So get the SVN update, and let me know what you think |
Did so, we are running now -1826. I think it is very usable, with maybe one exception (this might be a browser issue, however): When using the shortcuts and/or the ELCode buttons, sometimes the code is generated and the cursor in between the [XX] and [/XX] directive, but sometimes, the whole code directive is selected as if for editing
which prevents from immediately continuing to type (which, I guess, was the idea behind the shortcuts). The behaviour is not completely reproducible, and I have even seen it change during one and the same browser (=firefox) session while working on the same entry (*). I also had it once that the browser out of a sudden completely ignored the ELCode meaning, and instead used <Ctrl-I> for page info and <Ctrl-B> for the history.
(*) It just happened again!
BTW, there are (of course ) two other issues. They are still present in -1826
- one bug was reported by a logbook user: when using the "find" function in a logbook, and selecting one value from the "Author" drop-down list and another from the "Category" drop-down list, the elogd reports no entries found, but when specifying only the "Author" and leaving "Category" blank, many entries are found, including those with the "Category" being looked for. When specifying only the "Category" and leaving the "Author" blank, the elogd also reports no entries found. Has anyone reported a similar behaviour?
- We have one logbook top group for the beamtimes. Under certain conditions, a preset text is to be displayed.
{2&a} Preset Text = resource/text_1.txt
{2&b} Preset Text = resource/text_2.txt
However, the definitions of these conditions have to be repeated for every logbook in the group (putting it only under [global beamtimes] doesn't do it), otherwise they are ignored.
Any idea on these? |
|
2191
|
Wed Apr 4 11:37:56 2007 |
 | Yoshio Imai | | Request | Linux | 2.6.4-1795 | Re: Multiple ideas for multiple logbooks |
| Stefan Ritt wrote: | | Actually there is a way |
... and it works! Thank you!
| Stefan Ritt wrote: | | I fixed that now in the updated elcode.js. |
That works now, too!
| Stefan Ritt wrote: | | Your other problem of ignoring the control keys at all I could not reproduce. Try to reproduce it in a well-defined way and let me know. |
I will try to do that (new beamtime, new occasions ... ).
| Stefan Ritt wrote: | | Maybe you used a userlist attribute for the author? |
No, I didn't. I will try to investigate this further and let you know if I find anything.
So for the moment ... thanks for the help! |
|
2193
|
Wed Apr 4 14:20:41 2007 |
 | Yoshio Imai | | Bug report | Linux | 2.6.4-1826 | Re: Multiple ideas for multiple logbooks |
| Stefan Ritt wrote: | | Maybe some other problem? |
Possible, but I think it worked also on our server until the number of logbooks in the top group got larger than one. Can you try to see if your code still works when there is more than one logbook defined? |
|
65761
|
Thu Feb 28 19:07:19 2008 |
 | Yoshio Imai | | Request | Linux | All | 2.6.5 | #include statements and attachment visibility | Hi!
First of all, thank you again for the great software and all the support.
Recently, one collaborator here noted that it would be helpful if the preview of attached files could be disabled on a file-by-file basis (via a checkbutton next to the "Upload" button maybe?). This applies e.g. to cases where someone performs a measurement outside of routine operations and attaches the ASCII data file (preview not wanted, in particular if it contains many lines) and the graph representing the evaluation (preview wanted). The disabling should apply to both single-entry view and list view with "Show attachments" option.
Another "fancy" idea of ours would be to allow #include-like statements in the ELOG config file. E.g. if the number of logbooks gets large, people might choose to put old logbooks to an archive disk which is then stored on some shelf. If a user then wants to access these, the disk could be mounted again (say, under /elog-archive). But since we don't know which archive disk has been mounted, and in order to keep the main config file small, the best would be to have the configurations for the logbooks of each disk on the disk itself (say, in a file called additional.config). We could then have a line like#include /elog-archive/additional.config in the main config file. When the elogd is (re)started, it would try to include that file. If it finds none (because no archive disk is mounted) it would silently ignore this. But if it finds such a file, it would include the logbook definitions found therein.
Do you think it is possible (and preferable) to implement this?
Cheers
Y |
|
65771
|
Thu Mar 6 18:19:48 2008 |
 | Yoshio Imai | | Request | Linux | All | 2.7.3 | Re: #include statements and attachment visibility | Thanks you! I just installed the new revision, and it works.
However, it does not seem to work in list mode (with attach=1 option): elog still shows all the lines of attached text files there.
I also noticed that the images referenced inline are also shown in the attachment list in list mode, although this post gave me the impression that in list mode, too, inline images should only be displayed inside the elog entry and not in addition as attachment.
Might this be a bug, or is there a particular reason why it is like that? |
|
65773
|
Fri Mar 7 13:07:34 2008 |
| Yoshio Imai | | Request | Linux | All | 2.7.3 | Re: #include statements and attachment visibility | | Thank you, works perfectly! |
|
65817
|
Wed Apr 9 14:41:12 2008 |
 | Yoshio Imai | | Bug report | Linux | 2.7.3-2072 | Problems with elog client | Hi!
Since our upgrade to elog 2.7.3, it is not possible any more to edit an existing elog entry using the elog client with -e <id> option. The only console output is "Error transmitting message". Submitting an entry via the client is not problem.
Running the server with -v option does not yield any output at the time of the edit attempt. Running the client with -v option also doesn't help, because whatever the other options, only the help page is printed out and nothing else done. Btw, there is now a conflict between -s for "use SSL" and -s for the "subdir" option.
Any ideas?
Yoshio |
|
65822
|
Thu Apr 10 14:21:13 2008 |
| Yoshio Imai | | Bug report | Linux | 2.7.3-2099 | Re: Problems with elog client | I have tried the new revision, recompiling both client and server.
Unfortunately, the overall situation has not changed. We can still create new entries using the elog client, but editing an existing entry still does not work. However, thanks to your patch, the -v option now works again for the client side:
> elog -s -h <elog server> -p 443 -l current -u <user> <password> -a <Attributes> "TEST ENTRY"
Message successfully transmitted, ID=1
> elog -s -h <elog server> -p 443 -l current -u <user> <password> -e 1 "EDIT THIS ENTRY" -v
Successfully connected to host <elog server>, port 443
Request sent to host:
GET /current/1?cmd=download HTTP/1.0
User-Agent: ELOG
Cookie: unm=<user>;upwd=<password>;
Response received:
ET
Error transmitting message
Again, there is no output on the server side even when running with -v in console mode. There is the expected output when an entry is successfully created using the elog client. One aspect about this output is strange, though: the "Return" statement==== Return ================================
HTTP/1.1 302 Found contains the wrong "Location" header. It is notLocation: https://elog-server.domainname/logbook/ID but ratherLocation: https://client-host.domainname/logbook/ID where "client-host" is the hostname of the computer where the elog client was called. But, since the logbook entry is correctly created, this is perhaps not a problem at all.
Another thing: I have noticed that when using conditional preset texts, the "Preset Text =" statements have to be declared for each logbook of a logbook group; it is not sufficient to only declare it in the "[global]" section of the logbook group. This means that we only need to declare the conditions once, e.g.
Options Category = .... , Shift {1} , ....
{1} Options Subject = Shift start {a}, Shift end {b}, ....
but the preset text declarations{1&a} Preset text = shift_checklist.txt
{1&b} Preset text = shift_summary.txthave to be declared in every individual logbook section for the logbooks of this group. Is this expected behaviour, or a bug?
Cheers
Yoshio |
|