Hi, 

I have a logbook with guest access and guest can also enter a new entry (in config: Guest List Menu commands = New, Find, Select, Login). For other reason in a global section, I put 

Deny New = account1, account2

This somehow invalidates Guest List Menu commands, since as guest I don't see New button anymore. Is this behaviour desired? Otherwise, I would need to move Deny option to plenty of individual logbook configs. Just to explain the reason, those accounts are set up to only read entries and not to create new ones. Or maybe you can suggest a different solution?

Best

The function of "Drop attachments here..." is only for root user? I'd like it could be used by all users.

I can't confirm this behavoiur. In our instance, every user can use the attachment function of the elog.
Either through "Drag&Drop" or "Browse&Upload" in the entry editor.

What do you mean by "root" user?
The elog can have serveral admin users, but this behaviour is equal for admin and non-admin users.
You should not run the elog server as user "root" of the machine for security reason, but also for issues with file permissions.

I just used my own account to test the "Drag&Drop" function in this forum ,  and it failed.  In our case, we need to upload ten more images into logbook at once, it's more effective to use "Drag&Drop" than "Browse&Upload" feature for "Browse&Upload" only can choose one attachment at once, but "Drag&Drop" can choose several attachments at once. The admin user can use this feature, but non-admin user not in our site. I did run the elog server as  user "root". I'm not sure it is related to the problem.

In my testings I didn't found this behaviour, but my collegues also reported this issue.
So I searched for the difference between my test setup and the production logbooks.

I believe the "restrict edit = 1" config option may be responsible for this behaviour.
I had the browser console running in the background and "Drag&Drop" send an XHR request,
which failed with the message: "Only user can edit this entry".
This message is tied to the "restrict edit" option as far as I know.
So I tried removing the option and upload via "Drag&Drop" started to work as intended.
This behaviour only occurs for non-admin users, as admin users are not affected by

Can you verify this?
I can verify to get the same error message in this elog forum in the browser console.

I could figure out the bug. A fix can be found in this commit.
https://bitbucket.org/merrx/elog/commits/c3e3c4af9666006558aaf26d8f4841800e69f9af

Looks good, I merged the pull request.

Thanks for the merge.
I found a more general solution, as there could be the posibility to have the author as "select" or "radio box" input in the form, where the fix breaks.
But I think in most of the cases the author is a preset input, if used with "restrict edit = 1", so the merged fix should be fine.
https://bitbucket.org/merrx/elog/commits/7aacfbcac43b1192e5271fa7b2c80f4825c94d23

Today we ran into this issue again, but this time the curpit was encoding...
The author name in the password file was differently encoded as the author name from the xhr request.
For this instance there was a umlaut in the name.

I haven't got a good solution for this at the moment.
The workaround is to check the encording in the password file and make it matching.
But as for automated logins / user generation e.g. via LDAP (in our case) one should be aware of this issue.

Excellent, Thanks!

Good afternoon!

The elog does not see the time zone. It displays UTC + 0. When I transfer old entries to a new compiled log, they are displayed 3 hours earlier (my time zone is UTC + 3). When creating a new record, it creates them in the UTC + 0.

Compilation occurs in Cygwin.

Version elog – 3.1.4-3.

Please help solve this problem.

Dear, sir! There is a problem with a configuration file.

The code was compiled by Cygwin (gcc-core, gcc-g++, make, gdb, libssl-dev).  After a compilation a reference to our own css-file was written in configuration file and css-file was included in a folder “themes/default” of the project.

The problem is that in running elog-3.1.4-1 (and upper versions) css-file name in a code of a page has some random symbols before file-name, for example: <link rel="stylesheet" type="text/css" href="ø9öÿeLogOUK.css">. It was found that the problem is resolved if a string “Password file=passwd” is deleted, but in this case it is impossible to set passwords to the users.

Here is an example of configuration file which is taken from the forum and just one string (CSS=elogOUK.css) has added to the code

[global]

; port under which server is listening

Port = 8080

CSS = eLogOUK.css

[Accelerator]

Comment = Accelerator Logbook

; use user level password access

Password file = passwd

Login expiration = 1000

Admin user = ritt

Self register = 1

; look and feel

Guest menu commands = Back, Find, Login, Help

Guest find menu commands = Find, Login, Help

Date format = %B %d, %Y

; attributes

Attributes = Author, Author Email, Category, Subject

Options Category = Routine entry, Shift summary, Problem, Fix, Question, Info, Other

Extendable attributes = Category

Required Attributes = Category, Subject

Thread display = $Subject, entered by $author on $Entry date

Quick filter = Date, Category

; title as shown in the browser

Page Title = Accelerator Logbook - $subject

; preset author and email

Preset Author = $long_name

Preset Author Email = $user_email

; these attributes cannot be changed

Locked Attributes = Author, Author Email

; only author can change its own entry

Restrict edit = 1

; options for reply

Subst on reply subject = Re: $Configuration Name

Remove on reply = Author, Author Email

; No Email notification

Suppress Email to users = 1

____________________________________________________________________

What can be done to resolve this problem?

Hello Maxim,

I just stumbled on a similar issue. Also with a self-compiled elogd on Ubuntu.

We also use a custom css and by clicking on the "New" or "Reply" or "Duplicate" the elog generates the entry editor.
On the first load of this page the link to the css file is sometimes corrupted by having some garbage characters in it.
<link rel="stylesheet" type="text/css" href="ƒŒüthemes/name.css">

