giseldo/neodataset huggingface dataset:
Fix support e-mail

**As a** user 
<br>**I want to** get support by sending e-mail to support@nlx.io
<br>**so that** it's easy to get support

---

Current solution with external mail provider forwarding to Gitlab servicedesk stopped working.

**:white\_check\_mark: Acceptance criteria**

1.  E-mail addressed to support@nlx.io ends up in Gitlab Servicedesk

**:hammer\_and\_wrench: Proposed technical solution**

*   Use TransIP e-mail

Story points: 5.0
Filterable log messages for nlx-components

**As a** developer
<br>**I want to** have elasticsearch-readable log output on live environments
<br>**so that** I can filter through log individual log fields

**:white\_check\_mark: Acceptance criteria**

1. Logs outputted in JSON format for all NLX components

**:hammer\_and\_wrench: Proposed technical solution**

* Configure zap and logrus outputs to be json formatted

Story points: 2.0
Enhance visual link between overview and detail pane insight UI

**As a** user of the Insight UI
<br>**I want to** see some visual indication that something changes in detail pane when selecting another row
<br>**so that** my attention is drawn to the detail pane

---

Currently it is hard to see that content of detail pane changes due high similarity of content in all records

**:white\_check\_mark: Acceptance criteria**

1.  Visual indication when content of detail pane changes after selecting another record

**:hammer\_and\_wrench: Proposed technical solution**

* Add visual indication using :hover :active and maybe a border

**:link: Reference links**

*

Story points: 2.0
Directory UI doesn't give correct feedback for API link

**As a** user of the Insight UI
<br>**I want to** see some visual indication that url is copied
<br>**so that** I 

---

When hovering the icon to API url in directory UI, there is no indication to where it will lead.
Urgent because current UI gives no clue about what the user should do to use an API via NLX.

**:white\_check\_mark: Acceptance criteria**

1. When clicking the icon to API url in directory UI, there is feedback that the url is copied to clipboard

**:hammer\_and\_wrench: Proposed technical solution**

*

**:link: Reference links**

*



![Screenshot_2019-05-23_at_12.28.00](/uploads/e22fc703d23bc24c2175b9d5ad89d298/Screenshot_2019-05-23_at_12.28.00.png)

Story points: 3.0
Create sequence diagrams for automatic onboarding w/ admin dashboard and certificate generation

**As a** developer
<br>**I want to** have sequence diagrams on future systems
<br>**so that** I can understand their inner workings and work towards implementation

**:white\_check\_mark: Acceptance criteria**

1.  Sequence diagrams for onboarding with the admin dashboard and automatic certificate creation

**:hammer\_and\_wrench: Proposed technical solution**

* Sequence diagrams for goseq or websequencediagrams.com

Story points: 8.0
Add ElasticSearch, LogStash, Kibana to get insight in NLX sys logs

**As an** NLX developer
<br>**I want to** have ELK stack to get great insight in NLX sys logs
<br>**so that** I can find and analyse errors in an efficient manner
<br>**and** we can solve #556 

**:white\_check\_mark: Acceptance criteria**

1. ELK (ElasticSearch, Logstash, Kibana) deployed on our own NLX environments
1. All standard output from NLX components can be written to ELK
1. We can search / analyse those logs with Kibana

**:hammer\_and\_wrench: Proposed technical solution**

* For now quick 'n dirty on non-persistent storage
* Will wait for Haven to add persistent storage

**:link: Reference links**

*

Story points: 5.0
Make `go` available in gitlab shell runners

**As a** Developer
<br>**I want to** Have go available in $PATH in the gitlab shell runners
<br>**so that** golangci-lint can do it's job

**:white\_check\_mark: Acceptance criteria**

1.  This should be succeeding: https://gitlab.com/commonground/nlx/-/jobs/212261241

**:hammer\_and\_wrench: Proposed technical solution**

* Find out why the ansible role doesn't add go to PATH, or if it does, why golanci-lint doesn't have that same PATH. Then fix it.

Story points: 2.0
Create some initial sketches for the management-ui

**As an** administrator
<br>**I want to** configure the NLX components in a fancy dashboard
<br>**so that** I don't need the CLI after the initial configuration

**:white\_check\_mark: Acceptance criteria**

1.  We have some initial sketches what the dashboard could look like
1.  These initial sketches are the basis for some initial UI work



Intial sketches can be found on https://sketch.cloud/s/7dDVY

![image](/uploads/d9066acfa7ef114a955ed6366684aef9/image.png)
![image](/uploads/c8a6d457c8201810f43eb55eeb70b51c/image.png)
![image](/uploads/545a6aa3be282daa88fd6871c8e7f19d/image.png)


