Q: on 'FIND MENU commands =' <menu list>, posted by Steve Jones on Wed Aug 11 18:02:22 2004
|
The help text on the website says the following:
"The command Select can be used to select multiple messages for deletion of
moving to other logbooks."
This is not clear but was the intent to indicate that SELECT can be used to
either select multiple log entries for deletion OR for moving to another
logbook? If the latter, then this does not work if one adds the MOVE TO
menu item to the list. If the former then the helptext is a little misleading.
Thanks! |
Re: Q: on 'FIND MENU commands =' <menu list>, posted by Stefan Ritt on Thu Aug 12 21:10:29 2004
|
> The help text on the website says the following:
>
> "The command Select can be used to select multiple messages for deletion of
> moving to other logbooks."
>
> This is not clear but was the intent to indicate that SELECT can be used to
> either select multiple log entries for deletion OR for moving to another
> logbook? If the latter, then this does not work if one adds the MOVE TO
> menu item to the list. If the former then the helptext is a little misleading.
SELECT can be used for deletion OR moving OR copying. To enable the copy and move
commands, they have to be present in the "Menu commands" list, like
Menu commands = Back, New, Edit, Delete, Reply, Find, Config, Logout, Move to, Copy
to, Help
I added an appropriate note to the documentation, sorry for the misleading descriptoin. |
Re: Q: on 'FIND MENU commands =' <menu list>, posted by Steve Jones on Thu Aug 12 22:17:01 2004
|
> > The help text on the website says the following:
> >
> > "The command Select can be used to select multiple messages for deletion of
> > moving to other logbooks."
> >
> > This is not clear but was the intent to indicate that SELECT can be used to
> > either select multiple log entries for deletion OR for moving to another
> > logbook? If the latter, then this does not work if one adds the MOVE TO
> > menu item to the list. If the former then the helptext is a little misleading.
>
> SELECT can be used for deletion OR moving OR copying. To enable the copy and move
> commands, they have to be present in the "Menu commands" list, like
>
> Menu commands = Back, New, Edit, Delete, Reply, Find, Config, Logout, Move to, Copy
> to, Help
>
> I added an appropriate note to the documentation, sorry for the misleading descriptoin.
Thank you. I had added the "Move To" and this works at the log entry level (i.e., "Move
To <name>) but in the threaded view one does not get the enumerated list of logbooks.
I'll play around with it a little more before re-posting. When it didn't work as I
expected I read the docs and ran across the confusing text - so I stopped and asked!
Thanks again. |
Re: Q: on 'FIND MENU commands =' <menu list>, posted by Stefan Ritt on Thu Aug 12 22:24:04 2004 
|
> Thank you. I had added the "Move To" and this works at the log entry
level (i.e., "Move
> To <name>) but in the threaded view one does not get the enumerated list
of logbooks.
You get the "Move To" button only after pressing "Select", otherwise it does
not make sense. See attached screendump and config example. |
Re: Q: on 'FIND MENU commands =' <menu list>, posted by Steve Jones on Thu Aug 12 23:55:00 2004
|
> > Thank you. I had added the "Move To" and this works at the log entry
> level (i.e., "Move
> > To <name>) but in the threaded view one does not get the enumerated list
> of logbooks.
>
> You get the "Move To" button only after pressing "Select", otherwise it does
> not make sense. See attached screendump and config example.
Hmmm. I like the little buttons with the pull-downs for selections.
Unfortunately, I don't get that. With a config of:
Find Menu commands = New, Find, Select, Config, Change password, Logout, Help, Admin
Menu commands = Back, New, Edit, Delete, Reply, Find, Move To, Copy To, Config, Help
my screen only shows the "toggle" and "delete" buttons. Was there a recent rev
that allowed this to happen (I didn't see a comment on this).
BTW, on a log entry screen, is the appropriate behavior for the "Move To" option
to show multiple "Move To" links (one for each logbook) or should there also be
pulldowns?
Thanks |
Re: Q: on 'FIND MENU commands =' <menu list>, posted by Stefan Ritt on Wed Sep 8 11:44:56 2004
|
> Hmmm. I like the little buttons with the pull-downs for selections.
> Unfortunately, I don't get that. With a config of:
>
> Find Menu commands = New, Find, Select, Config, Change password, Logout, Help, Admin
> Menu commands = Back, New, Edit, Delete, Reply, Find, Move To, Copy To, Config, Help
Unfortunately menu commands are case sensitive, so you need a "Move to" instead a "Move
To". I changed this in the code so future versions will not be case sensitive any more.
> BTW, on a log entry screen, is the appropriate behavior for the "Move To" option
> to show multiple "Move To" links (one for each logbook) or should there also be
> pulldowns?
On the log entry screen, only menu links are possible for internal reasons, that's why I
have chosen that display mode. I agree that it can look clumsy if you have many
logbooks, but there is the "move to = <logbook list>" option to restrict the number of
target logbooks. |
Options Items limits, posted by Patricio Castro on Tue Aug 31 20:29:20 2004
|
Hello friends,
Exist some form to increase limits of items (100) in the Options List
Thanks for any help |
Re: Options Items limits, posted by Steve Jones on Wed Sep 1 22:25:01 2004
|
> Hello friends,
>
> Exist some form to increase limits of items (100) in the Options List
>
>
>
> Thanks for any help
I believe only through an edit of the C code and a recompile, as the values
are set as constants. I think this might be the line:
#define MAX_N_LIST 100
So, yes, there exists a way and the ease of this way is dependent upon your
comfort level with changing stefan's code. |
Re: Options Items limits, posted by Stefan Ritt on Tue Sep 7 17:49:50 2004
|
> > Hello friends,
> >
> > Exist some form to increase limits of items (100) in the Options List
> >
> >
> >
> > Thanks for any help
>
> I believe only through an edit of the C code and a recompile, as the values
> are set as constants. I think this might be the line:
>
> #define MAX_N_LIST 100
>
> So, yes, there exists a way and the ease of this way is dependent upon your
> comfort level with changing stefan's code.
Agree. The only potential problem is that if this value becomes too big, you
will get a stack overflow from time to time. So best is experiment yourself a
bit. A avlue of 150 or so should be no problem.
- Stefan |
PostScript Files shown as text., posted by Bryan Moffit on Fri Sep 3 20:17:20 2004
|
At some point, in the last week or so, I upgraded the debian-unstable
version (r1459-1) of elog. Now, PostScript files (as attachments) are
displayed (shown in ascii text, instead of just showing the link).
Is there an option in the elog.cfg to only display certain files (like .gif
or .jpg). |
PostScipt Files shown as text., posted by Bryan Moffit on Fri Sep 3 20:17:12 2004
|
At some point, in the last week or so, I upgraded the debian-unstable
version (r1459-1) of elog. Now, PostScript files (as attachments) are
displayed (shown in ascii text, instead of just showing the link).
Is there an option in the elog.cfg to only display certain files (like .gif
or .jpg). |
Q: On Solaris 8, eLog not honoring USR= and GRP= cfg file directives?, posted by Steve Jones on Wed Aug 11 18:12:35 2004
|
I'm not sure if this is a configuration problem or a bug, but running
v2.5.4subver1.413, elogd runs as user ROOT (UID0) even though the following
is in the elogd.cfd file:
Usr = nobody
Grp = essadm
All other directives added to the cfg file work, so I know eLog is reading
the cfg file.
The elogd binary *is not* setuid 0.
Thanks |
Re: Q: On Solaris 8, eLog not honoring USR= and GRP= cfg file directives?, posted by Stefan Ritt on Thu Aug 12 21:37:29 2004
|
> I'm not sure if this is a configuration problem or a bug, but running
> v2.5.4subver1.413, elogd runs as user ROOT (UID0) even though the following
> is in the elogd.cfd file:
>
> Usr = nobody
> Grp = essadm
>
> All other directives added to the cfg file work, so I know eLog is reading
> the cfg file.
>
> The elogd binary *is not* setuid 0.
I could not reproduce your problem with the current version (Revision 1.460)
under Linux. I guess you made sure that user "nobody" and group "essadm" exist.
Try to run elogd interactively, if you see any error message (without "-D"
flag). In the most recent version (1.460), I added some more debugging code
which tells you if elogd successfully fell back to another user, if you use the
"-v" (verbose) flag.
If all that does not help, I guess it's some peculiarity of Solaris. Maybe
someone else using Solaris has some idea. All elogd does is a call to
setuser("<user>");
I see no reason why this should not work on Solaris. |
Re: Q: On Solaris 8, eLog not honoring USR= and GRP= cfg file directives?, posted by Steve Jones on Thu Aug 12 22:18:56 2004
|
> > I'm not sure if this is a configuration problem or a bug, but running
> > v2.5.4subver1.413, elogd runs as user ROOT (UID0) even though the following
> > is in the elogd.cfd file:
> >
> > Usr = nobody
> > Grp = essadm
> >
> > All other directives added to the cfg file work, so I know eLog is reading
> > the cfg file.
> >
> > The elogd binary *is not* setuid 0.
>
> I could not reproduce your problem with the current version (Revision 1.460)
> under Linux. I guess you made sure that user "nobody" and group "essadm" exist.
> Try to run elogd interactively, if you see any error message (without "-D"
> flag). In the most recent version (1.460), I added some more debugging code
> which tells you if elogd successfully fell back to another user, if you use the
> "-v" (verbose) flag.
>
> If all that does not help, I guess it's some peculiarity of Solaris. Maybe
> someone else using Solaris has some idea. All elogd does is a call to
>
> setuser("<user>");
>
> I see no reason why this should not work on Solaris.
Ok, just checking. I will fiddle around with running it interactively and see what
I get, plus I'll have a look at the setuser function under Solaris.
Just for grins, what version of compiler are you using under Linux?
Thanks again! |
Re: Q: On Solaris 8, eLog not honoring USR= and GRP= cfg file directives?, posted by Stefan Ritt on Thu Aug 12 22:25:45 2004
|
> Just for grins, what version of compiler are you using under Linux?
gcc 3.2.2 (from RedHat Linux 9.0) |
Re: Q: On Solaris 8, eLog not honoring USR= and GRP= cfg file directives?, posted by Steve Jones on Mon Aug 16 21:48:49 2004
|
> > Just for grins, what version of compiler are you using under Linux?
>
> gcc 3.2.2 (from RedHat Linux 9.0)
Well, I am running 2.95.3 - hmmm. We have 3.3.2 - perhaps I'll try that and
see if there is a difference. |
Restricting viewing messages, posted by Jen Manz on Wed Aug 11 15:38:07 2004 
|
I am working on a logbook for a lab. I have two questions...
First - Some of the logbook entries should not be viewed by certain users.
What would be the easiest way to restrict viewing some entries?
Second - I have a welcome page for the ELOG that lists some info about the
ELOG. When I start the ELOG, the user sees the login page. After the user
logs in, the welcome page appears listing the restrictions. Right now, I
have a hyperlink that takes the user to new, find, etc. But I would like
to take the user right to the logbook and not have to come back to the
welcome page everytime. How can I do this?
I have attached the code I have so far. They are in .txt format for easier
viewing.
Thanks! |
Re: Restricting viewing messages, posted by Stefan Ritt on Wed Aug 11 16:02:52 2004
|
> First - Some of the logbook entries should not be viewed by certain users.
> What would be the easiest way to restrict viewing some entries?
The easiest way is to define two logbooks, with two different password files.
The more restricted logbook contains only those users who are allowed to see the
restricted entries. Use the commands "Move to" to move entries between the two
logbooks (see documentation).
> Second - I have a welcome page for the ELOG that lists some info about the
> ELOG. When I start the ELOG, the user sees the login page. After the user
> logs in, the welcome page appears listing the restrictions. Right now, I
> have a hyperlink that takes the user to new, find, etc. But I would like
> to take the user right to the logbook and not have to come back to the
> welcome page everytime. How can I do this?
Right now you need an exteral page on a public webserver. This page contains
then links to your elog server. I the next version I will implement the
possibility to server *.html files directly through elog. You can then put your
welcome page under themes/default/Welcome.html, and access it through the
starting link:
http://your.elog.server/logbook/Welcome.html
You will only see the Welcome page once, since all links in elog will point back
to .../logbook/ and not to .../logbook/Welcome.html. The config option "Welcome
page = Welcome.html" you have to remove then of course. |
THREAD DISPLAY = sucks up coded spaces, posted by Steve Jones on Fri Aug 6 22:35:10 2004
|
I was trying to do some hard coded spaces using:
Thread display = For: $Date for Shutdown. $DataCenter:
$short summary. Coordinator: $Shutdown Coordinator.
The spacing actually works mthe first time, but upon going back into editing
the config file, the coded spaces are gone, replaced with real spaces, and
when saved all real multiple spaces are, as one would expect, ignored. The
spacing reverts back to normal.
I tried other html tags but these show up as literals.
Thanks |
Re: THREAD DISPLAY = sucks up coded spaces, posted by Stefan Ritt on Sun Aug 8 16:25:09 2004
|
> I was trying to do some hard coded spaces using:
>
> Thread display = For: $Date for Shutdown. $DataCenter:
> $short summary. Coordinator: $Shutdown Coordinator.
>
> The spacing actually works mthe first time, but upon going back into editing
> the config file, the coded spaces are gone, replaced with real spaces, and
> when saved all real multiple spaces are, as one would expect, ignored. The
> spacing reverts back to normal.
>
> I tried other html tags but these show up as literals.
I fixed that in revision 1.448. The problem also showed up even in normal
logbook entry displays and in replies (before this fix, the in this text
whould not have shown up). Get the new version from CVS. |
Re: THREAD DISPLAY = sucks up coded spaces, posted by Steve Jones on Tue Aug 10 20:11:38 2004
|
> > I was trying to do some hard coded spaces using:
> >
> > Thread display = For: $Date for Shutdown. $DataCenter:
> > $short summary. Coordinator: $Shutdown Coordinator.
> >
> > The spacing actually works mthe first time, but upon going back into editing
> > the config file, the coded spaces are gone, replaced with real spaces, and
> > when saved all real multiple spaces are, as one would expect, ignored. The
> > spacing reverts back to normal.
> >
> > I tried other html tags but these show up as literals.
>
> I fixed that in revision 1.448. The problem also showed up even in normal
> logbook entry displays and in replies (before this fix, the in this text
> whould not have shown up). Get the new version from CVS.
As always - fantastic!
Thanks |
Login/Logout problem with elog and their solution, posted by Stefan Ritt on Thu Aug 5 10:49:21 2004
|
Hi everybody,
several people have reported of strange problems concering the login/logout
behaviour of elog. After editing elogd.cfg, they could not logout any more
from a logbook, or they were not able to log in. Here comes some
explanation. If you are not interested in the details, skip to the last section.
The login parameters (user name and password) are sored in cookies, which of
course have to be enabled for the elog site in your browser. Each cookie can
contain an optionsl "path=..." statement, which defines for which subtree in
the URL the cookie is valid. If you use a "global" password file (one where
the "password file = ..." statement is in the [global] section of
elogd.cfg), the elogd server stores a cookie with path "/", so it will apply
to the whole site and therefore to all underlying lobooks. If your password
file is defined in an individual logbook section, the elogd server stores a
cookie with path "/<logbook>", so that it applies only to the specific logbook.
The problem arises now if one moves the password file statement from the
global section to the logbook section or back. The browser might still have
old cookies, whic can override any newly set cookie.
Long story short conclusion: If you observe this behaviour, just delete all
cookies in your browser and you should be fine. I added some additional code
to version 2.5.4 which catches a few cases but unfortunately not all. |
|