giseldo/neodataset huggingface dataset:
Implement E2E-tests: use an order to access a service

**As a** user
<br>**I want** to use an order access a service from the Management UI
<br>**so** ?

**:desktop_computer: How to demonstrate / e2e test(s):**

```gherkin
Scenario: Use an order to access service
        Given "Vergunningsoftware BV" has the default Outway running
            And "Vergunningsoftware BV" has an active order with reference "order-ref-1" from "Gemeente Stijns" for service "basis-register-fictieve-kentekens" of "RvRD"
        When the default Outway of "Vergunningsoftware BV" calls the service "basis-register-fictieve-kentekens" via the order of "Gemeente Stijns" with reference "order-ref-1"
        Then "Vergunningsoftware BV" receives a successful response
```

**:white\_check\_mark: Acceptance criteria**

1. Implement the scenario as described above
1. Extract multiple gives from a single given
1. Update previously created scenarios to use the extracted givens

**:link: Reference links**

1.

Story points: 5.0
Self healing managmentAPI settings to directory

**As a** NLX participant
<br>**I want** the directory to be fully self healing for inways, outways and organizational information
<br>**so** when the directory is available again after failure, all the necessary information will be automatically added again and peace is restored in the land of NLX

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. organizational email address is send to the directory periodically
1. test scenario: remove a previously added email address and see if it will return again
1. same sync period as inways and outways

**:link: Reference links**

1.

Story points: 5.0
Add simple acceptance of NLX Terms & conditions to NLX management

**As a** NLX maintainer 
<br>**I want** to be able to explicitly accept the NLX terms and conditions for this NLX ecosystem
<br>**so** I announce that I'm participating and accountable for my own organization 


**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**


1. After login in, a user should see the Terms & Conditions (T&C) screen if they have not yet been approved for the organization of this Management API
1. When a user clicks 'Approve', this should be stored in the Management API
1. An audit log should be added when approving the T&C
1. The Directory API should accept an URL where the T&C are hosted
1. If this URL is not specified, the T&C should not be shown after authentication
1. Add E2E test for accepting T&C
1. This change should be communicated to NLX demo users
1. Update docs to include approving T&C

**:link: Reference links**

![_todo__Terms_of_use](/uploads/1e50ecf2701ae998c2529a5cd554b905/_todo__Terms_of_use.png)
[Gebruiksvoorwaarden_NLX_maart_2020.pdf](/uploads/97a8a5a52b375353653138ecefe32491/Gebruiksvoorwaarden_NLX_maart_2020.pdf)

Story points: 8.0
Register organization email address

**As a** NLX user
<br>**I want** to know if there is a (breaking) change upcoming
<br>**so** that I can make sure my NLX setup keeps working

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. Add field for organization email address in NLX management
1. Show BIG modal in NLX management while the organization email address is empty
1. The organization email address should be stored in the directory
1. Describe the organization email field in the docs

**:link: Reference links**

1.

Story points: 5.0
Inway and Outway directory registration

**As a** NLX user
<br>**I want** see which organizations are using this NLX network
<br>**so** that I can determine the value of this NLX network for my organization.

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. Of an outway the following information is stored in the directory:
 * Organization
 * Outway name
 * Version
 * Created at
 * Updated at
1. Add overview to directory UI
1. The overview displays a list of organizations participating on the NLX network
1. For each organization is displayed whether the organization offers services, consumes services or both.


![Screen_Shot_2021-11-29_at_10.17.09](/uploads/59304333e22ae897afcd7f70718e9510/Screen_Shot_2021-11-29_at_10.17.09.png)
column width:
- organization widest
- date only what's needed
- inways, outlays and services all the same width

**:link: Reference links**

1.

Story points: 8.0
Implement E2E scenarios

