Hello everybody.

I am sure that some of you (just like me) experimented already with themes 
and especially now with .CSS in order to give ELOG a different "look" 
and "feel". 

I was wondering if we could maybe share examples of such adapted 
ELOG's .CSS files (or themes). Maybe you can take a screen shot of your 
favorite ELOG "face" (no sensitive data, of course) and post it here as an 
attachement. Or is everybody using only the original look that Stefan 
delivers as default?

Let's share some inspiration. I'll post mine as soon as finished the re-
look.

Tomas

> > Is there a way to simulate an ELOG SUBMIT?
> 
> Have a look at the elog utility which comes in the package. It does exactly 
> this. It "simulates" a browser and does a submit directly to elogd. So you 
> can either redo the elog code somewhere, or call elog with the proper 
> command line parameters to insert logbook entries.

Thank you, Stefan!

> Is there a way to simulate an ELOG SUBMIT?

Have a look at the elog utility which comes in the package. It does exactly 
this. It "simulates" a browser and does a submit directly to elogd. So you 
can either redo the elog code somewhere, or call elog with the proper 
command line parameters to insert logbook entries.

I have another tricky question.

Is there a way to simulate an ELOG SUBMIT?

We developed a module which automatically inserts new submits from ELOG 
into an SQL database. The module is in testing phase but we can already 
tell it does the job as it should. 

This allows us to copy ELOG entries into SQL database. But in some cases, 
we would like to transmit data in the other direction too - from SQL into 
ELOG (synchronization).

Now, one way to do that is to create .txt files with entries directly, but 
we find it too risky (file-locking mentioned in a question earlier today 
can be one of the issues). So we're contemplating a possibility that ELOG 
does these inserts for us by processing some simulated SUBMITS.

We're assuming that ON SUBMIT, you generate a POST (or a GET ?) over http 
which is then processed by the ELOGD server. This should be possible to 
simulate in our synchronization application. Are we correct in our 
assumptions?

Tomas

Robert, this is exactly what we managed to do as well. And it works fine. 
The only issue is that the users from one group can "SEE" the book names 
available to other groups. 

The solution Stephane suggested seems like the only possible right now.

Anyways, thank you for your answers, Robert & Stephane !

Tomas


> I have managed to get this to work (so far).
> 
> What I do is use a separate password file and directory for each log.
> 
> I haven't tested it with with the current version but it worked fine before
> that. My testing consisted of creating a user in the main password file and
> see if he could get to anything I didn't want him to. This may not be 
enough
> for something that requires a high level of security. 
> 
> When I create a new user I move that line to the appropriate password file 
if
> it isn't already there.
> 
> You will get an invalid user message and a prompt if you try access a log 
that
> doesn't have your user name in the password file. 
> 
> I only have six people using it so this isn't much trouble.
> 
> I would like to see groups implemented to make this more manageable.
> 
> > Hi,
> > 
> > I was wondering if anyone had a solution for my problem.
> > We are trying to run several books on one server. The books are grouped 
> > such as follows :
> > 
> > Group Users1 = Book1, Book2, Book3
> > Group Users2 = Book4, Book5, Book6
> > Group Users3 = Book7, Book8, Book9
> > 
> > We would like to give access to selected users to only their Group. So 
that 
> > for instance Users1 cannot access the books of group Users3. I was 
> > wondering if there is any notion of "User profile" or security per 
logbook 
> > Group implemented?
> > 
> > What we do for now is that we have 3 different PASSELOG files and for 
each 
> > Book we need to specify which PASSELOG should be used for 
authentication. 
> > This works fine except that we prefer that users do not see the other 
> > logbooks listed in the main menu nor the other "inaccessible" logbook 
tabs 
> > in the logbook view. Is there a way to hide these for them (but only for 
> > them)?
> > 
> > Tomas

I have managed to get this to work (so far).

What I do is use a separate password file and directory for each log.

I haven't tested it with with the current version but it worked fine before
that. My testing consisted of creating a user in the main password file and
see if he could get to anything I didn't want him to. This may not be enough
for something that requires a high level of security. 

When I create a new user I move that line to the appropriate password file if
it isn't already there.

You will get an invalid user message and a prompt if you try access a log that
doesn't have your user name in the password file. 

I only have six people using it so this isn't much trouble.

I would like to see groups implemented to make this more manageable.

> Hi,
> 
> I was wondering if anyone had a solution for my problem.
> We are trying to run several books on one server. The books are grouped 
> such as follows :
> 
> Group Users1 = Book1, Book2, Book3
> Group Users2 = Book4, Book5, Book6
> Group Users3 = Book7, Book8, Book9
> 
> We would like to give access to selected users to only their Group. So that 
> for instance Users1 cannot access the books of group Users3. I was 
> wondering if there is any notion of "User profile" or security per logbook 
> Group implemented?
> 
> What we do for now is that we have 3 different PASSELOG files and for each 
> Book we need to specify which PASSELOG should be used for authentication. 
> This works fine except that we prefer that users do not see the other 
> logbooks listed in the main menu nor the other "inaccessible" logbook tabs 
> in the logbook view. Is there a way to hide these for them (but only for 
> them)?
> 
> Tomas

> No, but I will put it on the wishlist. Anyhow it is hard to implement 
> something like this. Assume that I would lock a page whenever it's edited 
by 
> someone. This person can edit it and forget to submit the changes, just 
close 
> the browser. Since the elogd server does not know when a remote browser 
is 
> closed, it cannot determine if the editing is just taking long or if the 
> person closed the browser. In the latter case, the message would be 
locked 
> forever and nobody could change it any more. If I put a timeout, like 
keep 
> locked for N minutes, it's again not 100% safe. I saw people doing shift 
work 
> with elog, opening a page, keeping it open for 8 hours and then submit 
it. 
So 
> if I set the timeout to 8h, and someone abandons editing a message, this 
> message would be blocked for 8h, which is probably also not what you 
want. 
> 
> Alternatively, I just can display a messge: Warning: this message is 
> currently edited by user xxx on host xxx. But if the warning is ignored 
by 
> the user, then again we have the same problem.
> 
> Do you see a clever solution to that?


I was thinking of having an icon on the page that administrator can click 
to 
unlock a record that has been left locked by someone, perhaps using 
something 
like 

Allow Unlock = admin (or even just have the option on the top like 
(Admin/Config) for administrators

Just like the delete function works, in addition to the Warning message as 
you suggested

> We are using elog as a small database system, today we came across a 
> problem where 2 people were editing the same record and the first one to 
> submit his changes were overwritten when the second person submitted his.
> 
> Is there anyway to lock a logbook record when someone has pressed EDIT, 
> maybe set a flag in the logbook entry so it has to be unlocked when its 
> submitted by the originator or by an administrator.

No, but I will put it on the wishlist. Anyhow it is hard to implement 
something like this. Assume that I would lock a page whenever it's edited 
by 
someone. This person can edit it and forget to submit the changes, just 
close 
the browser. Since the elogd server does not know when a remote browser is 
closed, it cannot determine if the editing is just taking long or if the 
person closed the browser. In the latter case, the message would be locked 
forever and nobody could change it any more. If I put a timeout, like keep 
locked for N minutes, it's again not 100% safe. I saw people doing shift 
work 
with elog, opening a page, keeping it open for 8 hours and then submit it. 
So 
if I set the timeout to 8h, and someone abandons editing a message, this 
message would be blocked for 8h, which is probably also not what you want. 

Alternatively, I just can display a messge: Warning: this message is 
currently edited by user xxx on host xxx. But if the warning is ignored by 
the user, then again we have the same problem.

Do you see a clever solution to that?