Tracking van wijzigingen, onderdeel van logging en auditing

Acceptatiecriteria :

• Wijzigingen in de teksten zijn ovv datum raadpleegbaar

Tasks

Tip: Do #18 first.

• In the history part of the page, show a list of ProductVersions, like: "{{ created_by }}, laatst bewerkt op {{ modified_on }} en gepubliceerd op {{ publicatie_datum }}"

De voorziening voorziet hierin maar dit valt buiten de scope van de SDG

• Add the filter taal to producten resource: Example: /api/v1/producten?taal=nl. This filters the inline queryset vertalingen to the given taal.

De invoervoorziening valideert de productbeschrijvingen en metadata van de productbeschrijvingen
Bij fouten worden aanwijzingen gegeven hoe de fout hersteld kan worden

Tasks

This is about showing form validation errors in the CMS. Make sure an error is shown in the CMS when...

• Filling in incorrect opening hours format
• Filling in incorrect postal code format
• non URLs in URL fields at product edit page
• Setting the publish date in the past
• Whatever else you can think of

...zodat ik de productomschrijving kan toespitsen op de gemeentelijke situatie, wanneer deze afwijkt van de referentieteksten

Dit geeft de gemeente de keuze om gebruik te maken van de standaardvertalingen of daar een eigen invulling aan te geven. De websites van de gemeentes en de Nationale Portalen blijven hiermee in sync

Acceptatiecriteria :

• De gebruiker heeft de mogelijkheid een vooringevulde tekst te overschrijven. De overschreven tekst wordt geleverd bij opvragen

Tasks

• This should have been done in #13.

Tasks

• Create Github actions to run tests
• Create Github actions to do style checks

... zodat ik ontzorgd word, zeker weet dat ik voldoe aan de SDG en de specifieke teksten van gemeenten waar mogelijk uniform zijn

Referentieteksten worden opgesteld door de gezamenlijke redactie. Deze teksten kunnen overgenomen en/of aangevuld worden met gemeentelijke informatie.

Acceptatiecriteria :

• De gebruiker heeft voor elk product de mogelijkheid voor de referentietekst te kiezen.

Tasks

• The checkbox described in #13 should suffice.
• On the product edit page, add link/button to reset the the current text in the textarea to the reference text.

Verduidelijk

• Is punt 2 nodig/gewenst? Yep

Om zicht te houden op de inrichting is het voor gebruikers wenselijk duidelijk te houden van welke producten reeds omschrijvingen tbv de SDG zijn ingevoerd

Acceptatiecriteria :

• Zie #11
• Per informatiegebied worden de producten getoond waarvan de aanvullende teksten niet zijn opgegeven

Tasks

• We use an icon to show whether a product is "beschikbaar" or not. This differs from a section as shown in the screenshot and was discussed with VNG.

Per gemeente kan het verschillen waar men voor bepaalde producten heen moet om de aanvraag te doen.
Het is nog onduidelijk hoe dit op de Nationale Portalen gaat werken

Acceptatiecriteria :

• bij elk product kan aangegeven worden op welke locatie het afgenomen kan worden.
• Indien een gemeente slechts 1 locatie kent dan wordt deze voorgeselecteerd
• Wanneer een product wordt opgevraagd dan worden de gekoppelde locatie geleverd

Tasks

• Add location edit form on edit page for locations (see screenshot)
• Add read-only version of the edit form on detail page (see screenshot)
• If there is only 1 location, by default make the first location checked.

De invoervoorziening voldoet aan de onderstaande prestatie eisen. De leverancier geeft aan wat de vereiste middelen zijn voor de gevraagde prestaties (server, netwerk, opslag)

Snelheid
Het laden van een pagina duurt maximaal 2 seconden
Het opslaan van een doorgevoerde wijziging duurt maximaal 3 seconden

