Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 284 of 808  Not logged in ELOG logo
ID Date Icon Author Author Email Category OS ELOG Version Subjectdown
  1950   Fri Sep 22 08:21:39 2006 Reply Stefan Rittstefan.ritt@psi.chBug reportAll2.6.2-1714Re: Top Text and Bottom Text only show "text" --- no files

Steve Jones wrote:
Stefan, I found the source of the problem. When you moved some files to "logbook_dir" you also told the code to look in "logbook_dir" for top and bottom text files. The documentation indicates that the location dir should be "resource_dir".


Yepp. I changed the documentation. Note that you can also specify an absolute path, like
/usr/local/elog/top.html

If the file name starts with a "/" (under Unix), the full path is taken instead of looking in the logbook directory.
  1385   Fri Aug 5 12:06:47 2005 Reply Stefan Rittstefan.ritt@psi.chBug reportLinux2.6.0-CVSRe: Top Groups, Show Top Groups, password file and Protect Selection page have nasty interaction

Chris Green wrote:
Index: elogd.c
===================================================================
RCS file: /usr/local/cvsroot/elog/src/elogd.c,v
retrieving revision 1.739
diff -r1.739 elogd.c
21368,21369c21368
< sprintf(str, "?fail=1", user);
< redirect(lbs, str);
---
> redirect(lbs, "?fail=1");


Thanks, applied.


Chris Green wrote:
Regardless (ie if I use the original CVS code or the patched version), a hard-to trace problem occurs with my configuration whereby users are denied access after password entry at the logbook selection page (even when details are verifiably correct), and users are dropped through to the next (non-protected) Top Group page. This problem goes away if "Protect Selection Page" is turned off.


I hope I have fixed this problem, at least it works ok here when I tried with your config file.

One note I would like to make however: "Top groups" were invented for having completely separate logbook groups. Before the invention of top groups, one had to run several instances of elogd for different departments for example, where one department should not see the other department's logbooks. But having many departments means having to maintain many elogd daemons. This led to the invention of top groups, so one daemon can serve several independent groups, each having their own [global] section, with probably their own administrator.

In your case however, it would be more applicable not to use top groups, but use nested groups. Like
Group MiniBooNE = Analysis, Miscellaneous
Group Analysis = Charged Current Pi Plus, Neutral Current Coherent Pions
Group Miscellaneous = demo

I presume this is more what you want, and you can avoid some problems which arise from top groups.



Chris Green wrote:
A kind of "shadow" of this problem occurs if you create a new logbook from the Change Config File page, whereby after creating the new logbook one is dropped through to the next Top Group's selection page after saving the configuration (and the url has ?fail=1 added to it, althoguh line 21368 above is hardly the only place where this could have occurred).


I have not tested this one, but it could well be that the modification I made also fixes this.
  1388   Fri Aug 5 16:15:04 2005 Smile Chris Greengreenc@fnal.govBug reportLinux2.6.0-CVSRe: Top Groups, Show Top Groups, password file and Protect Selection page have nasty interaction

Stefan Ritt wrote:
One note I would like to make however: "Top groups" were invented for having completely separate logbook groups. Before the invention of top groups, one had to run several instances of elogd for different departments for example, where one department should not see the other department's logbooks. But having many departments means having to maintain many elogd daemons. This led to the invention of top groups, so one daemon can serve several independent groups, each having their own [global] section, with probably their own administrator.

In your case however, it would be more applicable not to use top groups, but use nested groups. Like
Group MiniBooNE = Analysis, Miscellaneous
Group Analysis = Charged Current Pi Plus, Neutral Current Coherent Pions
Group Miscellaneous = demo

I presume this is more what you want, and you can avoid some problems which arise from top groups.


The quick attempt I just made to use this doesn't do what I want, which is to require password protection for the Analysis logbook selection page. If you think that *is* possible and I just didn't configure it properly, I'd appreciate pointers. In the meantime though, your bug fixes appear to have solved my top group / password problem and I think I'll proceed with that for now.

Thanks again,
Chris.
  1392   Fri Aug 5 16:51:02 2005 Reply Stefan Rittstefan.ritt@psi.chBug reportLinux2.6.0-CVSRe: Top Groups, Show Top Groups, password file and Protect Selection page have nasty interaction

Chris Green wrote:
The quick attempt I just made to use this doesn't do what I want, which is to require password protection for the Analysis logbook selection page.


