Heart-Profit ERP
November 30, 2024, 10:38:58 am *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: Opnieuw Genereren Impliciete Autorisaties - opeens niet meer geautoriseerd?  (Read 3131 times)
0 Members and 0 Guests are viewing this topic.
pascal
Designer
*****
Offline Offline

Posts: 2595


View Profile WWW
« on: May 22, 2013, 02:22:41 pm »

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?

Logged

Heart-Profit company ID: BS
mdekraa
Designer
*****
Offline Offline

Posts: 2068



View Profile WWW
« Reply #1 on: May 22, 2013, 04:19:37 pm »

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.
Logged

Heart-Profit company-ID : AD
-----------------------
There are 10 kinds of people, those who understand binairy and those that don't
Wouter Rijnbende
Administrator
Partner
*****
Offline Offline

Posts: 5367


View Profile WWW
« Reply #2 on: May 22, 2013, 06:57:56 pm »

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.
Logged

Heart-Profit company ID : HA
pascal
Designer
*****
Offline Offline

Posts: 2595


View Profile WWW
« Reply #3 on: May 23, 2013, 10:13:03 am »

Quote
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.
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.
Code:
      LOVATV    Koppelen Versch.vorm aan Art.             Nee
      LOVEFA    Faktureren                                Nee
      LOVEFAO1                                            Nee
      LOVEFAOV  Faktureren Overigen                       Nee
      LOVKOV    Print Verkoopoverzichten                  Nee
      LOVKRA    Raadplegen Verkopers                      Nee
      LOVKTV    Toevoegen Verkopers                       Nee
      LOVKVW    Verwijderen Verkoopgebieden               Nee

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?


* autorisatiegroep KAM - expliciete autorisaties.png (22.39 KB, 663x610 - viewed 267 times.)
* autorisatiegroep KAM - expliciete en impliciete rechten.txt (44.58 KB - downloaded 129 times.)
Logged

Heart-Profit company ID: BS
Wouter Rijnbende
Administrator
Partner
*****
Offline Offline

Posts: 5367


View Profile WWW
« Reply #4 on: May 25, 2013, 05:33:12 pm »

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.
Logged

Heart-Profit company ID : HA
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Valid XHTML 1.0! Valid CSS!
Page created in 0.084 seconds with 20 queries.