Hi Stefan,

Must have missed it when the fixed/not fixed thread marking got implimented.

Anyhow, my main point would still apply for where the thread is not yet fixed, but is in one of a number of possible
states  (waiting, panic, work-in-progress....).  Clearly you can label the latest entry in a thread with the latest
status, and icon, but when in collapsed mode, you only see the initial entry.  If the latest entry were shown
(optionally), then one can tell at a glance in the collapsed listings which entry may need direct attention.



> > In the past I have requested the "mark whole thread" feature, not yet implimented.
> 
> That's not correct, it is implemented. Just add an attribute for that. Assume you have problem reports, so you 
> add
> 
> Attributes = ..., Fixed
> Options Fixed = boolean
> Quick filter = Fixed
> 
> If you add a new entry, "Fixed" is false by default. All replies to that entry will contain then the same flag. 
> Now if you want to mark the whole thread as fixed, do the following:
> 
> - go into list display
> - display all entries in threaded mode
> - click on "Select"
> - select the thread you want to mark as fixed and click "Edit"
> - now keep all attributes, but check the "Fixed" check box
> 
> and voila, the whole thread will contain "Fixed = 1". Using the quick filter, you can now show all fixed threads 
> with one click.

Hi Stefan,

When Moving entry (and replies) from one log book to another, is it possible to prevent elog from renumbering
the entries' ID number(s) ($@MID@$).  While it may not be good practice, we've referred to these numbers in
cross-referencing, and it all goes wrong when an entry is moved from an "Open" thread to a "Closed" thread (cf
your FAQ about marking of whole threads).

In the cases I'm thinking about, i.e. from main logbook to archive logbook(s), there would never be a clash of
ID number.

Thanks,

David Pilgram.

Hi Stefan,

Any possibility on this one?

David Pilgram.
> Hi Stefan,
> 
> When Moving entry (and replies) from one log book to another, is it possible to prevent elog from renumbering
> the entries' ID number(s) ($@MID@$).  While it may not be good practice, we've referred to these numbers in
> cross-referencing, and it all goes wrong when an entry is moved from an "Open" thread to a "Closed" thread (cf
> your FAQ about marking of whole threads).
> 
> In the cases I'm thinking about, i.e. from main logbook to archive logbook(s), there would never be a clash of
> ID number.
> 
> Thanks,
> 
> David Pilgram.

Thanks Stefan,  Downloading shortly and I'll let you know ;-)
> > Hi Stefan,
> > 
> > When Moving entry (and replies) from one log book to another, is it possible to prevent elog from renumbering
> > the entries' ID number(s) ($@MID@$).  While it may not be good practice, we've referred to these numbers in
> > cross-referencing, and it all goes wrong when an entry is moved from an "Open" thread to a "Closed" thread (cf
> > your FAQ about marking of whole threads).
> > 
> > In the cases I'm thinking about, i.e. from main logbook to archive logbook(s), there would never be a clash of
> > ID number.
> > 
> > Thanks,
> > 
> > David Pilgram.
> 
> I have implemented this feature in revision 2205. You need to set the new flag "Preserve IDs = 1" in the 
> configuration. I have not tested this extensively, but I'm sure you will do it ;-)

Hi Stefan,

I've been slowly moving threads, and twice now so far (and reproducably) had elog crash.

In each case, it is trying to move a thread with more than 24 entries; it copies the first 24 entries, then
crashes with "Segmentation Fault".  It does not erase the lock file /var/run/elog.pid

I have got around this by manually copying the entries beyond no 24, then deleting the thread entry by entry.

I am aware that I have an old and limited machine (586, 256MB RAM, running Slack 10), and at first I was
"content" to write it off as that; but when it crashed for the second time at exactly the same entry (the
twenty-forth) even though the size of the entries would have been significantly different, I wondered if there
was some factor within  elog that could affect this.

I've not tried it with Copy to:, but imagine it will also be affected as the only difference with this and Move
to: is the deletion of the thread after all the entries had been copied.

> > Hi Stefan,
> > 
> > I've been slowly moving threads, and twice now so far (and reproducably) had elog crash.
> > 
> > In each case, it is trying to move a thread with more than 24 entries; it copies the first 24 entries, then
> > crashes with "Segmentation Fault".  It does not erase the lock file /var/run/elog.pid
> > 
> > I have got around this by manually copying the entries beyond no 24, then deleting the thread entry by entry.
> > 
> > I am aware that I have an old and limited machine (586, 256MB RAM, running Slack 10), and at first I was
> > "content" to write it off as that; but when it crashed for the second time at exactly the same entry (the
> > twenty-forth) even though the size of the entries would have been significantly different, I wondered if there
> > was some factor within  elog that could affect this.
> > 
> > I've not tried it with Copy to:, but imagine it will also be affected as the only difference with this and Move
> > to: is the deletion of the thread after all the entries had been copied.
> 
> This rings a bell: it's probably related to some internal stack overflow, since the entries are copied 
> recursively. I have an idea on how to fix that, but I need time for that.
Thanks Stefan,  I'll be keeping an eye out on any annoucement about this one!

Hi Stefan,

I don't know if anyone else would be interested or need this...

If you have an Roption, and it is not required (maybe...) or have a preset attribute, it is possible to make an
entry and have replies without any of the attributes in that Roption being selected.

However, once an attribute in that Roption has been selected, it is not possible to go back (editing) to the
condition before one was selected on that entry (so far as I can tell).  

Is a way of cancelling all the possible attributes in an Roption practical?  Would others want it?  It is
possible with options, as there is a "please select" which can be used to cancel whichever attribute in the
option that has been selected.

Regards,  David

> > Hi Stefan,
> > 
> > I don't know if anyone else would be interested or need this...
> > 
> > If you have an Roption, and it is not required (maybe...) or have a preset attribute, it is possible to make an
> > entry and have replies without any of the attributes in that Roption being selected.
> > 
> > However, once an attribute in that Roption has been selected, it is not possible to go back (editing) to the
> > condition before one was selected on that entry (so far as I can tell).  
> > 
> > Is a way of cancelling all the possible attributes in an Roption practical?  Would others want it?  It is
> > possible with options, as there is a "please select" which can be used to cancel whichever attribute in the
> > option that has been selected.
> > 
> > Regards,  David
> 
> The easiest to achieve this is to define another option. Assume you have the three options
> 
> One, Two, Three
> 
> and you want to "unselect" them. So just add a fourth option like
> 
> Unspecified, One, Two, Three
> 
> so if you do not want any of the "One, Two, Three", just click on "Unspecified" and you get what you want.

This is sort of what I do now, I just wondered if there was a way of clearing that would leave the field completely
blank in the YYMMDDa.log file.

Thanks.