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. 

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.

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.

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.

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.

I also notice that collapse does not work properly if I have anything selected in the quick filter.

Tried a variant, this time for NEW entries (not EDIT), which I meant to do to begin with; sorry if that was confusing. 

Hi,

I am having trouble modifying the elog client to allow larger attachment.  I
have elogd configure for attchment sizes of 10Meg and I would like the
option to be able to use the elog client.  Can anyone give me key points as
to how to go about doing this?  I have tried but I must be missing something.

Also, as a suggestion, it might make sense to add a MAX_ATTACHMENT_SIZE def
in a common header file.

Thanks
Kevin