giseldo/neodataset huggingface dataset:
Provider can see its orders

**As a** admin of NLX Management of a [Delegatee]
<br>**I want** to see my orders  
<br>**so** I have the same insight as my [Delegator(s)]

**:desktop_computer: How to demonstrate / e2e test(s):**

1. Open NLX Management as an Delegator
1. Add a new order
1. Open NLX Management as the designated Delegatee
1. See that the new order is missing
1. Click on the 'fetch order' button
   - When clicking the button, the management api will check all organizations for new orders for me
1. Go to 'Opdrachten' list view and see the newly added opdrachten

**:white\_check\_mark: Acceptance criteria**

1. The delegatee will only fetch his own orders
1. It should be possible to retrieve the orders when directory is down
   - Do this similarly to how we do it in the outway
1. Sort same as overview of delegator: by valid until desc

**design**

See below in comments

Story points: 5.0
Add values.schema.json to our helm charts

**As a** developer
<br>**I want** to be able to validate my helm values
<br>**so** that I can catch mistakes before deploying


**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. values.schema.json file added to all our public charts (nlx-inway, nlx-outway, nlx-management)
1. Validate using `helm lint` (https://helm.sh/docs/topics/charts/#schema-files)

**Notes**

- Reply from Conduction on the tooling they use that requires these value files:  
> "Wij gebruiken zelf Dashkube, maar bijvoorbeeld Rancher, Red kuber, Open shift, Azure dashbashboard en bitnami ondersteunen dit volgens mij ook"

**:link: Reference links**

1. https://austindewey.com/2020/06/13/helm-tricks-input-validation-with-values-schema-json/

Story points: 5.0
Remove horizontal lines on log in screen (minor usability issue)

This issue came up multiple times now, so we better fix it. I actually became victim myself last week, so that says enough ;)

The horizontal lines makes it look like inputs, but they are purely decoration. By removing them, this is no longer an issue.

![image](/uploads/7eb753676c6e520ca130ce15e4f8a89b/image.png)

Story points: 1.0
Enable basic access authentication for NLX management

**As a** new interested developer
<br>**I want** to be able to use basic access authentication in NLX management 
<br>**so** I do not need OpenID Connect provider to get up and running

**:desktop_computer: How to demonstrate / e2e test(s):**

1. 

**:white\_check\_mark: Acceptance criteria**

1. able to choose during installation between basic auth and OIDC (= default setting)
1. change docs to match new option
1. login page will be included in NLX management
1. remove DEX from NLX try me
1. local development will use basic auth. All other env. will use OIDC
1. edward must install nlx on his laptop


**:link: Reference links**

1.

Story points: 8.0
Simplify NLX Try me setup

**As a** developer
<br>**I want** to use a simplified NLX setup
<br>**so** I can easily experiment with all NLX functionality

**:desktop_computer: How to demonstrate / e2e test(s):**

1. 

**:white\_check\_mark: Acceptance criteria**

1. Replace using the Directory from the `demo` environment with a local directory  
- custom CA
- directory registration API
- directory inspection API
- directory monitor

