Heart-Profit ERP

We werken met autorisatiegroepen, waar weer gebruikers lid van kunnen zijn.
Zo is er een autorisatiegroep KLA_MEDEW_A dit betreft een medewerker v/d afdeling Klantenservice.

Deze groep heb ik een tijdje geleden aangemaakt. Nu heb ik hier gisteren een nieuwe gebruiker aan toegevoegd.
Om te zorgen dat de autorisaties daadwerkelijk toegepast worden, heb ik 9-6-4 Genereren Impliciete Autorisaties uitgevoerd.

Dit is op zich gelukt, alleen zijn de groepsleden die er al jaren in staan ineens niet meer geautoriseerd voor bepaalde funkties.
Voor de duidelijkheid: ik heb bij het toevoegen van de gebruiker niks aan de autorisatiegroep zelf veranderd. Dus dan verwacht je dat wanneer je de impliciete autorisaties opnieuw genereert er niks veranderd voor de al bestaande leden.

Voorbeeld: na opnieuw genereren impliciete autorisaties is gebruiker niet meer geautoriseerd voor funktie LOVI (menu 1-4-3), zie schermafdruk.
Deze funktie gebruiken mensen van Klantenservice regelmatig, eerder lukte het altijd om erin te komen. Nadat ik de autorisaties opnieuw gegenereerd heb niet meer.

Wanneer ik vervolgens LOVI aan de autorisatiegroep toevoeg, aut. genereer en de gebruiker opnieuw in laat loggen, lukt het wel.
Nu staan er ook specifieke LOVI-funkties onder 9-6-1 F5, F1 Raadplegen Impliciete Autorisaties (schermafdruk 2).

Volgens mij stonden die er vroeger niet maar zijn ze (na updates?) later toegevoegd.
Zie bv autorisatiegroep KLA_MEDEW_B, deze heb ik niet opnieuw gegenereerd en hier staan geen funkties LOVIxxx onder 9-6-1 F5 F1 (schermafdruk 3).

Mijn vraag: kan het zo zijn dat er na updates gebruikers specifiek autorisatie nodig hebben om funkties te kunnen gebruiken?
Dus dat eerder LOVI standaard wel toegankelijk was en nu niet meer?
Zoja, dit is lastig omdat ik niet kan raden welke funkties die autorisaties behoeven, zoals nu LOVI. Hoe moet ik hiermee omgaan?

wij hebben hetzelfde gehad, er moet iets zijn verandert in de opbouw van de authorisaties, ook hier moesten we mensen expliciet authoriseren, waar ze voorheen gewoon rechten hadden.

In principe kan de struktuur best anders zijn na een upgrade. Immers, er hoeft maar een menu een andere indeling te krijgen, jij alles autoriseert op hoog niveau (en alles wat er onder ligt), en dit levert de menu wijziging triggert een kompleet andere set met impliciete autorisaties.

Maar... puur theorie dus, want wij wijzigen niet een hele menu struktuur.

Voorlopig is er nog niets wat in deze hoek wijst.

Dat B geen LOVI funkties toont, kan gewoon het effekt zijn van het feit dat je niet op LO, LOVI, en alles wat er onder ligt, geautoriseerd hebt. De expliciete definities bij A tonen aan dat het nu werkt. Tsja. Leuk. Je bent ook geautoriseerd voor LOVI; maar, zie B, als je de rechten tot LOVI niet zijn ontnomen (ze komen niet in het lijstje voor bij B, dus Nee), geldt dat je alles mag.
Wat ik graag had willen zien, is dat LOVI in de lijst had gestaan met "geautoriseerd nee". Dan had je daarna kunnen uitzoeken waarom.

Merk op dat jij hier ook je funkties toont op volgorde van naam. Leuk om een funktie terug te zoeken, maar 't zegt niets over de volgorde waarin de definities zijn opgenomen, en wat een uitzondering op wat is.

Daarnaast, en daar zou ook een oorzaak in kunnen zitten, krijg je met iedere upgrade een nieuwe versie van de tabel met elementaire funktie aanroepen die voor deze autorisaties worden gebruikt. Deze tabel (LOHF) moet altijd expliciet gereorganiseerd worden. Ik denk dat er maar weinig gebruikers zijn die dat ook daadwerkelijk doen. Er is dus ook een kans dat je vorige generatie set gewoon niet gewerkt heeft, en dat het nu wel werkt.

Dus, probeer niet naar een verleden te kijken, probeer te beoordelen of gezien hoe e.e.a. gedefinieerd is, het terecht is dat die melding komt, dan vind je vast wel de oorzaak.

