I am currently having a similar problem. I am migrating a few separate elogs to one new computer. I have three top groups set up with their own password files. If I log into top group A (TGA), and then try to go to top group B (TGB), I am presented with a "Create new user" screen for my login name for TGA. When I complete that form, I am taken to the user settings for top group A, rather than TGB. I can log out of TGA and then log into TGB fine, but if I try to switch between them without logging out, it freaks out.

There seems to be a problem with the cookies that keep me logged into the different top groups not recognizing that they are different entities. I'm running eLog 2.9.1 rev 436. Is it possible that this has been addressed in 2.9.2?

Thanks,

-t

 Hi,

I have several top groups and each has several logbooks.

If I use the global option Protect Selection page=1 and Show top groups = 1, after an user logs in to the top group selection URL, the elog steers away from the top group selection page, and automatically brings him to the logbook selection page of the first top group. Is the elog programmed to exhibit this behavior?

What I would prefer is that, after an user logs in, the elog stays on the top group selection page, sine each user has his preferred destination, not always the logbooks in the first top group. Is there any setting I can use in the config file to do this? 

(My users need to access different top groups and logbooks on regular basis).

Thank you and regards.

Internet Explorer fails to display correctly some aspects of pages generated by elog when the zoom functionality is used (Ctrl + and Ctrl -).  This is really a bug in the IE renderer rather than elog, but since IE can be persuaded to do better relatively easily it might be worth making some minor changes to make elog more robust when used with the buggy Microsoft browser.

The problem I encountered was initially with the multiple checkboxes for an Moptions attribute, but I noticed later it also affects the logbook tabs at the top of the screen.  If you start creating a submission to this forum in IE (7 or earlier, at least) you can see the problem; when zooming, the text labels and  the checkboxes do not scale together so start overlapping, and the same happens with the logbook tabs and the text links on them.  The problem is apparently to do with a proprietary IE concept called "layout" - see http://www.satzansatz.de/cssd/onhavinglayout.html for details - and IE struggles when some elements do not have the hasLayout property set to "true".

The fix is to coerce elements to have the hasLayout element set to "true" by giving them some benign CSS property.  The best I can find is to set "display: inline-block" for some of the key elements, and this can be done by modifying default.css rather than the elogd.c code.

Adding

span {
  display: inline-block;
}

to default.css (e.g. just after the default style definition for the "td" element) and adding

  display: inline-block;

to the style sets for the .sltab and .ltab classes (generic, not those specific to the "a" element) seems to prevent IE doing bad things with the display when zooming without messing up the display in Firefox.  I have not tested this comprehensively or in any other browsers, but I thought it might be worth passing on.

Cheers,

Richard Stamper

Hi Stefan,

Andreas

i have problems with execute delete (execute new works fine) in following config (the attribute 'Counter' will not evaluated). Can anybody help me?

Attribute substitution on 'execute delete' was not implemented, since I thought that the ELOG message ID would be used as the primary key in an SQL database, so one would not need the attributes. I added howver this functrionality in SVN revision 2159, so the next release will contain this fix.