Adding entries without being logged in stopped working with attachments, posted by Andreas Luedeke on Sat Aug 28 21:32:09 2021
|
Hi Stefan (et al),
we have several logbooks that allow to add new entries without logging in first.
That still works, as long as these entries don't have any attachments.
As soon as there is an attachment you are asked to login in the web interface.
I hope that this is not an intentional feature, but a bug?
Several of our software tools now fail to submit elog entries.
The problem occured when we upgraded to ELOG V3.1.4-2e1708b.
Version elog-3.1.4-611489b did not show this behaviour.
Kind Regards
Andreas
|
Logging Main page entries, each with multiple ongoing events , posted by Alan Grant on Wed Jul 21 16:16:29 2021
|
Is there any way to log child events on the detail pages for a fixed number of entries on the main page? For example, I have 15 vehicles to enter on the main page, ID'd by Vehicle Number. Within each of those entries I will be logging ongoing repair service entries with certain attributes.
So how might I design this concept without having repeating vehicle entries on the main page for every service event, and preferably without splitting the information between two linked logbook tabs?
|
Deny option and Guest commands, posted by Janusz Szuba on Mon Jul 19 18:41:29 2021
|
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 |
Drop attachments here..., posted by Xuan Wu on Wed Jun 23 03:48:22 2021
|
The function of "Drop attachments here..." is only for root user? I'd like it could be used by all users. |
Re: Drop attachments here..., posted by Sebastian Schenk on Mon Jun 28 14:53:44 2021
|
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.
Xuan Wu wrote: |
The function of "Drop attachments here..." is only for root user? I'd like it could be used by all users.
|
|
Re: Drop attachments here..., posted by Xuan Wu on Mon Jun 28 18:41:31 2021
|
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.
Sebastian Schenk wrote: |
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.
Xuan Wu wrote: |
The function of "Drop attachments here..." is only for root user? I'd like it could be used by all users.
|
|
|
Re: Drop attachments here..., posted by Sebastian Schenk on Tue Jun 29 15:21:06 2021
|
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.
Xuan Wu wrote: |
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.
Sebastian Schenk wrote: |
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.
Xuan Wu wrote: |
The function of "Drop attachments here..." is only for root user? I'd like it could be used by all users.
|
|
|
|
Re: Drop attachments here..., posted by Sebastian Schenk on Tue Jun 29 20:13:36 2021
|
I could figure out the bug. A fix can be found in this commit.
https://bitbucket.org/merrx/elog/commits/c3e3c4af9666006558aaf26d8f4841800e69f9af
Sebastian Schenk wrote: |
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.
Xuan Wu wrote: |
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.
Sebastian Schenk wrote: |
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.
Xuan Wu wrote: |
The function of "Drop attachments here..." is only for root user? I'd like it could be used by all users.
|
|
|
|
|
Re: Drop attachments here..., posted by Stefan Ritt on Tue Jun 29 20:20:38 2021
|
Looks good, I merged the pull request. |
Re: Drop attachments here..., posted by Sebastian Schenk on Wed Jun 30 13:50:08 2021
|
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.
Stefan Ritt wrote: |
Looks good, I merged the pull request.
|
|
Re: Drop attachments here..., posted by Xuan Wu on Wed Jun 30 04:38:21 2021
|
Excellent, Thanks!
Sebastian Schenk wrote: |
I could figure out the bug. A fix can be found in this commit.
https://bitbucket.org/merrx/elog/commits/c3e3c4af9666006558aaf26d8f4841800e69f9af
Sebastian Schenk wrote: |
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.
Xuan Wu wrote: |
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.
Sebastian Schenk wrote: |
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.
Xuan Wu wrote: |
The function of "Drop attachments here..." is only for root user? I'd like it could be used by all users.
|
|
|
|
|
|
Timezome problem, posted by Maxim on Wed Jun 23 15:28:00 2021
|
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. |
Problem with a self-compiled code., posted by Maxim on Mon May 31 14:51:39 2021
|
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? |
Re: Problem with a self-compiled code., posted by Sebastian Schenk on Thu Jun 3 16:02:02 2021
|
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
Maxim wrote: |
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
____________________________________________________________________
What can be done to resolve this problem?
|
|
Re: Problem with a self-compiled code., posted by Maxim on Wed Jun 23 14:08:15 2021
|
Good afternoon Sebastian!
Thank you very much for your help.
Sebastian Schenk wrote: |
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
Maxim wrote: |
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
____________________________________________________________________
What can be done to resolve this problem?
|
|
|
when using webserver authentication, how can I restrict the users that can edit any given elog?, posted by Christian Ospelkaus on Sat Jun 19 18:38:21 2021
|
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 |
Re: when using webserver authentication, how can I restrict the users that can edit any given elog?, posted by Christian Ospelkaus on Sun Jun 20 14:38:06 2021
|
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
Christian Ospelkaus wrote: |
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
|
|
How to format a column in list display?, posted by Andreas Luedeke on Fri Apr 23 20:08:10 2021
|
There is the nice conditional formatting feature for List display:
Cell Style <attribute> <value> = <style>
I would like to use it without conditions: some attributes should always be formatted in a specific way.
Specifically I want a generated attribute (combined from other attributes) to be display in monospace font.
The "Format Pikett = 0, attribname, messagelist " works nicely for the single entry display (pik1), but not for List view (pik-list).
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? |
Bug Report with CSS includes (was Re: How to format a column in list display?), posted by Andreas Luedeke on Mon Jun 14 17:25:02 2021
|
Okay, found some solution for my problem:
List Change Pikett = <div class="pikett">$Pikett</div>
CSS=pikett.css
And file themes/default/pikett.css contains:
.pikett {
background-color:white;
font-size:16px;
font-family:monospace;
text-align:left;
}
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"
rsprintf("<link rel=\"stylesheet\" type=\"text/css\" href=\"%s%s\">\n", css_base, css);
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
Andreas Luedeke wrote: |
There is the nice conditional formatting feature for List display:
Cell Style <attribute> <value> = <style>
I would like to use it without conditions: some attributes should always be formatted in a specific way.
Specifically I want a generated attribute (combined from other attributes) to be display in monospace font.
The "Format Pikett = 0, attribname, messagelist " works nicely for the single entry display (pik1), but not for List view (pik-list).
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?
|
|
Bug Report with CSS includes (was Re: How to format a column in list display?), posted by Sebastian Schenk on Mon Jun 14 18:51:59 2021
|
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
Andreas Luedeke wrote: |
[...]
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"
rsprintf("<link rel=\"stylesheet\" type=\"text/css\" href=\"%s%s\">\n", css_base, css);
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
|
|
|