Have a look at "top groups" in the documentation 

 Thanks. I got it working so far. One minor glitch:

I have one topgroup (with 2 subgroups),

  electronics

       trigger

       power

and onother topgroup (only 1 subgroup)

 mechanics

   detector

When I get the login screen for the second (with the only one subgroup) it says in the header:

   "Several logbooks are defined on this host. Please select the one to connect to:"

and below only the one group (detector)  is shown, so actually nothing to select.

This may be possibly achieved by not defining a subgroup for the second one and leaving it as a topgroup,

but I don't know how it behaves, when the group admin decides to create a subgroup. Can he do

without requiring superuser or elog permissions?

--

Christoph

> Is it possible to add one more "text entry" field ?

I guess you mean the main body text, which is multi-line. No, this is not
possible right, now, but I added your vote to the wishlist istem "Multi-line
attributes".

Your guess is correct. I would like to have that feature in ELOG.

Thanks

> > Is it possible to add one more "text entry" field ?
> 
> I guess you mean the main body text, which is multi-line. No, this is not
> possible right, now, but I added your vote to the wishlist istem "Multi-line
> attributes".

You can do this by defining groups. For this forum I did

Group Demo = Linux Demo, Database
Group Discussion = Forum, Config Examples, Contributions, Vulnerabilities

where each name on the right side of the equal sign is an individual logbook.

• you need to copy your logbooks into the "logbooks" directory.
• you need to copy your elog.cfg logbook config file to the new elog folder and reference it at start-up (something like "elogd -c /usr/local/elog/elogd.cfg ...")

Some people modify other stuff (CSS, java scripts) but if you had you would know what you did.

If the old ELOG was a 2.x version and the new is 3.x, then on the first start-up all logbook data files are copied into sub-folders for each year.
This is only done (automatically) during the first start-up, afterwards you can not use a 2.x version anymore (you won't want that anyway).

From your point of view that request is reasonable, but the reason of having mxml in a separate top level directory is that I use it in many different projects. If I would keep a copy of mxml in each project, I would have to update all of them manually if there is a bug. On the other hand the code of mxml changes very seldom. If you look at the history, it got ~5 changes last year, while elog itself had hundreds. And since I do not change the API, a bugfix in mxml should be to the benefit of all elog versions. It is like with other projects which depend on a number of packages. Like if you install Apache for example, you need a certain version of OpenSLL, a certain version of libcrypt, and so on.  So think of mxml like another package you have to combine with elog.