Ik zie een bolletje draaien, dus, misschien reageer ik voor mijn beurt, maar, om je toch alvast even een reaktie te geven (degene voor wie het bolletje draait is er "de rest van het jaar" niet meer :-):
De intentie is dat deze alleen leesrechten heeft vanuit CRM menu naar de klanten en verkooporders.
"Inklusief mutatiefunkties J/N" misschien impliceert dat je daarmee alle funkties te pakken hebt die data kan muteren (zoals berekenen toeslag kleine orders, afsluiten verkooporder etc), is dat NIET het geval. Je moet daar dus wel even goed de helptekst lezen! Mutatiefunkties worden enkel bepaalt op basis van hun funktienaam, zoals Toevoegen, Wijzigen en Verwijderen. Van Gereedmelden Produktieorder zal iedereen kunnen beredeneren dat je daarmee data muteert, maar, ze zal wat mij betreft niet als mutatiefunktie worden herkend!
Nb: Met aanvullend maatwerk best oplosbaar, als wij bijv. de programmatuur "scannen", per funktie bepalen of deze op e.o.a. manier iets aan de database wijzigt (APPEND, REPLACE, SQL INSERT/UPDATE/DELETE etc), die data in een tabel opslaan, ervoor zorgen dat jij die tabel via een Upgrade krijgt en deze up-to-date gehouden wordt, en dan op basis van die tabel op zoek gaan naar mutatiefunkties.
Ik heb dit ingericht met diverse explicite authorisaties, met toegang excl. mutatie=functies en scope is aan.
LOVO en LOVE staan ook zo.
Als ik LOVO en LOVE opneem als Expliciete Autorisatie in een Autorisatiegroep, en de rubrieken als volgt invul:
Geautoriseerd = Ja
Scope = Ja
Expliciete Toegang = Nee
Mutatiefunkties = Nee
en daarna de Impliciete Autorisaties genereer, dan zal LOVOWY voorkomen in de lijst met Impliciete Autorisaties met de waarde geautoriseerd = Nee.
Bij jou is dat ook het geval:
Als ik bij de impliciete authorisaties kijk bij LOVOWY staat daar gewoon dat de user niet geauthoriseerd zou moeten zijn
Tsja... dit zou voldoende moeten zijn. LOVOWY is dan geblokkeerd, ook vanuit het CRM scherm.
Is dat niet het geval, kontroleer dan even of:
* je bij je de gebruiker (MBE) hebt aangegeven dat hij met de Autorisatiegroep werkt die je gebruikt (VERK_MINUS)
* je de gebruiker (MBE) opnieuw hebt laten inloggen in Profit; dan pas worden de wijzigingen aktief
* je bij de gebruiker (MBE) niet toevallig manager rechten hebt toegekend
* je bij de gebruiker (MBE) de rechten niet overruled hebt door alsnog in te vullen bij 'toegang tot'
Maar ik bij een order die reeds in behandeling is kom ik er met LOVOWY1 gewoon bij
Dat klopt.
Dat komt omdat LOVOWY1 wat anders is dan LOVOWY, en LOVOWY1 niet toebehoort tot de "scope" van de funktie LOVO.
Vanuit menu 9-6-2 kun je opvragen welke funkties er toebehoren aan de scope van LOVO; LOVOWY1 hoort daar niet bij.
Dit soort uitzonderingen zul je dus nog even expliciet moeten opnemen bij je Expliciete Autorisaties (en daarna weer opnieuw de Impliciete Autorisaties genereren).
Ook als ik tracht een kleine order te wijzigen gaat er wat fout.
Ik mag geen regels wijzigen, maar toch genereerd het systeem dan de kleine order toeslag die iemand anders al verwijdert had.
En normaliter zou ik geen rechten meten hebben.
maar de "onder-water" functie dus wel.
Is denk ik een iets lastigere. Ten eerste geldt dat het berekenen van een toeslag kleine orders niet een Autoriseerbare Menufunktie is die je wel/niet kunt uitvoeren. Het betreft een funktie welke een berekening bevat die gewoon door het systeem wordt uitgevoerd, en "iets doet": in dit geval de order kontroleren op haar grootte en kleine orderkosten toevoegen.
Kleine orderkosten worden niet berekend vanuit de Toevoegfunktie, noch vanuit de Wijzigfunktie, maar eerder "bij het verlaten van de order". Dit heeft ermee te maken dat als je 100 regels moet toevoegen aan een order, je dit maar 1x wil berekenen, en niet bij iedere regel. De 1e regel zou kunnen zeggen dat er een toeslag nodig is, terwijl al bij de 3e regel blijkt dat je boven je minimum orderbedrag uitkomt. In dit geval zal "het verlaten van de order" ook op kunnen treden zonder dat je rechten hebt voor toevoegen/wijzigen.
Daarnaast mag je je afvragen wat voor een kwaad dit kan. Sterker nog, het zou juist fout gaat als iemand GEEN rechten zou hebben voor het berekenen van die kleine orderkosten. Ofwel, stel dat je onder de EUR 100,- een bedrag van EUR 20,- aan orderkosten berekend, en iemand heeft een order van EUR 50,- toegevoegd, dan zal daar al EUR 20,- aan orderkosten in staan. Dat het systeem hier opnieuw EUR 20,- uitrekent, kan helemaal geen kwaad, immers die EUR 20,- hoort er nu eenmaal in te staan.
Het zou juist fout gaan als blijkt dat er EUR 20,- in moet staan, maar je niet geaurotiseerd zou zijn om de EUR 20,- op te nemen (omdat dat een mutatiefunktie is).
Enige situatie die je je kan voorstellen is dat het zou zijn toegestaan om de gegenereerde regel van EUR 20,- te verwijderen en dat er funktionaliteit is die er dan ook voor zorgt dat die EUR 20,- weg blijft. Iets als "standaard komt er EUR 20,- bij, maar jij kunt aangeven "nee, doe voor deze order toch maar niet"'. Mocht zoiets bestaan, dan werkt er iets anders niet, immers, dan hoort die toeslag er gewoon niet opnieuw in te komen, maar of zoiets bestaat? Ik dacht van niet.