Story points: 3.0
Review app for NLX repo

**As a** PO
<br>**I want to** be able to judge merge requests for frontend in Review App environments
<br>**so that** I don't have to run the full app locally to review and get a more realistic preview

**:white\_check\_mark: Acceptance criteria**

1.  Review app added in pipeline
1.  Merge requests with frontend impact spawn a temporary environment
1.  New flow is documented
1.  New flow is demonstrated and understood by the whole team

**:hammer\_and\_wrench: Proposed technical solution**

* Complication is that we use multiple namespaces for deployment of multiple (demo) organisations. Let's try and add multiple namespaces by Review app
* Loadbalancers are seriously complicated - so we will keep internal trafic inside cluster (no public IP)

**:link: Reference links**

*

Story points: 8.0
Renovate bot for NLX repo

**As a** PO
<br>**I want** our repo dependencies to be automatically updated by Renovate Bot
<br>**so that** we are always up-to-date with minimal effort

---
Appears to be successful for DON repo, let's implement the same way for consistency

**:white\_check\_mark: Acceptance criteria**

1.  Renovate Bot proposes merge requests which are reviewed and merged manually.

**:hammer\_and\_wrench: Proposed technical solution**

*

**:link: Reference links**

*

Story points: 1.0
Implement log detail pane + pagination for the Insight UI

**As a** 
<br>**I want to**
<br>**so that**

**:white\_check\_mark: Acceptance criteria**

1. Remaining functionalities from #506
1. Remove search logs functionality - we don't support search in the API

**:hammer\_and\_wrench: Proposed technical solution**

*

**:link: Reference links**

*

Story points: 5.0
Insight API endpoint /fetch returns incorrect content-type

* URL  
`https://insight-api.test.voorbeeld-haarlem.nl/fetch`
* Response  
```
{"records":[],"page":0,"rowsPerPage":0,"rowCount":0}
```

**Expected**

Header `Content-Type` with `application/json` as value

**Actual**

Header `Content-Type` with `'text/plain; charset=utf-8` as value

**Add test!**

Story points: 1.0
Insight API endpoint /getDataSubjects returns incorrect content-type

* URL  
`https://insight-api.test.voorbeeld-haarlem.nl/getDataSubjects`
* Response  
```
{"dataSubjects":{"burgerservicenummer":{"label":"Burgerservicenummer"},"kenteken":{"label":"Kenteken"}}}
```

**Expected**

Header `Content-Type` with `application/json` as value

**Actual**

Header `Content-Type` with `'text/plain; charset=utf-8` as value

**Add tests!**

Story points: 1.0
Links in Navigation bar point to wrong environments

**As a** visitor of NLX.io
<br>**I want to** use the menu in relation to the environment that I'm in
<br>**so that** I won't get confused by the wrong links 

