Here at Intel OTC we've been using racktables and are so far pretty happy with it. There are a lot of things I would like to see, but maybe I'll do some contributing if I get time. Here's the first problem I've encountered (I didn't want to file a bug because I'm not sure it's a bug, but more a design problem). I created a dictionary entry for our servers so that we can store the expiration date of our DRAC certificates. Naturally, I then moved over to the reports page, because I wanted to see if a report would be generated for the DRAC certificate field. There was no such entry. So I dug in to see what was required. What I found was this: $breakdown[21] = array ( array ('from' => -365, 'to' => 0, 'class' => 'has_problems_', 'title' => 'has expired within last year'), array ('from' => 0, 'to' => 30, 'class' => 'row_', 'title' => 'expires within 30 days'), array ('from' => 30, 'to' => 60, 'class' => 'row_', 'title' => 'expires within 60 days'), array ('from' => 60, 'to' => 90, 'class' => 'row_', 'title' => 'expires within 90 days'), ); $breakdown[22] = $breakdown[21]; $breakdown[24] = $breakdown[21]; Digging in further, I found that 21, 22, and 24 are the attribute IDs of the three dictionary entries on install. Adding the new attribute ID (10003) magically added the appropriate date field to the page. I don't want to do it this way. Making changes to hardcoded values in code is a Bad Idea. In my opinion, hardcoding attribute types like this is also a bad idea, but baby steps, I suppose. That also creates (I believe) a 10,000 entry array, and that has memory implications. In my opinion, there should be an attribute attribute of some kind - perhaps tied in to the [T] date attribute type, that says "include this on expiration reports". It may even be reasonable to just automatically include anything that has a [T]date type in that report. Should I file a bug report after all? Perhaps if I get time I'll submit a patch. --Russell Russell Miller Sysadmin - OTC russellx.j.miller@xxxxxxxxx