ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
313
|
Fri May 2 18:10:36 2003 |
| Tomas Rudolf | tomas@mba.be | Question | | | Re: User Profile - Access to logbook group |
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 |
314
|
Fri May 2 18:50:48 2003 |
| Tomas Rudolf | tomas@mba.be | Question | | | Simulation of a submit |
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 |
316
|
Sat May 3 11:00:34 2003 |
| Tomas Rudolf | tomas@mba.be | Question | | | Re: Simulation of a submit |
> > 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! |
317
|
Sat May 3 11:08:11 2003 |
| Tomas Rudolf | tomas@mba.be | Other | | | ELOG Skins Showcase |
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 |
331
|
Thu May 8 16:49:05 2003 |
| Tomas Rudolf | tomas@mba.be | Request | | | "Selection page" parameter |
Hi,
I have a question concerning the "Selection page" ELOG.cfg parameter.
I was wondering if it is possible to specify a complete (absolute) URL such
as http://www.myserver.com/my_elog_menu.htm.
I need this type of configuration because we actually need to have the
custom selection page sitting on a different server from the one where ELOG
is run.
Thus far, the only work-around I could think of is to make a reference to a
local html file which redirects to the http:// resource outside of the
server.
When tried the absolute path, i got "The requested
file /usr/local/elog/http://www.myserver.com/my_elog_menu.htm was not found
on this server" error message. I'm wondering if it's just a bug or if there
is a reason for it.
Thanx,
Tomas |
335
|
Mon May 12 18:11:26 2003 |
| Tomas Rudolf | tomas@mba.be | Request | | | Re: |
> > I have a question concerning the "Selection page" ELOG.cfg parameter.
> > I was wondering if it is possible to specify a complete (absolute) URL
> such
> > as http://www.myserver.com/my_elog_menu.htm.
> >
> > I need this type of configuration because we actually need to have the
> > custom selection page sitting on a different server from the one where
> ELOG
> > is run.
>
> I added this possibility to the source code (->CVS), although it's not
clear
> to me how this should work for you. If you don't have access to the server
> where elogd is running, how should elogd then redirect you to somewhere
else?
Thank you Stefan,
It's not that we wouldn't have access to the ELOGD server, it's the fact that
we're trying to create our own dynamic selection page (with a more detailed
overview of the content of different logbooks - such as the date of last
logbook entry, number of entries in last week, month etc.) based on the
information we send from ELOG to our SQL server.
So in this case the user logs on to ELOGD (currently run on Linux) then will
be redirected to the selection page on a Windows machine (ASP getting all
necessary information from a MS SQL DB) and the dynamically created links
refer back to the ELOGD Linux server. May seem a little too complicated but
works fine.
Tomas |
343
|
Sat May 17 05:55:53 2003 |
| Tomas Rudolf | tomas@mba.be | Question | | | Re: Simulation of a submit |
I guess this question got somehow lost.
So once again : Is there a possibility to EDIT an existing message with
elog.exe ?
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.
We did some tests of your elog utility. It does what we need except for one
important thing: EDIT existing messages. Is there a way to edit en existing
message? Adding a new message or replying to an existing message works fine
but in our case we need to have the ability to modify messages that were
created in the past.
Tomas |
346
|
Mon May 19 23:54:09 2003 |
| Tomas Rudolf | tomas@mba.be | Request | | | HTML page formating |
Is there a possibility to integrate into ELOG some more features in terms
of page formating?
Currently, the .cfg file allows you to specify only the data structure of
the dataentry/consultation HTML page. And you only have very limited
possibilities to change the layout of the page (basically only the order of
attributes on the page and with the help of the .css file the font, color
and background of the page as a whole).
What we would like to do is to :
+ apply a stylesheet class to an attribute (change the particular TD class)
+ specify the width of a textfield (sometimes it is really not necessary to
have such a long textfield area for a 3-letter long code)
+ put an attribute on the same line as the previous one (instead of putting
it automatically on the next line)
Therefore, in addition to the current attributes & parameters, we suggest
the following syntax in the .cfg file:
+ parameter AttribPos which would specify the position of an attribute,
it's lenght (for text attributes only) and the .css class to apply
+ parameters in [] are optional
AttribPos AttribName = same_line, width, [class]
Examples:
AttribPos DateUp = 0,20, [important]
+ Attribute "DateUp" will be put on the next line, the textfield width will
be 20 characters and a .important class will be applied to it from the
default (or specified) .css file.
AttribPos DateUp = 1,15,
+ this puts the DateUp attribute on the same line, width 15
We believe that these improvements would help to make the ergonomy of the
screen better and thus facilitate the user-dataentry/consultation. |
Attachment 1: elog_improve_layout.jpg
|
|