* build: move frontend assets to Bootstrap 5.3 and Tom Select * feat: migrate templates and scripts to Bootstrap 5, dropping jQuery Templates - Rename Bootstrap 4 classes and data attributes (data-bs-*, ms-/me-/ps-/pe-, text-start/end, form-group -> mb-3, input-group wrappers removed, badges, custom controls -> form-check/form-select, media -> d-flex, btn-close, ...) - Dark mode now uses Bootstrap 5.3 colour modes (data-bs-theme on <html>), set from <head> to avoid a flash of the light theme - Remove the Bootstrap 4 /bootstrap/ demo page - Contextual table classes (table-success etc.) still work as plain backgrounds for the rigboard key JavaScript - Remove jQuery: src.js/interaction.js and every inline template script are rewritten in plain JS on top of small helpers (helpers.js, bundled with Bootstrap into jpop.js so inline scripts can use them) - Replace bootstrap-select/ajax-bootstrap-select with Tom Select. The remote search now sends the `q` parameter and reads `text`, which is what the API actually uses (the old picker sent `term` and read `label`) - HTML fragments are fetched with an X-Requested-With header so views keep rendering their modal variants, and fetched scripts are re-executed - Remove the Bootstrap 4 plugin script includes * fix: stop rigboard header buttons stretching to full width under Bootstrap 5 * fix: restore dark-mode brand colours and contextual table colours under Bootstrap 5 * fix: brighten dark-mode links and make coloured card outlines visible * fix: calendar layout and grid borders, navbar search button width, guard missing modal links * fix: readable text in dark-mode Tom Select inputs and placeholders, restore form-control column widths * build: split the Dockerfile into cached stages with prod and dev targets * deploy: make compose.yml development-only with live reload, and document it * fix: keep badge text colour for links inside badges * fix: restore table-bordered grid lines in dark mode * fix: include Bootstrap's progress styles and keep progress labels readable
TEC PA & Lighting - PyRIGS
Welcome to TEC PA & Lighting's PyRIGS program. This is a reimplementation of the previous Rig Information Gathering System (RIGS) that was developed using Ruby on Rails. PyRIGS is our in house app for the centralisation of information on our events and now assets.
For setup information and other such helpful stuff check the Wiki
Apps
- PyRIGS: Base app, stores 'global' information
- RIGS: Rigboard stuff - event calendar etc
- assets: Database of our kit, testing data etc
- training: Logs in-house training within various "departments" (sound, lighting etc).
- versioning: Our custom logic built on top of django-reversion. Semi-modular.
- users: Our custom logic for registration and profiles. Semi-modular.
Running locally
Warning
compose.ymlis for development only and must not be run in production. It mounts the source into the container, runs Django's development server withDEBUGon by default, and uses placeholder captcha keys. Production is deployed from the image built by theprodtarget of theDockerfile.
The compose stack runs Postgres, the Django development server and a gulp watcher that rebuilds the CSS/JS. Changes to Python code and templates reload the app automatically, and changes to pipeline/source_assets are rebuilt into pipeline/built_assets (refresh the browser to pick them up).
- Copy
.env.exampleto.envand fill it in. For local use set at least:The sample data commands refuse to run unlessDEBUG=true DJANGO_ALLOWED_HOSTS=localhostDEBUG(orSTAGING) is true. - Start the stack (migrations run automatically on start):
The first start installs the node modules, so give the assets a minute to appear. After changing
docker compose up -d --buildpyproject.toml,uv.lockor theDockerfile, rebuild withdocker compose up -d --build(or rundocker compose watch). - Open http://localhost:8000/.
Creating a user
docker compose exec pyrigs python manage.py createsuperuser
Sample data
Load sample users, events, assets and training data (run once on a fresh database):
docker compose exec pyrigs python manage.py generateSampleData
The individual commands (generateSampleUserData, generateSampleRIGSData, generateSampleAssetsData, generateSampleTrainingData) can be run separately, but run the user one first. To remove the sample data again (requires DEBUG=true):
docker compose exec pyrigs python manage.py deleteSampleData
The sample data creates these logins (the password is the same as the username):
| Username | Password | Access |
|---|---|---|
superuser |
superuser |
Superuser |
finance |
finance |
Finance and Keyholders groups |
hs |
hs |
H&S and Keyholders groups |
keyholder |
keyholder |
Keyholders group |
basic |
basic |
Approved user, no groups |
It also creates a number of generic profiles (e.g. AmyPond, RoryWilliams) which have no password set, so they can't be logged into.
Development
Linting and formatting use ruff, run through prek (a pre-commit compatible hook runner) using .pre-commit-config.yaml:
uv sync
uv run prek install # run the hooks on every commit
uv run prek run --all-files