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

This is possible with conditional attributes. An additional trick would be to not show the text body of an attribute is not selected. This way the user first has to select the attribute, then the text field with the specific preset will show up. The configuration would be something along these lines:

Attributes = Type, Subject
Options Type = One{1}, Two{2}, Three{3}
Show text = 0

{1} Preset text = text1
{2} Preset text = text2
{3} Preset text = text3
{1,2,3} Show text = 1

Of course you have to supply proper text files text1, text2, text3.

- Stefan

 Thanks, it works perfectly!

How do I make selection page show only list of logbooks that logged on user has access to? 

Right now, say I have 4 logbooks, and I have access to 2 of them. I turned on Protect Selection page = 1. So when I go to home page, I need to logon first, then I am given selection page. I am given list of 4 logbooks, I can only click into 2, which is expected.  

Instead of given list of 4 logbooks, I would like to know if there is a way to make selection page only contains 2 logbooks which I have access to?

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.

Just look in the documentation for "preset text = ...". 

Hello, I have

authentication = kerberos

kerberos Realm = xxx

I ran tcpdump and know elogd server did attempt to contact kerberos server. I could run kinit username@realm_name, and klist shows my ticket fine. 

I receive "kerberos error 256: Decrypt integrity check failed. Please check your kerberos configuration" when I entered my password wrong purposely on login page.

I receive "Invalid user name or password!' when I entered my correct password. 

Please advise. 

I forgot to mention, I also have Password file line in elogd.cfg file. Because without password file line, I wouldn't get login screen. I know my test account is not in the main.pwd file. I believe elogd does go to kerberos server to compare password. I just don't get why I get invalid username and password when I entered correct password, while kerberos error (expected) when I enter wrong password.  

Authentication = Kerberos

Kerberos Realm = xxx

Password file = main.pwd

 It's resolved.  I read the documentation again, and found out my mistake. I didnt have username defined on password file. 

 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

You get a drop-down list if you define several options for an attribut, like

Options Category = Start Up, Start Down, Other

The you can select one of the categories from the drop-down list.

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

I know that this is for searching. But you don't get the point. You have attributes, like Date, Category, Subject. Each attribute can either contain arbitrary text (like the subject), or one of a set of predefined values. So category can be, let's day, "one", "two", "three". You define the possible options of the category with

Options Category = one, two, three

If you then define the quick filter

Quick filter = Category

then you get for the category a drop-down box where you can select "one", "two" or "three". If you do so, elog shows all logbook entries where the category attribute has the selected value.

I hope that this is clearer now. 

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

No this is not right. Better read the manual carefully, then come back here again. 

Hello,

I'm not able to authenticate to a logbook using my text based browser links, so I've started investigating with wget hoping solving the problem one will lead to a solution for the other.  I've seen some examples on how to use wget to parse logbook entries in this forum, but my attempts keep returning the login page.  Any advice would be helpful and appreciated.  Here are a couple of the command line arguments I've tried:

wget --save-cookies cookie.txt --keep-session-cookies -d "http://hostname/LOGBOOK?unamee=YYY&upassword=XXX" -O elog.txt

wget --save-cookies cookie.txt --keep-session-cookies -d --post-data="redit=&uname=YYY&upassword=XXX&remember=1" -e robots=off "http://hostname/LOGBOOK" -O elog.txt

After these executions, my cookies.txt file remains empty.  Running subsequent command with "--load-cookies=cookies.txt" still points me to the login page.

Many Thanks,

Chris 

I've just checked that 'wget --no-check-certificate --save-cookies cookie.txt --keep-session-cookies -d "https://elog-gfa.psi.ch/SLS?uname=uuu&upassword=ppp" -O elog.txt'

created a file cookie.txt. The file contains three lines of data if uname and upassword are a valid login, and it is empty (beside of three comment lines) if they are not a valid login (wrong user or wrong password).

Could it be related to the set-up of your particular logbook?

In a configuration with elog running (8080) under Apache (80) [as explained in admin guide], what is the syntax for tunnelling in with ssh, of both the ssh command and the browser locator?

Maybe some more information will help with the question.  Here's the results of my playing around with URL = /host.domain/subdir in elog.cfg.  Commented out, I can access locally with http://localhost:8080 and tunnelled (1234:host.domain:8080) with http://localhost:1234, with and without Apache (i.e., Apache is bypassed?).  URL = /host.domain/elog in elog.cfg works locally with browser locator localhost:8080 (of course), localhost/elog, and host.domain/elog, but the tunnel directly to 8080 no longer works, nor does http://localhost:4321/elog (even though this ends up showing the same URL on the remote browser as on the local browser) (4321:host.domain:80).  http://localhost:4321 brings up the Apache window.  Every other URL assignment I tried failed both locally and remotely, so, I assume the ssh tunnel directive is wrong, or the browser locator, or maybe still URL = .  Anyway, my question is, what am I doing wrong?

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.

Ups. I never imagined that someone would use more than 10 conditions. I'm not 100% sure if the problem is the clist array, but can you try to set it to 20 and see if it gets better? You can also send me your config file and I can try it myself. 

I'll try increasing the list size(s), and will also prepare a simplified config file for you to look at.  Maybe there is a another way to implement what I am trying to achieve?  

In general terms I am trying to give an e-log a "memory" of what has been recorded previously in order to constrain what is permissible to record next.  I do this by starting a log with an initial entry, then alter the config so that users can add records only by duplicating the last record.  The log records the current state of some variables, and allows users to record changes to the state of any of these variables. Conditions are used to constrain the permitted state changes, depending on the current state; conditions are also used, with subst options, to update the current state variables when changes are made.

Specifically, we have "Mate-Demate" logs for connectors to record when connectors are mated and demated.  Previously we just had an attribute for each connector in an assembly with options "Mate", "Demate" and "-" to indicate that either a mate or demate was carried out or that the connector was not touched on this occasion (although others were).  My cunning plan was to ensure that a "Demate" (or no-op) was possible only if the connector is currently mated, and conversely that a "Mate" (or no-op) was possible only if the connector is currently demated.  For each connector (e.g. ConnectorA), there are now two attributes

• "ConnectorA state", to record the current state, and
• "ConnectorA" to record any change.

A new record can be created only by duplicating the last record, thus copying the current state of the connectors, and for each connector the relevant config file entries are like this:

Show Attributes = ConnectorA
Show Attributes Edit = ConnectorA state, ConnectorA
Locked Attributes = ConnectorA state
Preset on duplicate ConnectorA = -
Options ConnectorA state = Mate{1}, Demate{2}
{2} Options ConnectorA = -, Mate{3}
{1} Options ConnectorA = -, Demate{3}
{3} Subst ConnectorA state = $ConnectorA