In order to avoid having to remember multiple usernames/passwords for
different systems, is it possible for ELOG to use external authentication
via Active Directory, etc?

Thanks,
Steve

'Date' attributes can only be between 1970 and 2037, since I use internally the
unix time format. I added a test so future versions will complain and not crash
when the date is outside that range.

If you need dates before 1970, don't use the 'Date' format, simply use strings.

God really STRANGE and problematic effect on 2.5.5-1 (can't remember it this
was with 2.5.5 or 2.5.4-X but i'm nearly sure it worked well):

Entering a date (Formate Bithday = date) may crash down the server:
Value is 22.2.2004: Everything is well
Value is 22.2.1962: Server crashes emmediatly (menas restarzing several
times, always the same problem)

I do not have time to check true all the years for finding out where the
problem may beginn, sorry. Also I was not able to check on other systems
right now. My system: Win XP Pro SP 1, IE 6 as well as Mozilla Calssic 1.7.3. 

Didn't check it under Linux right know in case of a lot work.

Clould you this fix please Stefan???  THANK'X!!!

God really STRANGE and problematic effect on 2.5.5-1 (can't remember it this
was with 2.5.5 or 2.5.4-X but i'm nearly sure it worked well):

Entering a date (Formate Bithday = date) may crash down the server:
Value is 22.2.2004: Everything is well
Value is 22.2.1962: Server crashes emmediatly (menas restarzing several
times, always the same problem)

I do not have time to check true all the years for finding out where the
problem may beginn, sorry. Also I was not able to check on other systems
right now. My system: Win XP Pro SP 1, IE 6 as well as Mozilla Calssic 1.7.3. 

Didn't check it under Linux right know in case of a lot work.

Clould you this fix please Stefan???  THANK'X!!!

Could you implement a 'hide attribute' and 'sort attribute' config option?
While sort is probably not so easy to do the hide option would already 
be very useful.  What I want to do is to use elog to collect bibtex entries
which are then used to generate a bibtex file.  So, e.g. if the entry 
type 'Article' is selected I would like that all fields that do not make
sense are hidden.  Currently I just lock them.  The config looks like
this:

Attributes                  = Login, Bibtex Key, Entry Type, Address,
Annote, Author, Booktitle, Chapter, Crossref, Edition, Editor, Howpublished,
Institution, Journal, Key, Month, Note, Number, Organization, Pages,
Publisher, School, Series, Title, Type, Volume, Year, URL, Short Comment
Options Entry Type          = Article{1}, Book{2}, Booklet{3}, InBook{4},
InCollection{5}, InProceedings{6}, Manual{7}, MastersThesis{8}, Misc{9},
PhDThesis{a}, Proceedings{b}, TechReport{c}, Unpublished{d}
Required Attributes         = Entry Type
; ARTICLE
{1} Comment Author          = [required]
{1} Comment Journal         = [required]
{1} Comment Title           = [required]
{1} Comment Year            = [required]
{1} Locked Attributes       = Address, Annote, Booktitle, Chapter, Crossref,
Edition, Editor, Howpublished, Institution, Key, Organization, Publisher,
School, Series, Type


Instead of Locking the attributes, hiding them altogether would make the
entry form look much nicer.  
A further improvement would be to sort the attributes, e.g. for author I
would sort the like this, i.e. the more important entries first:

{1} Sort Attributes    = Author, Title, Journal, Volume, Pages, Year, Month,
Number, Note

Attributes not mentioned in the sort line could then be displayed 
in any order. 

there is a guide on the contributions logbook at

elog:Contributions/11

for securing Elog using SSL and Apache.

> Display Subsystem = <a href="/LogBook1/?Subsystem=$Subsystem" style="color:
> saddlebrown">$Subsystem</a>
> 
> ABC and DEF links would perform filter searches of a _different_ logbook.   
> 
> MOptions does not work because the options are not fixed.   The options can be any
> numeric ID for items in a related logbook.
> 
> Consider the case of two logbooks, where we wish to associate items in the second
> logbook with more than one item in the first logbook.  We could define separate
> attributes for each "parent item", e.g. Parent1, Parent2, Parent3, then use a
> "Display" spec to convert a numeric ID into a hyperlink to the first logbook's item.
>   The exact relationship is not important, could be parent/peer/child - some generic
> relationship.
> 
> The benefit here would be the same as having separate links for MOptions attribute
> values.

Ah, now I'm getting your point. You want kind of relational database where a logbook
correspond to a table, using the entry ID as primary key. Well, elog was not designed
having that in mind, so its capabilities will always be very limited. A MySQL with
phpMyAdmin might be better for that.

But what you could do is to put manual links betweek logbooks. If you enter in an
attribute following text:

elog:Forum/816 elog:Forum/806

then you get two links to entries 806 and 816. Writing this is a bit more than just 
"816 | 806", but it's less than writing directly an HTML link.

> > After THREE tries to enter a long detailed list of questions, all have been 
> > replaced by just one:  why do ELOG textareas and entry forms lose all data 
> > if the browser goes back/forward?  Or if a submission causes an error?  
> > Other forms in other applications don't have this kind of data loss.
> > 
> > Submitting this now before I lose it again.  Will submit rest of questions 
> > as separate entries.
> 
> Really strange. I tried with Mozilla Firefox and IE 6.0 and none of them lost
> the entry data. What browser did you use? As far as I learned, data only
> vanishes on pages which have an HTTP header containing "Expires: ..." with a
> date in the past. But I made sure that the entry form does not contain this.

IE 6.0.   

I am accessing an internal ELOG instance through an Apache reverse proxy on port
80, per the FAQ.  Just tested without the proxy and there is no data loss problem
with back/forward.  

When I access the ELOG forum, I am going through a forward proxy to the Internet,
which probably explains the data loss on error messages.

Will investigate proxy configuration regarding "Expires: " headers and post here
if I find a solution.

> Please refreain in the future from sending many small entries. People being
> registered with email notifications on the forum get flooded by notifications.
> In worst case, write your posting using an editor and do copy-and-paste into a
> single posting.

Sorry about that, will do.