You are here

Projects Database Web Service

Printer-friendly versionPrinter-friendly version
→ This page details the old projects database service, whose functionality has been largely replaced by DPMT. This page is retained for historical purposes only and will be removed in future.

This document details some frequently-asked questions about the UG4 and MSc project database tracking website, used by both students and coordinators. This information is solely of relevance to Coordinators and Computing Support. Staff or students who need assistance with the projects database should contact the appropriate member of teaching staff in the first instance.


The site is a basic (and somewhat esoteric) PHP web front-end to a database of project proposals. It is however a powerful way to propose projects and allocate students quickly. Its authentication is handled by Cosign and allows any authenticated user to access its pages, propose projects or request project preferences. A limited number of users are admins and can use the administrative functions of the site to allocate students to projects.

The admin interface

The key to understanding the administrative interface is use of the check-box pseudo-tab system. It looks like this:

The admin page allows you to enable or disable different panels of functionality from the top of the page: simple enable or disable those modules you'd like to see on-screen at any one time, and click 'Update' to see them. By default, only 'Std' and 'Student' are enabled, as this allows you to do most allocation duties. However you will need to use the others in the course of projects administration. Notable panels include:


Shows important allocation and contention information about standard projects, as well as allowing editing individual students. It's recommended to keep this panel enabled whenever you're dealing with students or projects.

Std., Self Prop.

Shows standard and self-proposed projects allocations, respectively. Normal student-to-project allocation is performed from the 'Std.' Panel, as well as bulk student allocation edits. Self-proposed allocations cannot be performed en masse from the latter panel; instead click 'edit' beside the appropriate entry.


a list of projects. Useful for locating projects not normally visible on the normal "/projects" index pages. Selecting a project from this list sends you to the project descriptor page: as an administrator you will see an 'edit' link whenever you view project descriptor pages.


This panel allows you to create project groups and and allocate staff and students, so that they appear on the public groups page.

Degrees, Special, Subj. Areas, Others

Allows you to see and edit the code mappings for Degrees, Specialist areas, etc.

Year Restrict

This important panel contains various types of year control and restriction options, which are explained below.


This section is mostly self-explanatory, but it's worth noting a few quirks.

1st Name Last Name Matric Degree Major Minor Self Grp Alloc

columns shown can be changed using the 'Columns' tool at the bottom of the table. This is important for showing selection information, which optionally includes information about the project supervisor and whether the student has met the supervisor.

self-proposed projects though 'self' is of course an attribute of the project, it's unfortunately also used to define the allocation. So if a student has been allocated to a self-proposed project you will find they disappear from the list of students. Check the 'Self Prop.' page if you can't find them elsewhere.

Degree Codes and also those for specialist areas, etc., can be found in the 'degree' or other relevant section of the admin interface.

Year and Restriction

The projects database data is partitioned by year, meaning most data is entered from scratch each year, but allowing project data to be copied from previous years by their authors. It has a concept of 'active year' which controls which year the standard project listing URLs refer to (for non-administrators).

It can be confusing to learn that administrators see a different year by default than other users. You can check to see which year is current using the 'year restrict' panel. You'll see a listing like:

Current / Default Year

You are currently administering the year 2012.

The Current Year for users is 2011: this is only year to which proposals and preference submissions are allowed.

The current year is the most recent year, below, set to 'Viewable by all'.

Available Years (click to administer):
  • 2009 Viewable by all
  • 2010 Viewable by all
  • 2011 Viewable by all
  • 2012 (Admin Only)

In this example you can see that users visiting or /ug4/ will go to the 2011 data, as this is the most recent year viewable by all. By default, admins will see the 2012 data (and regular users are prohibited from viewing any of this data). Users and admins can see other years' data (where permitted) by appending a /year/ to the site URL, e.g. Historical data is normally left visible.

Note that from this panel you can only alter the status of year 2012. Clicking any of the year links on the panel would you to the equivalent admin panel for the non-default year, and the option to change the year above will change accordingly.

Another important part of setting up a new year is ensuring that provisional are not made immediately public. This can controlled by the last section of this panel:

Allocations for 2012 are currently restricted to:

When public, allocations will be viewable as normal via the /project-allocations URL (to staff, or all users, as appropriate).

Second Marker Preferences

These can be set, for any project year set to "public", by markers visiting the appropriate preference form (staff visiting will be presented with a list of projects against which to set preferences). Once set, they can be seen in aggregate on the admin page:

Student Details...
user1, user2

Clicking on one of the usernames presents that user's selections in full.

I found an error!

If the web interface caught an error, and informed you that 'this error has been logged', then support already know about it and we'll look into it. However it wouldn't hurt to contact computing support with any other information about the error, including what you were attempting to do and whether or not you require further assistance.

Last reviewed: 

System Status

Home dirs (AFS)
Other services
University services
Scheduled downtime

Choose a topic