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?

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.

And if an admin user trys to change the password of an other user, a error is displyed that the old password of the admin user is
wrong and nothing happens with the password of the non-admin user.

elog console (admin user awrzkrz changes the password of testuser1):

GET /demo/?cmd=Config&config=TestUser1&cfgpage=1&admin=1&cfg_user=TestUser1&active=1&new_user_name=TestUser1&new_full_name=TEST+User&new_user_email=test%40heaven.org&cmd=Change+password HTTP/1.1
Returned 1032 bytes
GET /demo/?config=TestUser1&newpwd=test1234&newpwd2=test1234 HTTP/1.1
Returned 20 bytes
GET /demo/?cmd=Change%20password&config=awrzkrz&fail=1 HTTP/1.1
Returned 1215 bytes
 

Thanks for help!

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:

    <name>TestUser1</name>
    <password encoding="SHA256">3c2QQ0KjIU1OLtB29cl8Fplc2WN7X89bnoEjaR7tWu.</password>
    <full_name>TEST User</full_name>
    <last_logout>0</last_logout>
    <last_activity>0</last_activity>
    <email>test@heaven.org</email>
    <inactive>0</inactive>
    <email_notify/>
  </user>
 

"password encoding" has got the same value for each user after creating them with their own passwords....

That's the main issue i have, because i don't know this password and can't set a known one....

frustrating....

any help would be appreciated

password file = anyfile.pwd

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.

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 attribute fields write and display the HTML code?

2) If I understand you correctly the problem also contradicts your statement: "When an existing elog entry gets shown by the browser, the code is translated back to the character." and is visible in this very post. The subject field writes and displays it incorrectly, while the body text writes and displays it perfectly OK. See: Č č ?

3) We do not use any scripts. If we were to use a script to replace the HTML code with the actual character, the attribute fields would still display È instead of Č. Also, I have no idea how to write such a script. :)

Thanks,

Matej

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.

1. In edit mode, I click the image icon
2. A pop-up "Image Propertied" shows with two tabs "Image Info" and "Upload" (selected)
3. Click on Browse button and select an image
4. Now
   • if I click OK, I get an error "Image source URL is missing".
   • if I go to "Image Info" tab - what URL am I supposed to enter, 68757/<1> ?

I found an old thread elog:68410 (from 2016) but could not find a solution that would work for me. Where does "Preview attachments" option should be inserted? In the global section?

Hopefully there's a simple explanation for this

Piotr

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 attribute "Lovec" preset as $long_name. This cannot be displayed correctly even when using HTML and the text tag.

orange sqare - This appears in translated menus and in the attribute "Preža" where the options are listed. The character is written correctly in the translation and the log file, but is displayed incorrectly as È and è.

pink square - After using the script on this attribute "Opis" to insert the html text tag the field correctly displays the characters. The minor problem remains when exporting this to a csv file where the html text tag remains.

I have no idea what effort it would take to change the ANSI background of the application to UNICODE and I can't really expect you to do this. On the other hand most modern applications go through this step eventually, mostly because of the Chinese and the Russian markets.

Thanks again for the otherwise great product, I guess we'll have to start using letters c and C instead. Best reagards,
Matej

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.