3-level conditional not working, posted by Harry Martin on Thu Mar 20 07:34:24 2025
|
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. |
Re: 3-level conditional not working, posted by Harry Martin on Sun Jul 20 23:20:02 2025
|
Tried a variant, this time for NEW entries (not EDIT), which I meant to do to begin with; sorry if that was confusing.
[cond_test]
attributes = region, manufacturer, model
options region = american{us}, japanese{jp}, european{eu}
show attributes = region
{us} options manufacturer = ford, chrysler, gm
{jp} options manufacturer = toyota{toy}, nissan{nis}, mitsubishi{mit}
{eu} options manufacturer = audi, mercedes, bmw, volvo, fiat
{us} show attributes = region, manufacturer
{jp} show attributes = region, manufacturer
{eu} show attributes = region, manufacturer
{toy} options model = corolla, prius, miata
{nis} options model = sentra, murano
{mit} options model = starion, outlander, mirage
{toy,nis,mit} show attributes = region, manufacturer, model
I'm not sure if my multi-character conditional names are allowed or not, but they do seem to work... somewhat. Note that I even tried a couple different ways of specifying which attributes to show (single versus multiple OR conditionals). The problem now is that all of the attributes are always shown, seeming to ignore the conditionals entirely.
Harry Martin wrote: |
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.
|
|
collapse does not seem to work as expected, posted by Harry Martin on Thu Jul 17 23:43:25 2025
|
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. |
Re: collapse does not seem to work as expected, posted by Harry Martin on Fri Jul 18 22:42:02 2025
|
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.
|
|
Re: collapse does not seem to work as expected, posted by Harry Martin on Fri Jul 18 23:10:33 2025
|
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.
|
|
|
Re: collapse does not seem to work as expected, posted by Harry Martin on Sat Jul 19 00:02:45 2025
|
I also notice that collapse does not work properly if I have anything selected in the quick filter.
Harry Martin wrote: |
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.
|
|
|
|
once a week we are having elogd segault?, posted by mathew goebel on Fri Jul 18 17:46:43 2025
|
Jul 17 20:36:21 elog kernel: elogd[179095]: segfault at 7ffda4d82000 ip 00007f97033a1406 sp 00007ffda4d58c38 error 6 in libc-2.28.so[7f9703374000+1cd000]
Elog version ELOG V3.1.5-30ada1df
Running on a Rehdat 8 enterprise server
compiled with a Makefile change :: change -Wno-unused-result to -Wno-unused-value
Wondering if anyone has been seeing this? |
passing %s to $shell interpreted differently in preset vs preset on reply, posted by Harry Martin on Wed Jun 18 01:20:47 2025
|
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.
|
WYSIWYG Editor Not Showing in HTML Mode, posted by Pawel Nita on Mon May 5 11:39:17 2025
|
Hi all,
I'm experiencing an issue on Kubuntu 24.04 where the WYSIWYG editor (in HTML mode) doesn't appear at all. This happens across multiple browsers (tested with Firefox and Chromium). The editor area is simply blank, without any visible toolbar or editable content area.
Has anyone encountered this on Kubuntu or found a workaround? Any tips would be appreciated!
Thanks in advance,
Pawel |
Re: Custom input forms implementation , posted by Marcel Zauner-Wieczorek on Mon Apr 28 11:50:25 2025
|
Please excuse my double-posting. But my first entry was not displayed on the forum and I haven't received feedback yet. I think this is because I responded to an entry that was still in draft mode, whereas my entry was a "normal" entry. My initial entry has the Message ID: 69870 and was in reply to: 68348
***
Dear Andreas and Stefan,
First of all thank you for the template for a checklist. I have created my own version of it and the HTML looks fine. For comparison, I temporarily also included the shiftcheck template provided by Stefan to my ELOG.
However, I have the same problem as JD. After submitting the data in shiftcheck, I receive the error "Cannot open file passwords.pwd: No such file or directory" and the URL is http://localhost:8085/ShiftCheck/?cmd=Submit&suppress=1&unm=&upwd=&Author=Marcel+Zauner-Wieczorek&edit_id=&D=1&M=4&Shift=Morning&a4=&h2=&a5=&a6=&c1=&c2=&c3=&c4=&c5=&bb1=&cr1=&cr9=&cr18=&cr20=&cr21=&cr23=&cr24="
I have tried to include the path of the password file in the cfg file (using "", <>, <"">, and only the path name), but then the elogd.exe won't start at all unless I change it back to the simple "Password file = passwords.pwd".
Here is an excerpt of my config file:
****
[global]
port = 8085
Password file = passwords.pwd
Login expiration = 1
Admin user = Marcel
Login user = Marcel
Self register = 1
Group General = ShiftCheck
Group Gas phase instruments = Checklist_MARGA
Restrict edit time = 1
Admin restrict edit time = 0
Autosave = 60
[ShiftCheck]
Comment = Shift Check List
Attributes = Author, D, M, Y, Shift, a1, a2, a3, a4, a5, h1, h2, h3, h4, h5, c1, c2, c3, c4, c5, c6, c7, bb1, cr1, cr2, cr3, cr4, cr5, cr6, cr7, cr8, cr9, cr10, cr11, cr12, cr13, cr14, cr15, cr16, cr17, cr18, cr19, cr20, cr21, cr22, cr23, cr24, cr25, cr26, sw1, sw2, sw3, sw4, sw5
Quick filter = Shift, Author
Options Shift = Morning, Evening, Night
Enable attachments = 0
Show text = 0
Custom new form = shiftcheck.html
Custom edit form = shiftcheck.html
Custom display form = shiftcheck.html
List after submit = 1
[Checklist_MARGA]
Comment = Check List for MARGA
Date Format = %d.%m.%Y
Time Format = %d.%m.%Y %H:%M:%S
Reverse sort = 1
Attributes = Author, D, M, Y, On, DP2h, T_SJAC, T_heat, EC_An, EC_Cat, IonBal, IS_Cat_Ae, IS_An_Ae, IS_Cat_Ga, IS_An_Ga, P1, P2, Err, Com
Quick filter = Author
Enable attachments = 0
Show text = 0
Custom new form = checklist_MARGA.html
Custom edit form = checklist_MARGA.html
Custom display form = checklist_MARGA.html
List after submit = 1
***
I am actually confused about the passwords.pwd file. I have successfully created several users with passwords and I can use their credentials to log into the different labbooks. However, none of these users (let along their (encrypted) passwords) turn up in the passwords.pwd file. I don't know where ELOG saves these information, but it's apparently not the passwords.pwd file that is defined in the cfg file and that I have access to.
I hope that someone can help me with this issue. Otherwise, I would omit the password function within ELOG and find an external solution for a password protection.
Cheers,
Marcel |
Segfault on elog-3.1.5-1 when uploading file., posted by gary holman on Thu Dec 12 18:45:49 2024
|
I am receiving a segfault whenever I attempt to upload a file. Please see attached .txt for valgrind output. This occurs in version elog-3.1.5-1. I reverted back to version elog-3.1.4-3 and the segfault does not occur.
Segfault occurs in Elog version: elog-3.1.5-1
System:
Virtualization: kvm
Operating System: Ubuntu 24.04.1 LTS
Kernel: Linux 6.8.0-49-generic
Architecture: x86-64
Hardware Vendor: QEMU
Hardware Model: Standard PC _Q35 + ICH9, 2009_
Firmware Version: 1.15.0-1
Firmware Date: Tue 2014-04-01
Firmware Age: 10y 8month 1w 5d
Valgrind command: valgrind -v --leak-check=full --track-origins=yes ./elogd -s /usr/local/elog -c /var/www/elog/he6/elogd.cfg -f /var/run/elog/he6.pid
Steps to reproduce:
1. Login elog
2. Create new logbook entry
3. Attachement 1: Select Browse
4. Select any file.
5. Select Upload |
Re: Segfault on elog-3.1.5-1 when uploading file., posted by gary holman on Thu Dec 12 19:01:39 2024
|
Looks like duplicate report to https://elog.psi.ch/elogs/Forum/69826
gary holman wrote: |
I am receiving a segfault whenever I attempt to upload a file. Please see attached .txt for valgrind output. This occurs in version elog-3.1.5-1. I reverted back to version elog-3.1.4-3 and the segfault does not occur.
Segfault occurs in Elog version: elog-3.1.5-1
System:
Virtualization: kvm
Operating System: Ubuntu 24.04.1 LTS
Kernel: Linux 6.8.0-49-generic
Architecture: x86-64
Hardware Vendor: QEMU
Hardware Model: Standard PC _Q35 + ICH9, 2009_
Firmware Version: 1.15.0-1
Firmware Date: Tue 2014-04-01
Firmware Age: 10y 8month 1w 5d
Valgrind command: valgrind -v --leak-check=full --track-origins=yes ./elogd -s /usr/local/elog -c /var/www/elog/he6/elogd.cfg -f /var/run/elog/he6.pid
Steps to reproduce:
1. Login elog
2. Create new logbook entry
3. Attachement 1: Select Browse
4. Select any file.
5. Select Upload
|
|
Re: Segfault on elog-3.1.5-1 when uploading file., posted by Stefan Ritt on Thu Dec 12 19:46:02 2024
|
A statement like "core dumped" does not help much. Same with valgrind memory leaks. I need a full strack trace with all parameters when the segment violation occurs. The easiest is when you run elogd vom inside gdb, and once you get the signal, do a "where" to see th full stack trace.
As you can see from this forum, there is absolutely no crash when you upload any file, so it must have to do with your config file or anything whcih is special in yoru environment. We have to find what this is so that I can reproduce it here.
Stefan |
Re: Segfault on elog-3.1.5-1 when uploading file., posted by gary holman on Thu Dec 12 20:29:40 2024
|
Thanks for further instructions here is full stack trace:
Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
warning: 44 ./nptl/pthread_kill.c: No such file or directory
(gdb) where
#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
#1 __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3 0x00007ffff764526e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4 0x00007ffff76288ff in __GI_abort () at ./stdlib/abort.c:79
#5 0x00007ffff76297b6 in __libc_message_impl (fmt=fmt@entry=0x7ffff77ce765 "*** %s ***: terminated\n") at ../sysdeps/posix/libc_fatal.c:132
#6 0x00007ffff7736c19 in __GI___fortify_fail (msg=msg@entry=0x7ffff77ce74c "buffer overflow detected") at ./debug/fortify_fail.c:24
#7 0x00007ffff77365d4 in __GI___chk_fail () at ./debug/chk_fail.c:28
#8 0x00007ffff7738019 in __strlcpy_chk (s1=<optimized out>, s2=<optimized out>, n=<optimized out>, s1len=<optimized out>) at ./debug/strlcpy_chk.c:28
#9 0x000055555557ac8a in strlcpy (__n=356, __src=0x89ab3c42edf52f00 <error: Cannot access memory at address 0x89ab3c42edf52f00>, __dest=0x7ffffffd5370 "agarcia") at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:156
#10 el_submit_attachment (lbs=lbs@entry=0x5555566873d8, afilename=afilename@entry=0x7ffffffd57e0 "pfSense-UDP4-1194-yuhaosun-config.ovpn",
buffer=buffer@entry=0x5555566bba67 "dev tun\npersist-tun\npersist-key\ndata-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC\ndata-ciphers-fallback AES-256-CBC\nauth SHA256\ntls-client\nclient\nresolv-retry infinite\nremote pfsense."...,
buffer_size=buffer_size@entry=5265, full_name=full_name@entry=0x7ffffffd58e0 "") at src/elogd.cxx:4547
#11 0x00005555555f91ea in decode_post (logbook=logbook@entry=0x7fffffffbff0 "He6", lbs=lbs@entry=0x5555566873d8, string=<optimized out>,
string@entry=0x5555566bb1c9 '-' <repeats 29 times>, "16417726823211458101306576170\r\nContent-Disposition: form-data; name=\"unm\"\r\n\r\ngholman\r\n", '-' <repeats 29 times>, "16417726823211458101306576170\r\nContent-Disposition: form"...,
boundary=boundary@entry=0x7fffffffbef0 '-' <repeats 27 times>, "16417726823211458101306576170", length=length@entry=7649) at src/elogd.cxx:28662
#12 0x00005555555fb5cc in process_http_request (
crequest=crequest@entry=0x555556656658 "POST /He6/ HTTP/1.0\r\nHost: xxx.xxx.xxx.xxx\r\nX-Real-IP: 192.168.101.2\r\nX-Forwarded-For: 192.168.101.2\r\nConnection: close\r\nContent-Length: 7649\r\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win6"...,
i_conn=i_conn@entry=0) at src/elogd.cxx:29317
#13 0x00005555555ffc68 in server_loop () at src/elogd.cxx:30302
#14 0x000055555555b1b9 in main (argc=<optimized out>, argv=<optimized out>) at src/elogd.cxx:31327
(gdb)
Stefan Ritt wrote: |
A statement like "core dumped" does not help much. Same with valgrind memory leaks. I need a full strack trace with all parameters when the segment violation occurs. The easiest is when you run elogd vom inside gdb, and once you get the signal, do a "where" to see th full stack trace.
As you can see from this forum, there is absolutely no crash when you upload any file, so it must have to do with your config file or anything whcih is special in yoru environment. We have to find what this is so that I can reproduce it here.
Stefan
|
|
Re: Segfault on elog-3.1.5-1 when uploading file., posted by Stefan Ritt on Fri Dec 13 15:11:08 2024
|
Thanks to your stack trace, I found a case where a string might get overwritten, but only if the attachment file name is longer than 256 chars. I fixed the code and made a new RPM:
https://www.dropbox.com/scl/fi/r37qx9aka5ytt3j7vn4km/elog-3.1.5-20241213.el8.x86_64.rpm?rlkey=knct99pdltggunrbmyr2hpfe5&st=pkre24aq&dl=0
Alternatively, you can compile from sources. Give it a try.
Stefan |
Re: Segfault on elog-3.1.5-1 when uploading file., posted by gary holman on Fri Dec 13 19:40:57 2024
|
Thanks Stefen!
I built from source (ELOG V3.1.5-3a5f2f00) and I confirmed as fixed.
Stefan Ritt wrote: |
Thanks to your stack trace, I found a case where a string might get overwritten, but only if the attachment file name is longer than 256 chars. I fixed the code and made a new RPM:
https://www.dropbox.com/scl/fi/r37qx9aka5ytt3j7vn4km/elog-3.1.5-20241213.el8.x86_64.rpm?rlkey=knct99pdltggunrbmyr2hpfe5&st=pkre24aq&dl=0
Alternatively, you can compile from sources. Give it a try.
Stefan
|
|
Re: Segfault on elog-3.1.5-1 when uploading file., posted by Evinrude Motor on Tue Jan 7 20:35:23 2025
|
When will the new source be in the standard download area ? I'm on ubuntu .
gary holman wrote: |
Thanks Stefen!
I built from source (ELOG V3.1.5-3a5f2f00) and I confirmed as fixed.
Stefan Ritt wrote: |
Thanks to your stack trace, I found a case where a string might get overwritten, but only if the attachment file name is longer than 256 chars. I fixed the code and made a new RPM:
https://www.dropbox.com/scl/fi/r37qx9aka5ytt3j7vn4km/elog-3.1.5-20241213.el8.x86_64.rpm?rlkey=knct99pdltggunrbmyr2hpfe5&st=pkre24aq&dl=0
Alternatively, you can compile from sources. Give it a try.
Stefan
|
|
|
Re: Segfault on elog-3.1.5-1 when uploading file., posted by Stefan Ritt on Tue Jan 7 20:41:13 2025
|
It is in the usual download area which is referenced at https://elog.psi.ch/elog/download.html
Stefan
Evinrude Motor wrote: |
When will the new source be in the standard download area ? I'm on ubuntu .
gary holman wrote: |
Thanks Stefen!
I built from source (ELOG V3.1.5-3a5f2f00) and I confirmed as fixed.
Stefan Ritt wrote: |
Thanks to your stack trace, I found a case where a string might get overwritten, but only if the attachment file name is longer than 256 chars. I fixed the code and made a new RPM:
https://www.dropbox.com/scl/fi/r37qx9aka5ytt3j7vn4km/elog-3.1.5-20241213.el8.x86_64.rpm?rlkey=knct99pdltggunrbmyr2hpfe5&st=pkre24aq&dl=0
Alternatively, you can compile from sources. Give it a try.
Stefan
|
|
|
|
Re: Segfault on elog-3.1.5-1 when uploading file., posted by Evinrude Motor on Sun Apr 13 13:56:05 2025
|
So this never made it into the download area ? elog-latest.tar is elog-3.1.5-1 and contains no files from 2024 or 2025 .
Thanks
Stefan Ritt wrote: |
It is in the usual download area which is referenced at https://elog.psi.ch/elog/download.html
Stefan
Evinrude Motor wrote: |
When will the new source be in the standard download area ? I'm on ubuntu .
gary holman wrote: |
Thanks Stefen!
I built from source (ELOG V3.1.5-3a5f2f00) and I confirmed as fixed.
Stefan Ritt wrote: |
Thanks to your stack trace, I found a case where a string might get overwritten, but only if the attachment file name is longer than 256 chars. I fixed the code and made a new RPM:
https://www.dropbox.com/scl/fi/r37qx9aka5ytt3j7vn4km/elog-3.1.5-20241213.el8.x86_64.rpm?rlkey=knct99pdltggunrbmyr2hpfe5&st=pkre24aq&dl=0
Alternatively, you can compile from sources. Give it a try.
Stefan
|
|
|
|
|
Re: Segfault on elog-3.1.5-1 when uploading file., posted by Stefan Ritt on Thu Apr 17 13:10:43 2025
|
I stopped making tar files, since most people building elog from sources just pull it from the bitbucket repository:
$ git clone https://bitbucket.org/ritt/elog --recursive
$ cd elog
$ mkdir build; cd build;
$ cmake ..; make
Evinrude Motor wrote: |
So this never made it into the download area ? elog-latest.tar is elog-3.1.5-1 and contains no files from 2024 or 2025 .
Thanks
Stefan Ritt wrote: |
It is in the usual download area which is referenced at https://elog.psi.ch/elog/download.html
Stefan
Evinrude Motor wrote: |
When will the new source be in the standard download area ? I'm on ubuntu .
gary holman wrote: |
Thanks Stefen!
I built from source (ELOG V3.1.5-3a5f2f00) and I confirmed as fixed.
Stefan Ritt wrote: |
Thanks to your stack trace, I found a case where a string might get overwritten, but only if the attachment file name is longer than 256 chars. I fixed the code and made a new RPM:
https://www.dropbox.com/scl/fi/r37qx9aka5ytt3j7vn4km/elog-3.1.5-20241213.el8.x86_64.rpm?rlkey=knct99pdltggunrbmyr2hpfe5&st=pkre24aq&dl=0
Alternatively, you can compile from sources. Give it a try.
Stefan
|
|
|
|
|
|
New elog from template should update the subdir, posted by Liam Gaffney on Wed Apr 2 13:01:34 2025
|
Hello. We are using explicity subdir names on our elog server to manage a large number of "Top groups" and sub "groups". When we create a new logbook from a template in the same group, it would be beneficial to automatically give a new subdir based on the previous one. At the very least, it should not reuse the same parameter as the template (see below).
At the moment, it copies the subdir parameter from the template logbook, which results in the new logbook writing to the same location as the template. That is very confusing and has the potential to be harmful as people can (and recently did) decide to delete these "duplicate" entries. But they are not duplicates, they are the exact same entries as the template logbook and deleting them removes them forever!
The way around this at the moment is to manually update the subdir after copying, but then the logbooks need to be re-indexed before the new logbook will display correctly. That requires a manual restart of the elogd process, which is less than ideal. |
|