Capaciteit
100 web-redacteuren moeten tegelijkertijd kunnen (concurrent) werken in de invoervoorziening
Het aantal van 100 is gebaseerd op de aanname dat maximaal 10% van de 352 gemeentelijke web-redacties tegelijkertijd in de invoervoorziening aan de slag is. Van de gemeentelijke web-redactie werken er 3 redacteuren aan de productbeschrijvingen.
Nominaal zijn er naar schatting 20 redacteuren aan het werk in de invoervoorziening wanneer er geen landelijke wijzigingen op stapel staan
Minimaal aantal te beheren productbeschrijvingen is 35.000
Naar beneden afgerond 100 producten x 352 gemeenten = 35.200 productbeschrijvingen
Ieder product kent per gemeente een Nederlandstalige- en een Engelstalige beschrijving.
Het aantal producten gaat in de loop van de tijd groeien. De invoervoorziening start met de SDG shortlist (35 producten), vervolgens de longlist (bijna 100) en gaat mogelijk doorgroeien naar alle gemeentelijke producten (volgens UPL ongeveer 400).

Tasks

• Do performance test
• Document minimum server requirements

Inschrijver borgt dat alle activiteiten, ook die van Eindgebruikers en Beheerders worden vastgelegd in audit-/ logbestanden. Dit zodanig beveiligd dat deze bestanden niet zomaar kunnen worden ingezien, gewijzigd of verwijderd door hiertoe niet bevoegd personeel
Inschrijver borgt dat een logregel minimaal het volgende bevat:

1. Waar mogelijk een tot een natuurlijke persoon herleidbare identificatie.
2. Waar mogelijk de identiteit van het werkstation of de locatie.
3. Het object waar de handeling op werd uitgevoerd.
4. Het resultaat van de handeling.
5. De gebeurtenis.
   De datum en het tijdstip van de gebeurtenis.

Tasks

• Add django-timeline-logger
• Log changes (location save, product save, product publish, etc.) done in the CMS. Example can be seen here: https://github.com/open-formulieren/open-forms/pull/686/files
• The logs above should be visible in the admin interface
• Admin actions are logged by default

Referentieteksten worden:

• Binnen de invoervoorziening gebruikt ter ondersteuning van de gemeente redactie
• Buiten de invoervoorziening gebruikt om de burger te informeren

Acceptatiecriteria :

• Na het aanwijzen van een product zijn de relevante gegeven overzichtelijk aanwezig
• bovenin wordt altijd de generieke tekst getoond
• daaronder wordt de specifieke tekst getoond
  • als er nog geen specifieke tekst is, dan wordt deze aangemaakt en gevuld met een kopie van de referentietekst
  • per attribuut van de specifieke tekst kan de redacteur
    • de tekst wijzigen
    • de tekst 'resetten' naar de referentietekst
    • zien of de specifieke tekst gelijk is aan de referentietekst

De powerpoint CimPDC en SDG.pptx bevat een uitwerking hoe in het informatiemodel vanuit een specifieke tekst wordt verwezen naar een referentietekst.

Alternatieve oplossingen voor werken met referentietekst
Voor nu is in de acceptatiecriteria gekozen voor het maken van een kopie van de referentietekst. Andere oplossingen die overwogen zijn:

• De specifieke tekst verwijst naar de meest actuele versie van de referentietekst
  • + gemeente redactie wordt maximaal ontzorgd. Als referentieteksten wijzigen (correctie, wetswijziging, ..) dan volgen de specifieke teksten zonder inspanning van de gemeente
  • - specifieke teksten worden gewijzigd door de gezamenlijke redactie, terwijl de gemeente hiervoor verantwoordelijk is
• De specifieke tekst verwijst naar de versie van de referentietekst die door de gemeente is gezien en bevestigd
  • + gemeente redactie wordt ontzorgd, referentieteksten kunnen met minimale inspanning worden gebruikt
  • + gemeente heeft altijd expliciet voor een tekst gekozen
  • + voor gezamenlijke redactie maximaal inzicht in gebruik van referentieteksten
  • - na een wijziging van de referentietekst moet een gemeente deze actief kiezen, tot die tijd wordt de oude referentietekst getoond

