Can you try the "top groups" option, which means putting each logbook into a separate top group as described in the documentation. For us this works well, new users are only added to the right password file. There is however the problem that as admin you might be logged in to several logbooks (as remembered in your browser via cookies), so you might want to log out from all logbooks first (or clear all cookies of elog), then log in to one logbook and add the user there. In worst case you still can modify the password file by hand, they are plain ASCII files. Only the password has to be entered later since it's encrypted.

Stefan

• In the remote logbook, prohibit any modifications. You can do that with the Menu commands = ... option, where you just remove New, Edit, Reply and Duplicate.
  
• Do not allow public write access, but public read access. The remote logbook server can read but not write. This requires a guest access, see the manual.
  
• Create a special user, let's call it "mirroruser". Use this user to log in from the remote elog server by using the command Mirror user = mirroruser. Now restrict the right of this user via

  Deny New = mirroruser
  Deny Edit = mirroruser
  Deny Reply = mirroruser
  Deny Duplicate = mirroruser

  
  

The elog command has the option "-n <n>" to tell elog, what type of text it should expect.

[-n 0|1|2]               Encoding: 0:ELcode,1:plain,2:HTML

It is necessary for elog to know the type of encoding, otherwise it would not show non-html content correctly.

> 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

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

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

I think it is very good to include this in elog, but, 
since this is also a big security risk (especially if people are
running elogd as root) I would suggest a compile time option to 
enable this, like: gcc... -DALLOW_SCRIPT ...  
The default should be that it is disabled.
Maybe one should only allow it if the user running elogd is NOT root.

Heiko

Hi Al; if I understand your situation correctly you want to access Elog db (logbooks) via another way. There are many ways depending on your knowledge, type of work needed, and ease of use. I have found that accessing whatever I need via Elog gui is satisfactory in many situations-- by simply exporting. THEN take the raw csv/xml  file and manipulte it more easily from there. There are MANY free web sites that will take your data then, and put it in still another format that you choose (usually manipulating the rows/columns to your liking or doing mail-merge type work on your data). BTW WPS (Windows Office clone) is awesome at further 'mail-merg'  techniques. THEN at that point you may have close to what you are trying to accomplish. I've also used PHP alot in this type of situation and have replicated Elog's data format for it's db (logbooks)..; so PHP is great in this maner, although of course it takes time to 'get-it-right' if you are not well versed in it. If you go into detail more of what type of format you want as the finalized product, maybe  more suggestions will be made.

Happy belated New Years everyone,

John