The background tasks for new instruments (extracting data and searching for run types) are executed as background threads but aren't part of the thread pool/management system, so they might overload things.

It's possible to directly type an URL to get to the middle of the New Instrument page sequence without having started it first. Figure out how to stop it.

The general idea would be to check the underlying session bean and see what stage we're at, and go back to the latest stage.

The sea water CO2 runs use the sensor data in the data reduction calculations. What happens with the standards runs? What temperatures, pressures etc do they use if any?

Which of the calculated CO2 values do we get from a standards run? We need the corresponding version in the sea water for adjustments.

listToDelimited and delimitedToList convert between lists of strings and a string of values with semi-colon delimiters. Neither of them yet handle the case where a given value contains a semi-colon - such values will get split.

We simply need to escape these delimiters where they appear within values.

Some sensors have their measurements reported in electronic terms (mV, mA etc.) I assume there is an equation that converts these values to the true values. This leads to a number of questions:

1. What is the definition of this equation, and is it a linear/polynomial equation?
2. Is this equation fixed for specific sensor models? Is it worth (in future) adding a list of sensors and their equations to the system somehow?
3. Is calibration applied at the electronic level or the parameter level (i.e. are we calibrating the temperature or the electrical signal?)

If we can.

The Export column in the Data Files mockup should be renamed Actions, and combined with other actions. Each will have its own icon.

The Sample File Extraction thread for new instruments is not tracked by the Job Thread Pool. Make it so.

I have a feeling the tense switches between present and future in the Specification document. Check it and fix it.

Review all the Javascript in the mockup pages and replace it with jQuery where we can.

The labels are for the wrong ids.

The JobThreadPool is currently initialised in Pools.java, using a fixed number of threads.
This should be configurable.

The number of hours for which email verification and password reset codes are valid is currently coded into the UserDB.CODE_EXPIRY_HOURS class. It should be moved to application configuration.

The Job Manager doesn't track running threads, so if all the threads mysteriously disappear, the job thread pool will never have anything in. Set up something to recreate threads if we lose track of them.

The Settings menu must be disabled at certain points, e.g. when adding a new instrument.

Do all the finals have to be public? Review.

The conversion parameters on the New Instrument page shouldn't be there. Instead, these are folded into the calibration parameters entered when a file is uploaded.

The pointer on the user menu is a text selector. Should be a link clicky one.

Also check that the text can't be selected.

When there's multiple sensors, it's possible that one will have faults while the other is fine. We need a way to allow the user to remove faulty values or get the system to ignore the sensor for a given file.

In each case this would cause the QC to be run again.

On the Benguela Stream, a single voyage might be split across two data files. Allow two files to be uploaded and concatenated?

The popups showing the breakdown of the stat bars on the file list page should fade in and out.

The current job thread pool is broken. In the short term, rewrite it so that threads are created as needed, tracked (to make sure we're not running too many) and then destroyed at the end.

The JobManager can throw an awful lot of exceptions (InvalidClass, InvalidConstructor etc.). These all have to be caught outside, but the outside world doesn't need to know these details.

Make all the underlying classes inherit an overall InvalidJobException or similar, so only that one has to be handled.

and it's ugly. See login page and signup form.

On the Data Files page, there will be stat bards and pie chart views of some of the data.

The data should be in a Javascript data structure at the top of the file. When the page loads, a script will run to generate the stat bars. Pie charts will be generated on the fly when they are invoked.

As per title. To do when the first version is complete.

Also check that the thread name is reset when the thread is returned to the pool

JSF won't allow a space character to be typed in, so it can't be used as the 'other' character. Therefore we must add a radio button for it.

It may be possible to build the sensor inputs in the names.xhtml page using a loop. This depends on whether the value elements (named after bean properties) can be generated programatically.

Currently the authentication method returns instantly. Add incremental delays for repeated failures.

The job thread pool does not currently track threads that are running. This can cause problems if threads die unexpectedly, since they are expected to return themselves to the job pool.

The thread pool should keep a list of all running pools and periodically (how?) check that those threads are either still running or dead, and return them to the pool accordingly.

The jQuery-UI Resizable stuff doesn't react when the window gets resized. So we'll have to do it ourselves...

The configuration file path is currently in web.xml. Move it to context.xml with appropriate JNDI lookup for consistency.

And duplicate to all other sensors
Also need to remove the CSS left over from the conversion details table

If you enter a name for the second sensor but not the first, the page will complain about a missing value. Use javascript to auto-move it to the first entry before the form gets submitted.

A function to specify the start and end times for a specific file (i.e. ignore all before/after this point) would be handy.

Currently, running addJob doesn't verify the parameters - it leaves that until the job is actually run.

Instant checking of this might be useful, but it might not - the user won't be able to do anything about it anyway, and the job monitor (when it's written) is probably the place to get this stuff checked out.

The String.split method uses a regex. So when we're extracting file data, regex characters need to be recognised and escaped as appropriate.

The odds of anyone using these characters are virtually nil, but even so...

Needs doing for New Instrument and general file uploads.

Implement password reset

Check on the Names page.

Note that this is per-user only.

Files should be locked when someone is editing them. How?

When the application is first started, the first attempt to log in doesn't work - it goes straight back to the login page. After that it's fine.

This may or may not be intermittent.

It's a bare minimum at the minute

Somewhere on the QC page (in the title bar, most likely) show a live count of at least the number of Needs Flag records, and maybe counts of Good, Questionable and Bad records too.

If a job fails, the system tries to write the error to the database. If that fails, it does nothing. It should be put in a log file.

When a user has edited flags and suchlike, the QC and/or data reduction should be run again. How will the system know when to do this?

Possible options:

• User manually triggers it (undesirable)
• Any change triggers the appropriate action. Have a delay so it doesn't run instantly for every change, or wait until the user leaves the page.

Apparently they can be bound to a backing bean somehow.

We start with instrument/new/file_spec.xhtml