Tasks

• Add generic text above the specific text fields, as read only.
• Add detail page view/template for a product (field name, field help text and field value)
• If no specific text is available, show the reference text.
• Show all available languages as tab. Each tab includes the product in the selected language.
• [ ] Adjust the models to include PER FIELD whether to use the specific information, or reference information as a boolean (FIELD_use_reference ie. bewijs_use_reference - default True).
• Add get_FIELD helpers to retrieve the specific text if present, otherwise the reference text.
• For each field use the helpers to show the right text.
• Show whether this is the reference or specific text (not in screenshot).

..., opdat de specifieke teksten voldoen aan de SDG kwaliteitseisen

Zie paragraaf 5.5.4 Indeling van productbeschrijvingen

Verduidelijking nodig

Hoe zien we dit voor ons? De teksten achter de i-tjes? Is dit nog relevant?

..., zodat ik controle heb wie productbeschrijvingen kunnen wijzigen voor mijn gemeente

Acceptatiecriteria : het accountbeheer moet voldoen aan de eisen van de BIO, bijvoorbeeld dat het mogelijk moet zijn accounts te verwijderen.

Tasks

• Add CMS page/view/template to see the request.user->role->organizations (can be multiple). For each organization, show a list of users with their role (see mockup below)
• Add a delete action to remove users (ie. remove their Role, not the user itself). Only a beheerder of the same organization can see this action, and therefore only a beheerder can delete other users that belong to the organization that the user is a "beheerder" of.
• The logged in user cannot delete itself.
• Allow a beheerder to create users. A beheerder can only create users for the organziations they are "beheerder" for. A new user can be a "beheerder" or a "redacteur" (see 2nd mockup below)
• Upon creation of a new user, an invite is sent to setup the password. This invite should be reflected in the list of users (see mockup, "Mark Mah"

Mockup: List of users

Gebruikers

Amsterdam

Nieuwe gebruiker toevoegen

Harderwijk

NOTE: Users cannot delete themselves. John Doe is logged in in this mockup. John Doe is "beheerder" of Amsterdam and can delete Jane Bar and Martin Moo. John doe is also a "redacteur" of Harderwijk. Since John Doe is not "beheerder" of Harderwijk, he cannot delete Frank Foo. John Doe can not see/use the "Nieuwe gebruiker toevoegen" action for Harderwijk.

Mockup: Add new user

Nieuwe gebruiker toevoegen

U staat op het punt een nieuwe gebruiker toe te voegen voor de organisatie Amsterdam*.

De gebruiker ontvangt na het opslaan een uitnodiging om een wachtwoord in te stellen. Hiermee wordt ook het e-mailadres gevalideerd.

Opslaan

Inlog : zie beveiliging

Acceptatiecriteria : uit te werken

Tasks

• Add login view/template.
• Allow login with email address and password

Deze gegevens worden op de Nationale Portalen gebruikt om de gebruiker te informeren over de gemeenten.
$ Is deze info ook centraal op te halen (common ground)

Acceptatiecriteria :

• de gemeente redacteur heeft bij overzicht van zijn organisatie de mogelijkheid gegevens te wijzigen
• Zie verder algemene acceptatiecriteria v.w.b. opslaan

Tasks

• Modify LokaleOverheid model to include website, telefoonnummer, email, LAU-code
• Create template/view/form for editing organisation (LokaleOverheid) details

Opgenomen in mock-ups. Valt buiten scope voor de SDG
Acceptatiecriteria :

• Na verwijderen is de locatie niet meer opvraagbaar.

Om zicht te houden op de inrichting is het voor gebruikers wenselijk duidelijk te houden van welke producten reeds omschrijvingen t.b.v. de SDG zijn ingevoerd

Acceptatiecriteria :

• De gemeentelijke productlijst volgt de referentieteksten lijst (met unieke combi van UPN en doelgroep)
• producten zijn ingedeeld in de SDG informatiegebieden
• producten zijn gesorteerd op informatiegebied en daarbinnen op titel
• achter ieder product staat een icoon dat aangeeft welke teksten nog geschreven moeten worden, welke klaar zijn en welke nagekeken moeten worden.
  1. rood kruis (tekst niet gepubliceerd, u voldoet niet aan de SDG verordening)
  2. felle kleur uitroepteken (de referentietekst is gewijzigd, controleer uw specifieke tekst)
  3. groen minnetje (mijn gemeente voert dit product niet)
  4. groene vink (tekst geschreven)
• Per informatiegebied wordt het icoon met de hoogste prioriteit getoond (zie nummering hierboven). Oftewel achter een informatiegebied wordt alleen een groene vink getoon als alle producten binnen dit informatiegebied een groene vink hebben. Heeft één product een minnetje, toon dan het minnetje

Tasks

• Add view/template to show all "informatiegebieden" (with products) and products (that are "beschikbaar") under that "informatiegebied" for the logged in municipality.
• Per "informatiegebied" show how many "beschikbaar" products are in there (for the logged in municipality)
• For each product, show the languages that are available

Tasks

• Create models for each entity (see attached, and page 35 of document 8)
• Please use the Dutch terms for all model and field names!
• Make sure the fields are up-to-date from the Excel file (document 11).

Als VNG functioneel beheerder wil ik de productcatalogi van gemeenten in een herindeling kunnen samenvoegen, opdat deze gemeenten met minimale inspanning en kans op fouten een nieuwe gezamenlijke catalogus kunnen maken?

Verduidelijking nodig

Technisch kan dit. Je kan een product "omhangen" van de ene gemeente naar de andere. Dit zorgt dan wel voor dubbele producten? Wie beslist welke blijft? Ik zie meer problemen dan oplossingen :)