We have descripted several E2E scenarios using gherkin(https://cucumber.io/docs/gherkin/). These scenaro's should be implemented using the Cucumber framework.

We implemented the e2e scenario for creating the a service using Playwright but we decided we want to switch to Selenium because Selenium supports more browsers and offers support for running the test in paralel.

**:white\_check\_mark: Acceptance criteria**

1. Use Selenium
1. All Givens should use the management API directly instead of using the browser (recommented by Selenium because the browser is slow https://www.selenium.dev/documentation/test_practices/overview/)
1. Rewrite the Playwright implementation for "Create Service"(`testing/e2e/src/steps`) with Selenium 
1. The test should run in the pipeline
1. Scenarios should run independend from eachother
1. Try to use our BrowserStack account to setup the tests with BrowserStack. If this does not work use Selenium images.
1. Update BrowserStack account to teamcore@vng.nl
1. Add browser image to the dev docker compose file so we can run the test localy.  
```
browser:
    image: selenium/standalone-chrome:4.1.1
    shm_size: 2gb
    ports:
      - 4444:4444
```

The following scenario's should be implemented:
1. Delete an inway  #1458
1. Unset organisation inway #1459
1. Create an order
1. Create a service
1. Delete a service #1460
 
An example of how to use Cucumber in combination with Selenium: https://github.com/browserstack/cucumber-js-browserstack. Please note this example uses BrowserStack which we won't use so any configuration regarding BrowserStack in this example can be ignored.

Story points: 13.0
The organization owning the outway must be able to revoke access

It is not possible for a consumer to 'quit' or 'cancel' and ongoing access request. This potentially result in unnecessary activities (time spend by the owner of the service to assess the request) and when something is wrong at the owner side (the Inway) an access request with an error state will exists indefinitely (or at least until the owner fixes its problem). In order to have control over the access requests, it's necessary to be able to delete an request. Since you might delete a request which was actually already granted by the owner (the consumer just doesn't know that yet), it must also be possible to then cancel access from the consumer side of things. And if that's an option, then we just as easily can add that functionality to the UI making it explicitly possible.


Acceptance criteria:
- Add two buttons
    - one for cancelling access as a consumer (when you already had access)
       - must result in removing the access grant and maybe the proof -> figure it out
       - showing the correct status for the access of the specific outway -> back to no access again with the messages/status access cancelled by 'Ingetrokken door [user]' including time stamp
       - adding an audit log entry at the consumer side 
       - add the request access button

    - one for canceling an access request as a consumer
       - The cancelling access request button is only visible when at the supplier side the access is not granted (could be that the revoke action hasn't synchronized yet)
       - remove the access request on both sides
       - add audit record 
       - the status of the access of the specific outway must be No access including 'geannuleerd door [user]' and a timestamp
       - add the request access button

- Add end to end tests
- Check and update documentation when necessary

TODO:

- [x] Make split in audit log between action start and action end
- [x] Add database integration tests
- [x] Update Management UI
- [x] Update Inway
- [ ] Syncer moet approved access state niet opniuew updaten
- [x] Sequence diagram
- [ ] Check if there are changes to convert GORM to sqlc

Story points: 13.0
Add serialnumber to CSR

As a NLX demo user
I want to be able to add the subject serialnumber to my CSR
So that I am able to predict my URL's

Acceptation Criteria 
- [x] Add instructions on how to add a subject serial number in the docs
- [x] Add instructions on how to add subject serial number to an existing CSR
- [ ] Communicate this change to team Haven
- [x] The certportal should use the subject serial number in the CSR. If there is no subject serial number present, generate a random serial number
- [x] Verify that access requests still work after adding a subject serialnumber to an existing CSR. (DOES NOT WORK)

Story points: 3.0
Help user distinct own services from other services

**As a** NLX management user
<br>**I want** to have a clear distinction between my own services and those from others
<br>**so** I can easily find the service I'm looking for

**:desktop_computer: How to demonstrate / e2e test(s):**

1. Open NLX management
1. See button 'Mijn services'
1. Click on that button
1. See the page name 'Mijn services'
1. See button 'Directory'
1. Open Directory
1. See that the organization name of your own services is yellow. The others are the original color

**:white\_check\_mark: Acceptance criteria**

1. Services vertalen naar Mijn services
3. Color the organization name of my own services yellow in the directory

**:link: Reference links**

1.

Story points: 2.0
Remove an inway using the NLX management UI

**As a** system manager
<br>**I want** to be able to remove inways
<br>**so** that unused inways are no longer visible in NLX management

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. Add delete button to the Inway details screen
1. Ask for confirmation before deleting the inway
1. If the inway is still offering services display this in the confirmation dialog
1. If deleted inway is the organization inway and your are still offering service display the "No organization set" warning.    

**:link: Reference links**

1.

Story points: 5.0
Refactor database layer to adapters in the directory API

**As a** NLX developer
<br>**I want** seperate my database logic from my business logic
<br>**so** that the project remains easy to maintain

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. Split database and business logic into seperate layers
1. Add postgres folder to adapter folder


 ![Schermafbeelding_2021-10-27_om_13.59.42](/uploads/a38c4f4efa9007f241f152c822465e12/Schermafbeelding_2021-10-27_om_13.59.42.png)

**:link: Reference links**

1.

Story points: 5.0
Do not require trailing slash for outway URLs

**As a** NLX user
<br>**I want** my request to work when I do not add a trailing slash
<br>**so** that I do not get confused when my URL seems correct but fails

requested by steven gort

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

1. `localhost/12345678901234567890/servicename` should work
1. `localhost/12345678901234567890/servicename/` should work

**:link: Reference links**

1.

Story points: 3.0
Create database fixtures using our own repository interfaces in the directory API

**As a** developer
<br>**I want** to add test data for our database integration tests using our own repository interfaces
<br>**so** that we do not depend on a specific database

Additional benefits:

* We can safely run our database integration tests in a transaction which allows us to run the test in parallel without running the directory inspection API and directory registration API tests in different databases. 
* We no longer depend on an external tool to add our test data (https://github.com/go-testfixtures/testfixtures/)

**:desktop_computer: How to demonstrate / e2e test(s):**

1.
2. 
**:white\_check\_mark: Acceptance criteria**

1. 

**:link: Reference links**

1.

Story points: 8.0
View latest transaction log records in NLX management

**As a** NLX maintainer
<br>**I want** to have access to the latest transaction logs
<br>**so** I can see what's currently going on

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**
- [x] Enable getting the transaction log via the application-overview page (add link per organization)
- [x] Transaction log API returns records as JSON / GRPC
- [x] Add connection string to the managementAPI as a flag
- [x] The page should tell the user that he/she didnt activate the transaction logging 
- [x] Show the latest 100 records in NLX management (Make sure this is communicated to the user -> if easy peasy cheap: then use the variable containing the limit... otherwise just type it in the text*)
- [ ] Change the transaction documentation
- [x] Change the management API documentation in the guide
- [x] Change the current Logs icon in the UI to: Audit log
- [x] Add new logs icon with the text: Transactions log
- [x] Use internal certs as authorization on the API 

* text above: De laatste 100 records in de transaction log van jouw in- en outways

**row must resemble:**  
tijd | binnenkomend van | organisatie | service   
tijd | uitgaand naar    | organisatie | service

**:link: Reference links**

1. https://links.acc.nlx.io

Story points: 13.0
Document the usage of subject serialnumber

Request a demo certificate
* describe that the serialnumber is used by NLX as the organization identifier
Provide an API
* update URLs used in `Quering your own API's` section

Request a production certifiate
* describe that the serialnumber is used by NLX as the organization identifier

_For Subject.SerialNumber specification, see https://gitlab.com/commonground/nlx/nlx/-/issues/1376_

Story points: 2.0
Use subject serialnumber in the Inspection API, Management API, Inway and Outway

Directory Inspection API + Management API + Inway + Outway

**Acceptatie criteria**

- [ ] The directory inspection API returns serialnumber in the ListServices call
- [ ] Outway should use serialnumber to find services
- [ ] The serial number should be added to access request and orders (later on we will display these in the UI)

Directory-inspection-api
* return serialnumber in list services call

Management-api
* add serialnumber to access_requests_incoming
* add serialnumber to access_requests_outgoing
* user serialnumber as organization identifier in access grants
* use serialnumber as delagatee in orders
* use serialnumber in order_services

Management API & UI
* Replace the inputfield of organization name with subject serialnumber when creating an order
* Use subject serialnumber to create an access request
* add serialnumber to auditlogs

Inway 
* store serialnumber in TX log
* the check if there is an access grant for an organization should happen on serialnumber instead of organizationname
* the check if a received claim is owned by the sender should happen on serialnumber instead of organizationname

Outway
* parse serialnumber from url
* use serialnumber as identifier in the hashmap for services
* store serialnumber in TX log
* use serialnumber to retrieve order token instead of organization name
* use serialnumber as identifier in the hashmap for delegation claims

Story points: 13.0
Management UI should display subject serialnumber

**As a** systeembeheerder
<br>**I want** to see my own and other organizations their Subject serialnumber
<br>**so** every organization can be identified using their OIN

**:desktop_computer: How to demonstrate / e2e test(s):**

- When a OIN is present, it should be displayed
- When no OIN is present, it should display an empty value

**:white\_check\_mark: Acceptance criteria**

- [ ] Display the subject serialnumber of your own organization (to be designed by @petervermeulen)
- [ ] Display the subject serialnumber in directory view (to be designed by @petervermeulen)
- [ ] Subject serialnumber should be present in the MobX models

**:link: Reference links**

1.

![Group_52](/uploads/57cbe72a1765a36975187a34a81f9bd2/Group_52.png)

Story points: 2.0
The directory should display subject serialnumber when available

**As a** user
<br>**I want** to be able to find the OIN of every organization in the public directory
<br>**so** I can verify the organization

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:white\_check\_mark: Acceptance criteria**

- [ ] Display OIN in the public directory UI on the service detail pane

Design, see: https://gitlab.com/commonground/nlx/nlx/-/issues/1366

**:link: Reference links**

1.

Story points: 2.0
Make Certportal should add Subject serialnumber to certificates

**As a** user of the demo directory
<br>**I want** the certificate I request to contain a _Subject serialnumber_
<br>**so** I can use the certificate for my NLX components

**:desktop_computer: How to demonstrate / e2e test(s):**

1. Open the demo directory
1. Request a certificate
1. Download the generated CRT
1. Verify there is a subject serialnumber present using `openssl x509 -in org.crt -text`

**:white\_check\_mark: Acceptance criteria**

- [ ] Certportal should add a subject serial number in the `subject.serialnumber` field of the certificate 
- [ ] The subject serial number may not exceed a length of 20 characters
- [ ] The subject serial number must be unique within every NLX environment

**:link: Reference links**

1.

Story points: 3.0
Register organization inway

**As a** NLX developer
<br>**I want** the organization inway setting in the directory to recover it self when the directory database has been reset
<br>**so** that I have a self healing and more robust system 

**:desktop_computer: How to demonstrate / e2e test(s):**

1. Configure organization inway for "organization a"
2. Reset the directory database
3. Send an access request to "organization a"
4. "organization a" should receive this access request

** TODO **

1. [ ] ManagementAPI: GetOrganizationInway should return the organization inway flag
1. [ ] Inway: send "is organization inway" flag when calling RegisterInway
1. [ ] DirectoryRegistrationAPI: RegisterInway parses the organization inway flag and update the database

**:white\_check\_mark: Acceptance criteria**

1. Inway tells the directory that it should be used as management API

**:link: Reference links**

1.

Story points: 5.0
Change an existing order

**As a** maintainer
<br>**I want** to change an existing order
<br>**so** maintaining orders is flexible and easy

The following fields should be editable
1. Order description
1. Public key
1. Start/enddate
1. Services

**:white\_check\_mark: Acceptance criteria**
1. Add entry to auditlog
1. Add edit button to order detail view in the same way as service detail view (see screenshot)
1. Open order form
1. a changed order must result in one order on both ends again

**:link: Reference links**

![Schermafbeelding_2021-11-17_om_11.25.38](/uploads/aebb8d4d49744bee683a5f46b5bfa07e/Schermafbeelding_2021-11-17_om_11.25.38.png)

Story points: 5.0
Keep track of Inway activity

**As a** NLX maintainer  
**I want** to be able to know when an Inway was last active
<br>**so** we can prepare for automatically removing inactive Inways

**✅ Acceptance criteria**

1. When registering an Inway, the `created_at` and `updated_at` fields must be added (to know when an inway is created and when its address has been updated)
1. Process is replaced with CTX
1. Database logic is moved to `adapters`

Story points: 5.0
Handle service deletion

#### As a owner of a service:

**Current behavior**

A service with access requests(active or revoked) cannot be deleted.

**Expected behavior**

* If there are no active access requests the service can be deleted

* if there are active access requests, the user should be informed that there are still active access requests and confirm that the user is sure he/she wants to delete the service.

* If there are active orders containing the service, the user should be informed that there are still active orders and confirm that the user is sure he/she wants to delete the service.

* If there are active orders and access requests, the user should be informed there are still active access requests and orders, the user should confirm is sure he/she wants to delete the service.

#### As owner of an outgoing order containing services owned by another organization

No actions required

#### As owner of an incoming order containing services owned by another organization

No actions required

**:white\_check\_mark: Acceptance criteria**

1. A service can be deleted even if there are active access requests or/and orders
1. Front-end gets latest connected access requests/orders before deleting
1. Check if access requests is actually active and not, for example, revoked
1. Show confirmation dialog when there are still active access requests/ orders before deleting
1. Remove service, access requests and order_service entries from database
1. If scheduler of the management API detects that the service of an access grant has been deleted, the access grant should be deleted from the database.

Story points: 8.0
Document NLX installatie-reis afwerken

**Acceptatie creteria**

- [ ] handleiding verder doorlopen en uitbreiden
- [ ] alle TODO's zijn weggewerkt

We kunnen de Parkeerrechten API aanbieden als test-api. De Docker image: `nlxio/parkeerrechten-api` ([Parkeerrechten API](https://gitlab.com/commonground/nlx/demo/-/tree/master/parkeerrechten-api)).

**E-mail verzonden op 20 juli van @evangelderen met uitnodiging voor overleg op 10 augustus:**

> 10 augustus is de dag waarop de guide af moet zijn. Eerst in rudimentaire vorm (dus zonder lieve teksten erom heen) in het samenwerk MD bestand: https://hackmd.io/26na7EFER4yHJTfX6gQdEA?view
> 
> Wanneer hij dan goed is, dan knallen we hem in de docs site.
>  
> Niels: jij ben net terug van vakantie dan dus jij hebt alleen 3 dagen nog hiervoor en we bepalen samen met Ruben wat we oppakken.
> Ronald: jij gaat al superblij worden van de stappen die we vandaag 20 juli gezet hebben en ga absoluut je gang om het af te maken… maar… nogmaals… rudimentair.. de commando’s en korte uitleg zijn belangrijk
> Henk: voor jou is dit allemaal nieuw maar als het goed is, dan ben je nu je tweede week ingegaan en heb je waarschijnlijk de eerste week al op basis van deze guide lokaal zitten proberen en testen. Maar samen met Ronald kunnen jullie prima bepalen wat je de eerste week gaat doen.

Story points: 13.0
Add orders functionality to demo setup

**As a** presenter of NLX
<br>**I want** to be able to demonstrate orders
<br>**so** potential users of NLX can easily see how orders work

**Prerequisites**
- make sure public key of every organization can be copied (#917)


**:white\_check\_mark: Acceptance criteria**

- The application should not load the parkeerrechten initially, since we don't know what Claim to use.
Add a 'Parkeerrechten ophalen' button with the option to provide the Claim for every organization.
- The header containing the reference nr of the opdracht is: X-NLX-Request-Claim
  - The curl command is something like: curl my-outway.nl/org/service -H "X-NLX-Request-Claim: <opdrachtnummer>"
- the ui of parkeervergunning bv (admin) must have a text input for the order reference
- if the reference is kept empty, no Claim header should be added to the request
- describe test-flows for the orders-functionality (on ACC)

**:desktop_computer: How to demonstrate / e2e test(s):**

1.

**:link: Reference links**

1.

Story points: 5.0