ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
68246
|
Thu Jan 28 20:02:06 2016 |
| Devin Bougie | devin.bougie@cornell.edu | Bug report | Linux | 3.1.1 | Re: attachments created using "Image" button can not be clicked-on and do not appear in the attachment table. | As there appears to be some inconsistencies, I thought I'd document the behaviour of each of the attachment options.
------
1. Click on the "Image" button in the CKEditor, click on "Choose File" and browse to the file, click on "Send it to the Server", and click "OK".
- The image appears inline at the configured "Thumbnail size", but it is not clickable and it does not appear in the attachment table when viewing the entry.
2. Drag and drop an image into the body of the message.
- The image appears inline at the configured "Thumbnail size" and is clickable. As with "1," however, it does not appear in the attachment table when viewing the entry.
3. Drag and drop an image into the "Drop attachments here ..." section.
- The image appears in the attachment table at the configured Thumbnail Size, and is clickable.
4. From the attachment table, click on "Choose File" and then click on "Upload."
- The image appears in the attachment table at the configured Thumbnail Size, and is clickable.
------
We need to make sure the images are always clickable so that you can always view the full-sized image. Any suggestions for fixing this, short of reverting to v2.9.2, would be greatly appreciated.
Thanks again,
Devin
Devin Bougie wrote: |
This has been confirmed usign the Demo forum on this server. For example, please see https://midas.psi.ch/elogs/Linux+Demo/8
When an image is attached using the "Image" button in the CKEditor, that image does not appear in the attachment table for that entry. In addition, the image can not be clicked on to view the full image.
This was not the case in v2.9.2, at least.
Is there some configuration option I could toggle to change this behaviour? By default, we would like any attachment (whether it's made using drag and drop, the Image button, or the "Choose File" button) to appear in the attachment table *and* be clickable to view the full image.
Thanks,
Devin
|
|
Draft
|
Fri Feb 26 08:38:06 2016 |
| Nigel Warr | warr@ikp.uni-koeln.de | Bug report | Linux | | Possible bug in elogd execute_shell | I was just playing around with gcc6's new feature for warning about misleading indentation (which can often hide real bugs) and I think it found one in elog-3.1.1-1 at src/elogd.c:22538. Here there is an if statement, which looks as though it should be inside a loop, but it isn't. The code is:
for (i = 0; i < MAX_ATTACHMENTS; i++)
generate_subdir_name(att_file[i], subdir, sizeof(subdir));
if (att_file[i][0] && strlen(shell_cmd) + strlen(lbs->data_dir) + strl$
< sizeof(shell_cmd) + 1) {
strcpy(p, "\"");
strcat(p, lbs->data_dir);
strlcat(str, subdir, sizeof(str));
strlcpy(str, att_file[i], sizeof(str));
str_escape(str, sizeof(str));
strcat(p, str);
strcat(p, "\" ");
p += strlen(p);
}
and the if statment is accessing the loop variable i but it is actually outside the loop. Presumably, there should be some more curly brackets here. gcc6 gave the warning:
src/elogd.c: In function ‘execute_shell’:
src/elogd.c:22538:10: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation]
if (att_file[i][0] && strlen(shell_cmd) + strlen(lbs->data_dir) + strlen(subdir) + strlen(att_file[i])
^~
src/elogd.c:22536:7: note: ...this ‘for’ clause, but it is not
for (i = 0; i < MAX_ATTACHMENTS; i++)
^~~
|
68267
|
Fri Feb 26 08:47:22 2016 |
| Nigel Warr | warr@ikp.uni-koeln.de | Bug report | Linux | 3.1.1-1 | Possible bug in elogd execute_shell | I was just playing around with gcc6's new feature for warning about misleading indentation (which can often hide real bugs) and I think it found one in elog-3.1.1-1 at src/elogd.c:22538. Here there is an if statement, which looks as though it should be inside a loop, but it isn't. The code is:
for (i = 0; i < MAX_ATTACHMENTS; i++)
generate_subdir_name(att_file[i], subdir, sizeof(subdir));
if (att_file[i][0] && strlen(shell_cmd) + strlen(lbs->data_dir) + strl$
< sizeof(shell_cmd) + 1) {
strcpy(p, "\"");
strcat(p, lbs->data_dir);
strlcat(str, subdir, sizeof(str));
strlcpy(str, att_file[i], sizeof(str));
str_escape(str, sizeof(str));
strcat(p, str);
strcat(p, "\" ");
p += strlen(p);
}
and the if statment is accessing the loop variable i but it is actually outside the loop. Presumably, there should be some more curly brackets here. gcc6 gave the warning:
src/elogd.c: In function ‘execute_shell’:
src/elogd.c:22538:10: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation]
if (att_file[i][0] && strlen(shell_cmd) + strlen(lbs->data_dir) + strlen(subdir) + strlen(att_file[i])
^~
src/elogd.c:22536:7: note: ...this ‘for’ clause, but it is not
for (i = 0; i < MAX_ATTACHMENTS; i++)
^~~
|
68268
|
Fri Feb 26 09:09:03 2016 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 3.1.1-1 | Re: Possible bug in elogd execute_shell | Absolutely correct! Nice to see compilers getting better and better. I changed the code and committed it.
Nigel Warr wrote: |
I was just playing around with gcc6's new feature for warning about misleading indentation (which can often hide real bugs) and I think it found one in elog-3.1.1-1 at src/elogd.c:22538. Here there is an if statement, which looks as though it should be inside a loop, but it isn't. The code is:
for (i = 0; i < MAX_ATTACHMENTS; i++)
generate_subdir_name(att_file[i], subdir, sizeof(subdir));
if (att_file[i][0] && strlen(shell_cmd) + strlen(lbs->data_dir) + strl$
< sizeof(shell_cmd) + 1) {
strcpy(p, "\"");
strcat(p, lbs->data_dir);
strlcat(str, subdir, sizeof(str));
strlcpy(str, att_file[i], sizeof(str));
str_escape(str, sizeof(str));
strcat(p, str);
strcat(p, "\" ");
p += strlen(p);
}
and the if statment is accessing the loop variable i but it is actually outside the loop. Presumably, there should be some more curly brackets here. gcc6 gave the warning:
src/elogd.c: In function ‘execute_shell’:
src/elogd.c:22538:10: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation]
if (att_file[i][0] && strlen(shell_cmd) + strlen(lbs->data_dir) + strlen(subdir) + strlen(att_file[i])
^~
src/elogd.c:22536:7: note: ...this ‘for’ clause, but it is not
for (i = 0; i < MAX_ATTACHMENTS; i++)
^~~
|
|
68269
|
Fri Feb 26 17:20:52 2016 |
| Devin Bougie | devin.bougie@cornell.edu | Bug report | Linux | 3.1.1 | Links to images in notification message | We see two problems with the notificaiton email when attaching an image inline using drag-and-drop.
- The thumbnail does not appear in its proper location inline. There is a ? placeholder where the thumbnail should be, and the thumbnail then appears at the end of the message.
- Neither the ? placeholder nor the thumbnail that do appear are clickable.
Our v2.9.2 test installation exhibits the desired behavior.
- The thumbnail appears in its correct location inline.
- If you click on the thumbnail, you arrive at a URL displaying the full size image.
I am not able to drag-and-drop into the body of this message to test the behavior here. I am attaching a screenshot showing an example of the problem from our server.
Any suggestions would be greatly appreciated.
Many thanks,
Devin
|
68270
|
Fri Feb 26 17:35:54 2016 |
| Juergen Diefenbach | diefenba@uni-mainz.de | Bug report | Linux | 3.1.1 | Execute new|edit doesn't seem to work | I am trying to use the "Execute new|edit|delete" feature to track changes to an elog using git.
When a new entry is created a shell script should be executed (certain attributes of the logbook entry should be passed as arguments to it). The script will then automatically stage all changes and create an appropriate git commit message. For a "new" entry in the logbook the commit message is a bit more verbose. When editing or deleting a message only a short commit message like "Edit message 25" should be created. Therefore I really need to distinguish between "new", "edit", and "delete".
However, I experienced unreproducible behavior when creating "new" entries. Sometimes the command specified by "Execute new=" is called, sometimes the one specified by "Execute edit=" is executed. Most of the time it doesn't work as expected.
What I did so far to understand what goes wrong is I looked into elogd.c and found invoid submit_elog(LOGBOOK * lbs) that bedit is sometimes true and sometimes false, when creating a new entry, although it should be false then (right?).
This is why elogd then sometimes retrieves the wrong shell command from getcfg(lbs->name, "Execute edit"...) instead of getcfg(lbs->name, "Execute new"...) around line 23610 (not exact due to some eprintf()s inserted here and there to look at bedit and so on).
When deleting an entry, everything works fine: the shell command defined via "Execute delete=" is run, but this happens somewhere else in the code so it's not a surprise.
Do you have an idea how to fix this or can you point me in some direction to further track it down? Thank you! |
68271
|
Fri Feb 26 18:11:14 2016 |
| Devin Bougie | devin.bougie@cornell.edu | Bug report | Linux | 3.1.1 | Re: Links to images in notification message | From the notification I received, it looks like "2" is a problem with this server. In the email notification, we would like images to be a link to a URL displaying the full-size image (as they are in v2.9.2).
Thanks,
Devin |
68272
|
Sun Feb 28 18:24:58 2016 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Bug report | Linux | 3.1.1 | Re: Execute new|edit doesn't seem to work |
Juergen Diefenbach wrote: | I am trying to use the "Execute new|edit|delete" feature to track changes to an elog using git.
[...]
However, I experienced unreproducible behavior when creating "new" entries. Sometimes the command specified by "Execute new=" is called, sometimes the one specified by "Execute edit=" is executed. Most of the time it doesn't work as expected.
[...]
Do you have an idea how to fix this or can you point me in some direction to further track it down? Thank you! |
I'm just guessing, but you could try to disable the "save drafts" feature and see if the behaviour changes:
Save drafts = 0
If that is the case then Stefan will know where to look
Cheers
Andreas |
|