Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Expand
titleOverzicht van wijzigingen
Table of Contents
minLevel1
maxLevel7

[v8.32.2.0] Laatste loodjes voor Go-live van de eerste versie: ⚠️ API Key op Staging, MAGDA Connectie actief,
⚠️ velden hernoemd, verbetering dubbel detectie, ⚠️ weglaten van het concept afdeling

⚠️ API Key is actief op Staging (en productie)

De publieke API is nu enkel op te vragen met een API Key. Deze kan je aanvragen met dit formulier: Aanvragen API Key. Indien mogelijk, geef duidelijk aan voor welke toepassing, organisatie je toegang wil + voor welke omgeving (enkel staging of staging en productie.

Het opvragen van context, parameters en API documentatie is mogelijk zonder API Key.

MAGDA connectie staat actief

Voor de beheer API kan je nu ook al connecteren via Magda. De rechtstreekse link naar het verenigingsrgister zal mettertijd geschrapt worden. Diegene die die link gebruiken, wordt dus aangeraden om ook voor de staging omgeving al om te schakelen naar de MAGDA connectie. (Daar heet die omgeving wel T&I).

⚠️ Velden hernoemd

Als voorbereiding op het publiceren van verenigingsdata als linked open data, zijn op verschillende plaatsen velden hernoemd:

  • relaties.type → relaties.relatietype

  • contactgegeven.type → contactgegeven.contactgegeventype

  • vereniging.type → vereniging.verenigingstype

    • vereniging.verenigingstype.beschrijving → vereniging.verenigingstype.naam

  • hoofdactiviteiten.beschrijving → hoofdactiviteiten.naam

Verbeteringen in dubbel detectie

Bij het registreren van een feitelijke vereniging wordt gecontroleerd of er deze vereniging mogelijks al bestaat. Dit zoeken naar die andere vereniging was tot nu toe redelijk strikt. Momenteel accepteren we ook kleine verschillen in de naam of gemeente, zoals extra spaties, leestekens, hoofdletters, extra letters, accenten of verbindingswoorden (zoals de, het, van …).

Dit resulteert in extra resultaten tijdens de dubbel detectie met een grotere kans om diegene te vinden die echt een dubbel is. Aan de andere kant komen er hierdoor wel extra items terug die zeker geen dubbel zijn. We controleren nog steeds op gelijkenissen in naam+postcode OF naam+gemeente.

⚠️ Voorlopig weglaten van het concept afdeling

Tijdens het verzamelen van de data bij de piloten, hebben we vastgesteld dat er enorm veel begripsverwarring is omtrent de definitie van een afdeling. Hierdoor riskeren we om veel data op te laden met het verkeerde verenigingstype. Om deze reden hebben we voorlopig het onderscheid tussen een feitelijke vereniging en en afdeling laten vallen. We kennen nu dus enkel een vereniging MET een KBO nummer en een vereniging ZONDER een KBO nummer.

...

  • Het endpoint om afdelingen te registreren wordt tijdelijk gedeactiveerd (POST <BeheerURL>/v1/verenigingen/afdelingen)

  • De collection relaties wordt nog steeds weergegeven in de respons structuren, maar zal steeds leeg zijn

  • AFD - Afdeling wordt weggehaald uit de lijst van mogelijke verenigingstypes

[v8.6.0.0] 📚 Sorteren en relaties in de publieke zoekfunctie, 📚 KBO-nummer en status in de ACM API,
⚠️ 📚verwijderen oud pad voor registratie feitelijke verenigingen

datum installatie op staging:

Verbeteringen aan de publieke zoekfunctie

We hebben de publieke zoek functie uitgebreid met 1 extra dataveld en 1 extra mogelijkheid.

Opgelet: deze uitbreidingen zijn enkel toegepast op de publieke zoek functie en niet op de zoekfunctie in de beheer API.

📚 Relaties toegevoegd

We hebben de relaties tussen een afdeling en haar moeder (en omgekeerd) toegevoegd aan de zoekresultaten. Dit maakt het mogelijk om direct een link te tonen vanuit de resultaten en/of om te gaan zoeken op vereniging die een bepaalde relatie hebben met een andere vereniging.

Code Block
languagejson
GET <PubliekURL>/v1/verenigingen/zoeken?q=<zoekcriterium>
{
    "verenigingen": [
        {
            "vCode": "V0001001",
            "type": {
                "code": "AFD",
                "beschrijving": "Afdeling"
            },
            "naam": "Dit is een afdeling",
            ...
            "relaties": [
                {
                    "type": "Is afdeling van",
                    "andereVereniging": {
                        "kboNummer": "0123456789",
                        "vCode": "V0001002",
                        "naam": "Dit is een VZW",
                        "detail": "https://publiek.verenigingen.test-vlaanderen.be/v1/verenigingen/V0001002"
                    }
                }
            ]
            ...
        },
        {
            "vCode": "V0001002",
            "type": {
                "code": "VZW",
                "beschrijving": "Vereniging Zonder Winstoogmerk"
            },
            "naam": "Dit is een VZW",
            ...
            "relaties": [
                {
                    "type": "Heeft als afdeling",
                    "andereVereniging": {
                        "kboNummer": "",
                        "vCode": "V0001001",
                        "naam": "Dit is een afdeling",
                        "detail": "https://publiek.verenigingen.test-vlaanderen.be/v1/verenigingen/V0001001"
                    }
                },
            ],
            ...
        }

📚 Sorteren van de zoek resultaten

De zoek resultaten kunnen gesorteerd worden door het toevoegen van een sort variabele. De zoekvelden waarop kan gesorteerd worden zijn vCode, naam, korteNaam, roepnaam, type.code, type.beschrijving, doelgroep.minimumleeftijd en doelgroep.maximumleeftijd.

...

Code Block
languagejson
<PubliekURL>/v1/verenigingen/zoeken?q=*&sort=naam,-vCode
<PubliekURL>/v1/verenigingen/zoeken?q=*&sort=naam

📚 Toevoegen KBO nummer en status aan ACM API

Wanneer ACM de verenigingen voor een bepaalde persoon komt opvragen, gaan we naast de vCode en de naam ook de huidige status van de vereniging meegeven alsook eventueel het kbo-nummer. Dat biedt ACM de mogelijkheid om al dan niet te filteren op actieve verenigingen , maar ook om de KBO-verenigingen uit het verenigingsregister te matchen met de resultaten die een gelijkaardige vraag in het KBO oplevert.

Code Block
languagejson
GET <ACMURL>/v1/verenigingen?insz=<INSZ>
{
    "insz": "00000000196",
    "verenigingen": [
        {
            "vCode": "V0001001",
            "naam": "Deze vereniging is niet meer actief",
            "status": "Gestopt",
            "kboNummer": ""
        },
        {
            "vCode": "V0001002",
            "naam": "Dit is een vereniging uit KBO",
            "status": "Actief",
            "kboNummer": "1234567890"
        }        
    ]
}

⚠️ 📚 Verwijderen oude pad voor registratie van feitelijke verenigingen

De URL om een feitelijke vereniging te registreren werd in een vorige versie al gewijzigd naar

...

In deze versie werd oude pad (zonder extensie feitelijkeverenigingen ) verwijderd en is dus niet meer bruikbaar.

Verwerking ontvangen feedback

📚 Fix inconsistentie beheer api problemdetails

In de swagger werd op sommige plaatsen nog gebruik gemaakt van Microsoft.AspNetCore.Mvc.ProblemDetails of Microsoft.AspNetCore.Mvc.ValidationProblemDetails. Deze zijn nu verwijderd.

📚 Verwijder nullable uit Swagger doc

In de swagger werden sommmige velden als nullable aangeduid, wat problemen opleverde voor de Magda implementatie. Die nullable vermeldingen zijn overal weggehaald.

Fix: Etag wordt niet aangepast in beheer detail na Patch van een KBO contactgegeven

Na het wijzigen van een KBO contactgegeven (PATCH <BeheerURL>/v1/verenigingen/<vCode>/contactgegevens/kbo/<KBOContactgegevenId>) wordt een Etag in de response header meegegeven. Wanneer we vervolgens het Beheer detail van die vereniging opvragen (GET <BeheerURL>/v1/verenigingen/<vCode>) zien we dat daar de Etag niet werd aangepast.

Tijdstip in Beheer historiek wordt nu in Zulu time formaat getoond

Het tijdstip in beheer historiek werd weergegeven in UTC, maar zonder dit expliciet te vermelden. Een wijziging die om 15u werd uitgevoerd, kwam dus gewoon als 13:00:00 terug. Dit werd makkelijk fout geïnterpreteerd als 13u. Om duidelijk aan te geven hoe dit tijdstip moet geïnterpreteerd worden, wordt het nu in Zulu formaat getoond: 2023-09-28T13:00:00Z

[v7.29.0.0] 📚 Verrijken KBO gegevens, 📚 Stoppen van een vereniging, ⚠️ 📝 Aanpassingen aan swagger

datum installatie op staging:

Verrijken KBO gegevens

Gegevens die we uit KBO obvergenomen hebben, kunnen niet aangepast worden. We maken het nu wel mogelijk om voor deze data objecten de velden in te vullen die niet uit KBO overgenomen zijn.

📚 Wijzigen van de maatschappelijke zetel volgens KBO

Voor de maatschappelijke zetel volgens KBO is het mogelijk om de velden naam en isPrimair aan te passen. Het locatietype, adres en adresID blijven steeds ongewijzigd. Deze actie mogelijk via een apart endpoint

Code Block
languagejson
PATCH <BeheerURL>/v1/verenigingen/<vCode>/kbo/locaties/<LocatieID>
{
  "naam": "locatie naam voor de maatschappelijke zetel",
  "isPrimair": true
}

📚 Wijzigen van KBO contactgegevens

Ook voor de contactgegevens die overgenomen worden uit KBO kan je enkel de velden beschrijving en isPrimair aanpassen. Ook hier is dat via een apart endpoint

Code Block
languagejson
PATCH <BeheerURL>/v1/verenigingen/<vCode>/kbo/contactgegevens/<contactgegevenID>
{
  "beschrijving": "beschrijving voor dit contactgegeven uit KBO",
  "isPrimair": true
}

Tijdelijk nabootsen van functiehouders uit KBO

Zolang we niet de juiste machtiging hebben om persoonsgegevens op te halen uit KBO, zijn we een beetje geblokkeerd om verder te ontwikkelen op de vertegenwoordigers van een KBO vereniging. Om dit euvel te verhelpen, maken we het nu mogelijk om de KBO functiehouders na te bootsen door bij elke registratie van een KBO vereniging een vaste set van personen toe te voegen. Deze set kan op aanvraag aangepast worden (om zelf ook te kunnen testen). Van elke vertegenwoordiger voegen we insz, voor- en achternaam toe. We vinden deze gegevens terug in beheer detail en in beheer historiek

Code Block
languagejson
GET <BEHEERURL>/v1/verenigingen/<vCode>/historiek
...
        {
            "beschrijving": "Vertegenwoordiger 'John Doke' werd overgenomen uit KBO.",
            "gebeurtenis": "VertegenwoordigerWerdOvergenomenUitKBO",
            "data": {
                "vertegenwoordigerId": 1,
                "isPrimair": false,
                "roepnaam": "",
                "rol": "",
                "voornaam": "John",
                "achternaam": "Doke",
                "e-mail": "",
                "telefoon": "",
                "mobiel": "",
                "socialMedia": ""
            },
            "initiator": "Postman",
            "tijdstip": "2023-09-13 07:11"
        },
        {
            "beschrijving": "Vertegenwoordiger 'Jane Doe' werd overgenomen uit KBO.",
            "gebeurtenis": "VertegenwoordigerWerdOvergenomenUitKBO",
            "data": {
                "vertegenwoordigerId": 2,
                "isPrimair": false,
                "roepnaam": "",
                "rol": "",
                "voornaam": "Jane",
                "achternaam": "Doe",
                "e-mail": "",
                "telefoon": "",
                "mobiel": "",
                "socialMedia": ""
            },
            "initiator": "Postman",
            "tijdstip": "2023-09-13 07:11"
        },
...

Wijzigen van KBO vertegenwoordigers

Nu we vertegenwoordigers van KBO verenigingen beschikbaar hebben, kunnen we deze gegevens ook aanvullen met gegevens die niet in KBO terug te vinden zijn. Dit zijn exact dezelfde gegevens dan wat je mag wijzigen voor een vertegenwoordiger van een feitelijke vereniging of een afdeling. We gebruiken hier geen specifiek endpoint voor. We controleren wel dat je voor KBO verenigingen geen vertegenwoordigers kan toevoegen, noch verwijderen.

Code Block
languagejson
PATCH <BeheerURL>/v1/verenigingen/<vCode>/vertegenwoordigers/<vertegenwoordigerId>
{
    "vertegenwoordiger": {
        "rol": "voorzitter",
        "roepnaam": "Joske",
        "isPrimair": true,
        "e-mail": "joske@vereniging.be",
        "telefoon": "012 34 56 78",
        "mobiel": "0412 34 56 78",
        "socialMedia": "https://social.media/Joske"
    }
}

📚 Stoppen van een vereniging

Wanneer een feitelijke vereniging of een afdeling de activiteiten stopt, kan je dat ook aangeven in het verenigingsregister. Voor deze gebeurtenis is een apart endpoint beschikbaar. De einddatum is een verplicht veld, waarvoor geldt: startdatum <= einddatum <= vandaag

...

Je kan de einddatum aanpassen door nogmaals de STOP aan te roepen met de nieuwe einddatum. Dit zal de einddatum aanpassen en een aparte gebeurtenis aanmaken (“EinddatumWerdGewijzigd“)

Aanpassingen aan swagger

📚 Nieuw pad voor het registreren van een feitelijke vereniging

De URL om een feitelijke vereniging te registreren zal gewijzigd worden naar

...

Voorlopig is het oude pad (zonder extensie feitelijkeverenigingen nog beschikbaar, maar dit zal binnenkort weggehaald worden.

📚 sample data verbeteren

Voor elke mogelijke API call is gecontroleerd dat de sample data in de API documentatie is ingevuld en ook correcte, mogelijek waarden bevat.

⚠️ 📚 Verwijderen van de endpoints voor contexten en parameters uit de beheer API

We hebben de endpoints voor de JSON LD contexten en dat voor de parameters (nu enkel de hoofdactiviteitenVerenigingsloket) weggehaald uit de Beheer API. Voor beide verwijzen we nu naar de Publieke API waar je deze data ook kan opvragen.

Code Block
GET <PubliekAPI>/v1/contexten/<contextnaam>
GET <PubliekAPI>/v1/hoofdactiviteitenVerenigingsloket

[v7.10.0.0] ⚠️ 📚 Verrijken KBO verenigingen, 📚 INSZ toevoegen aan beheer detail en ⚠️ 📚 verwerking ontvangen feedback

datum installatie op staging:

Verrijken KBO verenigingen

Het is nu ook mogelijk om extra gegevens toe te voegen aan verenigingen met rechtspersoonlijkheid, ook gekend als de KBO-verenigingen. Na registratie van een KBO-vereniging kan je deze verrijken met eigen data (doelgroep leeftijd, roepnaam, correspondentie- en activiteiten locaties en eigen contactgegevens) . De gegevens die overgenomen werden uit KBO mogen niet overschreven of verwijderd worden. Hierbij is gekozen om zoveel mogelijk gebruik te maken van de bestaande endpoints. De URL structuur is ook eenvormig gemaakt. Zo zal elke wijziging aan een bestaande vereniging steeds opgeroepen worden met een URL die begint met <BeheerURL>/v1/verenigingen/<vCode>

⚠️ 📚 Wissel route voor Patch KBO

Door het eenvormig maken van de URL structuur, is het pad om de basis gegevens van een KBO vereniging aan te passen aangepast van <BeheerURL>/v1/verenigingen/kbo/<vCode> naar <BeheerURL>/v1/verenigingen/<vCode>/kbo

Code Block
languagejson
PATCH <BeheerURL>/v1/verenigingen/<vCode>/kbo
{
  "korteBeschrijving": "URL is aangepast"
}

⚠️ 📚 Metadata veld beheerBasisUri verwijderd

Door het eenvormig maken van URL structuur en door het maximaal herbruiken van de endpoints voor het verrijken van de KBO verenigingen, is de waarde in het metadataveld beheerBasisUri niet langer geldig. De plek waarmee aangeduid wordt welke endpoint te gebruiken is voor welke data, wordt eerder bepaald door het veld bron (zie verder) dan door een vaste basisURI . Het veld metadata.beheerBasisUri is weggehaald uit beheer detail.

📚 Toevoegen bron van de gegevens

Om duidelijk het verschil te maken tussen de gegevens die overgenomen zijn van KBO (en dus beperkt aanpasbaar zijn) en de gegevens die vrij te beheren zijn, is er een nieuw veld toegevoegd met naam bron en waarden Initiator en KBO. Dit veld is enkel in beheer detail terug te vinden, maar wel op verschillende niveaus:

...

Code Block
languagejson
GET <BeheerURL>/v1/verenigingen/<vCode>
{
  "vCode": "V0001001",
  ...
  "bron": "KBO",
  "locaties": [
    {
      "locatietype": "Maatschappelijke zetel volgens KBO",
      "bron": "KBO",
      ...
    },
    {
      "locatietype": "Correspondentie",
      "bron": "Initiator",
      ...
    }
  ],
  "Contactgegevens": [
    {
      "type": "E-mail",
      "bron": "KBO",
      "waarde": "IkKomUitKBO@vereniging.be",
      ...
    },
    {
      "type": "E-mail",
      "bron": "Initiator",
      "waarde": "IkBenAchterafToegevoegd@vereniging.be",
      ...
    }  
  ]
}

📚 Doelgroep leeftijd

Net zoals voor feitelijke verenigingen en afdelingen kunnen we nu ook de doelgroep leeftijd van een KBO vereniging beheren. Dit gebeurt via het endpoint voor het wijzigen van de basisgegevens. De regels, validaties en verwachte antwoorden zijn hierbij identiek aan het wijzigen van de doelgroep leeftijd voor feitelijke verenigingen en afdelingen. (zie https://vlaamseoverheid.atlassian.net/wiki/spaces/AGB/pages/6264848448/Release+notes+-+Staging+omgeving#Wijzigen )

Code Block
languagejson
PATCH <BeheerURL>/v1/verenigingen/<vCode>/kbo
{
    "doelgroep": {
        "minimumleeftijd": 8,
        "maximumleeftijd": 88
    }
}

📚 Toevoegen roepnaam voor KBO verenigingen

Voor een KBO verenigingen kunnen we naast de officiële naam (die overgenomen werd uit KBO) ook een roepnaam bepalen. Hiermee kan je aangeven hoe deze vereniging beter gekend is, wat soms afwijkt van de officiële naam zoals die in KBO gekend is. Bij registratie van een KBO verebniging is deze roepnaam leeg (""). Je kan een roepnaam toekennen aan een KBO vereniging, maar deze achteraf ook weer leeg maken. Dit alles gebeurt via hetzelfde endpoint voor het beheren van de basis gegevens van een KBO vereniging.

...

Code Block
languagejson
PATCH <BeheerURL>/v1/verenigingen/<vCode>/kbo
{
    "roepnaam": ""
}

Bijkomende locatie voor een KBO vereniging

De maatschappelijke zetel wordt overgenomen uit KBO. Via decentraal beheer kan je (net zoals voor feitelijke verenigingen en afdelingen) 1 correspondentie adres en meerdere activiteiten locaties toevoegen. Dit gebeurt via het zelfde endpoint als voor de feitelijke verenigingen en afdelingen.

...

Het is NIET mogelijk om een maatschappelijke zetel volgens KBO via decentraal beheer toe te voegen en het is ook NIET mogelijk om de maatschappelijke zetel volgens KBO te wijzigen of te verwijderen.

Bijkomende contactgegevens voor een KBO vereniging

Na registratie van de KBO vereniging worden de contactgegevens beschikbaar in KBO overgenomen naar het verenigingsregister. Via decentraal beheer kan je bijkomende contactgegevens toevoegen. Dit gebeurt via het zelfde endpoint als voor de feitelijke verenigingen en afdelingen.

...

Het is NIET mogelijk om een contactgegevens uit KBO via decentraal beheer toe te voegen en het is ook NIET mogelijk om een contactgegeven uit KBO te wijzigen of te verwijderen.

📚 INSZ terug toevoegen aan beheer detail

Eerder werd het INSZ weggehaald uit alle mogelijke antwoorden van het verenigingsregister. Dat gaf echter praktische problemen, o.a. voor het ophalen van de contactgegevens van een persoon die in een loket ingelogd is. We brengen het veld INSZ terug, maar wel enkel in beheer detail

Code Block
GET <BeheerURL>/v1/verenigingen/<vCode>
{
  "vCode": "V00010001",
  ...
  "vertegenwoordigers": [
    {
      "vertegenwoordigerId": 1,
      "INSZ": "12345678901",
      "voornaam": "John",
      "achternaam": "Doe",
      ...
    }
  ]
}

Verwerking ontvangen feedback

Wijzigen direct na registratie geeft issue met If-match

We hebben een bug opgelost waarbij het niet mogelijk was om direct na een registratie van een nieuwe vereniging, de basisgegevens van deze vereniging te wijzigen, waarbij gebruikt gemaakt werd van de If-Match header . Dit bleef steeds een 412 teruggeven. Nu is dit wel mogelijk.

📚 Toevoegen API documentatie voor dubbeldetectie response bij registreer afdeling

Bij registratie van een afdeling wordt een dubbel detectie uitgevoerd. Indien dubbels ontdekt worden, geeft dit status code 409 met in de response de mogelijke duplicates. Dit was voorheen al zo, maar dit stond nog niet gedocumenteerd in de API documentatie. Status code 409 is toegevoegd als mogelijke response.

⚠️ 📚 Consistente status codes bij ontbrekende data

Wanneer je bij het beheren van data een onbekende vCode gebruikt of een onbekend ID van een locatie, contactgegeven of vertegenwoordiger, dan was er voorheen een inconsistentie in de response codes. Meestal werd status code 400 terug gegeven, maar soms ook 404. Dat is nu gelijk getrokken:

  • Een onbekende vCode of een onbekend ID geven telkens een 400 terug bij het beheren

    • Dit betekent een aanpassing van de response code bij het beheren van een onbekend contactgegeven

  • Een onbekende vCode geeft een 404 terug bij het opvragen van gegevens

    • Dit betekent een aanpassing bij het opvragen van een onbekende context

[v6.16.2] Integratie met KBO + ⚠️ 📚 Correcties aan de bestaande API definitie + verwerking ontvangen feedback

datum installatie op staging:

Integratie met KBO via Magda dienst GeefOnderneming

Validatie KBO nummer bij registratie van een KBO vereniging

Bij registratie van een KBO vereniging, wordt Magda dienst Onderneming.GeefOnderneming-02.00 gebruikt om na te gaan of:

...

Opgelet: De testomgeving van Magda dienst GeefOnderneming verwijst naar de testomgeving van KBO. Daar kan je werkelijke data terugvinden, maar wel een verouderde versie. Het is dus perfect mogelijk dat je een recent aangemaakte VZW niet kan registreren omdat deze nog niet in de testomgeving aanwezig is.

Overname van de gegevens

Na correcte validatie van een KBO-nummer worden volgende gegevens overgenomen uit KBO

...

Hetzelfde kan zich ook voordoen met de contactgegevens uit KBO. Ook hier nemen we deze contactgegevens niet over en voegen we een gebeurtenis toe ContactgegevenKonNietOvergenomenWordenUitKBO met in de details van die gebeurtenis het contactgegeven zoals het in KBO terug te vinden is.

⚠️ 📚 Correcties aan de bestaande API definitie

Email → E-mail

De correcte schrijfwijze is e-mail met een streepje ertussen. Dit hebben we overal doorgevoerd, maar heeft vooral impact op

  • Contactgegevens: het contact type is nu E-mail

  • Vertegenwoordigers: Hier is E-mail een aparte eigenschap

  • Historiek van de vereniging: telkens wanneer in data een labelE-mail gebruikt wordt

  • De tekst van de foutboodschappen bij validatie van de gegevens

Swagger validatie issues opgelost

De swagger van de Beheer API voldoet nu aan de vereisten volgens swagger.io

Maatschappelijke zetel → Maatschappelijke zetel volgens KBO

Locatie type Maatschappelijke zetel (enkel beschikbaar bij het zoeken naar of bij het opvragen van het detail van een vereniging) is hernoemd naar Maatschappelijke zetel volgens KBO

Verwerking ontvangen feedback

Beschrijving in historiek bij beheren van contactgegevens

De beschrijving in de historiek van een vereniging bij toevoegen, wijzigen of verwijderen van en contactgegeven is nu aangepast, en dan vooral het gebruik van de aanhalingstekens. De beschrijving is nu E-mail 'info@vereniging.be' werd toegevoegd. warbij geen aanhalingstekens meer geplaatst worden rond het contact type.

bugfix: bij wijzigen van locaties

We hebben en foutje opgelost waarbij na het wijzigen van een locatie die wijziging niet in rekening gebracht werd bij volgende beheer acties. Zo was het bijvoorbeeld mogelijk om meerdere locaties primaire te maken via de wijzig locaties actie.

[v6.4.0] ⚠️ Beheren locaties + doelgroep leeftijd + ⚠️ voorbereiding op Magda integratie (initiator, correlation id, opkuis zoekresultaten, JSON-LD context) + behoud sortering van de collections

Beheren locaties

We kunnen nu ook locaties beheren (toevoegen, wijzigen en verwijderen) en dit zeowel met adrescomponenten (straatnaam, huisnummer, …) als met een adres identificator (link naar het adresregister).

⚠️ Aanpassen structuur locatie object

Eerst en vooral is de structuur van het locatie object aangepast:

...

Code Block
languagejson
GET <BeheerURL>/v1/verenigingen/<vCode>
{
    "@context": "https://beheer.verenigingen.test-vlaanderen.be/v1/contexten/detail-vereniging-context.json",
    "vereniging": {
        "vCode": "V0001001",
        ...
        "locaties": [
            {
                "locatieId": 1,
                "locatietype": "Activiteiten",
                "isPrimair": true,
                "naam": "VAC Gent",
                "adres": {
                    "straatnaam": "Koningin Maria-Hendrikaplein",
                    "huisnummer": "70",
                    "busnummer": "",
                    "postcode": "9000",
                    "gemeente": "Gent",
                    "land": "België"
                },
                "adresvoorstelling": "Koningin Maria-Hendrikaplein 70, 9000 Gent, België",
                "adresId": {
                    "broncode": "AR",
                    "bronwaarde": "https://data.vlaanderen.be/id/adres/3706808"
                }
            }
        ],

⚠️ Wijzigingen aan het registreren van een nieuwe feitelijke vereniging of afdeling

Wanneer je een locatie wil opgeven bij registratie van een nieuwe feitelijke vereniging of een nieuwe afdeling, dan moet je nu de nieuwe structuur van het locatie object gebruiken.

...

Wanneer je een adresId opgeeft, dan zijn zowel broncode als bronwaarde beide verplicht in te vullen. Broncode kan enkel de waarde AR bevatten en bronwaarde moet een URI zijn van het adresregister (begint met https://data.vlaanderen.be/id/adres/)

Toevoegen van een nieuwe locatie

Dit kan enkel voor een feitelijke vereniging of een afdeling. Je kan een nieuwe locatie toevoegen aan een bestaande vereniging met een POST API call waarin je een locatie object opgeeft. Ook hier kan je kiezen tussen een adres, een adresId of beide.

Code Block
languagejson
POST <BeheerURL>/v1/verenigingen/<vCode>/locaties
{
    "locatie": {
        "locatietype":"Activiteiten",
        "isPrimair": false,
        "naam": "Extra locatie",
        "adres": {
            "straatnaam": "Nieuwstraat",
            "huisnummer": "2",
            "busnummer": "b",
            "postcode": "2222",
            "gemeente": "Nieuwegem",
            "land": "België"
        },
        "adresId": {
            "broncode": "AR",
            "bronwaarde": "https://data.vlaanderen.be/id/adres/2222222"
        }
    }
}

Verwijderen van een bestaande locatie

Om een bestaande locatie te verwijderen, kan je een DELETE actie uitvoeren waarbij je verwijst naar de locatieId die je wil verwijderen

Code Block
DELETE <BeheerURL>/v1/verenigingen/<vCode>/locaties/<locatieId>

Wijzigen van een locatie

Om een bestaande locatie te wijzen, gebruik je een PATCH method waarbij je verwijst naar de locatieId die je wil wijzigen. Hierbij toch enkele aandachtspunten:

...

Code Block
languagejson
PATCH <BeheerURL>/v1/verenigingen/<vCode>/locaties/<locatieId>
{
    "locatie": {
        "naam": "Gewijzigde locatie",
        "adres": {
            "straatnaam": "Wijzigingslaan",
            "huisnummer": "2",
            "busnummer": "b",
            "postcode": "2222",
            "gemeente": "Wijzigem",
            "land": "België"
        }
    }
}

Doelgroep leeftijd

We introduceren een doelgroep classificatie gebaseerd op leeftijd. Hierbij kan je voor elke vereniging een range definiëren van leeftijden waarvoor de vereniging activiteiten aanbiedt. Deze minimum en maximum leeftijd kan je opgeven bij registratie van een feitelijke vereniging of een afdeling en kan je achteraf ook wijzigen.

Beide waarden zijn optioneel. De default waarden zijn 0 voor de minimumleeftijd en 150 voor de maximumleeftijd.

Bij registratie

Code Block
languagejson
POST <BeheerURL>/v1/verenigingen
{
    "naam": "Spelletjesclub",
    "doelgroep": {
        "minimumleeftijd": 7,
        "maximumleeftijd": 77
    }
}

Wijzigen

Het wijzigen van de leeftijdsrange kan je uitvoeren met het PATCH commando waarmee je de andere basisgegevens wijzigt.

...

Code Block
languagejson
PATCH <BeheerURL>/v1/verenigingen/<vCode>
{
    "doelgroep": {}
}

Zoeken op leeftijd

De minimum- en maximum leeftijd zijn ook beschikbaar als zoekcriterium in de 2 zoek functies (beheer zoek en publiek zoek). Hiermee kan je zoeken naar verenigingen voor personen van een bepaalde leeftijd - bij wijze van voorbeeld de query om te zoeken naar alle verenigingen voor een 14-jarige

Code Block
GET <BeheerURL>/v1/verenigingen/zoek?q=doelgroep.minimumleeftijd:<=14 AND doelgroep.maximumleeftijd:>=14

Voorbereiding op de Magda integratie

Onze Beheer API zal binnenkort beschikbaar gesteld worden als een Magda dienst. Om deze integratie voor te bereiden, waren enkele wijzigingen noodzakelijk.

⚠️ Verplichte headers x-correlation-id en VR-initiator

Elke call naar de Beheer API moet verplicht deze 2 headers bevatten:

...

De API documentatie van de Beheer API is natuurlijk nog steeds zonder deze headers op te vragen.

⚠️ Opkuis van de zoekresultaten

In de zoekresultaten kon je tot nu toe nog enkele velden vinden met gegenereerde data, zoals activiteiten en doelgroep. Deze velden zijn niet relevant en zijn er nu dus uitgehaald.

Json-LD Context

De API documentatie beschrijft nu ook het pad naar de JSON-LD contexten, en dit zowel in de publieke API als in de beheers API.

Voor beheer historiek werd eveneens een link naar een JSON-LD context toegevoegd.

Sortering van de collections blijft behouden na wijziging

Wanneer je wijzigingen aanbrengt aan een vertegenwoordiger, een contactgegeven of een locatie, dan werd voorheen steeds de laatst gewijzigde onderaan in de collection geplaatst. We geven de waarden nu telkens terug gesorteerd op het interne id (zoals bvb locationId).

...

  • Stel we hebben een vereniging met 3 locaties: 1, 2 en 3.

  • Na registratie was de volgorde 1, 2, 3

  • We wijzigen nu locatie 2

  • Vroeger was de volgorde 1, 3, 2

  • Nu blijft de volgorde 1, 2, 3

[v3.28.1] Beheer zoek + Opt-Out voor verenigingen + Controle kbonummer uniek + relatie tussen moeder en afdeling

Zoek functie in beheer API

De zoek functie die bestond in de publieke API is nu ook beschikbaar via de beheer API, met slechts enkele verschillen:

...

Code Block
languagejson
GET <BeheerURL>/v1/verenigingen/zoeken?q=vCode:V0001001
{
    "@context": "https://beheer.verenigingen.test-vlaanderen.be/v1/contexten/zoek-verenigingen-context.json",
    "verenigingen": [
        {
            "vCode": "V0001001",
            ...
            "links": {
                "detail": "https://beheer.verenigingen.test-vlaanderen.be/v1/verenigingen/V0001001"
            }
        }
    ],
    "metadata": {
        "pagination": {
            "totalCount": 1,
            "offset": 0,
            "limit": 50
        }
    }
}

Opt-out voor feitelijke verenigingen

Een feitelijke vereniging kan er voor kiezen om zich te registreren, maar niet zichtbaar te zijn in de publieke stroom. Deze keuze wordt weergegeven door het veld isUitgeschrevenUitPubliekeDatastroom. Wanneer deze aan staat (waarde = true), dan is deze vereniging niet terug te vinden in de publieke zoek functie en kan je van deze vereniging ook niet het publieke detail opvragen. De vereniging is wel terug te vinden in de beheer zoek en beheer detail functie.

...

Code Block
languagejson
PATCH <BeheerURL>/v1/verenigingen/V0001001
{
    "isUitgeschrevenUitPubliekeDatastroom": true
}

Controleer dat een KBO nummer uniek is

Wanneer we een KBO vereniging registreren met een KBO nummer dat al bestaat in VR, dan resulteert dit in status code 200 (in plaats van 202). De location header bevat in dit geval de plek waar je deze KBO vereniging kan gaan raadplegen. (analoog aan de registratie van een nieuwe KBO vereniging)

Code Block
languagejson
POST <BeheerURL>/v1/verenigingen/kbo
{
    "kboNummer": "0123456789"
}
Respons 200
Location Header : <BeheerURL>/v1/verenigingen/V0001001 

Relatie tussen moeder en afdeling wanneer moeder ook in VR zit

Wanneer de moeder vereniging reeds geregistreerd was in het verenigingsregister wanneer een afdeling van deze moeder wordt geregistreerd dan krijgen zowel moeder als afdeling een relatie die verwijst naar de andere. In deze relatie staan zowel de vCode als een link naar de andere.

...

Code Block
languagejson
GET <BeheerURL>/v1/verenigingen/V0001002
{
    "vereniging": {
        "vCode": "V0001002",
        "type": {
            "code": "AFD",
            "beschrijving": "Afdeling"
        },
        "naam": "Dit is de afdeling",
        ...
        "relaties": [
            {
                "type": "Is afdeling van",
                "andereVereniging": {
                    "kboNummer": "0123456789",
                    "vCode": "V0001001",
                    "naam": "Dit is de moeder vereniging",
                    "detail": "https://beheer.verenigingen.test-vlaanderen.be/v1/verenigingen/V0001001"
                }
            }
        ]
    }
}

[v3.17.0] Beheer basisgegevens voor KBO vereniging + ⚠️ verwijder INSZ uit respons + ⚠️ toevoegen voor- en achternaam + registreer afdeling + parameters in beheer API

Beheer basisgegevens voor KBO vereniging

Voor een vereniging met rechtspersoonlijkheid (soms ook een KBO vereniging genoemd) kan je nu ook de basisgegevens aanpassen. Omdat de gegevens uit KBO niet mogen overschreven worden, blijft er in het PATCH commando enkel de korte beschrijving en de hoofdactiviteiten over. (naam, korte naam en startdatum komen uit KBO). We gebruiken hiervoor een ander pad, dat start met /v1/verenigingen/kbo. Dit pad zal later ook gebruikt worden voor alle andere aanpassingen aan KBO verenigingen.

...

Code Block
languagejson
PATCH <BeheerURL>/v1/verenigingen/kbo/<vCode>
{
    "korteBeschrijving": "Hier komt de korte beschrijving voor een KBO vereniging",
    "hoofdactiviteitenVerenigingsloket": ["HOSP"]
}

⚠️ Verwijder INSZ uit respons

Voor de bescherming van de persoonsgegevens, gaan we vanuit het verenigingsregister nergens het INSZ van een persoon teruggeven. Deze velden werden weggehaald uit beheer detail en beheer historiek.

⚠️ Toevoegen voor- en achternaam

De toegang tot het rijksregister, en bij uitbreiding het KSZ vereist een machtiging van het RR. We voorzien dat we deze machtiging pas gaan krijgen na opstart van het verenigingsregister. Tot we alle toelatingen verkregen hebben, gaan we de voor- en achternaam van de personen toch moeten opvragen aan de gegevens initiatoren. We hebben deze velden toegevoegd aan alle requesten waar ook een INSZ nummer opgegeven wordt:

...

Code Block
languagejson
POST <BeheerURL>/v1/verenigingen/<vCode>/vertegenwoordigers
{
    "vertegenwoordiger": {
        "insz": "11111111161",
        "voornaam": "Jane",
        "achternaam": "Doe",
        ...
    }
}

Registreer afdeling

Je kan nu ook een nieuwe vereniging registreren die een afdeling is van een KBO vereniging. Die KBO vereniging moet daarvoor nog niet geregistreerd te zijn in het verenigingsregister. Voor de registratie gebruiken we een ander pad /v1/verenigingen/afdelingen. De structuur van de request is identiek aan die van de feitelijke vereniging, behalve het extra (verplichte) veld kboNummerMoedervereniging.

...

Code Block
languagejson
GET <BeheerURL>/v1/verenigingen/<vCode>
{
    "vereniging": {
        "vCode": "V0002656",
        "type": {
            "code": "AFD",
            "beschrijving": "Afdeling"
        },
        "naam": "Dit is een afdeling",
        ...
        "relaties": [
            {
                "type": "Is afdeling van",
                "andereVereniging": {
                    "externId": "6889835269",
                    "vCode": "",
                    "naam": "Naam van de Moeder vereniging"
                }
            }
        ]
    }
}

Parameters in beheer API

Je kan n u ook de lijst met mogelijke waarden van parameters (zoals hoofdactiviteitenVerenigingsloket) ophalen via de beheer API. Het resultaat is identiek aan de gelijkaardige call in de publieke API.

Code Block
languagejson
GET <BeheerURL>/v1/hoofdactiviteitenVerenigingsloket
{
  "hoofdactiviteitenVerenigingsloket": [
    {
      "code": "BIAG",
      "beschrijving": "Burgerinitiatief & Actiegroep"
    },
    {
      "code": "BWWC",
      "beschrijving": "Buurtwerking & Wijkcomité"
    },
    ...
  ]
}

Onderscheid bij het registreren tussen een feitelijke vereniging en een vereniging met rechtspersoonlijkheid

Wanneer we een vereniging registreren op de gebruikelijke manier, dan is het nu expliciet gemaakt dat het hier gaat om een feitelijke vereniging. Een nieuwe eigenschap type wordt toegevoegd aan de vereniging. Deze eigenschap is zichtbaar wanneer je de details van vereniging ophaalt. Dit type kan je ook terugvinden in de publieke zoek API en in het publiek DETAIL van een vereniging.

...

Code Block
languagejson
GET <BeheerURL>/v1/verenigingen/<vCode>
{
    "vereniging": {
        "vCode": "V0001002",
        "type": {
            "code": "VZW",
            "beschrijving": "Vereniging zonder winstoogmerk"
        },
        "naam": "VZW 9381134967",
        ...
        "sleutels": [
            {
                "bron": "KBO",
                "waarde": "9381134967"
            }
        ]
    }
}

Wijzig vertegenwoordigers + ⚠️ Verplaatsen initiator naar de headers

Wijzig vertegenwoordigers

Op het endpoint van vertegenwoordigers kan je nu ook de gegevens van een vertegenwoordiger wijzigen. Je kan alle gegevens wijzigen, behalve het INSZ. Het is een PATCH commando. je moet dus enkel de gegevens doorgeven die effectief gewijzigd zijn. De niet-gewijzigde gegevens mag je doorgeven, maar het hoeft niet.

Code Block
languagejson
PATCH <BeheerURL>/v1/verenigingen/<vCode>/vertegenwoordigers/<vertegenwoordigerId>
"vertegenwoordiger": {
        "rol": "Nieuwe rol",
        "roepnaam": "nieuw",
        "isPrimair": true,
        "email": "deNieuwe@vereniging.be",
        "telefoon": "012 345 678",
        "mobiel": "0471 23 45 67",
        "socialMedia": "https://twitter.com/deNieuwe"
    }

⚠️ Verplaatsen initiator naar headers

Het veld initiator is verplicht bij elke actie waarbij data gewijzigd wordt. (zie ook https://vlaamseoverheid.atlassian.net/wiki/spaces/AGB/pages/6285361348/API+documentatie#Initiator-verplicht-bij-elke-schrijfopdracht ). Dit veld staat niet langer in de request body, maar wel in een header met naam VR-Initiator.

Code Block
languagejson
curl 
  --request POST
  --url 'https://beheer.verenigingen.test-vlaanderen.be/v1/verenigingen'
  --header 'VR-Initiator: OVO002949'
  --header "Content-Type: application/json"
   --data '{"naam": "DemoNaam"}' 

Beheer hoofdactiviteiten + Toevoegen en verwijderen vertegenwoordigers + Uitbreiding documentatie

Beheer hoofdactiviteiten

Het PATCH commando waarmee je al enkele gegevens van en vereniging kon aanpassen zoals naam, korte naam, ... kan nu ook gebruikt worden om de hoofdactiveitenVerenigingsloket aan te passen. Hierbij geef je telkens de volledig nieuwe set door.

Code Block
languagejson
PATCH <BeheerURL>/v1/verenigingen/<vCode>
{
    "hoofdactiviteitenVerenigingsLoket": ["TOER","GEWE"],
    "initiator":"ReleaseNotes"
}

Toevoegen en verwijderen van vertegenwoordigers

Er is een nieuw endpoint om vertegenwoordigers toe te voegen en te verwijderen. Om dit te realiseren is er in de beheer detail (GET) een vertegenwoordigerId toegevoegd. Tegelijkertijd is het veld primairContactPersoon hernoemd naar isPrimair om consistent te zijn met de dataset van contactgegevens.

...

Code Block
languagejson
DELETE <BeheerURL>/v1/verenigingen/<vCode>/vertegenwoordigers/<vertegenwoordigerId>
{
    "initiator": "ReleaseNotes",
}

Uitbreiding documentatie

De documentatie van de Beheer API, de Publieke API en de ACM API bevat nu een uitleg voor elk veld in de parameters, maar ook in de request - en response bodies.

De documentatie van de publieke API bevat ook de nodige informatie over de API Key: hoe deze te gebruiken maar ook hoe die kan aangevraagd worden.

⚠️ contactgegevens vertegenwoordiger + historiek data voor registreer vereniging + ⚠️ API key voor publieke API + licentie + lege tekst velden als ““

⚠️ Contactgegevens vertegenwoordiger

Op aanvraag hebben we de contactgegevens van een vertegenwoordiger hervormd en daardoor sterk vereenvoudigd. Je kan per vertegenwoordiger slechts 1 email, 1 telefoon, 1 mobiel nummer en 1 social Media account toevoegen. Bij het registreren van een nieuwe verenigingen ziet dat gedeelte er dan als volgt uit:

Code Block
languagejson
"vertegenwoordigers": [
    {
        "insz": "70030164342",
        "rol": "Voorzitter",
        "primairContactpersoon": true,
        "email": "email@vereniging.be",
        "telefoon": "012/34 56 78",
        "mobiel": "0475 123456",
        "socialMedia": "https://twitter.com/mijnprofiel"
    },
    ...
]

Historiek bij registreer vereniging

Om de historiek van de verenigingsdata volledig te kunnen reconstrueren, is er nu extra data toegevoegd bij de eerste gebeurtenis, het registreren van een nieuwe vereniging

Code Block
languagejson
GET <Beheer URL>/v1/verenigingen/<vCode>/historiek
{
    "vCode": "V0005490",
    "gebeurtenissen": [
        {
            "beschrijving": "Vereniging werd geregistreerd met naam 'Nieuwe vereniging voor demo'.",
            "gebeurtenis": "VerenigingWerdGeregistreerd",
            "data": {
                "vCode": "V0005490",
                "naam": "Nieuwe vereniging voor demo",
                "korteNaam": "DEMO",
                "korteBeschrijving": "Deze vereniging is gemaakt ter demonstratie van deze historiek",
                "startdatum": "2002-04-01",
                "kboNummer": "0563634435",
                "contactgegevens": [
                    {
                        "contactgegevenId": 1,
                        "type": "Email",
                        "waarde": "demo@vereniging.be",
                        "beschrijving": "Algemeen",
                        "isPrimair": true
                    },
                    {
                        "contactgegevenId": 2,
                        "type": "Telefoon",
                        "waarde": "055/123.456",
                        "beschrijving": "Algemeen",
                        "isPrimair": true
                    },
                    ....
                ],
                "locaties": [
                    .....
                ],
                "vertegenwoordigers": [
                    .....
                ],
                "hoofdactiviteitenVerenigingsloket": [
                    ......
                ]
            },
            "initiator": "Demo",
            "tijdstip": "2023-04-20 16:40"
        }
    ]
}

⚠️ API Key voor de publieke API

Om de publieke API te kunnen aanspreken, is voortaan een API Key vereist. Deze API Key kan meegegeven worden als request header vr-api-key of als path parameter

...

Je kan een API Key aanvragen in onze CRM toepassing. Het aanvraag formulier is terug te vinden via deze link

Licentie

Om duidelijk de rechten en plichten van gebruikers van de API aan te geven, hebben we deze ondergebracht onder de Modellicentie Gratis Hergebruik - v1.0

Lege tekst velden als ““

We gaan nu consistent lege tekst velden teruggeven als "" in plaats van null.

⚠️ Nieuwe vorm contactgegevens + Beheren ervan

⚠️ Nieuwe vorm contactgegevens

Naar aanleiding van de feedback ontvangen bij demo’s en bij contact met lokale besturen, is het formaat voor de algemene contactgegevens van een vereniging aangepast:

...

Code Block
languagejson
POST <BEHEER-URL>/v1/verenigingen
{
    "naam": "Voorbeeld Contactgegevens",
    "contactgegevens":[
        {
          "type": "Email",
          "waarde": "info@vereniging.be", 
          "beschrijving": "Algemeen", 
          "isPrimair": true 
        },
        { "type": "Email", "waarde": "bestuur@vereniging.be", "beschrijving": "Bestuur", "isPrimair": false },
        { "type": "Telefoon", "waarde": "012/34.56.78", "beschrijving": "Algemeen", "isPrimair": true },
        { "type": "Website", "waarde": "https://www.vereniging.be", "beschrijving": "Algemeen", "isPrimair": true },
        { "type": "SocialMedia", "waarde": "https://twitter.com/vereniging", "beschrijving": "Algemeen", "isPrimair": true }
    ],
    ...
}

Beheren van contactgegevens

Het is nu ook mogelijk om de contactgegevens van een vereniging aan te passen, meer bepaald een contactgegeven toevoegen, wijzigen of verwijderen. Om dit te realiseren is bij de beheer detail een contactgegevenId toegevoegd:

...

Code Block
languagejson
POST <BEHEER-URL>/v1/verenigingen/<vCode>/contactgegevens
{
    "initiator":"...",
    "contactgegeven": {
        "type": "Email",
        "waarde": "extraMail@mijnvereniging.be",
        "beschrijving": "Nieuw contactgegeven voor deze vereniging",
        "isPrimair": false
    }
}

Meer info in de historiek van een vereniging

De historiek van een vereniging is uitgebreid met de velden beschrijving en data. De beschrijving kan je gebruiken om een gebruiker aan te geven wat de verandering was. De gebeurtenis samen met de relevante data kunnen gebruikt worden om te integreren in een toepassing.

...

Code Block
languagejson
GET <BEHEER-URL>/v1/verenigingen/<vCode>/historiek
{
    "beschrijving": "Korte naam werd gewijzigd naar 'ABC'.",
    "gebeurtenis": "KorteNaamWerdGewijzigd",
    "data": {
        "korteNaam": "ABC"
    },
    "initiator": "OVO000001",
    "tijdstip": "2023-03-22 13:22"
},
{
    "beschrijving": "Contactinfo met naam 'Algemeen' werd toegevoegd.",
    "gebeurtenis": "ContactInfoLijstWerdGewijzigd",
    "data": {
        "contactnaam": "Algemeen",
        "email": "info@vereniging.be",
        "telefoon": null,
        "website": null,
        "socialMedia": null,
        "primair": true
    },
    "initiator": "OVO001833",
    "tijdstip": "2023-03-23 18:58"
}

Wijzigen ContactInfo van de vereniging

Voor een bestaande vereniging kan je nu ook de contactInfo van de vereniging aanpassen. Dit is een uitbreiding op het bestaande PATCH endpoint, met dezelfde afspraken zoals vermeld in https://vlaamseoverheid.atlassian.net/wiki/spaces/AGB/pages/6233948508/voorlopig+Datamodel+en+beschikbare+API+s#Gebruik-van-PATCH-voor-wijzigingen. Je hebt dus de mogelijkheid om:

...

Deze change resulteert in slechts 1 event ContactInfoLijstWerdGewijzigd, maar achterliggend wordt wel bijgehouden welke contactnamen toegevoegd, gewijzigd of verwijderd zijn.

Wijzigen startdatum

Behalve de naam, korte naam en korte beschrijving kan je nu ook de startdatum wijzigen voor een bestaande vereniging. Dit is een uitbreiding op het bestaande PATCH endpoint, met dezelfde afspraken zoals vermeld in https://vlaamseoverheid.atlassian.net/wiki/spaces/AGB/pages/6233948508/voorlopig+Datamodel+en+beschikbare+API+s#Gebruik-van-PATCH-voor-wijzigingen. Om de startdatum leeg te maken, kan je "startdatum": "" gebruiken in de request body.

Dubbel detectie v1

Bij het registreren van een nieuwe vereniging wordt eerst gecontroleerd of deze vereniging mogelijks al bestaat. Als er potentiële dubbels gevonden worden, wordt de vereniging niet geregistreerd, maar krijg je deze lijst van dubbels in het antwoord terug.

...

Later zal de dubbel detectie veel verfijnder geïmplementeerd worden, maar de proces flow (teruggave van potentiële dubbels, mogelijkheid om toch te registreren met het token) blijft gelijk.

Verbetering contactgegevens - Bug ivm busnummer - vCode case insensitive - check op correct JSON formaat

Validatie op contactgegevens

Er werd extra validatie toegevoegd op de de contactgegevens, zowel die van de vereniging, als die van de vertegenwoordigers:

  • De eigenschap contactnaam is nu verplicht en moet uniek zijn voor de vereniging of per vertegenwoordiger.

  • We kunnen een primair contact aanduiden (met eigenschap primairContactInfo) - default value = false. Er mag slechts 1 contact als primair worden aangeduid voor de vereniging of per vertegenwoordiger.

  • We controleren op het formaat van de contactgegevens:

    • een email moet aan het volgende formaat voldoen (naam@domein.vlaanderen) waarbij

      • de naam moet beginnen met een letter of cijfer, gevolgd door 0 of meerdere letters, cijfers of speciale karakters ('!#$%&'*+/=?^_`{|}~-') en moet eindigen op een letter of cijfer

      • het domein moet beginnen met een letter of cijfer en enkel een liggend streepje mag bevatten of punt voor subdomeinen

      • het top level domein moet minstens 2 letters bevatten en enkel uit letters bestaan.

    • een telefoon moet minstens 1 cijfer bevatten - verder mogen ook de karakters whitespace, ()+./-

    • een website moet beginnen met http:// of https:// en moet minstens 1 punt bevatten

    • socialMedia : zie website

Andere wijzigingen

  • De request body wordt gecontroleerd of dit een correct JSON body formaat is.

  • Bij het definieren van een vCode in de URL (bij publiek detail, beheer detail, beheer historiek, …) wordt nu ook getolereerd dat de vCode met een kleine v wordt weergegeven.

  • Wanneer het busnummer van een locatie niet is ingevuld, dan zal het samengestelde adres niet langer het woord “bus + <blanco>” bevatten. Dat deel wordt dan weggelaten.

ACM projectie met echte data en Hoofdactiviteiten Verenigingsloket

ACM Projectie met echte data

Bij registreren van een nieuwe vereniging met vertegenwoordigers, dan zijn die vertegenwoordigers ook onmiddellijk gekoppeld aan de vereniging zodat ze zich kunnen aanmelden. Anders gezegd : de ACM API is nu in sync gebracht met de beheer detail en is dus niet langer gebaseerd op statische data.

...

Code Block
languagejson
GET <ACM-URL>/v1/verenigingen?insz=71032512357
{
    "insz": "71032512357",
    "verenigingen": [
        {
            "vCode": "V0001016",
            "naam": "Frele Ranken Aan Noestige Kennisboom"
        }
    ]
}

Hoofdactiviteiten Verenigingsloket

Ook de hoofdactiviteiten uit het verenigingsloket die bij een vereniging horen, zijn niet langer gebaseerd op gegenereerde data (de fameuze brolfeeder) maar wel op data zoals aangegeven bij het registreren.

...

Code Block
languagejson
GET <Publiek-URL>/v1/verenigingen/zoeken?q=*&facets.hoofdactiviteitenVerenigingsloket=BIAG
{
  "verenigingen": [
    {
      "vCode": "V0002019",
      "naam": "Frele Ranken Aan Noestige Kennisboom",
      ...
      "hoofdactiviteitenVerenigingsloket": [
        {
          "code": "BIAG",
          "beschrijving": "Burgerinitiatief & Actiegroep"
        },
        {
          "code": "BWWC",
          "beschrijving": "Buurtwerking & Wijkcomité"
        }
      ],
        ...
    },
  
  ],
  "facets": {
    "hoofdactiviteitenVerenigingsloket": [
      {
        "code": "HOSP",
        "aantal": 6,
        "query": "https://publiek.verenigingen.test-vlaanderen.be/v1/verenigingen/zoeken?q=*&facets.hoofdactiviteitenVerenigingsloket=HOSP"
        },
    ...
    ]
  },
  ...
}

Vertegenwoordigers en hun contactgegevens

Bij het registreren van een nieuwe vereniging kan je nu 0..n vertegenwoordigers mee opgeven en voor elke vertegenwoordiger 0..n contactgegevens.

...