Behandelaar vanuit persoonskaart archiveren

Actiereeks-archief
1

Probleemstelling
Vaak is TOPdesk ingericht met een automatische synchronisatie van medewerkersgegevens vanuit een bronsysteem, zoals Active Directory. Gaat een medewerker uit dienst? Dan wordt de persoonskaart automatisch gearchiveerd. Het is echter maar zelden het geval dat ook behandelaarsaccounts automatisch worden gearchiveerd bij uitdiensttredingen. Dit is echter wel aan te raden, vanuit het perspectief van informatiebeveiliging. Behandelaars kunnen immers heel veel informatie opzoeken.

Analyse
TOPdesk heeft twee ingangen: de Selfserviceportal en het behandelaarsgedeelte. Als je te maken hebt met een automatische import van persoonsgegevens uit Active Directory, dan is het waarschijnlijk dat de loginnamen voor beide ingangen overeen komen. De logica van deze actiereeks is dus: als een persoonskaart wordt gearchiveerd, en er bestaat een behandelaar met exact dezelfde loginnaam, archiveer dan automatisch de behandelaar daarna.

Actiebeheer: actie
JSON
Importeer de JSON als actiereeks en vul de variabelen met de juiste waarden (URL en authenticatie-string).

Actiebeheer: gebeurtenis
Kaartsoort: Persoon
Soort: Kaartdatum
Kaartdatum: 1 minuut na Datum/tijd van wijziging
Voorwaarden: Gebeurtenis treedt op wanneer “Kaart is gearchiveerd” is Waar.

Randvoorwaarden in TOPdesk
De eerste randvoorwaarde is: de loginnaam van de persoonskaart en die van het behandelaarsaccount moeten overeen komen. Deze loginnamen zijn overigens niet hoofdlettergevoelig, dus paulm en PAULM werkt. De tweede randvoorwaarde is dat er een standaard Reden-voor-archiveren moet zijn ingesteld (Instellingen -> Functionele instellingen -> Algemene opzoeklijsten -> Reden voor archiveren).

Aandachtspunten
De gebeurtenis is gebouwd op 1 minuut na Datum/tijd van wijziging. Dit zorgt ervoor dat de actiereeks ook werkt bij automatische imports, die anders geen gebeurtenissen oproepen.

2

NB
Er zat een schoonheidsfout in de actiereeks: de actiereeks ging ook af wanneer er geen behandelaarskaart gevonden kon worden bij de persoonskaart. In de uitvoeringslogs verscheen daarom een rood kruis. Deze fout is sinds vandaag verholpen.

3

Yay! tweede actie reeks en werkend! Ben er blij mee, al is de toepasbaarheid voor ons misschien beperkt. (Onze ‘uitdienst’ procedure duurt lang: meestal archiveer ik behandelaars direct na hun laatste werkdag, terwijl personen soms wel maanden in een administratieve pijplijn zitten voor de bij mij uitkomen. Evengoed een prima vangnet, en waardevol als voorbeeld)

Vraag: waaruit volgt de tweede randvoorwaarde precies? De loginnamen zie ik terug in de if clause, de reden-voor-archiveren niet.

Ik heb een ‘Reden-voor-archiveren’ toegevoegd door de juiste id toe te voegen aan de body van stap twee. Ik neem aan dat als de behandelaars kaart al eerder gearchiveerd is, dat deze actiereeks dan evengoed gewoon wordt uitgevoerd? Wanneer wil je de randvoorwaarden in de actiereeks opnemen, en wanneer ben je beter af zo’n voorwaarde af te vangen in de gekoppelde gebeurtenis? Hier schuilt aanzienlijk potentieel voor verwarring lijkt me …

4

De tweede randvoorwaarde noem ik om de actiereeks simpel te houden. Is er namelijk geen standaard reden-voor-archiveren, dan moet je er 1 meegeven in de actiereeks (zoals jij dus hebt gedaan).
Maar die laatste stap is vrij complex (opzoeken van de juiste unid en het op de juiste plek invullen). De uitleg zou dan veel uitgebreider moeten terwijl de toegevoegde waarde maar weinig is. Dat vond ik niet nodig.

5

Aha, helder! Ja. bedankt voor de verheldering.

Je actiereeksen handleiding is een bron van inspiratie.

6

Nog een vraag over deze oplossing;

Als ik de action sequence uitvoer zonder event, gaat ie dan kijken of alle tot op heden gearchiveerde personen en behandelaarsaccount en hebben -> en zo ja, deze dan archiveren?

De uitgangsbasis in deze is dus de persoonskaart, dus behandelaren die geen persoonskaart hebben hoeven niet bang te zijn dat hun account opeens disabled is?

Het is best wel een ingrijpende action sequence (de 1e keer). Vandaar mijn voorzichtigheid.

7

Als je deze actiereeks niet aan een event koppelt maar gewoon aftrapt op 1 persoonskaart, dan gaat ie alleen die behandelaar archiveren. Dus hij gaat dan niet 1 voor 1 alle personen & behandelaars af.
En inderdaad, behandelaren die geen persoonskaart hebben, die worden niet geraakt.

8

