Module: middleware-common

Potentially Updates req with pagination

The name field is used in queries.

Emulate fetchDatasetInfo but from Platform API and with more detail such as typology

Middleware. Updates req with 'entities' same as fetchEntities so not to be used together!

Fetches entities from the Platform API (mainWebsiteUrl) instead of Datasette. Uses REST API with query parameters instead of SQL, made in line with fetch spec pattern to allow easy swapping.

Middleware. Updates req with 'entityIssueCounts' same as fetchEntityIssueCounts so not to be used together!

Functionally equivalent (for the utilization of the LPA Dashboard) to fetchEntityIssueCounts but using performanceDb

Middleware. Updates req with resource.

Middleware. Fetches all local-planning-group entities from the Platform API in a single call and derives two outputs: . - takes org code and:

• req.parentGroup {Object[]|null} - If this org is a member of any planning group(s), returns an array of those groups with { entity, name, organisation }. Null if this org belongs to no planning groups.

• req.planningGroupMembers {Object[]|null} - If this org IS a planning group, returns an array of its member organisations with { organisation, name }, where name is resolved via a parallel Platform API lookup. Falls back to the org code as name if the lookup fails. Null if this org is not a planning group.

Fetches provision records for the current organisation and any planning groups it belongs to, filtered to the current dataset. Includes the organisation name via a JOIN on the organisation table.

Requires: req.params.lpa, req.params.dataset, req.parentGroup (set by fetchLocalPlanningGroups) Sets: req.provisions — array of { dataset, project, provision_reason, organisation, name }

TODO: Does it need fetchMany any more, would allow an append of Org Name to fetchLocalPlanningGroups result

Fetches error-severity issue tasks from the platform API for the current organisation, then deduplicates by (dataset, issue_type, field) keeping the highest count per group. When req.params.dataset is set (e.g. dataset task list page), filters to that dataset and uses a limit of 100. Without a dataset (e.g. LPA overview page), fetches across all datasets with a limit of 500. Result is stored on req.tasks as { tasks: [...], count: N }.

Was the resource accessed successfully via HTTP?

Middleware. Set req.handlerName to a string that will identify the function that threw the error.

Middleware to determine authority level based on entity quality Queries the Platform API twice: first for 'authoritative' quality, then for 'some' quality if needed, only needs 1 result

Middleware. Prevents indexing of certain pages

Middleware. Drops issues that were raised against an older resource and no longer apply to the current one, by checking for a more recent fact for each issue's entity/field.

Currently unused. It is commented out of processRelevantIssuesMiddlewares — the per-issue lookups proved too slow, and the problem it solves had only been seen for one organisation. Nothing in src/ calls it; only its unit tests do. Issue counts in the UI therefore include issues the provider may have already fixed.

Keep or delete deliberately — do not assume it is running.

No-ops when req.resources is empty. Reads and rewrites req.issues.

Provides the list of available/supported datasets.

Middleware. 404s when the requested page number falls outside the available range.

Must run after something has set req.dataRange (see getSetDataRange), since the upper bound comes from dataRange.maxPageNumber.

Middleware. 404s when req.params.lpa is not a known organisation.

Mounted with router.use('/:lpa', ...) so it guards every organisation-scoped page.

Fails open: the organisation list comes from Redis, and if that lookup errors (or Redis is unavailable and the list is empty) the request is allowed through rather than 404ing every dashboard page. A later fetch will 404 if the organisation genuinely does not exist.

Middleware.

Builds middleware that validates req.params against a valibot schema and puts the parsed result on req.parsedParams for later steps to use.

On failure it does not call next(err) — it renders the 400 error page directly and ends the chain there.

Usage: the first step of almost every chain in this app. Schemas live in routes/schemas.js.

Middleware. Validates query params according to schema. Short circuits with 400 error if validation fails. Potentially updates req with parsedParams

this needs: { schema }

Middleware that overrides the specification with a local fallback for plan datasets that are not yet in a production-ready format in the specification table. When the fetched specification is for 'local-plan', it checks whether the current dataset exists in the plan-fallback.json config and, if so, replaces req.specification with the fallback data so that pullOutDatasetSpecification can extract the correct dataset-specific fields.

Middleware chain to process entities and prepare them for the issue table

Middleware chain to process the dataset specification and prepare it for the issue table, conditional execution on whether a specification exists