Is there a limit on the number of conditions that can be simultaneously active in a log?  When I activate more than 10 conditions I start to see side effects with other conditions being deactivated.  I think this is due to the hard-coded array size of 10 for clist in the match_param function in elogd.c.  If so, could this limit be increased?  

Are there other limits on the number of conditions, or the length of condition names?  If I've understood the code right, the _condition string holds a comma-separated list of the active conditions, so the 256 byte length of this will also put some limit on the number of conditions that can be active.

 I'm having some confusion with configuring my logbook.  In the global section of the logbook I have the quick filter enabled, but it is not a drop down list, only an editable text field:

I think it is an attributes issue, but I'm having some trouble making sense of those from the syntax page.  Here is my config file:

[global]

port = 8080

usr = vulcanstaff

Max content length = 1073741824

Menu commands = New, Edit, Delete, Reply, Find, Last day, Move to, Copy to, Import, Help

RSS Title = $subject, posted by $author on $entry time

RSS Entries = 10

Quick filter = Date, Subject, Subtext

Use Lock = 1

Reverse sort = 1

Required Attributes = Author, Subject

[Experiment_Logbook]

Theme = default

Comment = Experiment Logbook

Attributes = Author, Author Email, Type, Category, Subject

Options Type =  Other

Options Category = Start Up

Extendable Options =Category

Page Title = $Subject

I forgot to mention - this is for searching the logbook.   So would the config file look more like this:

[global]

port = 8080

usr = vulcanstaff

Max content length = 1073741824

Menu commands = New, Edit, Delete, Reply, Find, Last day, Move to, Copy to, Import, Help

RSS Title = $subject, posted by $author on $entry time

RSS Entries = 10

Options Category = Date, Subject, Subtext

Quick filter = Date, Subject, Subtext

Use Lock = 1

Reverse sort = 1

Required Attributes = Author, Subject

Thanks Stefan, I think I understand, and now I see the options definition on the syntax page.  I apologize for taking up your time and thank you for the great software.  I think this is right now:

Options Search = Date, Subject, Subtext

Quick filter = Search

I would like to set up the text are as a template. The documentation indicates this can be done however I am unable to find reference to how it is accomplished.

Dear all,

Is it possible to have a dynamic "preset text" option?

I would like to switch the template file depending on the attribute value. (Of course this attribute values will be a fixed list of options, not extandable). 

I see there one difficulty, that: if user already started editing the text body, he could lose this data. But I think that this could be left on user responsibility to take care about it.

Another option could be to always insert the template text on the very beginning of the text body.

Is this feature implemented, or maybe someone have done it by changing the server code?

Cheers

I don't think there is a good secure way so far, but would like to have your opinion. 

If I want user to create logbook for themselves, what's the best way to do it? I guess Execute $attribute = <command> may work, have it write to cfg file, but obviously it impose security problem. Is there a good and secure way to allow user to create logbook themselves?

 Is there a way to set user permission based on certain attribute? can Allow command = <user list> based on attribute?
for example, say type home, user1 can read, user2 can write, user3 can not access type home, but can access type work. 

In short, is access control available when I use type to get functionality of separate logbooks? If so, how is this access control done?