Autoriseren

[Wouter Rijnbende]

Binnen Profit zijn er een aantal manieren om te autoriseren:

a. Standaard autorisatie op Funktieniveau (zonder modules)
b. Autoriseren m.b.v. module Profit-Autorisatie
c. Autoriseren op veldniveau middels Profit-DynScreen


Algemeen

Alvorens uit te leggen op welke wijzen we kunnen autoriseren, eerst even wat algemene uitleg.

Profit is modulair opgebouwd uit duizenden verschillende Funkties. Menu's, Toevoegfunkties, Wijzigfunkties, Verwijderfunkties, Raadpleegfunkties, Printjes, TouchScreens, noem maar op.  Niet alle Funkties uit de programma-directory's van Heart-Profit zijn ook daadwerkelijke schermfunkties; er zitten ook veel "berekenfunkties" en "be-/verwerkingsfunkties" tussen. Dit zijn funkties die slechts een berekening uitvoeren, danwel iets bewerken of verwerken, zonder dat er daadwerkelijk interactie met de gebruiker is.

Als we het over Autoriseren op Funktieniveau hebben, dan bedoelen we hiermee alleen dié Funkties die daadwerkelijk interactie hebben met de Gebruiker. Al deze Funkties worden op het scherm gepresenteerd als een separaat Form, met in de titelbalk de naam van de betreffende Funktie. Onderstaand een voorbeeld van het Hoofdmenu, met als Funktienaam "LO" van "Logistiek".

Zouden we nu een zijstap maken naar menuoptie #3 (Verkoop), dan opent zich een nieuw Form (= Funktie) LOVE.

Voeren we nu menuoptie 1, en nogmaals 1 uit, dan zijn we weer 2 Funkties verder. We zitten nu (via menu LOVO) in LOVORA.

Iedere Funktie spreken we overigens uit in termen van 2 letters. LOVORA wordt dus uitgesproken als LO-VO-RA.

LO = Logistiek
VO = Verkooporders
RA = Raadplegen

Wetende dat Toevoegfunkties eindigen op TV, Wijzigfunkties op WY, en Verwijderfunkties op VW, dan mag duidelijk zijn dat LOVOTV, LOVOWY en LOVOVW de Funktienamen zullen zijn voor het Toevoegen, Wijzigen en Verwijderen van Verkooporders.

Autoriseren gebeurt op basis van deze Funktienamen.


Standaard autorisatie op Funktieniveau (zonder modules)

Bij de Gebruikersgegevens (Toevoegen of Wijzigen) is het mogelijk om de betreffende Gebruiker al dan niet te autoriseren voor Funkties binnen Profit.

Dit gebeurt middels de rubrieken "Toegang tot" en "Geen toegang tot".

Voor de duidelijkheid beginnen we met het uitleggen van de laatstgenoemde rubriek.


Geen toegang tot:
Verreweg de meeste Funkties in Heart-Profit zijn standaard toegankelijk voor alle Gebruikers. Ofwel "alles mag, totdat anders wordt aangegeven". Een nieuwe Gebruiker, waarvoor nog geen rechten zijn gedefinieerd, mag dus standaard via Hmenu-3-1-1 naar Raadplegen Verkooporders, om daar vervolgens nieuwe orders toe te kunnen voegen. Stel nu dat de nieuwe Gebruiker van afdeling inkoop is, en dat we vinden dat ze niets in "Verkoop" te zoeken heeft. Middels rubriek "Geen toegang tot" kunnen we dan de Funkties opsommen waar de betreffende Gebruiker niet in mag komen (meerdere Funkties dienen door een komma te worden gescheiden).

Invulling van LOVE zorgt ervoor dat deze Gebruiker niet meer in de Funktie LOVE kan komen. Bij het uitvoeren van deze Menuoptie zal nu de volgende melding verschijnen:

Omdat de Gebruiker nu niet meer in dit menu kan komen, kan ze dus ook niet meer kiezen voor de opties van dit menu, en daarmee kan ze ook de Funkties "Verkooporders", "Leveringen", "Faktureren" etc. niet meer opstarten.