Ik heb het werkend gekregen in onze test omgeving. Een beetje gepuzzeld en andere items gelezen, met name om de TopdeskLoginZichtbaar string te krijgen. Dus helemaal top!

Nu heb ik een bijkomende vraag:
Kunnen eventueel openstaande tickets op de behandelaar ook in dit proces weer teruggezet worden op de behandelaarsgroep van dienst? Het gebeurt natuurlijk wel eens (en bij ons wat regelmatiger helaas).

Suggesties zijn welkom!

9

Nee in principe kan dat niet. Sommige behandelaars zitten ongetwijfeld ook in meerdere behandelaarsgroepen, dus dat wordt supercomplex.
Oplossing zou zijn om een selectie te maken, die alle open meldingen zichtbaar maakt met een gearchiveerde behandelaar. En dan elke maand die selectie checken.

10

Algemeen:
Wellicht kun je er nog een kennisgevingsmail, naar functioneel beheer, aan koppelen, zodat je op de hoogte bent dat er een gebruiker is gearchiveerd.
Deze laat je dan via een gebeurtenis (1 minuut na archiveren kaart “Behandelaar”) plaatsvinden.

11

Ik probeer deze actiereeks in de testomgeving uit.
Ben nog niet heel ervaren in actiereeksen/json bestanden.

Heb deze json geimporteerd maar krijg onderstaande foutmelding in de response body:
Response body: [{“message”:“No permission to see the requested operator.”}]

Ik ben funct beheerder en kan alle kaarten (personen/behandelaren) zien en bewerken… etc
Waarom heb ik in deze geen permissie? Waar pas ik iets aan en wat?
Vr.gr.
Petra Sanders

12

Petra, Jij bent niet diegene die het uitvoert. Het is de API-gebruiker die het uitvoert. De rechten van de API-gebruiker moeten correct zijn, dus: schrijf en archiveerrechten voor behandelaars en personen

1 Like
13

SUPER! Dankjewel het is gelukt!!!

14

Ik kom er niet uit wat er bij onderstaande ingevuld moet worden.

“name”: “TOPdeskLoginZichtbaar”,
“value”: “”
},
{
“name”: “TOPdeskLoginOnzichtbaar”,
“value”: “”

15

Dag Karin,

Bij TOPdeskLoginZichtbaar dien je de api user in te voeren. In ons geval heet deze bijv. topdeskapi
Geen idee waarom TOPdeskLoginOnzichtbaar benoemd word deze wordt verder niet gebruikt.

Ik gebruik onderstaande json deze werkt al jaren goed voor ons.

{
    "formatVersion": "2.15",
    "exportDate": 1701167778211,
    "action": {
        "module": "tas_persoon1",
        "name": "Behandelaarsaccount archiveren",
        "description": "Actiereeks gedownload vanaf het Actiereeks-archief:\nhttps://topdeskforum.laansloot.nl/c/actiereeks-archief",
        "configuration": {
            "variables": [
                {
                    "name": "TOPdesk_url",
                    "value": ""
                },
                {
                    "name": "TOPdesk_username",
                    "value": ""
                },
                {
                    "name": "TOPdesk_password",
                    "value": ""
                }
            ],
            "mappingDefinitions": [],
            "steps": [
                {
                    "type": "HTTP_REQUEST",
                    "executionCondition": "ALWAYS",
                    "customExecutionCondition": "",
                    "name": "getoperator",
                    "method": "GET",
                    "url": "${_variables.TOPdesk_url?no_esc}/tas/api/operators?topdesk_login_name=${tasloginnaam}&page_size=1",
                    "headers": [
                        {
                            "name": "Authorization",
                            "value": "Basic ${_base64(_variables.TOPdesk_username+\":\"+_variables.TOPdesk_password)}"
                        },
                        {
                            "name": "Accept",
                            "value": "application/json"
                        }
                    ],
                    "escapeBodyValues": false,
                    "bodyType": "FREEMARKER_TEMPLATE",
                    "logRequestBody": true,
                    "logResponseBody": true,
                    "body": ""
                },
                {
                    "type": "HTTP_REQUEST",
                    "executionCondition": "CUSTOM",
                    "customExecutionCondition": "<#if _responses.getoperator.body?? && tasloginnaam?has_content &&\n(tasloginnaam?upper_case == _responses.getoperator.body[0].loginName?upper_case)>true</#if>",
                    "name": "archiveoperator",
                    "method": "PUT",
                    "url": "${_variables.TOPdesk_url?no_esc}/tas/api/operators/id/${_responses.getoperator.body[0].id}/archive",
                    "headers": [
                        {
                            "name": "Content-Type",
                            "value": "application/json"
                        },
                        {
                            "name": "Authorization",
                            "value": "Basic ${_base64(_variables.TOPdesk_username+\":\"+_variables.TOPdesk_password)}"
                        },
                        {
                            "name": "Accept",
                            "value": "application/json"
                        }
                    ],
                    "escapeBodyValues": true,
                    "bodyType": "FREEMARKER_TEMPLATE",
                    "logRequestBody": true,
                    "logResponseBody": true,
                    "body": "{}"
                }
            ]
        }
    }
}