Tasks

• Add documentation for VNGR management

Tasks

• Register all models as appropriate admin-model
• Use proper admin list fields that make sense
• Add some sorting and filtering options that make sense.

..., zodat ik geen dubbel werk heb en alle deelnemers dezelfde teksten hebben

Klopt het dat gemeentelijke producten van een samenwerking altijd hetzelfde zijn, of is er ruimte voor couleur locale binnen de samenwerking?
Een samenwerkingscatalogus waaruit de deelnemende gemeenten kunnen kiezen?

De agile werkwijze wordt vastgelegd en afgestemd tussen leverancier en opdrachtgever en kan alleen in onderling overleg schriftelijk worden gewijzigd.

De Producten API wordt geraadpleegd door de Nationale Portalen en op termijn door gemeenten en andere afnemers. De Producten API is publiek toegankelijk.

Snelheid
Anonieme afnemers hebben geen garantie op responsetijd
Bekende afnemers (met API key) kunnen onbeperkt opvragen met een gegarandeerde responsetijd:
Enkelvoudige opvragingen (één product van één gemeente) maximaal 0,1 seconden
Meervoudige opvragingen maximaal 0,5 seconden

Capaciteit
Anonieme afnemers kunnen onbeperkt opvragen, maar worden bij grote aantallen in de snelheid geknepen.
Aan bekende afnemers (voor nu 4 portalen) moet kunnen worden gegarandeerd dat 10 productbeschrijvingen per seconde kunnen worden opgehaald.

Deze eisen gelden als de voorlopige eisen, totdat deze op basis van daadwerkelijke gebruikgegevens kunnen worden vastgesteld.

Tasks

• Add API-token as optional authentication mechanism. Please don't use the default from DRF (token linked to user) but make a completely separete Token model. See Objects API.
• Add throthling for users that do not use an API-token (max 100 requests/minute)

Er is nog geen duidelijkheid of een productbeschrijving moet kunnen bestaan uit meerdere productuitvoeringen en hoe dit dan doorwerkt op het informatiemodel en de producten API

Op de Nationale Portalen dient naast de samenvattende beschrijving ook gemeentelijke informatie getoond te worden. Deze informatie wordt uit de invoervoorziening API gehaald

