Thanks Stefan, I'll try that. It's strange, though: At work, we're running 2.7.6 (and have used older versions in the past) and we have several logbooks with each at least one or two attributes with '?' and never had a problem with conditionals. Hence my surprise when this suddenly hit me with 2.8.1+ at home. Removing the '?' would be quite some work, as I'd have to change all logbooks and the associated data (the latter could probably be done with "rpl", I hope). I'll think about it.

That's actually a limitation of fckedit. It simply does not interprete any style sheets, that's why actually the elogd program hard-wires the colors etc. Sorry for that.  

; General settings
Menu commands = List, New, Edit, Duplicate, Delete, Reply, Select, Move to, Download, Find, Logout, Help, Config,Admin
List Menu commands = New, Select, Find, Logout, Help, Config, Admin, Import, Download
Date Format = %d/%m/%Y
List conditions = 1
List display = Edit, Type, Created, StatusA, StatusB, Archived, Test Text, Public?

; Attributes
Attributes = Type, Created, StatusA, StatusB, Archived, Test Text, Public?
Required Attributes = Type

; Attribute Types
Type Created = date
Type Archived = date

; Options & Tooltips
Options Type = Type1{0}, Type2{1}
Options StatusA = Status-A-red, Status-A-orange, Status-A
Options StatusB = Status-B-red, Status-B-orange, Status-B
Options Public? = yes,no

; Conditionals
{0}Show Attributes Edit = Type, Created, StatusA, StatusB, Archived, Test Text, Public?
{1}Show Attributes Edit = Type, Created, StatusA, Archived, Test Text, Public?

Your problem is the "?" in the attribute Public?.  Attributes may only contain ordinary characters. Unfortunately I did not document this so far. Therefore I put some fix in SVN revision 2387 which allows your attribute Public?, but I'm not 100% sure if this works in all places. The safest is just to remove the question mark.

You need to do two things:

1) Add you new icon to  <elog directory>\themes\default\icons

2) Refer to your new icon in the config file like

IOptions Icon = icon1.gif, icon2.gif, new_icon.gif

I just ran into an odd bug with conditional attributes: If I add a certain attribute to "Required Attributes", none of the conditionals will work anymore. I have tried to create a small logbook definition that will demonstrate the problem (the original logbook is more complex and uses two sets of conditionals, both of which will be disabled when the bug hits):

; General settings
Menu commands = List, New, Edit, Duplicate, Delete, Reply, Select, Move to, Download, Find, Logout, Help, Config,Admin
List Menu commands = New, Select, Find, Logout, Help, Config, Admin, Import, Download
Date Format = %d/%m/%Y
List conditions = 1
List display = Edit, Type, Created, StatusA, StatusB, Archived, Test Text, Public?

; Attributes
Attributes = Type, Created, StatusA, StatusB, Archived, Test Text, Public?
Required Attributes = Type

; Attribute Types
Type Created = date
Type Archived = date

; Options & Tooltips
Options Type = Type1{0}, Type2{1}
Options StatusA = Status-A-red, Status-A-orange, Status-A
Options StatusB = Status-B-red, Status-B-orange, Status-B
Options Public? = yes,no

; Conditionals
{0}Show Attributes Edit = Type, Created, StatusA, StatusB, Archived, Test Text, Public?
{1}Show Attributes Edit = Type, Created, StatusA, Archived, Test Text, Public?

The above logbook definition works. However, if I replace the Required Attributes = Type with Required Attributes = Type, Public?, the conditionals will no longer work. I can see the difference in the reactions of the browser - with the extra attribute, nothing happens when I change "Type". Without, the browser will spring into action and reload as soon as I change "Type". I've tested this with both Firefox 3.6.13 and Konqueror 4.4.5 on Kubuntu 10.04 as clients. Fortunately, this is not a showstopper for me, as it is not mandatory to have this attribute defined as required, but I find it a weird issue nonetheless.

Cheerio,

Thomas

P.S.: I'm currently running the latest SVN version of elogd on OPenBSD as I ran into the same problem as described in Message 66984. The above problem also happens with the 2.8.1 I was using before. Some feedback: The SVN version compiled and ran without any further intervention on OpenBSD - very nice!

/* workaround for wong timezone under MAX OSX */
long my_timezone()
{
#if defined(OS_MACOSX) || defined(__FreeBSD__)
   time_t tp;
   time(&tp);
   return -localtime(&tp)->tm_gmtoff;
#else
   return timezone;
#endif
}

 BINGO! That was it - thank you! I've added the || defined(__OpenBSD__) in the place you described above and now the dates are correct. While I was at it, I also had a look at what other ifdefs there are for FreeBSD and the only other one I found was also in elogd.c:

#if defined (_BSD_VA_LIST_) && defined (__FreeBSD__)

I'm far from being a C programmer, but I did some quick and dirty compile tests with various ifdefs set and apparently, _BSD_VA_LIST_ is not set on OpenBSD, so I guess that this statement does not need modification. I will keep my eyes peeled for strange behaviour, though...

Cheerio,

Thomas

P.S.: One thing I noticed is that the OpenBSD variant of gcc throws these warnings when compiling elogd.c:

gcc -g -funroll-loops -fomit-frame-pointer -W -Wall -DHAVE_SSL -I../mxml -o elogd src/elogd.c crypt.o regex.o mxml.o strlcpy.o -lcrypto -lssl
/tmp//ccHhMZfy.o(.text+0xd2f): In function `int_vasprintf':
src/elogd.c:826: warning: vsprintf() is often misused, please use vsnprintf()
/tmp//ccHhMZfy.o(.text+0xae8): In function `xstrdup':
src/elogd.c:736: warning: strcpy() is almost always misused, please use strlcpy()
/tmp//ccHhMZfy.o(.text+0x13c7): In function `my_shell':
src/elogd.c:1197: warning: sprintf() is often misused, please use snprintf()
/tmp//ccHhMZfy.o(.text+0xf0ae): In function `el_correct_links':
src/elogd.c:5178: warning: strcat() is almost always misused, please use strlcat()

I'm not certain whether this is specific to this gcc variant, but I seem to remember that the OpenBSD folks added some extra warnings and suchlike as part of their overall code audit, so I thought I'd mention it.

The problem is most probably related to the time zone. elogd contains a function:

/* workaround for wong timezone under MAX OSX */
long my_timezone()
{
#if defined(OS_MACOSX) || defined(__FreeBSD__)
   time_t tp;
   time(&tp);
   return -localtime(&tp)->tm_gmtoff;
#else
   return timezone;
#endif
}

I have just installed elog 2.8.1 on my OpenBSD 4.8 server (I've added the necessary Makefile patch to "Contributions"). Everything seems to work fine, however, I ran into a very odd problems with the dates of the logbook entries: When I start a new entry, the current date/time is displayed correctly. When I submit the entry and look at it again, the date has changed to some value in 1996 . I've checked the actual logbook file and there, the entry has a Date line like this:

Date: Thu, 03 Feb 2011 23:53:28 -13049141
 

The "-13049141" looks very suspicious to me - but I have no idea whatsoever why this happens. I had elogd running with -v, but that did not give me any hints. Any ideas how to debug/resolve this would be much appreciated...