I found the bug in the code and made a PR on the bitbucket. Here is the commit to fix it yourself.
https://bitbucket.org/merrx/elog/commits/cea193ded7161bb6d1f67725ca109d2d4341128a

Best wishes,
Sebastian

Good afternoon Sebastian!
Thank you very much for your help.

Dear elog users & developers,

the subject line says it all: when using webserver authentication, how is it possible to restict access of users to any given elog? Only using the apche rules? Admin user and Login user do not seem to be doing anything for me. I am using elog as packaged by debian for buster, using an apache ssl proxy. Thank you for providing this software,

Christian

Dear all,

I figured it out. Current global config is (using kerberos instead)

[global]
port = 8081
Default encoding = 0
SSL = 0
Authentication = Kerberos
URL = https://my_url_here/
interface = 127.0.0.1
Password file = global.pwd
SMTP host = my_mail_host
Logfile = /var/log/elog.log
Logging level = 3
User = elog
Grp = elog

Best,

Christian

Would it be possible to create a new command "List format <attribute> = <css_class_name>,<css_class_value>,<width>,<size>", or is there another way to achieve this?

Okay, found some solution for my problem:

And file themes/default/pikett.css contains:

That works like a charm - until I log in to the logbook. Then the include of the CSS in the header is garbled with some "prefix" of random chars:

And a quick check in the source code shows some bad code:

L7615: function "show_html_header"

Here css_base is a not initialized local variable of the function. In fact the above line is the only reference of that variable char css_base[1000].

The bug is still present in elog-3.1.4-611489b

Hi Andreas,

the bug you have found was already reported in an earlier issue, together with the same solution you have found.
https://elog.psi.ch/elogs/Forum/69368

Best wishes,
Sebastian

Hi Stefan,

I've just tried to read the $text with subst into another field and failed.
It looks like $text is only available for the execution of shell scripts in the "execute new|edit|delete = <script>" command.

Could that be added? I can think of a multitude of applications:

• In my case I want to fill an attribute X either with free text or generated from other fields. The list view will show just X and not how it was generated.
• I could fill an attribute automatically with the character length of the text.
• I could parse the text in a shell script and set other attributes according to the content.

Thank you for considering it.

Cheers, Andreas

$text is the full body text and can go over many lines. Since attributes are restricted to single lines, it's not possible to substitute them with the body text.

Stefan

While the input widget of text attributes is a single line, they can easily be multi-line in the display - when you use HTML at least.
And of course the user can parse the text field and generate a single line, if he wants to.
If you leave it to me, I'll create wonderful applications to that feature :-)

Please? ;-)

Sure, attributes can be shown multi-line, but they cannot be stored in the elog internal database. The database is a very old design and only allows for single line attributes. Just look at a YYMMDDa.log file and you will see that. I would have to change the database format to somethign more advanced like XML, but that would take me a couple of weeks or months.

Soooorrryy! ;-)

Hi Stefan,
no problem: if I just strip all newlines from the $text field (in HTML you use <br> anyway, the newline has no function apart from whitespace), and my multiline attribute is fine to go.
I do not intend to make the attribute editable: it is just used for display. Because that allows me to create the attribute either from free text or from combining other fields - depending on conditional attributes.

As a special feature you could strip all newlines beforehand, when providing the $text for subst statements.

Cheers, Andreas

I should tell that I found a simpler way to achieve the same:
I suppress the "text" field and use a single line text input field instead.
The single line input in "free text" modes just contains "<br>" : I would have had to use those in the text field anyway.

I am not Stefan, but maybe I can add to this issue.

Personally I think it is not a good way to dump all the information into the text field and try to let the server parse it.
This could be archived more simply by using e.g. the python elog scripts or using the elog command tool to directly submit well structured elog entires.

As you have mentioned you could use the "execute new|edit|delete" commands to do the things you want to do.
Let the called script fetch the elog entry and alter it in the way you like and resubmit the entry.
(You have to make sure to don't generate a endless loop and you have to proably have to use a forwarding script as the elog "execute" command waits for finished execution).
This way you don't touch the 1500 characters limit of passing $text to the execute command.

Also the point "filling an attribute X with free text" needs some kind of (extended) parsing, which isn't possible with the subst command.
In our elog we such an attribute X, which is in some conditions filled with a set of other attributes and on other conditions just a normal input field, so the user could type custom text in.

"fill an attribute automatically with the character length of the text" could be done with the above mentioned execute command or it could be done on the clientside (e.g. browser using javascript or if automatically generated by a script, then directly by the script)

I hope it helps to build our application.
Best wishes,
Sebastian

Hello Stefan,

I stubbled on a issue with our elog.
We introduced an attribute "mode" to one of the elogs and it breaks the "Find" function as this attribute is already used for the viewing settings "full", "summary" and "threaded".
(HTTP parameter pollution)

I suspect other special attributes used by the internals of elog should also not be allowed.
A quick search in the "Find" reveals these attributes in the URL, so I guess, these should also be avoided.
This list could be incomplete

npp, ma, da, ya, mb, db, yb, attach, reverse, mode

A simple workaround would be updating the documentation to add these to the list of forbidden attributes.
https://elog.psi.ch/elog/config.html
Maybe a warning can be added, if the elog behaves unexpected, try other attribute names, as they can conflict with internal attributes.

A fix could be to add a prefix for internal attributes, which can't be used for user attributes.

Best wishes,
Sebastian

PS: I also noticed using the "Find" command, the generated URL contains 2 reverse attributes like "reverse=0&reverse=1"