Acceptatiecriteria :
De API moet voorzien in de functie GET /SDG Producten
De functie geeft alle productgegeven terug van alle gemeenten
De functie is te filteren op productnaam, taal, doelgroep en gemeente

Design

Please use DRF and DRF-Spectacular.

0. The whole API is read-only.
1. The list endpoints can be a list of the detail serializer (default with viewsets)
2. Make sure list views are paginated.
3. All filters (indicated with ?) are optional.
4. All objects have a uuid.
5. All serializers should be pretty flat unless specified (arrays, inlines)
6. When I mention "link" it means the URL to the relevant resource.
7. Concepts should never be returned by the API.

/api/v1/catalogi
?organisatie=x

/api/v1/catalogi/{uuid}
- catalog details
- organisatie link
- producten array of links to products

/api/v1/producten

/api/v1/producten/{uuid}  # use active today as default
?organisatie=x,doelgroep=x,catalogus=x,publicatiedatum__gte=x
- upn url
- upn code
- beschikbaar
- etc..
- locaties array of links # the m2m table..
- vertalingen array of inline details # similar to detail page in the cms
  - taal (ISO code)
  - generiek fields flattened into this inline
  - specifiek fields flattened into this inline

/api/v1/producten/{uuid}/historie
\# same serializer as above but a list of all (published!!) versions

/api/v1/organisaties

/api/v1/organisaties/{uuid}
- org details
- catalogi array of links
- locaties array of links

/api/v1/locaties/

/api/v1/locaties/{uuid}
?organisatie=x

NOTE: No need to filter on taal for now.

De kern van de SDG

Acceptatiecriteria :

• voor elke taal (op dit moment NL en EN) is het mogelijk referentie en specifieke teksten op te stellen.

Tasks

Tip: Do #14 first.

• Add "Wijzigen" button to go to the edit page of the product in that language.
• Add edit page view/template/form for the product
• Upon initial creation of the product (based on the reference product), fill the fields with the texts from the reference product.

Verduidelijking

We will not add "follow the reference texts at all times"! The tasks below are removed:

• Indicate (checkbox ..._use_reference) below the text, whether this is a specific text, or a reference text (not in screenshot).
• Only if this checkbox is unchecked, you can edit the text.

In the end, there are 2 functions below each text field:
✅ Gebruik altijd de laatste referentie teksten ♻️ Kopieer laatste referentie tekst in het tekstveld

De invoervoorziening voldoet aan de eisen van digitoegankelijk.nl

Tasks

• Check all pages with the SiteImprove Accessibility checker and fix reported issues (if relevant).

... en verschillende stylesheets kan worden gevisualiseerd (als test) voordat men definitief publiceert.

Verduidelijking nodig

Is dit echt nodig? Wij gaan niet over hoe e.e.a. eruit komt te zien op de NNP. We hebben al wel een WYSIWYG-editor waardoor de opmaak al wel in basis-vorm getoond wordt.

Tasks

• Create small design for preview
• Add preview page (pretty empty)
• Add preview button to detail/edit page

API to give concepts is done in another ticket.

Proceslogica en bedrijfsregels zijn los van elkaar en los van de interactie naar gebruikers instelbaar.

Herbruikbaarheid
De broncode van componenten is beschikbaar als open source software met een EUPL-licentie.
De broncode is goed gedocumenteerd
De broncode wordt beheerd in een git-repository van VNG Realisatie

Testbaarheid
De Producten API wordt getest met de API Testvoorziening van de VNG (ATV)

Tasks

