Marinerg-i Test Access Service
This is the backend for the Marinerg-i Test Access Portal. Researchers apply for time at marine renewable energy test facilities. A review board evaluates each application, the board chair decides, and accepted applications lead to a facility test report.
It is a Django app with a REST API, built for the
Marinerg-i project. The Angular frontend is in
marinerg-i/frontend. Run it
separately and point it at this backend.
Try it locally
Read infra/quick_start.sh, then run it:
./infra/quick_start.sh
It creates a virtual environment, installs the dependencies, sets up a local database with an admin user, and starts the server. Browse to localhost:8000/api.
Develop
The app reads its settings from the environment. infra/dev.txt has working
values for local development. Keep real deployment settings out of the repo.
uv sync --group dev
source infra/set_dev_environment.sh
uv run python manage.py migrate
uv run python manage.py sync_roles
uv run python manage.py runserver
If the server says the secret key is missing, the settings didn't load into your shell.
uv run tox runs every check CI runs: format, lint, types, the tests, the
Celery tests, the schema check and the e2e collection. After you change a model
or serializer, regenerate the schema and client, and commit them:
uv run python manage.py generate_client marinerg_test_access.client
After you change an access policy, rewrite the deployed sweep's declaration:
WRITE_DECLARATION=1 uv run pytest tests/test_policies.py
To see the portal in every state, load the demo data into an empty database.
It runs only with DEBUG on:
rm -f db.sqlite3
uv run python manage.py migrate
DJANGO_DEMO_PASSWORD=<a password> uv run python manage.py seed_demo
It adds 13 people in every role, 9 public facilities and 1 private one, and 5
calls: one finished, one in board review, one open with a submitted
application and a draft, one closing tomorrow, and one draft. Every demo user
signs in with DJANGO_DEMO_PASSWORD. src/marinerg_test_access/demo/ says
how the data is made.
infra/dev.txt sets DJANGO_FRONTEND_URL to the frontend's dev server, so
signing in returns you to the frontend, not to this server's port.
PDF summaries
Each submitted application gets a PDF summary, built by
Gotenberg. Without Gotenberg the summary is a zip of
the HTML and the attachments instead, so you don't need it for most work. The
tests in tests/integration/ need it and are skipped without it.
To run Gotenberg locally and include those tests:
podman run -d --rm -p 3000:3000 gotenberg/gotenberg:8.34.0
GOTENBERG_URL=http://localhost:3000 uv run python runtests.py
These settings control it:
| Variable | Default | Purpose |
|---|---|---|
GOTENBERG_URL |
unset | The Gotenberg service. Unset gives a zip instead of a PDF. |
GOTENBERG_TIMEOUT_SECONDS |
120 |
How long to wait for one conversion. |
GOTENBERG_RETRY_ATTEMPTS |
3 |
Attempts per request, including the first. |
GOTENBERG_RETRY_BACKOFF_MS |
500 |
Delay before the first retry. It doubles each time. |
Gotenberg runs all requests through one Chromium process. When that process restarts, every request in progress fails with a 500, which is why the client retries.
The review flow
Each call runs its applications through a review flow, from ichec-django-core's
workflows app. flows/access_review.yaml
is the template. Every migrate loads it, and each new call gets its own copy:
- Facility review. Each facility the applicant chose confirms it discussed the application. The step ends when the call closes.
- Board review. Each board member reviews.
- Decision. The chair accepts or rejects.
- Test report. After acceptance, the chosen facility reports on the test.
Reviews, decisions and reports are tasks at /api/tasks/, and their answers
are forms at /api/populated_forms/. Each assignee gets a notification.
Until a call opens, its coordinator can change its copy at /api/steps/, such
as to drop the facility review, to have one review suffice, or to pick the
reviewers instead of assigning the whole board. They set each step's template
file at /api/forms/.
Some things are left to people:
- A call closes at
closes_at. The coordinator or chair can reopen it with a new date. - The coordinator or chair can reopen one application with
reopen, to let the applicant change or submit it after the close. - When a board member declines, the chair either assigns someone else, or runs
proceedto move on with the reviews in hand. - With several facilities on an application, the chair sets
chosen_facilitybefore accepting. - An admin corrects an application's place with
move, such as after a mistaken withdrawal.
available_actions on each resource lists what the caller may do now. Each
model's Access policy says who may do what, and tests/test_policies.py
holds each policy in words.
Who sees whom
Board review is anonymous: applicants never see who sits on a board or who
reviewed them. Staff are the members group. policies.py registers the
member policy, and tests/test_members.py has a test for each row.
| Who | Sees | Why |
|---|---|---|
| Signed-out visitor | A call's contact email | To ask before applying |
| Applicant | Themself, and the call's contact email | The board stays hidden |
| Board reviewer | The applicant's name on each application they review | To judge the team |
| Facility staff | Applicants who chose their facility, with email, and other staff | To discuss the application before reviewing |
| Chair and coordinator | The call's applicants, with email, and all staff | To run the call and replace a reviewer who declines |
| Staff | Other staff: name and email | To pick people for calls |
| Admin | Everyone, with account details | To manage members |
A member's phone, identifiers, groups and image need view_member_account,
which only admins have. The call editor picks people from /api/staff/, which
lists only staff.
Release
Each pipeline on main has release patch, release minor and
release major buttons. Press one to publish that release. Then pin the new
version in marinerg-deploy and release its image. The deployment runs
migrate and sync_roles.
Licence
Copyright of the Irish Centre for High End Computing (ICHEC), released under the
MIT Licence. See LICENSE.
1 maintainer
Metadata
1 maintainer
Release files for marinerg-test-access 8.0.0
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| marinerg_test_access-8.0.0.tar.gz | 359.5 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| marinerg_test_access-8.0.0-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 723.3 kB
Release files / marinerg_test_access-8.0.0.tar.gz
| Download URL | marinerg_test_access-8.0.0.tar.gz |
|---|---|
| Size | 359.5 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
57b3c425cfe0522335808e138467f84c4b8aefac49b637a2112c6e4d997cf592
|
|
BLAKE2b-256 checksum How to use checksums |
66b0edc3aba8a41e0436edb441568adc6f2cf524d19f19565d4e12bddfd55702
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.14.7
|
Release files / marinerg_test_access-8.0.0-py3-none-any.whl
| Download URL | marinerg_test_access-8.0.0-py3-none-any.whl |
|---|---|
| Size | 363.8 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
a2c9dacf30ebc2b9e6014bea00decda530480fd4d8f3bf2f8bb386b62e051ddd
|
|
BLAKE2b-256 checksum How to use checksums |
3a122ec6f2cd97ceae5884ed87a068d3ac3d99fcd68a19e561e74f7a25fa44f0
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
twine/7.0.0 CPython/3.14.7
|
