giseldo/neodataset huggingface dataset:
Sort logs latest first

**:pencil2: Description**

**As a user of the Insight app** 
<br>**I want to see the newest log entries first**
<br>**so that I don't have to click to the last page to see that what I just came for**

**:white\_check\_mark: Acceptance criteria**

1. Logs should be sorted descending by the `created` property

**:hammer\_and\_wrench: Proposed technical solution**

*

**:link: Reference links**

*

Story points: 1.0
Implement directory design

**As a** nlx user 
<br>**I want** a future proof directory
<br>**So that** I will keep using it

**:white\_check\_mark: Acceptance criteria**

1. Implement [design](https://sketch.cloud/s/wxR9w)
1. Create generic components when applicable
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**

* https://sketch.cloud/s/wxR9w

Story points: 8.0
Make sure the Insight app unregisters old service workers automatically

Bugreport: Old service worker in insight app causes app to load with blank screen
- When loading the insight app (https://insight.demo.nlx.io/) in Chrome, I get a blank screen and a few errors.
- Inspection showed that there was an old service worker still active, somehow causing the app startup to fail.
- After manually unregistering the service worker, the app worked as expected.

Proposed solution: Make sure the Insight app unregisters old service workers automatically

![Screenshot_2019-01-18_at_21.39.14](/uploads/0d7fa5bd1759c4d98c31a4e4241b9f02/Screenshot_2019-01-18_at_21.39.14.png)

![Screenshot_2019-01-18_at_21.39.23](/uploads/1dbbead0099b21686ad75a836491a308/Screenshot_2019-01-18_at_21.39.23.png)

![Screenshot_2019-01-18_at_21.39.46](/uploads/3a7e17c51fb3660315fd0b4911314b09/Screenshot_2019-01-18_at_21.39.46.png)

Story points: 1.0
Cleanup offline services in directory after 14 days

**:pencil2: Description**

**As a** NLX user

**I want to** have an overview of active services on the directory ui

**So that** I know which services I can rely on

**:white\_check\_mark: Acceptance criteria**

1. Directory should clean up inways that are offline for 14 days
1. This period should be reflected in the docs
1. The 'cleanup threshold' should be configurable when starting the directory container

**:hammer\_and\_wrench: Proposed technical solution**

* Store the  'last online time' per service in the database


Story points: 3.0
Add contact details to service config

Add contact details to service configuration.

Perhaps two e-mail addresses would suffice:

* tech   (for questions from NLX management, this one is not public)
* public (for questions from NLX end users to other end users, which is published in directory UI)

Can be optional, so non-breaking (for now).

Tasks:

* Create design
* Update database
* Update directory registration/inspection API
* Update inway
* Update documentation
* Implement design


**Design**
<br>https://sketch.cloud/s/wxR9w/p/directory
- Ignore the telephone number (depiction of possible extra contact info in the future).
- Ignore other design changes in directory, this will be applied in a different ticket.

Story points: 1.0
Fix font in svg used in docs

https://docs.test.nlx.io   

On Safari/MacOS the text is shown in wrong font

![Screenshot_2019-01-03_at_19.37.19](/uploads/4a6c79df7a2c04f1ec401950aa6f4a72/Screenshot_2019-01-03_at_19.37.19.png)

Story points: 1.0
Move marketing site nlx.io from Github to Gitlab

**:pencil2: Description**

**As a** developer

**I want to** have all NLX related code available on GitLab

**So that** development is easier

**:white\_check\_mark: Acceptance criteria**

1. The CI / CD pipeline should be configured on GitLab
1. The commit history should not be preserved
1. Deployment should be available on `nlx.io`
1. Deployment is only for PROD. Other environments will be configured as part of another story.

**:hammer\_and\_wrench: Proposed technical solution**

*

**:link: Reference links**

* https://github.com/VNG-Realisatie/nlx.io 
* https://gitlab.com/commonground

Story points: 3.0
Design a versioning policy

**As a** customer
<br>**I want** to know what the version policy of NLX is
<br>**so that** I know what measures to take for internal maintenance policy

**:white\_check\_mark: Acceptance criteria**

1.  We have a page in our documentation that describes how we release and what we expect from system administrators.
1.  We have internal documentation that describes how we handle breaking changes and our version skew policy.

 **:link: Reference links**

- [X-Road](https://confluence.niis.org/display/XRDKB/Release+Notes) uses a simple semantic version system, also documented in more detail [here](https://github.com/nordic-institute/X-Road-development/blob/master/DEVELOPMENT_MODEL.md#34-publish). In Finland they recommend their production users to update within four weeks after the central server has been updated.
- [Chrome](https://www.chromium.org/getting-involved/dev-channel), has release channels
- [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/docs/concepts/release-channels), has release channels
- [NodeJS releases](https://nodejs.org/en/about/releases/), uses semantic versioning with LTS
- [Ember.js releases](https://emberjs.com/releases/), uses semantic versioning with LTS

Story points: 3.0
Add info logging to the inway

As a user who is configuring a inway I would like to see logging of the inway so I can debug issues which I may have during implementation.  

Log:
*  Certificates loaded.
*  Calls to the directory.
*  Service-config being loaded.
*  Calls coming from a outway.


Acceptance criteria:

- More verbose logging of NLX components (status logs etc.)

- Logging is easily obtainable through for example `tail -f`

- The documentation describes how to view logs


Story points: 2.0
Add info logging to the outway

As a user who is configuring a outway I would like to see logging of the outway so I can debug issues which I may have during implementation.  

Log:
*  Certificates loaded
*  Calls to the directory
*  Calls made to the outway

Acceptance criteria:

- More verbose logging of NLX components (status logs etc.)

- Logging is easily obtainable through for example `tail -f`

- The documentation describes how to view logs

Story points: 2.0
Add Getting started guide to docs.nlx.io

Getting Started contains the following steps:
- Preparing
- Certificates
- Using a service
- Start an outway
- Providing a service
- Start an inway
- Transactionlogs

Create example based on Docker Compose.
Reuse docker compose.yml made by @RonaldKoster 

As a Getting Started (walkthrough) with parts, like: https://docs.docker.com/get-started/

Every part needs a verification step (check if your action went well).

Story points: 8.0
Update documentation based on user feedback


Check where this information needs to be added in the docs and 
update the documentation to make it clear that:

- An outway is needed to contact an inway.
- How to mitigate problems with containers that are tagged with :latest.
- How to check if your inway/outway is running.
- The directory exists and that the services offered by an inway can be published in the directory.
- The directory can be used to check if a service is online.
- That localhost on a docker container does not resolve to the hostmachine.

Story points: 3.0
Clarify current situation of environments and targets audiences (with visual)

- Create clear description of current target audiences, environments
- Markdown file available on gitlab
- Relevant visuals available
- Clear name & versioning convention incl url
- Show how this relates to build/deploy pipelines
- Plan how to communicate to target audiences

NLX devs have their own flow with several public environments, next to the public environments ment for demo, pre prod and production.

It helps to clarify which is which, including some visual that shows flow for audiences.

Rough sketch  (won't be accurate in current form, but exactly that is the problem - needs clarification)
![Screenshot_2019-01-03_at_20.11.02](/uploads/4d1b5305a9ac627a9fd99dd9ef8c8e0e/Screenshot_2019-01-03_at_20.11.02.png)

Story points: 5.0
Update gitlab runner go version to 1.11.4

We want to keep using golang:1-alpine in our docker images because we don't want miss any security updates. The latest version of go currently is 1.11.4. and this version produces different hashes as previous versions when running go mod tidy. Because of this our gitlab runner will not pass go.mod.tidy test.  

We need to update our git lab runner to use go version 1.11.4 so we can keep using golang:1-alpine in our docker images

Story points: 1.0
Create an business overview of 'how to start with NLX'

**As a** Business representative
<br>**I want to** have a business overview of NLX
<br>**So that** I can asses what I need to implement NLX and what the business benefits are after implementing NLX.
<br>*NLX documentation so far is clear for (most) developers. What i see is that almost every municipality that is interested in connecting with NLX is searching for a functional (business) overview of 'how to start with NLX?'.
In most municipalities they have to start a project and need to find a budget before they can start (...). So the business needs to understand it first, before some technical people will make a start. For Business people/management the current documentation is not sufficient.*

**:white\_check\_mark: Acceptance criteria**

**The Business overview is available on https://docs.nlx.io/ and makes clear:**
1. What kind of people do i need (what kind of knowledge is required)?
2. What environment(s) do i need?
3. What kind of tools/functionaly do i need in my municipality to connect with NLX?
4. What will be the investment?
5. How much time is estimated for a first connection, a PoC?
6. Which connections are easy tot start with?
7. Acceptance of the business overview by @dennisdewit! 
8. What the business benefits are after implementing NLX!

**:hammer\_and\_wrench: Proposed technical solution**

* business overview document in Markdown
* overview in public available Archimate model

**:link: Reference links**

* https://docs.nlx.io/
* 


Story points: 8.0
Bump dependency due to CVE

Dependency with high severity [CVE-2018-16469](https://nvd.nist.gov/vuln/detail/CVE-2018-16469)

Package merge
Vulnerable versions: < 1.2.1
Patched version: 1.2.1

https://gitlab.com/commonground/nlx/blob/master/txlog-ui/package-lock.json#L3980
https://gitlab.com/commonground/nlx/blob/master/txlog-ui/package-lock.json#L7022

Story points: 1.0
Insight-ui RDW backend demo api returns 500

Possible solutions:

1. In depth configuration Check @GeertJohan [timebox 3 uur]
2. Get rid of navigation item & long term solution by IRMA team [1 point]

After selecting rdw from the list and scanning QRCode the api call to RDW getproof api point returns 500.

api url (jwt from this sample will expire)
https://irma-api.demo.voorbeeld-rdw.nl/api/v2/verification/jZpQZz9AmUqMSeB5GTZDZIpBfp4iMscKtgNvVTyAo6nW/getproof

response received: {
    "error": "EXCEPTION",
    "status": 500,
    "description": "Encountered unexpected problem",
    "message": "io.jsonwebtoken.SignatureException: Unable to calculate signature using RSA PrivateKey. Could not sign data"
}

![image](/uploads/160f0eb311515d99bf5c4b765a750b98/image.png)

Story points: 1.0
Add all available service data from API to NLX management directory

Show all date we have in the directory detail drawer.
- Button to documentation
- Button to specification
- Support addresses
- Flip the status and API type below the title. Status first, then API type (because there is not always an API type to be shown)
- Note: the inline error alert is positioned above the buttons.


**Acceptatie criteria**

1. All data from API result is placed on detail pane as specified in attached design
1. Icon on docs en specs  button is smaller than normal


![image](/uploads/18da4517c8f12f0455522a4111a9cc59/image.png)
![image](/uploads/8ce8b04f17b202ef897f8d262233248a/image.png)

Story points: 2.0
Styled dropdown in settings

We use a select component in the settings, but it is without (dark mode) styling. See:

![image](/uploads/5aa0a96adf562ca127e7a6f1b3c8bbcb/image.png)

We have a styled react-select component in the appstore, but it is not in de design system yet. <br>
![image](/uploads/071b94a8cbb741011796cc630f07681e/image.png)


**Acceptance criteria**


1. Make component available (from appstore) in design system
1. White dropdown on settings page replaced with the new component

Story points: 3.0
Empty states for collapsibles

The empty states within collapsibles are in regular texts right now. This should be in `<small>` text, to make it visually clear that it is not content.<br> Also, the text has a hover and active state, but it is not clickable. It should not have any interaction states.

**Acceptance criteria**

1. All empty states styled as empty states

Current situation:<br>
![image](/uploads/2e7f0f37efebb748ae2f2eadd5a47ebb/image.png)
![image](/uploads/0a9542ecfab89e7b8299c92dd425dd8c/image.png)

Design:<br>
![image](/uploads/7cbc4d48b2b1cd2e75f04a280b3356a4/image.png)

Story points: 1.0
Move settings menu item below

The settings menu item should be secundair, shown at the bottom.<br>
Note: there is a spacing of `1rem` between the bottom of the navigation and the lowest menu item.

![Navbar_Copy](/uploads/bdb071f4c4b8cce559d596f9732ea4e7/Navbar_Copy.png)
![image](/uploads/81bf2254e0bc6691439a78789c904aa6/image.png)

Story points: 1.0
Make sure UI represents actual state after actions

**As a** _user_
<br>**I want** the UI to automatically update after an action
<br>**so** I don't have to manually refresh or open the service detail to see the actual state

Actions:

- request access
- approve access request
- reject access request
- retry access request after fail
- revoke access

-- 
Out of scope: updating list of orgs with access after granting access


**:desktop_computer: How to demonstrate / e2e test(s):**

1. 

**:white\_check\_mark: Acceptance criteria**

1. After actions listed above, show new state in frontend


**:link: Reference links**

1.

**Implementation**

- API's should give new state as result on the call

Story points: 3.0
Combine inspection and registration API into directory API

**As a** maintainer
<br>**I want** to combine inspection and registration API into one new directory API
<br>**so** that the whole setup becomes more easy to understand and less work to maintain 

**:white\_check\_mark: Acceptance criteria**

1. Inspection and registration API combined into new directory API
1. This should not be breaking
1. Add deprecation warning to the directory registration api URL and directory inspection api URL flags both will be replace by a single directory API url
1. Reuse a fixed IP of the registration/inspection API for the combined directory API so that the existing firewalls rules still work.
1. Update the IP reference information on docs.nlx.io


**:link: Reference links**

1.

Story points: 13.0
Proxy browser traffic to Mngt API through Mngt UI

**As a** sysadmin
<br>**I want** to easily setup NLX Management
<br>**so** that I cannot make any mistakes and save some time

**:white\_check\_mark: Acceptance criteria**

1. Connection from browser (via LB) to Management API is no longer needed / possible
1. Remove nginx config
1. Setup go project
1. Use go static file server
1. Setup reverse proxy fpr /api /oidc
1. html/css/js are embeded in the executable. Serve actual files when developing
1. build go binary in docker file
1. update helm chart

**:tools: Technical implementation**

- Management UI changes from Nginx to Go server with html/css/js
- Requests from browser to Management API goes through Management UI

IST:
![Screenshot_2020-10-19_at_18.41.49](/uploads/9eb6ec5d0ab06e7bfbe2ef12209ef600/Screenshot_2020-10-19_at_18.41.49.png)

SOLL:
![Screenshot_2020-10-19_at_18.42.11](/uploads/be86a7324c6bb50f42c91ce284967147/Screenshot_2020-10-19_at_18.42.11.png)



**:link: Reference links**

1.

Story points: 5.0
Migration to Postgres DB from ETCD

**As a** developer
<br>**I want** to use a database type which is more suited for NLX management
<br>**so** that efficiency is increased

Currently we use an ETCD database. As the feature list of NLX management becomes more complete we are realsing that ETCD, which is a key value database, might not be the right choice. Objects like services, access requests, access grants are tightly related to eachother and storing these objects in a key value database is making less and less sense.

Replacing the key value database with a relational database seems like the right choice. 

With a relational database we can:

* easily retrieve related objects adn therefore greatly simplify the management API codebase
* improve data integrity


**:desktop_computer: How to demonstrate / e2e test(s):**

1. 

**:white\_check\_mark: Acceptance criteria**

1. Support for SQL type databases (mysql, msql, postgres), avoid database specific functionality.
1. ETCD database is replaced by postgress
1. Management API executable can do it's own migrations
1. Support for TLS on database connection 
1. User GORM as ORM (https://gorm.io/)
1. Support SQLite for development

Implementation

1. Use migrate (https://github.com/golang-migrate) for migrations
1. Migration is embeded in the management API  


Technical implementation

1. Start management API with `serve` command to serve API 
1. Start management API with `migrate` command to do migrations


Tasks:

1. [x] Create datamodel
1. [x] Create migrations
1. [x] Update helm charts / deployments
1. [x] Update documentation
1. [x] Implement running migrations using the binary
1. [x] Package migration files into the binary 
1. [x] Implement GORM in management-api
1. [x] Solve access request locking with new database
1. [x] Check which GRPC calls require DB transactions
1. [ ] Use SQLite for testing
1. [ ] Clean demo environment (volume claims, tokens, secrets)

**:link: Reference links**

1.

Story points: 20.0
Show different counter when there are 0 access request

When there are 0 access request, the regular counter can be shown in the collapsible. <br>
Only show the notification bubble counter when there is 1 access request or more.<br>
See designs attached.


![Group_110](/uploads/8f1484c0fdd470924beb96199e038f4c/Group_110.png)

Story points: 1.0
Display warning when no organisation inway is selected

**As an** provider of services
<br>**I want** a very annoying and clear warning when I do not have an inway selected to receive incoming access requests
<br>**so** that requesting organisations can submit their access requests

**:desktop_computer: How to demonstrate / e2e test(s):**

1. 

**:white\_check\_mark: Acceptance criteria**

1. On starting the application: when an organisation offers at least one service and does not have an organisation inway configured, a system warning should be shown on every page.
1. Check if the banner should still be visible: when updating the organization inway, when update/add/remove a service.

Note: we will need to update this logic when we implement delegation

**:link: Reference links**

1.

**:unicorn: Design proposal**
- Non dismissible banner on top (as part of the header?)
- Visible on all pages
- Stays until an organization inway is chosen
- The link goes to the settings page
- NLX management specific component
<br><br>Old design:<br>[/uploads/2c34ae5b9a4e00c0d3fe7149a4e0b898/Banner.png]()
<br><br>New design:<br>![Artboard_Copy](/uploads/8c3b09701a3da5b50c9e1c0cd1f9b4e0/Artboard_Copy.png)

Story points: 3.0
After revoked access grant, new request  should be possible

**As a** user of a requesting organisation
<br>**I want** to be able to request access again after my access is revoked
<br>**so** that I can retry after I've fixed the reason over which my access was revoked

Currently, when org B revokes access to a service, org A  cannot request access again.
This is even worse since the UI behaves as if you can request access, although the flow won't work.


**:white\_check\_mark: Acceptance criteria**

1. After access to a service is revoked, a new request for access to that same service can be made


**Implementation**

1. Access request state has to be in sync on both sides, this requires a poll mechanism that polls until resolved
1. After access granted, this grant needs to be exchanged and stored on requesting side


**:link: Reference links**

1.![Toegang_ingetrokken](/uploads/f0f66a2ab2d9a5666ede814f01a18adf/Toegang_ingetrokken.png)

![Toegang_ingetrokken_directory](/uploads/049c2380f0386eaad36534b91cafb736/Toegang_ingetrokken_directory.png)

### Insights and TODO's

A `service` has `latestAccessRequest` and `latestAccessProof`. When access has been rejected, the access proof will get a `revokedAt` property.  
This would make it possible for us to show a "Request access" button to create a new access request.

However, if a new access request is created, the `latestAccessProof` is still there. We need it to be there to display the right data, but it makes it difficult to show the state of the **new** access request.

We cannot compare the `revokedAt` date with the `createdAt` date of the new access request, because these dates are created by different clocks (systems).

- [ ] Therefore (and maybe other reasons) we need to set a `accessRequestId` prop on the `accessProof` object.
- [ ] Then we can update the frontend (`directoryServiceAccessState`) to show the correct things on screen.

Story points: 5.0
Set the new 'permissions' policy header

**As a** sysadmin
<br>**I want** the NLX frontend to have complete security headers
<br>**so** that our hygiene is tip top

Set the 'permissions' header in all our frontends.
More important for public frontends than the Management UI

We do not allow anything. All permissions disallowed.

**:white\_check\_mark: Acceptance criteria**

1. Headers set

**:link: Reference links**

1. https://scotthelme.co.uk/goodbye-feature-policy-and-hello-permissions-policy/

Story points: 2.0
Enable insight UI configuration when using NLX Management

**As a** beheerder
<br>**I want** to be able to use the insight UI when using NLX Management
<br>**so**

This is part of #1024. Before working on this, discuss with FE, BE & designer how we will solve this.

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

* The NLX Management should be sufficient to setup an environment to give the 'official NLX demo' (parkeervergunningen app), without having to use `nlxctl`

**Settings to be added to the NLX Management settings page**

- InsightAPIURL
- IrmaAPIURL

**:link: Reference links**

1.

Story points: 3.0
Retry a failed access request

**As a** nlx management user
<br>**I want** to be able to retry a failed access request
<br>**so** that I do not get stuck in a dead lock

![Screenshot_2020-09-29_at_11.35.21](/uploads/f446b06497cebe671abaf96d3f2f2f88/Screenshot_2020-09-29_at_11.35.21.png)

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. Pressing "Probeer opnieuw" will retry the access request
1. After pressing "Probeer opnieuw" the error Alert component disappears and the error message in the request access block changes to a spinner
1. On error while retrying, show toaster with error. Reset UI to initial state.
1. State should automatically update in UI of requesting organisation (without refresh)

**:link: Reference links**

1.

Story points: 3.0