Hi,

Since few days I Notice that I've some data who disappear from ELOG (software).

I find them on ELog/Logbooks, but can't view them in the application ELOG !

Is there a solution ?

Thanks.

I've inherited a position that includes deploying elog for an at-sea mission. Once at sea there's no gauntee of internet connection so I have to be sure things are going to work before hand. The machines I currently have (we have several backup machines) are running elog version 2.9.2 and I'm looking for a change log, or feature list to determine if it's safe to update the at-sea laptops to the latest version of elog.

On one hand, I could leave things as they are and I'm sure it will just work, on the other hand, I hate seeing things get out of date to the point that something just stops working some day and there's no ability to get support for old software.

I'm already running elog 3.1.4 on my personal machine I use for configuration development and testing and it seems to work well. The config file is pretty simple and seems to work with 2.9.2 on the at-sea machines, but I don't want to run into any suprises if there ends up being a compatibility issue at sea.

    for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n' ; )
        if (i < (int) sizeof(cookie)-1)
            cookie[i++] = *p++;

    for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n';)
        if (i < (int) sizeof(cookie) - 1)
            cookie[i++] = *p++;
        else
            break;

    for (i = 0; *p && *p != ';' && *p != '\r' && *p != '\n' ; ++p)
        if (i < (int) sizeof(cookie)-1)
            cookie[i++] = *p;

When someone logout from my Elog, or the person does not have access to a logbook (due to "Login user  =") the person gets a blank webpage with "redir" typed in the upper left corner.

I guess it should redir to some webpage? How can I get it to actually do that? Am I missing something in elogd.cfg?

I was wondering if there is a way to have a more detailed log of users' 
activities?
Current Logfile = <file> gives a good base for information about 
logins/access to 'protected' logbooks. 

What we would like to have is information about when a user reads an ELOG 
entry (to be able to determine the reaction/response time). 

For instance the LOG could look sg like this: 
%%user %%datetime %%logbook %%record read/edit/new/delete 

Have set up 3 top level groups, each with their own password file.
Ever since users have to 'login' twice to get to the appropriate elog.
You click on top level group, get to log book and click on the one you want 
and get login/password dialog box, click ok and and you get it again and 
then you finally get into the elog book.

Anything I can check on this behavior?

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.