This indeed is not possible and you have to use top groups for that.
  1747   Sat Mar 4 06:04:53 2006 Reply Steve Jonessteve.jones@freescale.comRequestAll2.6.1Re: Top Groups and logbook directorys

Steve Jones wrote:
I am re-working our elog setup and am seriously looking at using the "Top Group" feature. What I like best is the ability to create [global] configurations for a group (or type) of logbook when I host multiple types on the same server. I also like being able to specify a different password file, etc.

A limitation that I run into is I would really like the actual directory names used for storing the logbooks for the different types to be identical - which isn't possible when all logbooks (regardless of context) exist at the same directory level. For example, I might have:

3 physical locations: ABC, DEF, GHI

For each location I want to maintain two *groups* of logbooks - CircuitTests and BoardTests. What I would like to end up with is:
- CircuitTests
----ABC
----DEF
----GHI
- BoardTests
----ABC
----DEF
----GHI

Under current elog this is not possble as far as I know. Since each logbook is a physical directory, each logbook requires a unique name. The concept of a named [global] area fills the bill for all things but it would be nifty if one could do:
[global circuittests]
Logbook dir = circuittestlogbooks

[global boardtests]
Logbook dir = boardtestlogbooks

I suppose the poorman's way of doing this is for each logbook to do the following:
[ABC]
Subdir = boardtestlogbooks/ABC
[DEF]
Subdir = boardtestlogbooks/DEF
[GHI]
Subdir = boardtestlogbooks/GHI

or something like that, but I was hopic for something a little more integrated - like creating the hierarchical stuff via the GUI. Anyway, this probably sounds like a major overhaul, which definitely wouldn't be worth it unless I have completely missed something glaringly obvious.

Thanks!


Steve Jones wrote:
Perhaps it is best to ignore this -- I went for a workaround that I like. I am running into a few quirky things with Top Group but it is likely due to the fact that I have never used it.
  66123   Mon Dec 22 08:52:20 2008 Reply Stefan Rittstefan.ritt@psi.chQuestionLinux2.7.5-2137Re: Tooltips for MOptions - not working?

 

Ben Shepherd wrote:

Hi,

One of my logbooks is a fault reporting system; it emails a group of people when a fault is reported. There is an MOption 'Technical Groups', and I want to have a tooltip for each checkbox which shows who is referred to by each group name. However, individual tooltips for each MOption attribute don't seem to work. I've looked at the HTML code, and there's no 'title' attribute for the checkboxes, so it's not a browser problem. I've attached my config file. Any idea what's going wrong?

ben

 

The syntax for tooltips is

Tooltip <attribute option> = <tooltip>

but you have

Tooltip "<attribute>" "<attribute option>" = <tooltip>

which is not correct, but would make more sense, since you could have an attribut option being valid for several attributes. So I changed elogd to accept both syntax in revision 2158. Please note that you should not put "quotes" around attribute values or options.

  66133   Tue Jan 6 15:11:53 2009 Reply Ben Shepherdbjs54@dl.ac.ukQuestionLinux2.7.5-2137Re: Tooltips for MOptions - not working?

Stefan Ritt wrote:

 

Ben Shepherd wrote:

Hi,

One of my logbooks is a fault reporting system; it emails a group of people when a fault is reported. There is an MOption 'Technical Groups', and I want to have a tooltip for each checkbox which shows who is referred to by each group name. However, individual tooltips for each MOption attribute don't seem to work. I've looked at the HTML code, and there's no 'title' attribute for the checkboxes, so it's not a browser problem. I've attached my config file. Any idea what's going wrong?

ben

 

The syntax for tooltips is

Tooltip <attribute option> = <tooltip>

but you have

Tooltip "<attribute>" "<attribute option>" = <tooltip>

which is not correct, but would make more sense, since you could have an attribut option being valid for several attributes. So I changed elogd to accept both syntax in revision 2158. Please note that you should not put "quotes" around attribute values or options.

 Thanks! I got rid of the quotes around everything, and it works now.

ben

  2094   Tue Nov 28 10:20:12 2006 Reply Stefan Rittstefan.ritt@psi.chRequestWindows Re: Tool Tips

Grant Jeffcote wrote:
Hi Stefan,

Is there a way to add a 'Tool Tips' to individual 'Options' similar to that currently available for Attributes? I have several checkboxes under an attribute for predefined email groups and would like to see if I can make the recipient list viewable via a mouse hover using the 'Tool tip' feature.
If not possible can it be added to the wishlist?


Ok, I implemented this. It is in revision 1760 and will be contained in the next release.
ELOG V3.1.5-3fb85fa6