ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
69419
|
Mon Nov 22 00:44:21 2021 |
| Harry Martin | harrymartin772@gmail.com | Question | Linux | 3.1.2 | Re: Body of new messages not getting saved when submitted | Thank you for your quick response, Sebastion. The new version of ckeditor is 4.5.7 -- is this version compatible with elog 3.1.2? It is possible that I am using an outdated elog or outdated ckeditor due to the fact that this server is a bit old; I am looking to upgrade this machine soon, but I have several other issues to resolve first.
Sebastian Schenk wrote: |
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
Harry Martin wrote: |
I've been using elog for a few years now. I've had the current setup working for me up until today.
If I create a new message (entry, whatever they are called), or if I attempt to update an existing message, only the header information is saved. The body (the part I can see in the editor) does not get saved.
Yesterday, I did do some updates on the server machine. Among them was an update to apache2, but I am not using apache2 (I can disable apache2, and elogd continues serving elog on client machines). Also updated were several python3 packages; I ran into a compatibility problem with python3 with a different package, so I wonder if that could have some impact for elog also. About 50 packages were updated altogether.
Here are the packages that were updated yesterday (in case this is of interest to solving the issue):
[...]
This is a devuan ascii server only for clients on a local area network.
|
|
|
69420
|
Mon Nov 22 19:28:28 2021 |
| Harry Martin | harrymartin772@gmail.com | Question | Linux | 3.1.2 | Re: Body of new messages not getting saved when submitted | (disregard my recent post here about missing package -- that wasn't the elog server!)
I can see that ckeditor was upgraded 11/19, which is would be prior to my recent attempts to use elog. It was apparently a security update, so I am not sure it is sensible to downgrade. OTOH, I am the only person here, and I have all sides carefully barracaded, so I don't think it would be much of an issue. But please disabuse me of my ignorance if need be.
Harry Martin wrote: |
Thank you for your quick response, Sebastion. The new version of ckeditor is 4.5.7 -- is this version compatible with elog 3.1.2? It is possible that I am using an outdated elog or outdated ckeditor due to the fact that this server is a bit old; I am looking to upgrade this machine soon, but I have several other issues to resolve first.
Sebastian Schenk wrote: |
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
Harry Martin wrote: |
I've been using elog for a few years now. I've had the current setup working for me up until today.
If I create a new message (entry, whatever they are called), or if I attempt to update an existing message, only the header information is saved. The body (the part I can see in the editor) does not get saved.
Yesterday, I did do some updates on the server machine. Among them was an update to apache2, but I am not using apache2 (I can disable apache2, and elogd continues serving elog on client machines). Also updated were several python3 packages; I ran into a compatibility problem with python3 with a different package, so I wonder if that could have some impact for elog also. About 50 packages were updated altogether.
Here are the packages that were updated yesterday (in case this is of interest to solving the issue):
[...]
This is a devuan ascii server only for clients on a local area network.
|
|
|
|
69421
|
Mon Nov 22 19:45:08 2021 |
| Harry Martin | harrymartin772@gmail.com | Question | Linux | 3.1.2 | Re: Body of new messages not getting saved when submitted | After downgrading ckeditor, my elog installation is working again. Thanks for your help.
Harry Martin wrote: |
(disregard my recent post here about missing package -- that wasn't the elog server!)
I can see that ckeditor was upgraded 11/19, which is would be prior to my recent attempts to use elog. It was apparently a security update, so I am not sure it is sensible to downgrade. OTOH, I am the only person here, and I have all sides carefully barracaded, so I don't think it would be much of an issue. But please disabuse me of my ignorance if need be.
Harry Martin wrote: |
Thank you for your quick response, Sebastion. The new version of ckeditor is 4.5.7 -- is this version compatible with elog 3.1.2? It is possible that I am using an outdated elog or outdated ckeditor due to the fact that this server is a bit old; I am looking to upgrade this machine soon, but I have several other issues to resolve first.
Sebastian Schenk wrote: |
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
Harry Martin wrote: |
I've been using elog for a few years now. I've had the current setup working for me up until today.
If I create a new message (entry, whatever they are called), or if I attempt to update an existing message, only the header information is saved. The body (the part I can see in the editor) does not get saved.
Yesterday, I did do some updates on the server machine. Among them was an update to apache2, but I am not using apache2 (I can disable apache2, and elogd continues serving elog on client machines). Also updated were several python3 packages; I ran into a compatibility problem with python3 with a different package, so I wonder if that could have some impact for elog also. About 50 packages were updated altogether.
Here are the packages that were updated yesterday (in case this is of interest to solving the issue):
[...]
This is a devuan ascii server only for clients on a local area network.
|
|
|
|
|
69866
|
Thu Mar 20 07:34:24 2025 |
| Harry Martin | harrymartin772@gmail.com | Bug report | Linux | 3.1.5 | 3-level conditional not working | Not sure if this is a bug or not; if it is not, kindly reclassify the category.
Following is a small example of what I will dub a 3-level, conditional logbook:
[cond_test]
attributes = region, manufacturer, model
show attributes edit = region
options region = american{1}, japanese{2}, european{3}
{1} options manufacturer = ford, chrysler, gm
{2} options manufacturer = toyota{4}, nissan{5}, mitsubishi{6}
{3} options manufacturer = audi, mercedes, bmw, volvo, fiat
{1,2,3} show attributes edit = region, manufacturer
{4} options model = corolla, prius, miata
{5} options model = sentra, murano
{6} options model = starion, outlander, mirage
{4,5,6} show attributes edit = region, manufacturer, model
This example is hardly complete, but it is sufficient to demonstrate the issue I am running into. This works until I select from the 2nd level (manufacturer); it won't display the dropdown for the model (I think my show attribute edit is supposed to display that). Is there a restriction on how many levels of conditional I can have? If there is, it would be disappointing because I am trying to do something similar to this example.
I hope there is something very simple I can do to correct this, or perhaps a completely different approach that accomplishes the same thing. I'd like to stick with the multi-level selection process as I have done here.
I am running elog 3.1.5 on Devuan Chimaera (approx. Debian Bullseye, sans systemd) in a Virtualbox VM. |
69879
|
Wed Jun 18 01:20:47 2025 |
| Harry Martin | harrymartin772@gmail.com | Bug report | Linux | 3.1.5 | passing %s to $shell interpreted differently in preset vs preset on reply | I am finding that '%s' passed to a $shell(...) command must be escaped when calling from Preset on reply, but not when calling Preset new. Example:
[tickler]
Comment = Automated Tickler List Experiment
Attributes = Blurb, TickleDate
Type TickleDate = date
Required Attributes = Blurb
Preset TickleDate = $shell(date -d 'now + 30 days' '+%s')
Preset on reply TickleDate = $shell(date -d 'now + 30 days' '+%%s')
Date Format = %Y-%m-%d
Note that I have to escape the Preset on Reply's shell command argument with double percent signs, but not on Preset new. The configuration I have provided here does work and correctly overrides the output per the Date Format spec. This scenario should be easy to reproduce.
It could be I am doing something incorrectly, but it seems to me that there is no reason why the calls should need to be handled differently. I can live with this for the moment, but I do hope it is fixed in a later release so that $shell calls have consistent syntax and semantics.
|
69880
|
Thu Jul 17 23:43:25 2025 |
| Harry Martin | harrymartin772@gmail.com | Bug report | Linux | 3.1.5 | collapse does not seem to work as expected | When I click on "collapse," even several times, I still see all the replies in each thread rather than just one entry representing each entire thread.
I am running elogd 3.1.5 on devuan chimaera (bullseye) which I built from source. I had the same results with 3.1.4 and 3.1.3.
I tried to disable the quick filter just to see if that impacted the behavior, but it didn't.
If there are any other tests I can use to narrow the problem, please suggest them. Without a working collapse feature, I cannot get a quick birdseye view of, say, all open threads. |
69882
|
Fri Jul 18 22:42:02 2025 |
| Harry Martin | harrymartin772@gmail.com | Bug report | Linux | 3.1.5 | Re: collapse does not seem to work as expected | I should add that this does not happen in every logbook. I'm looking into what the distinction is that causes this in certain logbooks and not in others.
Harry Martin wrote: |
When I click on "collapse," even several times, I still see all the replies in each thread rather than just one entry representing each entire thread.
I am running elogd 3.1.5 on devuan chimaera (bullseye) which I built from source. I had the same results with 3.1.4 and 3.1.3.
I tried to disable the quick filter just to see if that impacted the behavior, but it didn't.
If there are any other tests I can use to narrow the problem, please suggest them. Without a working collapse feature, I cannot get a quick birdseye view of, say, all open threads.
|
|
69883
|
Fri Jul 18 23:10:33 2025 |
| Harry Martin | harrymartin772@gmail.com | Bug report | Linux | 3.1.5 | Re: collapse does not seem to work as expected | Figured it out: I had "Sort Attributes" set on the logbooks that were failing to collapse correctly. At least, I think that is the distinction.
I think I can live with "Sort Attributes" disabled; I don't recall why I chose to set the "Sort Attributes" in the first place. But I still think this is an issue.
Harry Martin wrote: |
I should add that this does not happen in every logbook. I'm looking into what the distinction is that causes this in certain logbooks and not in others.
Harry Martin wrote: |
When I click on "collapse," even several times, I still see all the replies in each thread rather than just one entry representing each entire thread.
I am running elogd 3.1.5 on devuan chimaera (bullseye) which I built from source. I had the same results with 3.1.4 and 3.1.3.
I tried to disable the quick filter just to see if that impacted the behavior, but it didn't.
If there are any other tests I can use to narrow the problem, please suggest them. Without a working collapse feature, I cannot get a quick birdseye view of, say, all open threads.
|
|
|
|