--- 
Depends on move to Gatsby (#540)

**:white\_check\_mark: Acceptance criteria**

1.  When you are on https://docs.test.nlx.io/ and click on "about" you should always go to right environment 
1.  Should also work for review envs

**:hammer\_and\_wrench: Proposed technical solution**

*  Small Javascript using Environment Variables   (env.json)

**:link: Reference links**

* [Existing script in Insight UI](https://gitlab.com/commonground/nlx/blob/9f0a69d05577be62e407724ffcb17549d5d86fff/insight-ui/docker/startup.sh) to expose environment variables from the Docker container to the browser's `window.env`

Story points: 2.0
Consistent licence information

**As a** PO
<br>**I want** it to be clear which licence is applicable to our code
<br>**so that** there can be no doubt about the license 

**:white\_check\_mark: Acceptance criteria**

1. Add individual licence statements to all code files
1. Make sure there is a licence defined in the root of the repository + README

**:hammer\_and\_wrench: Proposed technical solution**

*

**:link: Reference links**

*

Story points: 2.0
PoC: Administrator dashboard

**As a** developer
<br>**I want to** have a PoC for the administrator dashboard
<br>**so that** we have a clear picture of what (and how) we want to build the dashboard

**:white\_check\_mark: Acceptance criteria**

1. PoC showing setting up an inway with a single command (docker run)
2. Provide documentation describing the setup

**:hammer\_and\_wrench: Proposed technical solution**

* 

**:link: Reference links**

* #429

Story points: 13.0
Provide technical CHANGELOG

**As a** NLX user
<br>**I want to** see the changes between NLX versions
<br>**so that** I can foresee the upgrade path

**:white\_check\_mark: Acceptance criteria**

1. There should be a CHANGELOG available for NLX, automatically generated from commit logs
1. Instructions for devs, in contribution.md
1. Validated list of components and exact way to spell them (scopes)
1. Start with current version +1  (continue sequence)

**:hammer\_and\_wrench: Proposed technical solution**

* https://semantic-release.gitbook.io/semantic-release/

**:link: Reference links**

* https://gitlab.com/commonground/cg-design-system
* https://keepachangelog.com/en/1.0.0/

* TODO: setup gitlab token for semantic-release

Story points: 3.0
Make URLs in the context of NLX predictable

**As a** NLX user
<br>**I want to** have predictable URLs in the context of NLX
<br>**so that** a service can offer APIs that provide linked data

Currently URLs in NLX are structured as:

```
http://{outway}/{organization-name}/{service-name}
```

This structure makes URLs in NLX unpredictable as `{outway}` is different in every organization.

With this story we want to support request URLs in the following format: 

```
http://{service-name}.{organization-name}.services.nlx.local
``` 

by adding functionality to the outway. This makes URLs in the context of NLX predictable.


**:desktop_computer: How to demonstrate**

1. Start an outway
1. Set `HTTP_PROXY` env variable to the address of the outway
1. Use curl to make a request to http://{service-name}.{organization-name}.services.nlx.local
1. The request should be received by {service-name} of {organization-name}
1. Use curl to make a request to {outwayaddress}/{origanization}/{service} 
1. The request should be received by {service-name} of {organization-name}

**:white\_check\_mark: Acceptance criteria**

1. The outway forwards requests to hosts with the TLD `.services.nlx.local` to the specific service on NLX.
1. `HTTP_PROXY` is used
1. New feature is described in docs

 
**:hammer\_and\_wrench: Possible technical solutions**

**:question: Open questions**

1. Do we want requests on NLX to be explicit (`*.*.nlx.local`)? Or should we allow internet-routable hostnames te be fetched over NLX implicitly through a SRV record in the public DNS (`*.org.nl`) as well? ->Yes we should allow internet-routable hostnames te be fetched over NLX as a follow up story
1. Should we route non-NLX requests through the outway as well? Possible idea's:
    - Yes, but with a log in the txlog
    - Yes, but we should forward non-NLX requests to an organization proxy

**:warning: Possible problems**

1. Organization names with spaces and dots are not usable when we switch to a hostname, so we should introduce hostname-friendly slugs.

**:link: Reference links**

* PoC #508
* WIP https://gitlab.com/commonground/nlx/nlx/merge_requests/376
* WIP https://gitlab.com/commonground/nlx/draw-io/-/blob/master/concepts/OutwayProxySetup.drawio

**:microphone: Request for feedback**

* Joost (Kadaster)
* @sergei-maertens 

**:hammer\_and\_wrench: Proposed sequence diagram**
![OutwayProxySetup-Page-4](/uploads/11619c74167a5170eb2b6a3103067e41/OutwayProxySetup-Page-4.png)


Story points: 8.0
Add OAS specification for Outway Authorization

**As a** 
<br>**I want to**
<br>**so that**

**:white\_check\_mark: Acceptance criteria**

1. OAS document API between outway and authz adapter/service

**:hammer\_and\_wrench: Proposed technical solution**

* Add spec file to repository
* Link redoc or similar in the readme/docs

**:link: Reference links**

*

Story points: 3.0
Add documentation for Outway Authorization

**As a** 
<br>**I want to**
<br>**so that**

**:white\_check\_mark: Acceptance criteria**

1. Add document about outway autorisation to further reading
1. Questions by Amsterdam are addressed in the documentation

**:hammer\_and\_wrench: Proposed technical solution**

*

**:link: Reference links**

*

Story points: 5.0
Implement Outway Authorization based on PoC

**As a** nlx-user 
<br>**I want to** configure my outway to use a authorization service 
<br>**so that** calls going through my outway are authorized

**:white\_check\_mark: Acceptance criteria**

1. Require TLS connection between outway and autorisation server
1. Let authz _acknowledge_ headers, instead of adding them

**:hammer\_and\_wrench: Proposed technical solution**

*  Based on Ronald PoC


Story points: 5.0
Add instructions to use NLX with Docker for Windows

**As a** Windows user
<br>**I want to** have instructions to get started
<br>**so that** I don't have to switch to Mac or Linux to use NLX

**:white\_check\_mark: Acceptance criteria**

1. The 'Get started' section should be compatible with Windows 10

**:hammer\_and\_wrench: Proposed technical solution**

* https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
* https://www.vagrantup.com

**:link: Reference links**

* Documentatie van Berenschot: [Documentatie_050819.docx](/uploads/4138559d709720f7835eef34fa49b1d7/Documentatie_050819.docx)

Story points: 5.0
Add TLS between client and outway

**As an** nlx-user
<br>**I want to** secure traffic between my application and the outway
<br>**so that** nobody can snoop my data

**:white\_check\_mark: Acceptance criteria**

1. Outway can be configured with a self-signed certificate
1. Outway supports TLS connections from clients, TLS v1.2 and up
1. Outway requires the usage of TLS

**:hammer\_and\_wrench: Proposed technical solution**

*

**:link: Reference links**

*

Story points: 5.0
[PoC] outway proxy

**As a** NLX developer
<br>**I want to** know if the outway proxy design is feasible
<br>**so that** I can improve the design and work towards a new way of handling requests over NLX

**:white\_check\_mark: Acceptance criteria**

1.  Outway handles traffic using HTTP_PROXY setup

**:hammer\_and\_wrench: Proposed technical solution**

*

**:link: Reference links**

*

Story points: 8.0
Implement Insight design

**As a** user
<br>**I want to** use a consistent and future proof ui
<br>**so that** I have a reliable user experience.

**:white\_check\_mark: Acceptance criteria**

1. Implement design (landing, scan, logs, wizard) scoped to design link
1. Create generic components when applicable (add to design system)
1. Design is not optimized for mobile but the content should accessible
1. Current dependencies should be removed (base.css, MaterialUI & jQuery) should be removed
1. Implement using `styled-components`

**:link: Reference links**

Design: https://sketch.cloud/s/wxR9w/p/insight

Story points: 8.0
Inway: use assert package in go tests

**As a** developer
<br>**I want to** use `"github.com/stretchr/testify/assert"` to do my assertions  
<br>**so that** I conform myself to the go standard

**:white\_check\_mark: Acceptance criteria**

1. 

**:hammer\_and\_wrench: Proposed technical solution**

*

**:link: Reference links**

*

Story points: 2.0
[PoC] Authentication service for the outway

**As a** NLX user
<br>**I want to** configure my own authentication service to be used by the outway
<br>**so that** requests made through my outway are authenticated.

**:white\_check\_mark: Acceptance criteria**

1.  Authentication service definition in gRPC
1.  Authentication service is configurable on the outway
1.  When a authentication service is configured each request to the outway will be verified using the configured service.  
1.  Outway logs user-specific headers set by the authentication service.
1.  Outway strips user-specific headers before sending it to the inway of a service that is not within the organization of the outway.
1.  Reference implementation of the authentication service based on hardcoded users.
1.  NO docs / NO unit tests

**:hammer\_and\_wrench: Proposed technical solution**

* Outway sends authentication request to the authentication service containing:

  * Destination organization
  * Destination service
  * Request path
  * The contents of `X-NLX-Authentication` header (arbitrary text)
  * Transactionlog id (generated by the outway)

* Authentication service decides whether the request may continue, and optionally provides values that the outway can set onto the outgoing request for the fields:

  * `X-NLX-Requester-User`
  * `X-NLX-Requester-Claims`

**:link: Reference links**

* nlx/design/authentication-within-organizations.md

Story points: 13.0
Draw NLX in typical infrastructures of gov organisations

**As an** infrastructure manager
<br>**I want to** know how NLX fits in typical infra architectures
<br>**so that** I can decide to integrate NLX in my organisation

**:white\_check\_mark: Acceptance criteria**

1. At least three different, typical infrastructure overviews with NLX implemented
1. Created in Archimate

**:hammer\_and\_wrench: Proposed technical solution**

*

**:link: Reference links**

*

Story points: 3.0
Exclude TLS v1.2 support

**As a** Architect 
<br>**I want to** use TLS version v1.3 and exclude v1.2
<br>**so that** NLX works faster, is more secure and complies with the advice of the Forum Standardisation (https://www.forumstandaardisatie.nl/sites/bfs/files/FS%20181010.3A%20Forumadvies%20TLS%201.3.pdf)

**:white\_check\_mark: Acceptance criteria**

1. All inter-nlx components : minimum TLS v1.3
1. `Client -> Outway` & `Inway -> API` : minimum TLS v1.2  
1. Exclude unsafe cyphers for v1.2
    
**:hammer\_and\_wrench: Proposed technical solution**

* exclude TLS v1.2 support and heb exclude the following ciphers:
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)   ECDH x25519 (eq. 3072 bits RSA)
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)   ECDH x25519 (eq. 3072 bits RSA)
- TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
- TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
- TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
- TLS_RSA_WITH_AES_256_CBC_SHA (0x35)  
- TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)   ECDH x25519 (eq. 3072 bits RSA) 
- TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)   

