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.

I could figure out the bug. A fix can be found in this commit.
https://bitbucket.org/merrx/elog/commits/c3e3c4af9666006558aaf26d8f4841800e69f9af

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.

Hi Chris,

my old entry was related to the admin options of edit time.
The option "Admin restrict edit time" was implemented later, see ab8b98c

As a workaround you should be able to give "Restrict edit time" a ridiculous high number in the specific logbook, which should overwrite the global.
In the documentation is no rule specified for diabling global settings for specific logbooks, as far as i know.

Best wishes,
Sebastian

Hi Anthony,

the elog has a mirroring function, which synchornizes config and logs between multiple instances.
See the bottom section of https://elog.psi.ch/elog/config.html

Best wishes,
Sebastian

Hello Harry,

the elog server (elogd) is a standalone application written in C and contains a full webserver and logfile management system.
There are no other dependencies to apache or python.

You can use a webserver like apache or nginx in combination with elog to act as a proxy,
e.g. to handle the encryption part of the communication between your web browser and the elogd, but you don't need to.

Regarding the first part of your message:
The elog server worked normally; entries (including the text body) got saved correctly until the last update? 
The only thing in your list of updates, I can think of making this problem could be the update of ckeditor as it is the text editor used by elog.
The other packages should not be related to elog... but I am not a package maintainer.
I compiled elog from source and it brings the necessary files with it.

Best wishes,
Sebastian

Hello,

I noticed the wikipedia article of the ELOG got deleted in November 2021.
With the reason: "Poorly sourced article, and I was not able to find good sources myself."

I could access the old article through web.archive.org, but for the project it would be good, if the article got revived.

I have requested an undeletion of the article. The article was deleted  "PROD", which means that someone tagged it. And if noone removes the tag, it could be deleted.

I could revive the article. So in the future, One should have an eye on it and maybe update the current version of the software.

If there iy an paper on the elog, maybe it could be cited for more creditability.