Thanks Stefan, I managed to get it to work now.

Stefan, 
We are interested in using your ELOG (which we consider to be a wonderful 
application) even more. We would like to make a few adaptations in your 
source code, above all to add some functionality that we are missing.

I was wondering if there is a way we could coordinate the development 
together. For instance, would it be of your interest to receive the code 
adaptations we do and implement it in your future releases? 

To be more specific, for the moment we are really interested in 
implementing the SHELL script execution on the server (I noticed it is in 
your wishlist).

Best regards,

Tomas Rudolf
Micro Belgium Application

> > We are interested in using your ELOG (which we consider to be a wonderful 
> > application) even more. We would like to make a few adaptations in your 
> > source code, above all to add some functionality that we are missing.
> > 
> > I was wondering if there is a way we could coordinate the development 
> > together. For instance, would it be of your interest to receive the code 
> > adaptations we do and implement it in your future releases? 
> 
> Sure, I'm very interested in those and ready to merge it into the main 
> development tree.
> 
> - Stefan

Thanx for your quick answer.
I'll keep you updated as we move ahead with the development.
Tomas

Hi Stefan,

I have a question concerning the Email notification in ELOG.

I have been testing various combinations of the parameters you describe in 
your documentation :

Email <attribute> <value> = <list> 
Use Email Subject = <string> 
Use Email From = <string> 
Omit Email To = 0|1 
Suppress Email to users = 0|1 

And I have encountered a problem using the Email <attribute> <value> = 
<list>. While this works fine for me when the <attribute> is of a type 
textfield, Options or ROptions, I don't seem to be able to have it working 
for the MOptions <attribute> = <list>.

The aim is to have an email notification sent only to selected people 
instead of everybody. I was hoping that this would work :

[MyLogBook]
MOptions Message_To = NB,LW,EC,MD,CD,TV,AH,TR,JS
...
...
Suppress Email to users = 1
Email Message_To TR = tomas@mba.be
Email Message_To EC = etienne@mba.be
...
...

Of course, the tricky part is that it is "multiple choice" so any 
combination of recipients is possible.

Am I missing something? 
Thanx for any ideas how to solve this,

Tomas

Hi,
We prepared a customized theme to use with ELOG. It's called for example 
my_theme and is situated in the THEMES directory (together with the DEFAULT 
theme).

I defined the my_theme the global theme for ELOG:

[global]
Theme = my_theme

And it works fine for all the logbook in ELOG. However. The login screen 
and the main menu screen (the one with list of logbooks and # of entries) 
still takes the DEFAULT theme. 

If I change the my_theme name to default then everything works correctly 
(logon + main menu + all logbooks have the desired look).

Is the DEFAULT theme somehow hardcoded for the login screen and the main 
menu ?

Thanx for your answer

Tomas Rudolf

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

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 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