"Drop attachments here..." only functional in IE, posted by Michael Hibbard on Thu Apr 5 06:00:09 2018
|
Hello, the "drop attachments here..." feature is very useful, especially when I have multiple files. I can drag them all over in one operation,
however I have noticed that this feature only works well in the IE browser.
It does not work reliably in Safari/Chrome/Firefox. I have tired in both 3.1.3 and 3.1.2. I also have the same symptom on the Demo log book of |
|
Create past Elog entry., posted by Michael Hibbard on Mon Apr 2 23:31:51 2018
|
Hello, Sorry if this has been addressed elsewhere, but I could not find info.
I am wanting to submit a new elog entry (that should have been) for a past date, to predate log entrys currently in my system.
I assume I must manually create a new .log file. What ID# should I assign to this entry? Should I sub-increment (i.e 33.1)? I presume the |
Re: Create past Elog entry., posted by David Pilgram on Tue Apr 3 09:39:07 2018
|
Hi Michael,
Elog purists, look away now.
There is an "official" way to do this, which is to have fields for entry date (so can be in the past), but the yymmdda.log file will |
Re: Create past Elog entry., posted by Michael Hibbard on Tue Apr 3 22:34:49 2018
|
Thank you David, Andreas. Very useful forum.
David
Pilgram wrote:
Hi Michael, |
|
Re: Create past Elog entry., posted by Andreas Luedeke on Tue Apr 3 10:19:07 2018
|
David answered the question already.
I would distinguish if this is a once-in-a-year event, where you are willing to edit the logfiles as an administrator to fix it -
or
if it happens more weekly, and you want to enable the users to fix it themself.
If it happens once a year and you don't |
New elog setting for large attachments, posted by Stefan Ritt on Mon Mar 26 16:32:43 2018
|
Most mail delivery systems have a maximum size for attachments. In the past, if an elog attachment was larger than this size, the email server refused
to accept this email and no notification is sent. Now one can specify the maximum allowed email attachment size with
Max email attachment size = <n> |
BSOD, posted by Ales Novak on Fri Feb 23 21:27:12 2018 
|
Hi,
I have been using elog for a few years and it is a wonderfull software and has been one that I can't go without. So thank you very much for
making it. |
|
Re: BSOD, posted by Stefan Ritt on Mon Mar 19 16:45:07 2018
|
The dump does not help me much. I need to reporduce the problem in a controlled environment.
Stefan
Ales |
|
Problem with special character "č", posted by Matej Sedej on Fri Feb 16 09:18:56 2018
|
Hello!
First of all, thank you for this great piece of software! For now it seems to perfectly cover our need to log very basic events, there was a
setting for everything we wanted to set. |
|
Re: Problem with special character "č", posted by Matej Sedej on Fri Feb 16 09:36:18 2018
|
I see the same problem exists on this board as well. Actuall it appears only the attribute fields are affected. The č character was incorrectly
written to the log file from the subject field above, but correctly from the body text below.
Matej |
|
Re: Problem with special character "č", posted by Stefan Ritt on Tue Mar 6 15:08:23 2018
|
Actually unicode characters are converted by your browser into HTML code (such as Č) where 268 decimal = 10C hex. elog just writes to file what
it gets from the browser. When an existing elog entry gets shown by the browser, the code is translated back to the character. Why do you care what is
written to the log file? If you use scripts or so to parse your log files, you have to adapt them to correctly decode HTML encoded characters. This is |
|
Re: Problem with special character "č", posted by Matej Sedej on Tue Mar 6 15:29:38 2018
|
Hello Stefan,
thank you for the reply. The explanation does not solve my problem though.
1) Could you elaborate, why the body text field CORRECTLY writes the character while the |
|
Re: Problem with special character "č", posted by Stefan Ritt on Tue Mar 6 15:54:23 2018
|
In the attribe filed, HTML code is not allowed for security reasons. If you want to bypass this (on your own risk), put
allow html = 1
into your config file. |
|
Re: Problem with special character "č", posted by Matej Sedej on Tue Mar 6 16:09:05 2018
|
This tag does not change the behaviour, but I have noticed that I only have the problem in Chrome and Firefox but not in Internet explorer.
Matej
Stefan |
|
Re: Problem with special character "č", posted by Matej Sedej on Thu Mar 15 09:39:20 2018
|
To conclude this topic, we sadly can't use the characters č and Č propperly in the application. I have marked the problems in the screenshots
below:
red square - the user name is changed immediately after saving. It is also written into the log file in the |
|
Re: Problem with special character "č", posted by Stefan Ritt on Fri Mar 16 12:46:09 2018
|
I had time to look at the problem in detail. I found that a &#xxx; sequence is not correctly identified as HTML code, and thus displayed in plain
when used in an attribute. I fixed it in the current git revision and now it looks find in attribute (see attachment). Can you give it a try? Please note
that you need "Allow HTML = 1" in your config file. |
|
Re: Problem with special character "č", posted by Matej Sedej on Fri Mar 16 14:12:04 2018
|
Great news Stefan! Please pardon my ignorance, but I was not able to "make" it. I have no idea how to run this on Windows where the current
POC log resides. |
|
Re: Problem with special character "č", posted by Stefan Ritt on Fri Mar 16 14:35:05 2018
|
Easiest is to install the Cywgin environment (www.cygwin.com) and there select the C compiler package which installs also "make".
Matej
Sedej wrote:
Great news Stefan! Please pardon my ignorance, but I was not able |
|
Re: Problem with special character "č", posted by Matej Sedej on Fri Mar 16 15:39:17 2018
|
Phew, made it, sort of. Had to copy the contents of the mxml folder from an older version, the folder was empty in this git. I also had to change the
SSL to 0 and then it compiled without errors plus I had to copy the cygwin1.dll to the folder to make the service run.
So yes, I can confirm that manually inputting the Č in the attribute field now works correctly. Excellent! This solves the pink problem |
|
Re: Problem with special character "č", posted by Stefan Ritt on Fri Mar 16 17:51:30 2018
|
Pink problem: Yes the CSV export preserves the html tags, but what to do. CSV files are plain text with 8 bit characters. Unicode characgers have to
be represented with more than one byte. So either HTML encoding or some special escape sequence encoding. If you like the second better than the first,
I'm sure you find some conversion program on the internet. |
|
Re: Problem with special character "č", posted by Stefan Ritt on Fri Mar 16 18:08:10 2018
|
Special characters in use names should now work in the current version.
Stefan
Ritt wrote:
Pink problem: Yes the CSV export preserves the html tags, but what to |
|
Re: Problem with special character "č", posted by Matej Sedej on Fri Mar 16 20:54:40 2018
|
That's great, Stefan, it works indeed. I tried fiddling around a bit with different charsets but haven't been succesful yet. I'll play around
some more.
Stefan |
|
how to insert images inline, posted by Piotr Zolnierczuk on Tue Mar 6 16:59:29 2018
|
Hi,
I recently upgraded elog from 2.7 to 3.1 and have a hard time to insert images inline. The attachements work just fine. I am certain it is something
silly, but I cannot figure it out. |
|
Re: how to insert images inline, posted by Stefan Ritt on Tue Mar 6 17:28:46 2018
|
Before you click OK on your point 4, click on "Send to Server".
Stefan
Piotr |
|
Re: how to insert images inline, posted by Piotr Zolnierczuk on Tue Mar 6 17:49:49 2018
|
I did just that. The image was properly send to the server (it appears in the attachement list). However clicking OK still produces "Image source
URL is missing".
What is the URL that refers to an attachment? I've tried 68759/<1> and 68759/1 and even elog:1234/<1> (where |
Re: how to insert images inline, posted by Piotr Zolnierczuk on Tue Mar 6 18:01:30 2018
|
Got it to work. Removed "Preview attachments = 1" from the global section.
Thanks for your help.
Piotr |
User passwords not configurable with loacl passwordfile, posted by KaterKarlo99 on Tue Feb 27 15:11:23 2018
|
Hi!
Tryed windows an linux version. On booth the "Register new User" dialog is not displaying a password line.
so what password is used for the new user? Further the user can't change his password, because he didn't know the old one. |
|
Re: User passwords not configurable with loacl passwordfile, posted by Stefan Ritt on Tue Feb 27 15:32:30 2018
|
Have you configures user-level access via
password file = anyfile.pwd
Can your elogd server write to that file?
If yes, can you please post your config file? |
|
Re: User passwords not configurable with loacl passwordfile, posted by KaterKarlo98 on Wed Feb 28 11:38:23 2018
|
Hi Stefan,
thanks for the quick reply.
Yes, i've configured user-level access. Here is my cfg: |
|
Re: User passwords not configurable with loacl passwordfile, posted by KaterKarlo99 on Mon Mar 5 14:10:52 2018
|
I'm afraid that there is something wrong because each user will be written with the same (hashed) password to the local password file,
irrespective of the given password within the "new User dialog".
So for instance, every user in my password file lokks like this: |
|
Re: User passwords not configurable with loacl passwordfile, posted by Stefan Ritt on Mon Mar 5 14:29:26 2018
|
What happens when you don't use Kerberos authentication?
KaterKarlo99
wrote:
I'm afraid that there is something wrong because each user will be written |
|
Re: User passwords not configurable with loacl passwordfile, posted by KaterKarlo99 on Mon Mar 5 14:44:58 2018
|
Yeah!!
That did it! I remove the line "Kerberos authentication" and now it works!
Thanks! |
|
Entries disappear after editing + UTF16 problem, posted by Peter K on Wed Jan 31 09:06:10 2018
|
I found a sequence which hides the message from the list.
In addition this sequence corrupts UTF encoding of the text.
create new message
submit it
Edit this message again
click SAVE and then exit the editor (click Logbook |
|
Re: Entries disappear after editing + UTF16 problem, posted by Stefan Ritt on Thu Feb 1 10:34:42 2018
|
The message is not lost, but becomes a "draft". This works similar in most email systems. When you edit an email and son't send it, it
stays in your "draft" email folder and does not show up in your "sent" folder. Same here. You are suppost to "submit" you
entry, the "save" is just a temporary safety backup. If you do not submit (if you press BACK or your browser crashes), the entry is not submitted |
|
Re: Entries disappear after editing + UTF16 problem, posted by Peter K on Thu Feb 1 14:55:24 2018
|
Dear Stefan,
Thanks for quick reply.
I checked List drafts = 1 in config file - it does not show drafts in the list in my case. |
|
Re: Entries disappear after editing + UTF16 problem, posted by Stefan Ritt on Fri Feb 2 08:31:35 2018
|
You might have to update to the current elog version. This feature was implemented in Dec. 2016.
Stefan
Peter |
|
Re: Entries disappear after editing + UTF16 problem, posted by Peter K on Tue Feb 6 10:15:29 2018
|
We installed our elog from .apk in November 2017.
Version V3.1.2-bd75964
I suppose it already contains List drafts feature. |
|
Re: Entries disappear after editing + UTF16 problem, posted by Stefan Ritt on Tue Feb 6 10:23:26 2018
|
The -bd... number must be from the .apk package, which I don't have control over. You have to check the elog git hash code. You see it at the bottom
of each elog web page. For this forum server, it's ELOG V3.1.2-7933898 with
7 digit number at the end. |
|
Re: Entries disappear after editing + UTF16 problem, posted by Peter K on Wed Feb 7 14:22:23 2018
|
yes, that is exactly where I got this V3.1.2-bd75964 version!
Do you recommend to download it again from your site and compile?
Stefan |
|
Re: Entries disappear after editing + UTF16 problem, posted by Stefan Ritt on Wed Feb 7 14:26:01 2018
|
Tell me your current seven digit number and I can check if your version is too old.
Peter
K wrote:
yes, that is exactly where I got this V3.1.2-bd75964 version! |
|
Re: Entries disappear after editing + UTF16 problem, posted by Andreas Luedeke on Wed Feb 7 15:28:47 2018
|
Hi Stefan,
I think there is a misunderstanding: there is an ELOG commit with the GIT ID bd75964.
It is from Sep. 2016,
so: Peter, you should download a newer version.
Cheers
Andreas
https://bitbucket.org/ritt/elog/commits/all?search=bd75964
Stefan Ritt
|
|
Re: Entries disappear after editing + UTF16 problem, posted by Peter K on Thu Feb 8 15:09:42 2018
|
Dear Stefan and Andreas,
We have updated our elog to V3.1.3-7933898, now I see the drafts in
the list! |