Web Administration Simplified, Part III

The End of a Good Thing

This is the third and final part in my series of improving the administration for the web dashboard (the first two parts are here and here). In the first two parts I built a rough admin console, that allowed the following functionality:

• Reload dashboard configuration
• Add/modify/delete remote servers
• Load/install packages

I have now added the finishing touches and committed this to the trunk. In this post I’ll quickly cover what I’ve added.

Password Protection

Since this has the potential to totally screw up the dashboard, we don’t want every body to have access to it. Since I’m planning on releasing this in 1.4.4, now of the security framework is in place.

Since for the moment I’ve added a temporary fix to secure the dashboard admin. In the config file (dashboard.config) an administrator can set a password for this plug-in. This is done by adding a password attribute to the plug-in definition:

<administrationPlugin password="whoareyou" />
This then displays a login screen for the user:
 
When the user logins it will add a temporary cookie to the browser. This cookie is valid for 30 minutes, after this they will need to login again.
If there is no password, then the user will go straight into the admin page as per previously.
 
There is also a new Logout button in the commands section – for a secured admin section it will logout the user (i.e. expire the session cookie).
Package Maintenance
I have also completed the operations on packages. Clicking on an installed package will display the following options:
 
The Remove button is no longer available – this just made things more complicated.
Clicking on the Uninstall button does exactly that – it will completely uninstall the package:
 
Again, there is a log so people can see exactly what has been done:
 
Once a package has been uninstalled the “Remove” command is returned to the package options:
 
This removes the package from the server so it does not appear in the list anymore:
 
Which now gives the full load-install-uninstall-remove cycle for packages.
Hopefully this will simplify the maintenance of components within the dashboard, now it’s a simple automated process. This means less work for administrators and also less possibilities for error.
Package Improvements
I’ve also made a couple of improvements to the manifest in the packages. First, attributes are included under an element – they can no longer be specified separately. Secondly, it is possible to add a filter to the elements – this handles the scenario where there are multiple elements with the same name (e.g. xslFile, xslReportBuildPlugin, etc.)
The following is an example for the NUnit plug-in:
<package>

  <name>NUnit Results</name>

  <description>Display the results of a NUnit run.</description>

  <type>Plugin</type>

  <folders>

    <folder>

      <location>Xsl</location>

      <files>

        <file>unittests.xsl</file>

        <file>tests.xsl</file>

        <file>timing.xsl</file>

      </files>

    </folder>

  </folders>

  <configuration>

    <setting>

      <path>/dashboard/plugins/buildPlugins/buildReportBuildPlugin/xslFileNames</path>

      <filter>.='xsl\unittests.xsl'</filter>

      <name>xslFile</name>

      <value>xsl\unittests.xsl</value>

    </setting>

    <setting>

      <path>/dashboard/plugins/buildPlugins</path>

      <filter>@xslFileName='xsl\tests.xsl'</filter>

      <name>xslReportBuildPlugin</name>

      <attributes>

        <attribute name="description" value="NUnit Details"/>

        <attribute name="actionName" value="NUnitDetailsBuildReport"/>

        <attribute name="xslFileName" value="xsl\tests.xsl"/>

      </attributes>

    </setting>

    <setting>

      <path>/dashboard/plugins/buildPlugins</path>

      <filter>@xslFileName='xsl\timing.xsl'</filter>

      <name>xslReportBuildPlugin</name>

      <attributes>

        <attribute name="description" value="NUnit Timings"/>

        <attribute name="actionName" value="NUnitTimingsBuildReport"/>

        <attribute name="xslFileName" value="xsl\timing.xsl"/>

      </attributes>

    </setting>

  </configuration>

</package>
This contains both filters and attributes. Without these two changes the package was getting confused and updating the wrong elements! Now it happily updates everything correctly  
Some Initial Packages
I’m also in the process of building packages for the existing plugins. So far I have built the following plugins:

Modification History 
NUnit Results 
Project Configuration Display 
Project Statistics 
Queue Status Display 
Server Configuration Display 
Server Information Display 
Server Log Display 
Web Dashboard Administration 

Each of these plugins has a manifest file (these are in the project\WebDashboard\packages) plus a target in the Nant build script to generate the package. Each target will pull the necessary files and the manifest into a single package.
The files come from Project\WebDashboard, so the developers only need to worry about the main files. When the files are changed (e.g templates, supporting XSL, etc.), the build will automatically include the changes in the packages.
I’m still in the process of setting this up, but when I have finished the Nant script will generate all the packages, put them in the correct location and then add them to the installer. By default most of these packages are already installed, so the installer will also reflect this.
Nearly There
While I said this is the last post in the series, the work isn’t quite completed. I need to finish the build script to include the packages in the installer. I also have a few more packages to complete (mainly the build result packages). And then finally, I need to update the documentation.
But it’s already to go. When CCNetLive is back up, try getting one of the latest builds and try it out. Let me know if you find any issues or problems.