**:link: Reference links**

* https://www.forumstandaardisatie.nl/standaard/tls
* https://www.forumstandaardisatie.nl/sites/bfs/files/FS%20181010.3A%20Forumadvies%20TLS%201.3.pdf

**QUESTIONS:**  
- can we update to 1.3 without causing failures in the current eco system?  
   *yes, see: https://gitlab.com/commonground/nlx/nlx/-/issues/492#note_363856136*

Story points: 2.0
Version numbers shown in FE applications

**As a** user
<br>**I want to** see which version is running when opening one of the NLX apps
<br>**so that** I don't work under the wrong assumption

**:white\_check\_mark: Acceptance criteria**

1. Version number & commit hash is visible for txlog-ui, directory-ui and insights-ui in javascript console (table).
1. Use https://directory.demo.nlx.io/version.json


Story points: 2.0
Inway: compare SELF_ADDRESS with certificate domain

**As a** NLX user
<br>**I want to**  prevent an inway to start when a mismatch exists between self_adddress and certificate
<br>**So that** I cannot config an inway which will never be available

**:white\_check\_mark: Acceptance criteria**

1. Inway prints a error message when there is a mismatch between `SELF_ADDRESS` and certificate
1. the inway fails during start

**:hammer\_and\_wrench: Proposed technical solution**

