✨ NE:ONE Play ✨

This is a Hackathon implementation of the NE:ONE Play One Record Editor. Due to the nature of this code being written in 28 hours it is not pretty and pretty buggy. Therefore, this code is to be used at your own Risk, this code is not being maintained. A maintained and production ready version is currently in the planning.

Maintained fork — this fork is maintained by Cargolink. It combines the original hackathon project with the NE:ONE compatibility fixes from feature/aws, adds automatic server configuration with token refresh, and tests. Issues and PRs welcome. Original work by the authors credited below.

↑ Submission Video from Hackathon with Demo ↑

🏁 Getting Started

git clone https://github.com/aloccid-iata/neoneplay.git
cd neoneplay
npm i
npm run dev

Now connect to localhost:3000 and enter your One Record Object ID in the Search bar at the top.

The code was developed and tested (very limited testing 😅) using the Chrome Browser, therefore for the best experience use Chrome.

🔐 Preconfigured server (optional)

Instead of adding a server and pasting a token by hand in the settings dialog, the app can register one server automatically and keep its token fresh via the OAuth2 client credentials flow. Set these environment variables (all three required to activate; without them nothing changes):

Variable	Description
NEONE_PLAY_TOKEN_URL	OAuth2 token endpoint, e.g. http://keycloak:8989/realms/neone/protocol/openid-connect/token
NEONE_PLAY_CLIENT_ID	Client id for the client credentials grant
NEONE_PLAY_CLIENT_SECRET	Client secret
NEONE_PLAY_SERVER_HOST	ONE Record server host, default localhost:8080
NEONE_PLAY_SERVER_NAME	Display name, default NE:ONE
NEONE_PLAY_SERVER_PROTOCOL	http or https, default http
NEONE_PLAY_SERVER_COLOR	Card color, default #8b5cf6

The token request runs server-side (/api/token), so the client secret never reaches the browser and the identity provider needs no CORS setup. The token is refreshed automatically before it expires. Keep secrets in your environment or compose file, never in the code.

Run the tests with npm test.

☁️ Deploy the demo

The root Dockerfile builds a standalone production image. NEXT_PUBLIC_DEMO_MODE enables the in-browser demo mode (ships with PR #4; until that lands the flag has no visible effect) and is baked at build time, so pass it as a build arg:

docker build --build-arg NEXT_PUBLIC_DEMO_MODE=1 -t neoneplay-demo .
docker run -p 3000:3000 neoneplay-demo

cloudbuild.yaml builds and deploys the same image to Google Cloud Run (substitutions: _REGION, _SERVICE, _REPO for the Artifact Registry repository):

gcloud builds submit --config cloudbuild.yaml

One-time prerequisites on a fresh project, or the command above fails:

• The Artifact Registry repository named by _REPO must exist: gcloud artifacts repositories create cloud-run-source-deploy --repository-format=docker --location=<region> (or run gcloud run deploy --source . once, which creates it).
• The Cloud Build service account needs the Cloud Run Admin and Service Account User roles to deploy.

To preconfigure a server on the deployed service, set the NEONE_PLAY_* variables from the section above on the Cloud Run service (for example gcloud run services update <service> --update-env-vars ..., or via secrets); they are read at runtime, not build time.

🚧 Known Issues

• One Record Server has to have enabled CORS Headers
• When using One Record Servers without token authentication you need to expand the card to load the data (fixing this should just be adding a dependency to the useEffect Effect Array)
• Some Features only work after a HotReload, this can be done by just changing a random file (could be adding a semicolon) in the project and saving it (for example the arrow descriptors are only located correctly after a hot reload)
• Patch (Change) Requests only work on text fields outside of embedded objects. After committing a patch request the change is only displayed on servers without tokens, while on a server with a token the change is made but not shown in the UI. (sometimes patches don't work, in the hackathon there was not enough time for debugging)

🔎 Quirks

In the Hackathon the One Record Servers had a Bearer Token for Security Reasons. To demonstrate the NE:ONE Play Editor we asked for multiple servers to show how it could work with multiple industry players. We were given multiple servers, with the quirk that they all used the same Bearer Token, therefore in the Code (Settings.js file) there is a globalToken which is the Token for all of the hackathon servers. In the Hackathon this token was always filled in by hand as it had a lifetime of one hour.

✨ Development by

• Figma Design Prototypes: Man Bao Tran Nguyen
• Test Data Creation: Niclas Scheiber
• Software Implementation: Erik Goldenstein

---

If there are any questions, you are welcome to open an Issue, answers are not guaranteed. If you are interested in further exploring NE:ONE, NE:ONE Play or any other ONE Record related topics together, please feel free to contact Oliver Ditz (oliver.ditz@iml.fraunhofer.de) from the department of aviation logistics of the Fraunhofer IML.