> Seriously, I really hope It could make it... Could you try it on your side ?

My personal opinion here is, that if you want others to investigate your problems, then the best way to do it is like that:
- attach a minimal configuration that reproduces your problem (never attach a 100 line configuration, unless you've tested that the problem disappears
regardless of which line you remove!);
- attach the entry data, if the behaviour depends on the data;
- use a specific, to the point subject line;
- explain what you did, what happened and what you would have expected to happen;
- ask kindly; and then
- wait and hope for the best ;-)

(This is actually a very general procedure; I think it is applicable to all newsgroups, forums, etc.)

BTW: This tip was absolutely free of charge ;-)

>  
> > Seriously, I really hope It could make it... Could you try it on your side ?
> 
> My personal opinion here is, that if you want others to investigate your problems, then the best way to do it is like that:
> - attach a minimal configuration that reproduces your problem (never attach a 100 line configuration, unless you've tested that the problem disappears
> regardless of which line you remove!);
> - attach the entry data, if the behaviour depends on the data;
> - use a specific, to the point subject line;
> - explain what you did, what happened and what you would have expected to happen;
> - ask kindly; and then
> - wait and hope for the best ;-)
> 
> (This is actually a very general procedure; I think it is applicable to all newsgroups, forums, etc.)
> 
> BTW: This tip was absolutely free of charge ;-)

Andreas,
Thanks for your comments. Thats why I posted in the first msg my configuration details... I just hope there can be a solution :)
I saw in the doc that an attribute cant be bigger than 100 char. but I couldn't figure the maximum size for options...  I'm wondering if the issue comes from the browser not refreshing correctly or if its elog..
Again, I tought that if that was from elog limitations, the attributes wouldn't load the options presets at all... but they do, (attribute volume) ... just not all the time :)

I understand that you are proactive on this forum and eventually I was thinking of contributing with detailed specific config examples but for now I just would like to get on track :) 
The last time I used Elog was 10 years ago :) it changed alot since :)

elogd is spewing these messages about unknown cookies:

Received unknown cookie "is_returning"
Received unknown cookie "__utma"
Received unknown cookie "__utmz"
Received unknown cookie "SSESSee3cc9c70bedf9a840203765bf409d7b"
Received unknown cookie "SESSee3cc9c70bedf9a840203765bf409d7b"
Received unknown cookie "MidasWikiUserID"
Received unknown cookie "MidasWikiUserName"
Received unknown cookie "MidasWiki_session"

K.O.

Converting from elog 2.9.something to new elog 3.1.0 elogd refuses to start, instructs running elconv in one logbook.

When I do so, elconv converts a existing mhttpd-style elog entries to the new format (the corresponding new-format entries already exist)
and deletes everything else - this is very bad.

So there are 2 bugs:
- elogd should not tell us to run elconv when both old-style and corresponding new-style elog entries exist
- elconv should not delete all existing new-style elog entries.

I confirm that elconv *does* delete all new-style elog entries - with strace, I see it issue "unlink" on every elog entry.

What a disaster!

K.O.

this elog gives errors sending mail through PSI email server. (did not capture the error messages, sorry). K.O.

this elog offers me to edit a draft message, then yells at me "only some other user can edit this draft!!!".
methinks I should only be offered to edit draft messages that I own or I can edit. K.O.

elogd 3.1.0 moves all elog entries into year-named subdirectories. this feature makes it incompatible with older elogs and so should be clearly mentioned in the documentation,
in the release announcement and in the release and migration notes. K.O.

> elogd 3.1.0 moves all elog entries into year-named subdirectories. this feature makes it incompatible with older elogs and so should be clearly mentioned in the documentation,
> in the release announcement and in the release and migration notes. K.O.

That feature is one of the main reasons why the version jumped from 2.x to 3.x. 
A free tip: changes in major revisions do indicate some kind of incompatibility.
But yes, the release documentation by bitbucket is not really that useful: 
it is difficult for me too, to find out what changed with new releases. 
I have to admit here, that I haven't read any GIT tutorial yet.
By the way: you are welcome to contribute to the release documentation!

On your actual problem: to go back to a former version of ELOG you can simply
- stop elogd 3.X, 
- move all entries from the sub-directories one level up, and 
- start the 2.X version of elogd.

I wouldn't really call this an "incompatibility", would you? 
At least you can easily go back without much trouble.

Cheers
Andreas