Toegang tot:
Bij de vorige rubriek begonnen we met "Verreweg de meeste Funkties in Heart-Profit zijn standaard toegankelijk voor alle Gebruikers". Dat impliceert dus al dat er een aantal Funkties zijn die standaard niet toegankelijk zijn voor alle Gebruikers. Hierbij moet worden gedacht aan bijzondere Funkties, waarvan de impact zo drastisch kan zijn dat we niet willen dat zo maar iedereen dit soort funktionaliteit kan uitvoeren.  De Gebruiker moet dan expliciete toegang krijgen voor een funktie.

Voorbeelden zijn:

LOUFDB, waarmee de Boekingsgegevens van een Faktuur die al eens naar het Grootboek is doorbelast, nógmaals kan worden doorgeboekt naar het Grootboek (gevaarlijk, want als je de oude niet eerst verwijderd hebt, staan er vervolgens 2 setjes boekingen in het Grootboek).

LOFRKPWY stelt de Gebruiker in staat om achteraf, na het genereren van de Faktuur, handmatig de Kostprijs van een Faktuurregel te wijzigen. Uitermate handig als iets wat EUR 10,- kostte, voor EUR 1000,- op voorraad terecht is gekomen, en vervolgens is geleverd en gefaktureerd, en wat we alleen aan de Verkoopzijde willen oplossen.

ADBOBBVW zorgt ervoor dat de Gebruiker ineens rechten krijgt om door het systeem gegenereerde Batchboekingen ongekonditioneerd uit het systeem te verwijderen (waarbij de gebruiker er dan natuurlijk wel op een andere manier voor moet zorgen dat de betreffende Boeking in het Grootboek komt te staan, anders missen we boekingen).

Als deze rubriek aan de orde is, dan beschrijft de specifieke funktie dat wel in de helptekst, danwel krijgt U van Heart te horen dat U iemand "expliciet moet autoriseren" voor een bepaalde funktie.



Autoriseren middels module Profit-Autorisatie

Zodra de module Profit-Autorisatie beschikbaar is, kunnen er "Autorisatie Groepen" worden gedefinieerd.

Bij de standaard autorisatie methode moeten we per Gebruiker aangeven wat deze Gebruiker wel of niet mag.  Als we met Autorisatie-Groepen gaan werken, kunnen we een Groep maken voor alle Gebruikers die dezelfde rechten hebben, bijv. voor Inkoop, Verkoop, Produktie.

Autorisatiegroepen kunnen worden gedefinieerd vanuit Hmenu-9-6-8.

Nb: Zorg ervoor dat bij Systeemparameters (Hmenu-9-3-1-1) de parameter "Autorisatiegroepen automatisch bepalen J/N" met "Nee" beantwoord is. Ja was een instelling die jaren geleden in DOS omgevingen met een Novell Netwerk gebruikt werd, en waarbij de Novell Netwerk Bindery gescand werd op zoek naar Autorisatiegroepen; deze methode wordt zo goed als niet meer gebruikt (en zal hier verder niet worden beschreven).

Bij de Gebruikersgegevens kunnen we nu volstaan door de Gebruiker te koppelen aan de betreffende Autorisatiegroep, en vervolgens gelden alle Autorisaties zoals voor die Autorisatiegroep definieerd voor die betreffende gebruiker (aanvullend op de Autorisatiegegevens die op Gebruikersniveau zijn gedefinieerd). Bij Gebruiker HB vul ik nu Autorisatiegroep AU-INKOOP in.

Vervolgens kunen we bij deze Autorisatiegroep onze Autorisatiegegevens invoeren. Dit doen we vanuit Raadplegen Expliciete-/Impliciete Autorisaties (Hmenu,9,6,1), en dan toets F4 voor Raadplegen Expliciete Autorisaties, en daarna nogmaals F4 voor Toevoegen.

Per definitie kunnen we nog een aantal rubrieken wijzigen:


