| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
69363
|
Tue May 4 14:45:47 2021 |
 | Faith | faithlessangel85@gmail.com | Bug report | Linux | 3.1.2 | Bug: "Append on edit" triggers too often | The command "Append on edit = " is getting executed everytime, when a dropdown menu is changed. This happens even at the first creation of an entry, so the append text stucks up multiple times in the text body. |
|
69364
|
Tue May 4 15:24:56 2021 |
 | Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Bug report | Linux | 3.1.2 | Re: Bug: "Append on edit" triggers too often | I can confirm the issue also for "prepend on edit".
To be more precise, it gets executed everytime the condition state changes, if placed in the config without condition, or if placed in a condition, everytime the condition gets activated.
| Faith wrote: |
|
The command "Append on edit = " is getting executed everytime, when a dropdown menu is changed. This happens even at the first creation of an entry, so the append text stucks up multiple times in the text body.
|
|
|
69369
|
Mon Jun 14 16:15:10 2021 |
 | Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Bug report | Linux | Windows | Mac OSX | All | Other | 3.1.4 | Additional forbidden attributes | 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" |
|
69370
|
Mon Jun 14 17:25:02 2021 |
 | Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | All | V3.1.4 | Bug Report with CSS includes (was Re: How to format a column in list display?) | 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?
|
|
|
69372
|
Mon Jun 14 18:51:59 2021 |
| Sebastian Schenk | sebastian.schenk@physik.uni-halle.de | Bug report | All | V3.1.4 | Bug Report with CSS includes (was Re: How to format a column in list display?) | 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
|
|
|
69387
|
Wed Aug 18 09:05:51 2021 |
| Jan Just Keijser | janjust@nikhef.nl | Bug report | Linux | 3.1.4-2 | Re: "New User" option does not work when Authentication=Webserver | here's the patch that I use to enable use creation and deletion in combination with Webserver authentication.
The idea behind the patch is that if the user logged in via "http_user" is an elog admin, then {s}he is allowed to save a random user configuration, including creating or deleting a user.
| Stefan Ritt wrote: |
|
Unfortunately I locallly don't have Webserver authentication, so I cannot check or debug. If you send me a diff that works for you, I'm happy to incorporate it.
Stefan
| Jan Just Keijser wrote: |
|
Our setup uses "Authentication=Webserver" + no automatic user registration. Thus, logbook admins should add a user by clicking "Config" and then "New user". However, no matter what they fill in in the "new user " dialog, as soon as they hit "Save" an error pops up saying that their username (the admin one, not the new one) already exists. I found the following code:
int save_user_config(LOGBOOK * lbs, char *user, BOOL new_user)
{
char file_name[256], str[256], *pl, user_enc[256], new_pwd[80], new_pwd2[80], smtp_host[256],
email_addr[256], mail_from[256], mail_from_name[256], subject[256], mail_text[2000], str2[256],
admin_user[80], url[256], error[2000], sid[32];
int i, self_register, code, first_user;
PMXML_NODE node, subnode, npwd;
/* if we outsourced the authentication, use external username */
getcfg(lbs->name, "Authentication", str, sizeof(str));
if (stristr(str, "Webserver")) {
/* do not allow HTML in user name */
strencode2(user_enc, http_user, sizeof(user_enc));
} else {
strencode2(user_enc, user, sizeof(user_enc));
}
which seems to be the culprit: the admin user is logged using his/her Webserver (http_user) credentials and this overrides anything that he/she might fill in. If I remove the "Authentication" check then I can create a new user without problems. So, how to fix this? should the "Authentication=Webserver" check be extended with a self/auto registration check?
|
|
|
| Attachment 1: elog-webauth.patch
|
diff -Naur elog-3.1.4-3.org/src/elogd.c elog-3.1.4-3/src/elogd.c
--- elog-3.1.4-3.org/src/elogd.c 2021-02-19 09:55:03.000000000 +0100
+++ elog-3.1.4-3/src/elogd.c 2021-08-17 17:26:06.492232620 +0200
@@ -13273,7 +13273,7 @@
/* if we outsourced the authentication, use external username */
getcfg(lbs->name, "Authentication", str, sizeof(str));
- if (stristr(str, "Webserver")) {
+ if (!is_admin_user(lbs, http_user) && stristr(str, "Webserver")) {
/* do not allow HTML in user name */
strencode2(user_enc, http_user, sizeof(user_enc));
} else {
@@ -26139,6 +26139,8 @@
}
/* make sure user is logged in */
+ if (strcmp(user, http_user) == 0)
+ return TRUE;
if (lbs && !logged_in(lbs))
return FALSE;
|
|
69388
|
Sat Aug 28 21:32:09 2021 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | Linux | ELOG V3.1.4 | Adding entries without being logged in stopped working with attachments | 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
|
|
69399
|
Thu Oct 21 11:00:46 2021 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | Linux | 3.1.4-2e1708b | Redirect in Execute new needs space after ">" | EDIT: forget the tip below. Instead just call script files: inline scripting in the ELOG config shows very strange behavior. Doing the same in external scripts works reliable.
I just spend an hour searching for a problem. To avoid others to spend the hour again, here's a little "special behaviour" of shell execution in ELOG you should know about:
If you want to do redirect to a file in a shell execution, put a space before and after the redirecting. The following does not work:
Execute new = if ! [ -z "$CampaignID" ] ; then echo "$CampaignID" >/usr/local/elog/logbooks/elog-campaign.default ; fi
You will not get an error message, but the file is not created. But if you add a space it will work as expected:
Execute new = if ! [ -z "$CampaignID" ] ; then echo "$CampaignID" > /usr/local/elog/logbooks/elog-campaign.default ; fi
It is not really a bug; if you know about it, then it is not a big deal: hence this entry here. I saw this behavior on a Linux RHEL7 system.
In case you are wondering: I use this to create a default for the field CampaignID, to be used for new entries in combination with a Preset:
Preset CampaignID = $shell( if [ -r /usr/local/elog/logbooks/elog-campaign.default ] ; then cat /usr/local/elog/logbooks/elog-campaign.default;fi ) |
|