*

**:link: Reference links**

*

Story points: 2.0
Version numbers shown in containers

**As a** user
<br>**I want to** see which version is running when starting a NLX container
<br>**so that** I don't work under the wrong assumption

**:white\_check\_mark: Acceptance criteria**

1. Version number & commit hash is available in every image (inway, outway, insight-api, tx-api, txlog-api, directory-inspection-api, directory-registration-api, directory-ui, insight-ui, txlog-ui)
1. Version number & commit hash is shown in terminal when starting one of the above containers
1. This information should be added for every commit

**:link: Reference links**

* Frontend part is described in #486
* Related to #460

Story points: 3.0
Api point url and api response in the API documentation are difficult to read (increase contrast)

**As a** API user
<br>**I want to** be able to easily read api point url and response example
<br>**So that** I can understand API requirements

**:white\_check\_mark: Acceptance criteria**

1.  The api point url and the response are easy to read

**:hammer\_and\_wrench: Proposed technical solution**

- See if we can get the styling to work as default: http://rebilly.github.io/ReDoc/#operation/updatePetWithForm
- Could be that there is still custom styling overrides active.
- If above doesn't work, change text color to black


**:link: Reference links**

*  https://directory.demo.nlx.io/documentation/Enable-U/DemoService#operation/callStockDilutionUsingGET

![image](/uploads/fa37b837a4635e2a0a49397c710c7c47/image.png)

Story points: 2.0
Ensure high availability (HA) for all environments

**As a** dev, ops
<br>**I want to** have access to a highly available central services
<br>**So that** I can sleep at night

**:white\_check\_mark: Acceptance criteria**

1. Increase replica count in k8s deployment for all central services

**:hammer\_and\_wrench: Proposed technical solution**

* Use LBaaS feature of Fuga R2 (as mentioned by @GeertJohan in the comments)

**:link: Reference links**

*

Story points: 2.0
Document how to use the log level parameter for inway and outway

**As a** NLX user
<br>**I want to** know how I can set the log level of a inway and/or outway
<br>**So that** I can debug my inway/outway

**:white\_check\_mark: Acceptance criteria**

1.  The LOG_LEVEL environment variable is described in the docs (startup guide)
1. Update:  

* https://docs.nlx.io/try-nlx/management/getting-up-and-running
* https://docs.nlx.io/try-nlx/management/consume-an-api
* https://docs.nlx.io/try-nlx/management/provide-an-api
* https://docs.nlx.io/try-nlx/config-file/consume-an-api
* https://docs.nlx.io/try-nlx/config-file/provide-an-api

Story points: 1.0
Evaluate access rights for repo changes

**As PO** 
<br>**I want to make sure access rights for all nlx repos are "least privilege"**
<br>**so that only intended people can alter our production namespace**

**:white\_check\_mark: Acceptance criteria**

1.  Changes in infra on namespace / node level are reserved for ops specialists
2.  Changes to core components are reserved for maintainers and owners
3.  Proposal in slack

**:hammer\_and\_wrench: Proposed technical solution**

*

**:link: Reference links**

*

Story points: 2.0