Geautoriseerd J/N
Hiermee geven we aan of iemand geautoriseerd is voor deze funktie, of juist niet.


Scope hanteren
Zoals uitgelegd kan met de standaard autorisatie wijze iedere funktie worden geautoriseerd, en schakelden we met een simpele definitie voor "LOVE" heel Verkoop uit.
Laten we dit voorbeeld voor de duidelijkheid eens iets wijzigen. In plaats van het de-autoriseren van LOVE, ontnemen we de Gebruiker nu de rechten voor het Hoofdmenu van de Financiële Administratie (AD). Als de Gebruiker nu vanuit het Hoofdmenu naar de Financiële Administratie wil, krijgt ze de melding:

Hoewel de Gebruiker nu niet meer funktie AD kan opstarten, ligt de definitie van Autorisatie nu puur op de Funktie "AD", en niets meer...

Er zijn echter altijd meerdere wegen die naar Rome leiden, en zo ook kunnen we bijvoorbeeld via een andere logistieke Funktie (Financiële Groepen) een zijstap maken naar Raadplegen Grootboekrekeningen, om er vervolgens een toe te kunnen voegen.

Kijken we naar de hiërarchie van de geaktiveerde Funkties, dan zien we LO-LOAV-LOAB-LOGS-LOFG-LOFGRA-LOFGWY-ADGRRA-ADGRTV. Omdat we nu niet de Funktie "AD" raken, weerhoudt niets ons ervan om toch diverse financiële funkties uit te voeren, ondanks dat AD is dichtgespijkerd.

Een module Profit-Key verergert dit aspekt nog eens, immers, middels Profit-Key zijn we in staat om zelf sneltoetsen te definiëren, waarmee we rechtstreeks een Funktie kunnen aktiveren. Zo zien we onderstaand de situatie die ontstaat als we vanuit het Hoofdmenu met zo'n sneltoets rechtstreeks naar de Funktie ADGRTV gaan.

Het enige wat dus écht werkt, is als we stuk voor stuk alle Funkties gaan beoordelen, en deze gaan Autoriseren; tsja... en dat waren er duizenden...

Het belangrijkste voordeel van de module Profit-Autorisatie zit hem erin dat deze module in plaats is om de scope (het bereik) van een Funktie te kunnen bepalen.  Er zit een verschil in dat wat we het systeem vertellen, en hetgeen we daarmee impliceren. Binnen de module Profit-Autorisatie spreken we dan ook over "Expliciete Autorisaties" en "Impliciete Autorisaties".

Expliciete Autorisaties zijn de definities die de Gebruiker maakt. Zo geeft de Gebruiker aan (expliciet, door een definitie toe te voegen) dat de Gebruikers van Autorisatie Groep AU-INKOOP niet geautoriseerd zijn voor de Funktie "AD". Met rubriek "Scope hanteren" kan nu worden aangegeven of hiermee bedoeld wordt dat de Autorisatie puur en alleen de Funktie "AD" betreft (scope hanteren = Nee), danwel we hiermee bedoelen dat de Gebruiker niet geautoriseerd is voor AD, maar tevens niet "voor iedere Funktie die vanuit Funktie AD bereikt kan worden".

Impliciete Autorisaties zijn de Autorisatiegegevens waar het uiteindelijk om gaat. Dit is het resultaat van alle definities die we gemaakt hebben. Stel dat we expliciet zeggen dat iemand niet geautoriseerd is voor AD, Scope = Nee, dan impliceren we daar maar één funktie mee: alleen "AD". Stel dat we expliciet zeggen dat iemand niet geautoriseerd is voor AD, Scope = Ja, dan impliceren we daarmee dat alles wat onder AD ligt, ook niet geautoriseerd is. Het impliciete effekt is een waslijst met honderden financiële funkties die nu ook niet geautoriseerd zijn.

Op deze wijze zal ook de definitie ook ADGRTV deautoriseren, waarbij het dan niet meer uitmaakt op welke wijze de Gebruiker die Funktie wil aanroepen, via een ander menu of via een snelkoppeling, helaas, geen rechten voor de funktie zorgt ervoor dat we haar niet kunnen uitvoeren.

