Asset Database

This is a web-based card-index-style database — plus a few bells and whistles — for storing information about a single type of asset, originally real-estate properties in a management company's commercial portfolio.

For confidentiality, screenshots on this page show a modified subset of database fields used by the client, with fake data and files, and the application's real name is not given here.

Features

The main view (above) allows asset data to be viewed and edited. The form will adapt to any size of viewport, dividing content into an appropriate number of columns. Textareas will automatically resize to fit their content.

Below the form is a file management area, where each asset's associated files can be uploaded, downloaded or viewed. Drag-and-drop of files to and from the browser is supported where browser capabilities permit.

The asset selection dropdown offers real-time full-text search (below, left).

Where assets have geographical locations, and a user has provided latitude and longitude, assets can be displayed on and selected from a map (below, right).

Date fields can have deadlines attached; when these are impending or missed, on-screen warnings are provided at startup or on request (below, left).

Calculated field values are possible, for example the computed rent instalment shown below (right).

Simple, printable tabular reports are available (below, left). Users with write privileges can create and edit report layouts (below, right).

For logins, YubiKey hardware authentication dongles are supported in addition to usernames and passwords. Users can be defined as read-only, read-write, or administrative. The user's privilege level control the availablity UI options. Naturally, the server-side API checks every incoming request for a token associated with the appropriate privileges.

Development

Per the client's request for minimal dependencies, the only third-party libraries and services used are for mapping and Yubikey authentication; everything else is my own work.

The JavaScript front end includes two non-trivial code libraries of my own, which (client willing) may later find use elsewhere: one to render and manage HTML forms described by JSON schemas, and one to embed a file manager in a web page.

The PHP back end uses SQLite for data storage, perfectly adequate given the limited number of users. It is equally at home on Windows or Linux servers.

Asset data is stored as JSON in a single database column, along with a schema in a settings table. This meets the client's requirement for the schema to be easily editable, without requiring changes to the SQL database structure. It also makes the software sufficiently flexible to be used for other purposes: As soon as possible in development, I started dogfooding it as an address book, databases for personal book and DVD/Blu-Ray collections (below), and even as the software's own issue tracker. Multiple databases can co-exist on the same server, with configuration options allowing a different interface colour and menu icon per instance (handy for telling at a glance whether I'm in testing or production!). Each instance also has its own JavaScript file for field-value calculations, like runtime-per-episode and book volume shown below.

During development and maintenance, Python scripts and Selenium WebDrivers are used for automated in-browser functional and regression testing. One of these scripts was used for the initial import of data from other sources; I could have converted the data directly to database records, but this way it doubles as a test of data-entry functionality.

Availability

I developed and maintain the software under contract to a specific client, so I am not able to make the source code available at this time.