2. Running `docker compose up` should be sufficient to run the complete setup
3. Update the [Try me](https://docs.nlx.io/try-nlx/introduction) documentation section, to reflect these changes
4. Move 'Retrieve a demo certificate' to another section of the documentation

**:link: Reference links**

1.

Story points: 5.0
Automatically test NLX Try me setup

**As a** developer
<br>**I want** to use a simplified NLX setup
<br>**so** I can easily experiment with all NLX functionality

**:desktop_computer: How to demonstrate / e2e test(s):**

1. 

**:white\_check\_mark: Acceptance criteria**

1. Enable setting an organization inway via the NLX ctl
1. Add `docker compose up` command to the CI, perform a HTTP request using the outway to the inway and verify if the response is correct.
1. Trigger the pipeline from the NLX repository for every commit on the master branch. As we do with the '[Trigger packaging build](https://gitlab.com/commonground/nlx/nlx/-/pipelines/300996356)' job.
1. Post message in slack if the pipeline for 'Try NLX' fails. The same kind of message as we have for a failed build on the `master` branch of NLX.

**:link: Reference links**

1.

Story points: 5.0
Enable transaction logs for the Try NLX setup

**As a** developer
<br>**I want** the transaction log to be enabled by default when following the docs
<br>**so** I can experiment with the transaction logs functionality

**:desktop_computer: How to demonstrate / e2e test(s):**

1. When setting up Try NLX from the docs, transaction logs should be inserted in the txlog-db

**:white\_check\_mark: Acceptance criteria**

- Transaction logs are enabled by default for the [Try NLX](https://gitlab.com/commonground/nlx/nlx-try-me) Docker Compose file
- Document how the transaction logs can be viewed

**:link: Reference links**

1.

Story points: 3.0
Verwijder parkeervergunningen applicatie

**NLX repo**

- [x] Helm charts
- [x] insight-ui
- [x] insight-api
- [x] insight settings page in management ui & management api (remove support for both `irmaServerURL` and `insightURL properties)
- [x] references to the insight app should be removed from the docs
- [ ] `demo.nlx.io` -> to redirect to `directory.demo.nlx.io` -> should be done through ingress
- [x] remove DNS records for `application.*.*`
- [x] remove DNS records for insight
- [ ] remove DNS records for irma

**[Demo repo](https://gitlab.com/commonground/nlx/demo)**

- [x] overview-ui (https://gitlab.com/commonground/nlx/demo/-/merge_requests/44)

**Others**

- [x] https://gitlab.com/commonground/nlx/irma (archived)
- [x] remove Parkeervergunningen from Componentencatalogus
- [ ] Remove related Docker images from the GitLab & Docker hub registries

Story points: 3.0
Use parkeerrechten apps for gemeente Stijns on ACC

Part of #1206

Use 'toon parkeerrechten' app together with 'parkeerrechten API' in the acceptance environment for gemeente Stijns.


**Technical notes**

- we will not add the demo applications to the Review Apps (this would make Review Apps too big without too much added benefits)
- use the current NLX 'acc-environment' to deploy the demo applications (we will move these to the demo-environment later on, once we're ready setting up all apps, to shorten the feedback loop)
- the Helm-charts for the 'demo-environment' will be hosted in the NLX repository (`/helm` directory) (this is easier and allows us to focus on making NLX easier to install)
- add support for PostgreSQL to the `parkeervergunningen-api` and use PostgreSQL for the ACC environment

![Screenshot_2021-05-10_at_10.45.05](/uploads/c3367961d01db4ff43c2da9f5726c6bf/Screenshot_2021-05-10_at_10.45.05.png)

Story points: 3.0
Create NLX deployment chart (which includes all sub-charts)

**As a** developer
<br>**I want** to install NLX using a single command
<br>**so** I feel empowered

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. Enable installing NLX using a single Helm chart
1. Add support for the following "modes"  
- Provide a service
- Use a service
1. Document the following scenario's on docs.nlx.io:  
- Provide a service
- Use a service

**Tasks**

- [x] Support optional CertManager config by default
- [ ] Automatically run migrations
- [x] Add support for adding a super-user

**:link: Reference links**

1.

Story points: 8.0
Fix inconsistent Helm charts

**As an** organization attempting to setup NLX using Kubernetes
<br>**I want** properly documented Helm charts
<br>**so** I can install NLX without asking for help

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. Enable specifying a custom port and database name for the postgres connection 
(Make postgresql settings configurable in Helm charts)
* Management API/UI
1. An inway should be externally available by default  
(Make `serviceType` and related config configurable for Inway and document the different values / implications)
1. Review the ingress for the Inway (is this outdated and should it be removed for example?)
1. Make a clear distinction between the internal PKI and organization certs (if we don't succeed in issuing the internal PKI certificates using CertManager)
1. Make clear which fields are required in the Helm charts README

**:link: Reference links**

1.

Story points: 5.0
Create demo app to create a parkeerrecht

Depends on #1221 (copy app)

* [x] shows list of parkeerrechten (after clicking button)
* shows a form to add a parkeerrecht
  * [x] choose gemeente (list of gemeentes is passed through environment variables)
  * [x] enter kenteken, which fetches data from `basisregister-fictieve-kentekens` and `-personen`
  * [x] show car model and personal data. Then either:
    * if all ok: enable submit button
    * if not in selected gemeent: show warning
* [x] include application in deployment to ACC for the Vergunningsoftware BV

Story points: 3.0
Create E2E test for access request flow

Currently some parts of the database-layer are not being tested as we mock the database in our unittests. We do want to test this but it's hard to create end-to-end tests as it requires two Management API's, access requests etc.

We need e2e tests for:

1. Create a failing request to a service without access
2. Create an access request
3. Accept access request
4. Make the same request as in step 1 and watch it succeed

Story points: 2.0
Show overview of created delegations

**As a** municipality
<br>**I want** to have an overview of the delegations I have created
<br>**so** that I know which services can be accessed on my behalf by other organizations

**:desktop_computer: How to demonstrate / e2e test(s):**

1. As municipality, open NLX management and navigate to "Opdrachten"
1. If there are no delegations an empty state is shown
1. If there are delegations they are shown in the overview
1. Click on a delegation to open the delegation detail view in drawer
1. Click on "Toon verlopen opdrachten" to show expired delegations

**:white\_check\_mark: Acceptance criteria**

1. do not implement the status column
1. add a column with the validUntill: valid until as header
1. there is no difference between actual or expired orders
1. the table is sorted on validUntil Desc


Technical implementation



![_todo__Opdrachten](/uploads/40f8c525d0b070ad597f650c1f20c853/_todo__Opdrachten.png)

![_todo__Opdrachten_-_Ontvangen](/uploads/b8b0136209eb9ea24ed67550eb4d8752/_todo__Opdrachten_-_Ontvangen.png)

![_todo__Opdrachten_-_Verlopen_expanded](/uploads/bf92db68f984ee5f0b89c0545a887032/_todo__Opdrachten_-_Verlopen_expanded.png)

![_todo__Opdrachten_-_Empty_state](/uploads/d0fc0fa085097421d988706435483978/_todo__Opdrachten_-_Empty_state.png)

![_todo__Opdrachten_-_Details](/uploads/2d9fbef2854e3161cd8593486e499fd5/_todo__Opdrachten_-_Details.png)

**:link: Reference links**

1.

Story points: 5.0
Revoke access delegation

**As a** _user_
<br>**I want** _goal_
<br>**so** _purpose_

- een opdracht hoeft/kan maar door 1 partij ingetrokken worden
- een ingetrokken opdracht ziet er net iets anders uit in het overzicht (Peter)
- het intrekken gebeurt lokaal direct
  - via de scheduler gaat het naar de andere kant

scenario 1: opdrachtgever trekt actieve opdracht in
- een opdrachtnemer kan dus max de duur van zijn geldige claim nog bij de gegevens obv die opdracht

scenario 2: opdrachtnemer trekt actieve opdracht in
- de outway gaat controleren of de opdracht nog wel geldig is die hoort bij de referentie nr en organisatie naam in de call van de client
  - indien er geen actieve opdracht is, dan geen verzoek naar buiten
- een opdrachtnemer kan dus max de duur van zijn geldige claim nog bij de gegevens obv die opdracht

scenario 3: opdrachtgever of opdrachtnemer verwijderd inactieve opdracht
- dit is alleen een lokaal ding. niet syncen
- weight is 3 (just in case we want to create a separate story for this)


**Updated as part of discussion wed 25th**:

If we implement revoking an order as delegatee, we would introduce a pulling mechanism. This would require for the organization to have an inway, even if they don't provide any service.

We're in doubt if we should make an inway required for organizations not providing a service. This must be discussed first.

Conclusion: revoking incoming orders should not be possible, that's out of scope for now


![_todo__Opdrachten_-_Details_Copy_2](/uploads/1b4ba906864a8abe4cbf38eacdeb9e0c/_todo__Opdrachten_-_Details_Copy_2.png)

![_todo__Opdrachten_-_Ontvangen_Copy](/uploads/2ec5297e818395b1a3a446dda1dcbe3d/_todo__Opdrachten_-_Ontvangen_Copy.png)



**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. update the sequence diagram (as seen in the epic)

**:link: Reference links**

Story points: 13.0
Grant delegation to a supplier

**As a** municipality
<br>**I want** to be able to allow suppliers to access services on my behalf
<br>**so** that I do not need to share my private key

**:desktop_computer: How to demonstrate / e2e test(s):**

1. Make a request as Saas Party X to kentekenregister of RDW and watch it fail
1. Log in to NLX management of Gemeente Haarlem
1. Create delegation for Saas Party X to access the service kentekenenregister on behalf of Gemeente Haarlem
1. Make a request as Saas Party X to kentekenregister of RDW with the delegation header and watch it succeed

### Checks we perform when requesting a claim for an order:

All checks below must succeed, otherwise, no claim will be given.

* *Reference*: is there an order for the provided order reference?
* *Public key*: is public key of the order equal to the public key of the organization requesting the claim
* *Date*: is the end date of the order in the future



**:white\_check\_mark: Acceptance criteria**

1. As a municipality, I want to be able to add a new delegation for a SaaS Party
1. The fields required for a new order are:  
  - Reference (text field max length 100, unique value)
  - Description (max. length 100)
  - Public key (server-side validation if its a valid public key), text field
  - Name of the organization you want to delegate access to (URL-friendly, see [validation in our code](https://gitlab.com/commonground/nlx/nlx/-/blob/4c7f0be8b2c9c980351b6202fbd2106bf4acdab0/directory-registration-api/pkg/database/inway.go#L16)), text field
  - Valid from (valid date)
  - Valid until (valid date)
  - Services (only services for which the municipality has an access grant)
1. Management API of the Municipality should return the real created delegation (instead of the mock, build as part of #1179)
1. Make sure the relevant audit log records are implemented
1. Add description of delegations to docs.nlx.io

**Tasks**

1. [x] Implement add delegation form in UI
1. [x] Add endpoint to add order to management api (for municipality)
1. [x] Update `RequestClaim` endpoint to check if there's an order for the delegatee with the provided order reference
1. [x] `ExpiredAt` of claim should not exceed the `validUntil` property of the order
1. [x] Claim should expire after 4 hours

**Questions**

- How should the list of services look like? Proposal: `<organization-name> - <service-name>` Comment Peter: Good proposal
- Should 'Valid until' be required? Yes
- Should we add 'Doelbinding'? Is 'Opdrachtomschrijving' 'Doelbinding'? We will not add Doelbinding and "Opdracht omschrijving" and "Doelbinding" are not the same
- OPEN @ehotting : do we need to add a disclaimer that the opdracht is not a legal document?

![_todo__Opdrachten_-_Add_new_Copy](/uploads/1f31acbd7be2c8750c0987a904179ff6/_todo__Opdrachten_-_Add_new_Copy.png)

Audit log records:<br>
![image](/uploads/22f7ac388d017dd2896286e8d712ae36/image.png)

**:link: Reference links**

1.

Story points: 13.0
Access services as a supplier

**As a** supplier
<br>**I want** to access services using a mandate given by a municipality
<br>**so** I do not have to share my private key with the supplier

**:desktop_computer: How to demonstrate / e2e test(s):**

1. Send a request without delegation header and watch it fail
1. Saas Party X can access RDW on behalf of Gemeente Haarlem by sending a request with delegation header
1. The transaction log of RDW should show that the request was made on behalf of Gemeente Haarlem

**:white\_check\_mark: Acceptance criteria**

1. A supplier can access a service on behalf of an organization
1. The transaction log record made for a request should include that it was a delegation
1. Delegated access should be granted on the organization certificate of the supplier
1. A delegated request should be verifyable without making additional API requests.
1. The creation of claim must by synchronous

Tasks:

1. [x] Create the gRPC endpoint to retrieve a claim from municipality
1. [x] Store public key with incoming acces request
1. [x] Parse delegation header in the outway (@excol-org)
1. [x] Check if claim exists in the outway (@excol-org)
1. [x] Create the gRPC endpoint to retrieve claim outway-> management api  (@ndequeker)
1. [x] Verify claim in the inway using the public key stored in the incoming access request (!2346) (@RonaldKoster @ndequeker )
1. [x] Store delegation data in the transaction log of outway (@excol-org)
1. [x] Store delegation data in the transaction log of inway (@RonaldKoster @ndequeker)
1. [x] Add Saas Party X to Helm charts (!2332) (@RonaldKoster)
1. [x] Prepare demo setup to send a delegated request using Saas Party X, gemeente Haarlem and RDW
1. [x] Outway should fail to start if no management-api is specified.
1. [ ] Optional: add E2E tests for the demo scenario, using Cypress (see https://gitlab.com/commonground/nlx/nlx/-/issues/1199)


**Technical implementation**

1. The management API of the municipality will always return a valid claim. We will merge this with master but we won't release it. In case we need to make a release because of a bug we will add a feature flag to disable it.

**:link: Reference links**

Sequence diagram, see https://gitlab.com/groups/commonground/nlx/-/epics/14

Story points: 13.0
Remove ability to configure inway with config file

**As a** NLX maintainer
<br>**I want** to remove the ability to configure the inway with a .toml file
<br>**so** that NLX users are forced to embrace the future (NLX management) and NLX becomes easier to maintain

Breaking changes:
1. Authorization mode is replaced by access requests
1. ca-cert-path can no longer be configured

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. Improve code quality of the `inway`  
* remove `common/process.go` (replace with context?) (@excol-org @RonaldKoster )
* use plugin system from outway (move to `common`?) (@excol-org)
1. Update demo organization BRP so that is uses NLX management (@RonaldKoster)
1. Update the docs !2380 (@ndequeker)
1. Communicate this change together with @evangelderen
1. Remove all code needed for the .toml file

**:link: Reference links**

1.

Story points: 8.0
GRPC Gateway v1.x -> v2.x

As part of #1158, we've discovered that the [GRPC Gateway has released v2](https://github.com/grpc-ecosystem/grpc-gateway/releases/tag/v2.0.0) which is a new major version. We need to upgrade the compilation steps (from our proto-files to `*.pb.go`, `pb.gw.go` & `.swagger.json`).

We currently have five proto-files:

1. directory-inspection-api/inspectionapi/inspectionapi.proto
1. directory-inspection-api/stats/stats.proto
1. directory-registration-api/registrationapi/registrationapi.proto
1. management-api/api/management.proto
1. management-api/api/external/external.proto

We've tried to gradually move from v1 -> v2 using [Earthly](https://docs.earthly.dev), but did not succeed in a timely matter.
We can make another attempt, or transition to v2 for all our proto-files.

Story points: 3.0
Create a helm repository for the NLX helm charts

**As a** developer
<br>**I want** to download the NLX helm charts from a helm repository
<br>**so** that I can install/update the charts using the helm cli

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. There is a helm repository (https://helm.sh/docs/topics/chart_repository/)


**Todo**
- [ ] Replace repository in README's

**:link: Reference links**

1.

Story points: 3.0
Pagination for Services page

**As a** user
<br>**I want** to have a paginated list of the organizations of my service
<br>**so** my browser does not crash with large list of services

**:desktop: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. Add pagination for the Services page (max. 20 items per page)
1. Polling statistics for the services should only include statistics for the current page
1. Re-use the pagination component(s) from the DON project

**:link: Reference links**

1.

Story points: 3.0
Show pricing data of the service

**As a** user interested in a service
<br>**I want** to see the costs when this service is not free to use
<br>**so** I know I will receive an invoice

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. NLX Management directory should show detailed pricing info on the detail view
1. The 'request access modal' should indicate that you're requesting access to a paid service

**:link: Reference links**

1.

![_todo__Directory_-_Details](/uploads/9de006f2d040d0739a3573a8e11c0b2b/_todo__Directory_-_Details.png)

![Group_9_Copy_4](/uploads/222fac4a34d1900fee708fba73328c72/Group_9_Copy_4.png)

Story points: 5.0
Add pricing information to services

**As a** _user_
<br>**I want** _goal_
<br>**so** _purpose_


**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. When submitting a new service, the following fields are required:
   - administration fee (for setting up the contract and access)
   - subscription fee (per month)
   - transaction fee (cost per use)
1. Pricing fields are set to '0' by default
1. Service detail pane should display the pricing fields

**:link: Reference links**

1.

![_busy__Add_new_service](/uploads/8c020085cc2ae7c7a1c1d299d88a15f2/_busy__Add_new_service.png)

![_busy__Services_-_Details](/uploads/caa1f2284e0341d4fb0cea6fe33a8a3d/_busy__Services_-_Details.png)

Story points: 3.0