I am not sure I understand your bug report.

I can easily create IDs greater than 100'000 (see attached picture), but that is not your problem, or is it?

Cheers, Andreas

Well, in my example the ID link worked just fine.

There could be a string length limitation, but it could be as well the way you are creating the ID that is the source of the problem: I would need the part of your elogd.cfg that defines how you format your ID in order to try to reproduce your problem.

Cheers, Andreas

An attribute is similar to a variable. Do you know any programming language that allows to start a variable with a digit? I don't.

The solution is very obvious: start your attributes with a letter.

Cheers, Andreas

Here's a little example for a query for this logbook:

You can easily process this output with perl, to create reports. I use it for example to create counts for specific enties, like "Bug reports" that are not "closed", and show the results in some other user interfaces.

Cheers, Andreas

Hi Janusz,

You can change the following line in elogd.h and recompile:

#define MAX_N_LIST      100
That'll change the login user list limit. But it'll change other list length as well - which should not do harm unless you are very short of memory.

I don't see the Admin user list limit of 10 - aparently that is hard coded somewhere deep within (or I've just missed it).

Cheers, Andreas

> Dear all,
>   I have some logbook which uses preset text depending on some option values, and uses text files for this.
> 
> something similar to:
> 
> Options Type = Start of shift{1}, 2h{2}, 4h{3}, 6h{4}, End of shift {5}
> 
> {1} Preset text = MCProdStart.txt
> {2} Preset text = MCProd2h.txt
> {3} Preset text = MCProd4h.txt
> {4} Preset text = MCProd6h.txt
> {5} Preset text = MCProdEnd.txt
> 
> I wonder if there is a way to change/edit the text files from the web interface if you are admin of that logbook, or if the only way is to change the files directly in the elog server.
> 
> thanks Stefano

Hi Stefano,

it is not directly foreseen in the web functionality of ELOG, but it can be done like this:

You could have a second logbook that has the content of these files each in one logbook entry. 
You call a script "Execute edit =" that runs on the server and converts the specific ELOG entry into a file on the server.
Of course this is a security vulnerability, but you can confine the possibilities of the script.
E.g. to a hard-coded list of ELOG entries and files in a specific directory.
Still, someone could place a file on the server and then calls that file with an "Execute edit=" himself.
But if you do all this within a protected network that should be okay.

I do like the idea, thank you for the question! If you manage to do it please post it under Contributions :-)

Cheers, Andreas

I had a problem with restarting ELOG since about a year, and finally I found the culprit. I just want to share it here, to prevent anyone else to make the same mistake,

Stefan said "code is commited": that means you can download the latest version from https://bitbucket.org/ritt/elog, as described in https://elog.psi.ch/elog/download.html, and then compile it. Clear now?