Sinds enkele maanden doe ik dit expliciet wel (ook opgenomen in m'n eigen procedure). Daarvoor gedacht dat 'reorganiseren alle bestanden' ook voldoende was (je reorganiseert immers alle tabellen), wat dus niet zo is.

Het kan dus zijn dat ik een jaar geleden na een update niet expliciet LOHF gereorganiseerd heb, maar er wel wijzigingen in de elementaire funktie-aanroepen zijn gemaakt.
De autorisatiegroepen wijzig ik namelijk niet vaak, dus de autorisaties zijn misschien 2 jaar geleden voor het laatst gegenereerd.


Ik ben wel benieuwd of het volgende nu kan gebeuren:

De autorisaties op autorisatiegroep KAM zijn naar mijn weten al minstens 2 jaar niet meer gegenereerd. En ook geen wijzigingen in de expliciete autorisaties, want na zo'n wijziging genereer ik de autorisaties (logisch, anders heeft het ook geen zin).

Schermafdruk 1: de expliciete autorisaties van autorisatiegroep KAM.
Hieronder een deel van de impliciete autorisaties van autorisatiegroep KAM, LOVIxxx komt er niet in voor.

Wanneer ik nu de autorisaties voor groep KAM opnieuw ga genereren,  klopt het dan dat de KAM-gebruiker LOVI (menu 1-4-3) niet meer geautoriseerd is voor deze funktie?

Als dit zo is, is het probleem dat ik niet van tevoren weet wat er gebeurt wanneer ik voor een groep de autorisaties opnieuw genereer.
Ik weet nu dat er wijzigingen kunnen ontstaan en dat mensen geblokkeerd kunnen zijn voor een funktie terwijl dit gisteren nog wel mocht.
Hier kan ik de mensen natuurlijk voor waarschuwen en vragen contact op te nemen wanneer dit gebeurt, maar voor de gebruiker lastig te snappen en ook vervelend omdat ik er niet vantevoren op kan anticiperen (want nu geval LOVI, misschien zijn er igv andere autorisatiegroepen wel andere funkties die niet meer geautoriseerd zijn?).

Hoe kan ik hier nu het beste mee omgaan?

Zoals aangegeven, mag je standaard (bijna) iedere Funktie in Profit uitvoeren, tenzij anders aangegeven.

Middels Profit-Autorisatie autoriseer per voor een Funktie, en optioneel "alles wat eronder zit" maar wel tot de scope van die funktie behoort. Dit, in chronologische volgorde, waardoor als funkties gedeautoriseerd worden waar je dat niet wil, je ze weer open kunt zetten. Om te kunnen beoordelen waarom iets wel/niet geautoriseerd is, heb je die volgorde nodig.

Even een voorbeeld:

Je zou dus kunnen zeggen "niet geautoriseerd voor AD, en alles wat bij de scope hoort", maar daardoor kun je ook geen Grootboekrekeningen Raadplegen die je misschien bij een Financiële Groep moet invullen. Dus, daarna zeg je "maar ADGRRA weer wel toegestaan". Die laatste is dan weer alleen nodig omdat je eerst hebt gezegd dat alles wat onder AD ligt niet is toegestaan, want standaard mag een gebruiker gewoon in AD en alles wat er onder ligt (dus ook ADGRRA).

Ervanuitgaande dat dit alle autorisaties zijn die je gedefinieerd hebt, kan ik zien dat je geen LOVI hebt opgenomen bij expliciete autorisaties, en ook kan dit niet getriggerd worden door een bovenliggend menu (bijv. LO). Ofwel, wat dat betreft verklaarbaar dat LOVI* niet voorkomt in de impliciete autorisaties, immers, er is geen expliciete funktie opgenomen die dit triggert.

Naar mijn verwachting zal dit na opnieuw genereren ook niet anders zijn. De enige situatie waarin dat wél zou zijn, zou bijv. zijn als iemand uit een van de funkties die jij hier hebt opgenomen, een menu aanroep naar "Voorraaditems" heeft ingebouwd. Kan altijd, maar ik acht de kans heel klein. :wink:

Zo dit het geval is, kun je bij de Impliciete Autorisaties van die LOVI funkties op F1 drukken, en wat me er dan van bij staat wordt daar getoond uit welke Expliciete Autorisatie deze key gegenereerd is. Maar, probeer het eerst gewoon, als er geen LOVI funkties worden opgenomen is er sowieso niets aan de hand.

Vandaar mijn eerdere opmerking, probeer gewoon te bepalen of hetgeen je nu ziet terecht is bij wat je gedefinieerd hebt.