User Tools

Site Tools


Task List 2006

This document lists in more detail than the release notes tasks done in 2006 and January 2007 for NAV 3.2

T1: Improve snmp data collection

Task id T1
Assigned to Morten Brekkevold
Used time 20 hrs
Start date
Due for NAV 3.2
  • (Fixed by mortenv) Store the complete interface description string for router ports untouched in NAVdb. Modify the gwport report.

T3: Rewrite the message and maintenance tool

Task id T3
Assigned to Stein Magnus Jodal
Estimated time 120 hrs (approx. 240 hrs used)
Start date Approx. 17 July 2006 or later
Status Finished by 6 Oct 2006
Due for NAV 3.2

This is a big task. We suggest close to a complete rewrite of the message and maintenance tool. We would like to keep most of today's functionality, but simplify the user interface. Radically improved user friendliness is our goal.

We would like to split the tool into two separate tools:

  • Messages
  • Maintenance tasks

Database changes

We introduce four new tables replacing the original three tables;

message (replaces emotd)
maint_task (replaces (maintenance)
maint_component (replaces emotd_related)
message_to_maint_task (N-M relation replaces N-1)

The following fields will be defined:


Contains the messages registered in the messages tool. Each message has a timeframe for when it is published on the NAV main page.

messageid       sequential primary key
title           title of the message (text)
description     The message itself. Presented on the NAV main
                page, open information, should be understandable
                for end users (text).
tech_description technical description. Not compulsory. Not shown on
                the front page. Shown on drill down page, only for logged
                in NAV users. Contains more technical information
                regarding the message (text).
publish_start   start time for when the message is published 
publish_end     end time for publish
author          user (NAV logged in user) who posts the message. 
                Only he can edit. Others can make a follow up message.    
last_changed    timestamp when the message was edited the last time
                (typos etc may be edited)
replaces_message If there is a development in the case posted in the
                original message a follow up message may be posted, the
                follow up will have a reference to the message
                it replaces. Only the follow up is shown on the
                NAV main page with a link to its predecessor.
replaced_by     Foreign key to the message replacing this one.
                Automatically updated by triggers based on data
                from replaces_message.

Deprecated fields from emotd table:

type            deprecated
published       deprecated - was used for expiring message,
                we do this instead by adjusting the publish_end
affected        deprecated - not always relevant
downtime        deprecated - not always relevant
title_en        deprecated
desscription_en deprecated
detail_en       deprecated
affected_en     deprecated
downtime_en     deprecated


A maintenance task consist of a set of maintenance components. This may be entire locations or entire rooms or certain netboxes, modules and/or services.

A maintenance task has a time frame (start and stop time). In this time period events regarding the devices/services selected are not sent as alerts to NAV users. I.e. event engine will not post these events on the alertq, only on alerthist.

maint_taskid    sequential primary key
maint_start     start of the maintenance window
maint_end       end of the maintenance window
description     textual description of the maintenance task
author          author of the maintenance task. Only the author may edit.
state           takes the values 'scheduled', 'active', 'passed'
                or 'overridden'. maintengine changes this value.


Keeps track of the components that are chosen for a particular maintenance task. (key,value) pairs relate to the relevant NAV tables (location, room, netbox and service).

maint_taskid    the maintenance task this relates to.
key             may be location / room / netbox / module or service
value           relevant locationid/roomid/netboxid/serviceid

Note: We turn off the option of setting a module on service.


This table implements an N-M relation between messages and maintenance tasks. We thus allow a task to be related to zero, one or more message. Similarly a messsage may relate to zero, one or several tasks.

messageid       relation to a message 
maint_taskid    relation to a task


  • Define general styles for tabs that can be used elsewhere in NAV. Do not use the yellow color of today on inactive tabs.
  • Use a general tool header with icon and H2 header.
  • The maintenance tabs (2) are taken out and placed in the new tool for maintenance tasks.
  • Cleanup the compose message page (details on paper). Add the possibility of attaching 0..N maintenance task to a message. If possible use one page for the whole add/edit operation.
  • The three tabs for listing messages (active, planned, historic) are kept. In addition a fourth is added: “All”. We suggest a view that lists titles and time period (perhaps more). This may be expanded to all details, if possible on the same page. Clean up the look. More details for logged in users than anonymous.
  • The link to Maintenance setup is no longer relevant.
  • When expiring a message, the publish_end is set to current time.

Maintenance task

This new tool will have two tabs; one for putting things on maintenance, the other for displaying the maintenance schedule. In addition the Status tool will show a listing of what currently is on maintenance, see task T4 below (consider linking to this page).

  • We will simplify the procedure for putting things on maintenance. We introduce the term maintenance task which is the set of components that are set on maintenance for a given maintenance window. The procedure will be:
  1. Select components
  2. Select maintenance window
  3. Describe (in a few words) the maintenance task
  4. Not compulsory: Attach the task to a message (messages are

published on te NAV main page, maintenance descriptions are not)

  • Note: Multiple select in the tree select is turned off due to bugs it introduced. It should be looked into reintroducing this possibility. Often a set of devices in a given room should be placed on maintenance (and not the entire room).
  • Change the functionality to not allow modules on maintenance. This will also easier solve the previous bullet.
  • The maintenance list of NAV 3.1 is perhaps the least intuitive NAV page. Change this to a maintenance schedule page with a general calender month view. At each date the maintenance description is shown allong with the start (and end?) time for the maintenance window. The entries are in turn linked to a complete view of the maintenance task. If a room and/or location is on maintenance do not show the content of the room, but link to the report tool for details.

T4: Enhance the status tool

Task id T4
Assigned to Stein Magnus Jodal
Estimated time 40 hrs (28 hrs used)
Start date 13 Oct 2006
Status Finished by 3 Nov 2006
Due for NAV 3.2

Current maintenance status should be shown on the status page. This will involve two new sections (in bold), the complete list of sections then being:

  • IP devices down
  • IP devices in shadow
  • IP devices on maintenance
  • Modules down
  • Services down
  • Services on maintenance

The two maintenance listings should take the same columns as there equivalent status listing. Downsince and downtime will then illustrate the downtime of components on maintenance. If the components in question is not down, the value of downsince should be 'Up' and the value of downtime should be blank.

The history icon should be used for maintenence components in the same manner as other components on the status page.

In addition a wrench icon should be used, linking the maintenance details of the item in question. I.e. the details on the maintenance task that this item is part of (maintenance window, description, optional link to adhering message).

Note that the source for the maintenance listings should be the alerthist table looking for eventtype=maintenanceState where the end time is not set.

Check that the other status components do not include items that in fact are on maintenance!

Also check that the user status page preference with this change also supports the three new maintenance section.

If there i.e. are noe modules on maintenance, 'No modules on maintanance' should be shown.

The header of the maintenance sections should not link to 'history' as the others do, but instead link to 'maintenance schedule'.

NEW: From The services down section link to the alternative graphical view; https://nav.x.y/browse/service/allMatrix Feel free to improve this view. A matrix that shows the grid lines would be better. Or take a look at how Hobbit does this. I.e. use green and red balls/bullets instead, and drop the suggested grid lines.

T5: Enhance the report tool

Task id T5
Assigned to Morten Brekkevold, Stein Magnus Jodal
Estimated time 80 hrs (first four bullets)
Start date
Due for Partly NAV 3.2, maybe all
  • (Fixed by Morten) Make it configurable how many lines that are displayed on a search.

It is set to 100 today, consider if the default should be larger… 1000!

  • (Fixed by Morten) Add an unknown equipment detected with CDP report.

Use data from netboxinfo with key='unreqCDP'.

  • (Fixed by Morten) Consider two new columns in the netbox report: software and serial
  • (Fixed by Morten) Consider two new columns in gwport report: gwport.metric and gwportprefix.hsrp.

Alternatviely consider making a separate gwipport report with focus on IP attributes (ip addresses, metric, hsrp, vlan and more). The gwport report could then have all interfaces listed once, so that secondary addresses and static routes will not be included here, only in gwipport.

  • (Fixed by Morten) Consider deleting swport0, and more deprecated reports.
  • (Fixed by Morten) The room report uses netbox2, not netbox. Why??? See if netbox2 can be removed.

T6: Improve IP device center

Task id T6
Assigned to Morten Brekkevold, Stein Magnus Jodal
Estimated time 80 hrs
Start date 10 Nov 2006
Status Done for 3.2 by 22 Jan 2007
Due for NAV 3.2 and 3.3

IP Device Center

  • (Fixed by jodal) Fix the IP address wild card guess - it should only allow exact matches for IP addresses.
  • (Fixed by jodal) Show “First discovered by NAV” (below Last updated)
    • netbox.discovered field (default: now()) should be added and used here.
    • device.discovered field (default: now()) should also be added for consistency
  • (Fixed by jodal) Show and link to the number of modules, swport and gwport (as seen in the netbox report)
  • (Fixed by jodal) Move statistics to the bottom, below swport view
  • (Fixed by jodal) Show more data attributes for a device:
    • Uptime (below Availability): Use the netbox.upsince variable
    • Serial number (below Software)
  • (Fixed by jodal) Add a fourth color code for 10 gig
  • (Fixed by jodal) Split the legend display in two lines, one with focus on speed,

the other for other attributes:

  • Color legend: [] not active [] 10Mbps [] 100M [] 1G [] 10Gbps
  • Frame legend: [] half duplex [] full duplex [] trunk [] blocked
  • (Fixed by mortenv) Add interface name on the popup that is shown over a switch port
  • (Fixed by jodal) A link from the swport page (the one you see after clicking on a switch port) to the machine track search that shows all machines behind the given switch port


  • (Fixed by jodal) Remove the possibility of editing static routes in editDB (leaving the only nettypes to edit: reserved and scope)

T7: Improve the machine tracker

Task id T7
Assigned to Morten Brekkevold
Estimated time 1 hrs
Start date
Due for NAV 3.2
  • (Fixed by jodal) Info text explaining ARP and CAM timeouts.

T8: Improve Cricket in NAV

Task id T8
Assigned to John Magne Bredal
Estimated time 120 hrs
Start date
Due for NAV 3.2
  • (Fixed by John Magne) Support 64 bit interface counters in cricket. The separate giga-switch-ports and giga-router-ports with its one minute polls will then be history.
  • (Fixed by John Magne) Improve the data in the cricket menu column “description”

T9: Make a ranked statistics tool

Task id T9
Assigned to John Magne Bredal
Estimated time 60 hrs
Start date
Due for NAV 3.2
  • (Fixed by John Magne) Make a tool that gives reports ranked on bandwidth usage and other statistic parameters. The solution should be inspired by the NAV v2 solution.
  • most important:
  • octets/errors for ports all/one switch/router
  • cpu load / memory usage for routers

T12: Implement a more flexible SMS solution

Task id T12
Assigned to Stein Magnus Jodal
Estimated time 120 hrs
Start date 12 June 2006
Status Finished by 10 July 2006
Due for NAV 3.2
  • Reimplement the SMS send demon in python (perl in NAV 3.1).
  • Make it more modular, allow for sending SMS on external gateways.
  • Implement dispatchers that work with the new sms solution.
  • Implement support for event severities. Most severe events should be given priority.
  • Complement the solution with an alert profiles page that lists the logged in user's sent SMSes. This gives the user the ability to check which sms'es that is (read: should be) sent him. Note: This webpage is present in NAV v2.

T24: About page

Task id T23
Assigned to Stein Magnus Jodal
Estimated time 10 hrs (about 1 hour used)
Start date 13 Oct 2006
Status Finished by 13 Oct 2006
Due for NAV 3.2
  • Include an about page i NAV 3.2 that give information about NAV, gives credit to all contributors, links to !SourceForge and metanav and perhaps encourages NAV users to send us a postcard.
devel/tasklist2006.txt · Last modified: 2007/10/10 16:55 by faltin