From 41a3af8e7ec8b674610cb7d5293712fc1e4fd736 Mon Sep 17 00:00:00 2001
From: Alan Cruikshanks <alan.cruikshanks@gmail.com>
Date: Thu, 8 Feb 2024 09:36:12 +0000
Subject: [PATCH] Add pre back into protected environments

https://eaflood.atlassian.net/browse/WATER-4351

The project comes with an inbuilt mechanism to configure routes to not be available in protected environments, for example, production.

You can see this in `app/routes/data.routes.js`. Both `/data/seed` and `/data/tear-down` are configured to be `excludeFromProd`.

How this works is during startup our `app/plugins/router.plugin.js` calls `app/services/plugins/filter-routes.service.js` which handles filtering out those routes that should not be added when running in a protected environment.

To be honest, `excludeFromProd` is a bad name because it could be any environment we add to this

```javascript
function _protectedEnvironment (environment) {
  return ['prd'].includes(environment)
}
```

When this was first implemented `pre` was included so we could confirm routes were not available prior to shipping to production. However, in [Create endpoint to generate fake data](https://github.com/DEFRA/water-abstraction-system/pull/347) we took it out so we could get this fake data generator to work. It needed to be in `pre` because it generated data based on real bill runs.

Clearly we weren't on the ball because we didn't even bother to update the comments which still exist

```javascript
 * So, we use this service to ensure any endpoint that is still being worked on is not available when the API is
 * running in production. We also include pre-production in our protected environments so we can test and ensure
 * an endpoint does not get registered as part of our release testing and sign-off.
```

Since that time the fake data generator is no more and we need to be able to test again that routes (and therefore pages) are not accessible in production. Hence, we need to add `pre` back into our list of protected environments.