I would like to have different header for 'Text' internal attribute: e.g. an alias "Notes". So on the list page header of Text attribute column is Notes.

Is it already possible? I couldn't find it in Administrator's Guide. 

If not is it possible to add this feature?

This functionality was not implemented. I added it in SVN revision #2420, so it will be contained in the next release.

Dear all,

I wonder if anyone of you already tried to  change raw style in case of empty attribute value.

In my configuration file I have defined attribute "End date" (without quotation marks) and it's type is datetime.

How should I configure extra style for entries where this attribute doesn't have value.

My tries were:

Style End date = background-color:red

Style End date "" = background-color:red

Style End date " " = background-color:red

Style End date - = background-color:red

But they didn't work.

Any ideas?

Is it possible to have an attachment to an entry in a different directory to the working directory of the logbook being used?

By which I mean, if you have in logbook hidden the attachment files

../logbooks/hidden/110705_235520_whatthis-0.png
../logbooks/hidden/110705_235520_whatthis.pdf

that an entry in another logbook, public, can use the entries in hidden to show them (and do everything that you can do with an attachment)
without making another copy in public?

I see that if, working in public, you attach the .pdf file in hidden, the files get copied across as

../logbooks/public/110705_235520_whatthis-0.png
../logbooks/public/110705_235520_whatthis.pdf

that is, with the original (hidden) timestamp, and no second time stamp superimposed.  From which you can gather I've been playing around, manually editing a yymmdda.log file to try and get the result I want, even if for the moment it cannot be done via elog; but without success, although there were some bizarre interpretations by the elog program of the edited yymmdda.log file, depending upon what I tried.

For one entry, it is of course no big deal, copying the files into the public directory, but if you are dealing with multiple huge entries, it does seem wasteful of HD space

But my reason for this is that hidden has restricted access, whereas public has general access.  The attachments themselves are not restricted, but comments, history etc around them in the restricted access logbook should not become available to the general viewer.

Soren, you're not alone!  I've had similar problems, as did Sara Vanini (elog:67077).

In my case, it is because the "move" or "copy" function does not move all the messages in very long threads.   To be more precise, elog will crash in the attempt to move a long thread - say over 40 replies, I don't know for sure.  Sometimes it has already moved the entire thread before it crashes, sometimes not.  I'd not flagged it up as an issue because I could not be sure it was not a memory issue with the old (>12 years) linux box I was using earlier this year, but it still happens on this new (to me, only 3 years old) linux box.

Whether it is the number of entries, the total memory size of the thread or some combination, I don't know.

I've found that in the "move" case, it has not deleted all the messages from the donor thread, so that there is a semi-thread still hidden there.  Should one by chance select that semi-thread, (because it is found during a search) elog goes into infinate loop, which requires a reboot of this linux box to fix.   Certainly the pinning down the issue to the missing entry referenced by an <i>In reply to:</i> explains this part of the issue.  Of course, deletion of one entry within a thread, or other adjustments will do the same thing, just as you (Soren) point out above.

If it happens to me, I will go in to the yymmdda.log files and fix the problem, be it deleting the entries of the semi-thread, moving across missing entries from the donor to the acceptor logbooks, adjusting the <i>Reply:</i> and <i>In reply to:</i> lines, but that is quite a time consuming and error prone exercise.

 It would be nice to have this corrected. The problem occurs when you select (read) a message which refers to another message via "In-reply-to", and this message does not exist.

Soren