• De broncode van componenten is beschikbaar als open source software met een EUPL-licentie.
• De broncode is goed gedocumenteerd
• De broncode wordt beheerd in een git-repository van VNG Realisatie (getackled in #353)
• De Producten API wordt getest met de API Testvoorziening van de VNG (zie #354)

De Producten API ontsluit de productbeschrijvingen naar de nationale portalen en mogelijk ook naar gemeenten en andere geïnteresseerden. De productbeschrijvingen zijn publieke data.
De Producten API is publiek toegankelijk om te lezen
Afnemers moeten de zekerheid hebben dat zij de door gemeenten beheerde teksten ophalen
De Producten API authentiseert zichzelf met een (PKI) certificaat, opdat de Nationale portalen de zekerheid hebben productteksten van gemeenten te publiceren.

Tasks

• De Producten API ontsluit de productbeschrijvingen naar de nationale portalen en mogelijk ook naar gemeenten en andere geïnteresseerden. De productbeschrijvingen zijn publieke data.
• De Producten API is publiek toegankelijk om te lezen.
• De Producten API authentiseert zichzelf met een (PKI) certificaat, opdat de Nationale portalen de zekerheid hebben productteksten van gemeenten te publiceren. Niet meer nodig per comment van Martin.

Binnen de invoervoorziening gebruikt ter informatie van de gebruiker

Acceptatiecriteria :

• bij het navigeren naar de pagina worden de gepubliceerde gegevens getoond.

Tasks

• Add view/template to show Lokatie/LokaleOverheid data with link to go to the edit page.

Convenience voor de eindgebruiker

Acceptatiecriteria : na inloggen is het gebruikersprofiel zichtbaar

De Nationale Portalen mogen alleen die productgegevens tonen van een gemeente waarvan de gemeente heeft aangegeven hierover te beschikken.

Acceptatiecriteria :

De API moet voorzien in de functie GET /sdgproducten/{upnidentificatie}/gemeentes:

• De functie geeft terug welke gemeentes
• het product leveren
• het product niet leveren en
• het product (nog) niet hebben beschreven.

Tasks

• Add the filter productAanwezig to producten resource. Example: /api/v1/producten?productAanwezig=ja values: ja,nee,onbekend

..., opdat de gemeente redacties zelf de redacteuren kunnen toevoegen

Acceptatiecriteria : het accountbeheer moet voldoen aan de eisen van de BIO, bijvoorbeeld dat het mogelijk moet zijn accounts te verwijderen.

Tasks

• Add m2m relation between User and LokaleOverheid with a through-model Role
• Users that can only access the CMS are NOT staff users.
• On the User model, add a is_redacteur field. This field indicate people that can edit the reference texts.
• On the Role model, add a is_beheerder and is_redacteur field. These fields define the role of the user for a specific LokaleOverheid organization.
• Allow editing the model/fields in the admin
• Add filtering on these fields in the admin and show in columns in list_display.
• Also add filtering on LokaleOverheid.

Componenten zijn out-of-the-box geschikt voor installatie binnen een gestandaardiseerde (cloud-)infrastructuur platform (bijvoorbeeld Haven9).

De componenten zijn geautomatiseerd te testen en deployen middels een CI/CD pipeline
Het doorlopen van de pipeline duurt max 1 uur
De voorziening dient als container op (bijvoorbeeld een kubernetes) infrastructuur te kunnen worden gedeployed

Tasks

• Docker container bouwen via Github Actions
• Docker container publiceren op Dockerhub
• Unit tests uitvoeren via CI pipeline

In overleg met PO: het daadwerkelijk uitrollen naar een (Haven)omgeving is verplaatst naar een andere (niet must-have) user story.

This ticket is about reference products (Standaard*-models) that are managed by a user with the permission is_global_redacteur.

Tasks

• Add detail page view/template for a product (field name, field help text and field value)
• Last column (see screenshot) can be datum_wijziging date
• Show all available languages as tab. Each tab includes the product in the selected language.
• Clicking the yellow "Wijzigen" button shows an edit page, like the 2nd screenshot, with a textarea/input/markdown widget for each field. There's a save button at the bottom.

NOTE: Deactivate languages (as shown in the screenshot) are not part of this ticket.
These changes can be saved directly, no need to take any publishing (future) date into account or anything. The behaviour is simple and plain.

Tasks

• Setup the repository (@joeribekker)
• Create project board (@joeribekker)
• Create new project from default-project, named sdg (ie. I want to see from sdg.accounts.models import User)
• Commit project to this repo

De voorziening dient aan te sluiten en gebruik te kunnen maken van de landelijke integratiefaciliteit zoals benoemd in Common Ground
De voorziening dient gebruik te maken van (Linked) Open Data om reeds publiek beschikbare bronnen te kunnen raadplegen en de data te kunnen representeren in de voorziening
Hiermee dienen de koppelingen zoals beschreven in par 5.6 te worden gerealiseerd

Tasks

• Create management command to import SDG informatiegebieden into the proper models (Thema, Informatiegebied yes, we need them). See: https://standaarden.overheid.nl/owms/oquery/SDG-Informatiegebieden.csv -- Can you amend the models to register all columns?
• Create management command to import UPNs (Uniforme productnamen) into the proper models (UniformeProductnaam). See: https://standaarden.overheid.nl/owms/oquery/UPL-actueel.csv -- Can you amend the models to register all columns?
• Create management command to import Gemeenten into the proper models (Overheidsorganisatie yep, separate model and we need an extraAttribute "endDate" + querymanager to filter on active gemeenten =< today). See: https://standaarden.overheid.nl/owms/terms/Gemeente.xml

Where it says "Create management command" this should read as "make functions to import the data" and call these functions from a management command. Later on, we might need to do this periodically.

Een gemeente kan meerdere locaties hebben waar diensten worden geleverd

Acceptatiecriteria :

• Na het toevoegen is de locatie direct zichtbaar in het overzicht
• Na het toevoegen kan de locatie gebruikt worden om producten aan te koppelen

Tasks

• Modify Lokatie model to include openingstijden for each day, and adres, straat, nummer, postcode, plaats, land, website, telefoonnummer, email
• Add view/form/template to edit Lokatie details.
• Allow a new location to be added.

..., zodat ik mijn website periodiek kan synchroniseren

Het maken van een kopie van de gegevens staat op gespannen voet met het ?common ground? principe van ?data bij de bron?.

Acceptatiecriteria :

• De bestaande API functies worden uitgebreid met een functie om alleen wijzigingen binnen een bepaald timeframe op te halen.

Tasks

• Add the ability to add __gte to the publicatiedatum filter.

Autorisatie : alleen geautoriseerde gebruikers mogen gegevens bewerken. Er moet onderscheid gemaakt kunnen worden tussen gemeentelijke gebruikers en gebruikers die vallen onder de gedeelde redactie

Acceptatiecriteria : uit te werken

Tasks

• The logged in user sees the relevant menu items / template parts that it can access.
• Views are protected with regards to the user's role.

Essentially: A global editor can edit the reference texts. A municipality editor can edit THEIR municipality texts (role->organisation).

Gemeentelijke wens t.b.v. planning
in de mock-up wordt de mogelijkheid opgenomen om een datum op te geven. Dit is verder niet uitgewerkt

Acceptatiecriteria :

• Als een publicatiedatum is opgegeven dan wordt een gegeven pas uitgeleverd wanneer deze datum verstreken is.

Tasks

We introduce concepts and published products.

The idea is that users can keep editing concepts AND future published products without creating new versions. So, you can never edit already published products (ie, their publicatie_datum is in the past).

• Add ProductVersion model, with the fields: product=FK(Product), publicatie_datum (moved from Product to this model), created_by, created_on, modified_on
• Change ProductLocalization model to point from ProductVersion instead of Product (each localization belongs to a specific version)
  today)`
• On the edit page, add option to publish now (publicatie_datum = now()) or choose a specific date (publicatie_datum = choosen date). Note that the screenshot shows a non-edit page, but we're moving this to the edit page.
• Change the edit page to include a button "Opslaan als concept" (Save as concept) which does NOT allow a date to be picked, and the publish date remains empty upon save (no publish date basically means "this is a concept")
• Change the edit page so the latest ProductVersion is always edited (this can thus be a concept, or a (future) published product).
• Change the edit page so when a Product is edited and saved, only a new version is created when the existing product had a publicatie_datum in the past/today.
• Add validation to prevent a publicatie_datum that is earlier than another ProductVersion's publicatie_datum
• Add QuerySet function Product.get_latest_product_versions (the product with the highest publicatie_datum or publicatie_datum=None)
• Use the queryset function to adjust the product list view to show only the latest product versions.
• In the history part of the page, show a list of ProductVersions, like: "{{ created_by }}, laatst bewerkt op {{ modified_on }} en gepubliceerd op {{ publicatie_datum }}"

ProductVersion

• product=FK(Product)
• publicatie_datum
• created_by
• created_on
• modified_on

ProductLocalization

• product_version = FK(ProductVersion)
• [...]

Indien de producten API ook het schrijven van waarden gaat toestaan worden deze operaties conform de landelijke API strategie en de nog in ontwikkeling zijnde Digikoppeling profielen beveiligd met oAuth dan wel mTLS voor de beveiliging

Tasks

• Add markdown editor library for all textarea fields in the admin.

De invoervoorziening gaat gebruikt worden door medewerkers van een centrale redactie en medewerkers van gemeentelijke redacties.
Alleen geautoriseerde gebruikers hebben toegang tot de invoervoorziening
Inloggen met 2 factor authenticatie
Een username, password (iets weten)
Een (TOTP) token, gegenereerd met een app op eigen telefoon of laptop (iets hebben)

Ondersteuning voor role based access control.
Medewerkers van een gemeente krijgen toegang tot de beheerschermen op basis van een rol én een organisatie
Mogelijke rollen zijn bijvoorbeeld: redactiemedewerker, centrale redactie, beheerder, ?

Tasks

• 2-factor auth voor CMS inlog toevoegen

De betrouwbaarheidseisen van de invoervoorziening en de API zijn uitgewerkt in de SLA en worden vastgesteld in overleg met de Leverancier

Of raadpleegbaar met een API
Of redactie portalen werkt in invoervoorziening

Acceptatiecriteria :

• van een product wordt de Generieke tekst getoond indien aanwezig. Indien er geen generieke tekst beschikbaar is dan wordt een waarschuwing getoond

Tasks

• Add the GenericProduct fields as readonly above the editable fields of the SpecificProduct in the cms page
• If the reference product does not exist (anymore), show warning in the cms page ("Dit product is van de productenlijst verwijderd. Uw product is nog zichtbaar omdat u deze in het verleden heeft toegevoegd aan uw catalogus maar zal niet meer getoond worden op de Nationale Portalen.")
• If there are is no reference_product.generiek_product, show warning in the cms page ("Dit product heeft geen generieke product teksten") and then, don't show the generic fields.

Meldngen taken naar nieuw ticket verplaatst.

De invoervoorziening wordt gerealiseerd met open source software componenten.
De gebruikte ?technologie stack? bestaat uit gangbare componenten met een levendige community
Er wordt altijd gebruik gemaakt van door de community supported versies.

Acceptatiecriteria:

wanneer de generieke tekst is gewijzigd krijgt de gemeente een waarschuwing m.b.t. dit product dat de aanvullende teksten opnieuw beoordeeld moeten worden.
De actualiteitseis van de waarschuwing is laag. Een oplossing kan zijn dat dagelijks wordt opgevraagd welke teksten gewijzigd zijn

Tasks

• @markbacker overweegt een "laatste_wijzigingsdatum" / "publicatie_datum" te laten opnemen bij Generiek Product, per taal.
• Always color flags for languages (no logic anymore)
• Add new filter to check changes in generic text (like with standard texts)

@markbacker Helaas, het !-icoon gaat over wijzigingen in de standaardtekst, en niet over de generieke tekst. Nog een icoon toevoegen? Ook moet het IM aangepast worden want we hebben een publicatie datujm nodig.