Let op:
Niet iedere Funktie die vanuit een andere Funktie wordt aangeroepen hoort toe aan de Scope van die Funktie. Immers, aangezien we vanuit iedere Funktie zo goed als alles kunnen aanroepen, zou de Scope praktisch altijd "het hele pakket" opleveren. Derhalve zijn er regels:

* Een aanroep van een Funktie vanuit een Menu, middels een van de Menu-opties, behoort toe aan de Scope van dat Menu. Bijvoorbeeld de aanroep van LOVE vanuit menu LO.

* Een aanroep van een Funktie vanuit een Menu, middels een Funktietoets, behoort alleen toe aan de Scope van dat Menu als de aangeroepen Funktie dezelfde Applikatiekode impliceert.  Funktie ADRSRA die we middels toets F5 kunnen aanroepen vanuit Menu AD behoort dus wel tot de Scope van AD, omdat zowel AD als ADRSRA beide Applikatie AD impliceren. Raadplegen Debiteuren (LORDRA) daarintegen, welke vanuit menu ADDE kan worden aangeroepen, behoort niet tot de Scope van ADDE, omdat de ene Funktie AD impliceert, en de ander LO.

* Funkties die kwa naamgeving eindigen op TV,WY,VW,OP,AF (Toevoegen, Wijzigen, Verwijderen, Opnemen, Afvoeren) en worden aangeroepen vanuit een Funktie welke eindigt op "RA" (Raadplegen) horen standaard bij de Scope van die Raadpleegfunktie.

* Funkties die ná de F1 (voor verwerking) automatisch opgestart worden, horen standaard toe tot de Scope van die Funktie. Voorbeeld is Toevoegen Artikelen (LOARTV) welke bij het verwerken automatisch funkties als "Toevoegen Artikel-/Verschijning" of "Koppelen Artikel aan Artikelgroep" aanroept.


Expliciete toegang
Deze rubriek is vergelijkbaar met rubriek "Toegang tot" bij de Gebruikersgegevens. Ze is bedoeld om binnen de Autorisaties van een Autorisatiegroep expliciet toegang te kunnen geven voor funkties die standaard niet toegankelijk zijn en expliciete toegang vereisen (zie de eerder genoemde funkties zoals LOUFDB, ADBOBBVW etc.).


Inklusief Mutatiefunkties
Doel van deze rubriek is om aan te kunnen geven dat iemand wél is geautoriseerd voor bijv. "Verkoop", maar niet voor de Mutatiefunkties. De gebruiker mag dan wel kijken, maar niets wijzigen. Let op: deze kontrole werkt puur en alleen op basis van naamgeving van de funkties. Funkties die eindigen op TV,WY,VW,OP,AF zullen worden betiteld als "Mutatiefunkties". In werkelijkheid zijn er véél meer funkties waarmee data gemuteerd kan worden. Een écht degelijke kontrole zou pas kunnen worden uitgevoerd als binnen Profit een tabel voorhanden is, met daarin alle duizenden funkties erin, en waarbij per funktie wordt bijgehouden of deze funkties data wegschrijven naar tabellen.
Zo zal nu een Funktie als "Rapen & Goedkeuren v/e Raaplijst" (LOLRRG) niet als Mutatiefunktie worden betiteld, waar deze funktie wel degelijk mutaties aanbrengt in de database.


Als we naar Raadplegen Expliciete Autorisaties gaan, dan krijgen we keuze scherm waarin gevraagd wordt of we de definities willen zien op volgorde van datum genereren, danwel op alfabetische volgorde. Op volgorde van datum-/tijd is hierin de default waarde.

De reden dat de Autorisaties worden getoond in de volgorde waarin ze gedefinieerd is, is omdat de hele Autorisatie struktuur een samenspel is van definiëren van uitzondering op eerdere uitzonderingen, waarbij alle volgende definities de eerder gemaakte definities doet overrulen.

Een poging om dit wat te verduidelijken:

Stel, we vinden dat een Verkoper niets te zoeken heeft in het Financiële pakket. Met dat we deze Gebruiker uitsluiten van de Funktie "AD" + alles wat eronder ligt, mag die Gebruiker (dus) ook geen Grootboekrekeningen meer Raadplegen. Toch zijn er situaties waarin ze dat wél moet kunnen doen. Bijvoorbeeld omdat ze een Financiële Groep moet kunnen aanmaken en daarbij Grootboekrekeningen moet invullen, maar ook bij het toevoegen van Kostenregels aan een Verkooporder kan om een Grootboekrekening worden gevraagd. De definitie "niet geautoriseerd voor AD + alles wat eronder hangt" zal dus moeten worden overruled door "wel geautoriseerd voor ADGRRA" (al dan niet voor de mutatiefunkties ADGRTV, ADGRWY en ADGRVW). Zouden we éérst zeggen dat iemand wél geautoriseerd is voor ADGRRA, en daarna stellen dat ze niet geautoriseerd is voor AD + alles wat er onder hangt, dan mag ze uiteindelijk niet in ADGRRA. Het is dus van belang in welke volgorde we deze definities maken !

Na een Upgrade moeten in principe altijd de Impliciete Autorisaties opnieuw worden gegenereerd uit de Expliciete Autorisaties. In praktijk doet echter bijna niemand dat, maar, ervanuitgaande dat Menu strukturen kunnen wijzigen, en dat er nieuwe funkties in menu's erbij komen, zullen ook die Funkties de door u gedefinieerde definities moeten respekteren. Hiertoe dient opnieuw te worden bepaald wat het impliciete gevolg is van de expliciete definities.

Er zijn klanten die van mening zijn dat standaard iedere funktie dicht moet staan, en daarna expliciet open gezet zou moeten worden; dit 180 graden de andere kant op t.o.v. de door ons beoogde werkwijze "een gebruiker mag standaard alles, tenzij anders is aangegeven". Bij deze nadrukkelijk de opmerking dat e.e.a. niet op deze wijze behoort te worden opgezet. Doe je dat toch, dan zul je op diverse plekken gegarandeerd ellende tegenkomen. Nieuwe funktionaliteit kan niet worden uitgevoerd, omdat de er niet toe geautoriseerd bent, en welke schermen je open moet zetten weet je niet, want je komt al niet eens in die schermen, omdat ze niet geautoriseerd zijn. En, als je al een funktie open hebt gezet, komt de volgende, en de volgende, en etc. Ik zal hier niet te diep op ingaan, moraal is gewoon "niet beginnen met eerst alles dicht te spijkeren, om daarna alles wat wel toegestaan is weer open te moeten zetten".

Verder zijn er nog diverse funkties om Autorisatiegegevens te kunnen printen, danwel om de Autorisatiegegevens te kopieren van de ene Groep naar een andere Groep.



Autorisatie middels Profit-DynScreen

Met behulp van de module Profit-DynScreen kan voor een Gebruiker (of een Autorisatiegroep) een rubriek binnen het pakket worden voorzien van een andere Defaultwaarde. Daarnaast is het ook mogelijk om rubrieken Enabled of Disabled te maken afhankelijk van de Gebruiker of Autorisatiegroep.

Hiermee ontstaat eigenlijk ook een methode op te autoriseren, en wel op rubriekniveau.

Zo zijn we bijvoorbeeld in staat voor Autorisatiegroep AU-INKOOP in te stellen dat de Gebruikers van die Groep wel Debiteuren mogen wijzigen, maar dat rubriek "Kredietlimiet" gedisabled moet worden (zonder defaultwaarde impliceert ongeacht de waarde).

Het effekt is nu dat als een Gebruiker van die Autorisatiegroep naar Wijzigen Debiteuren gaat, het veld "Kredietlimiet" gedisabled wordt (op de waarde die dat veld had). De gebruiker kan verder alles wijzigen, behalve deze Kredietlimiet, waarmee dit ook onder de Autorisatiemethoden valt.