Gevolgen van velden toevoegen op table-view: Privileges!

[SuperWimmie]

Met de komst van Filemaker 10 ben ik gelijk in versie 9 voorbereidingen aan het treffen om straks zo snel mogelijk over te kunnen stappen.

 

Eén meest pijnlijk puntje is dat je in de list-view in versie 10 alle velden van Filemaker toe kan voegen in een overzicht, en deze zijn door gebruikers altijd te muteren...

(helaas is deze optie in 10v1 nog niet uit te schakelen als layout optie)

 

tenzij...

 

je in de Privileges de velden afschermt, zoals het eigenlijk ook zou moeten.

 

Maar...

 

Ik toon in een portal een child-tabel. Het lijkt mij logisch om de sleutelvelden van beide tabellen via de privileges op slot te zetten.

Maar een nieuw record toevoegen in de child tabel wil niet meer, zodra het sleutelveld in de child-tabel via de privileges op Alleen lezen staat.

Filemaker 9 komt in elk geval terug met een melding "This action cannot be performed because this field is not modifiable.", wat aanduidt dat het sleutelveld (ook bij nieuw aan te maken records) in de child niet door deze gebruiker gemuteerd kan worden...

 

Deze foutmelding wordt zowel in versie 9 als versie 10 gegeven.

 

Wie kan hier de oplossing aandragen??

Edited January 9, 2009 by Guest

[SuperWimmie]

sssttt... wimmie is aan het prutsen.

 

** puzzelpuzzel **

 

Ah. Gevonden!

 

"Prohibit modification of value during data entry" instellen op de veldeigenschappen!

Het lijkt helemaal de juiste oplossing te zijn, alhoewel enig testwerk op zijn plaats is.

[hbrendel]

Eén meest pijnlijk puntje is dat je in de list-view in versie 10 alle velden van Filemaker toe kan voegen in een overzicht, en deze zijn door gebruikers altijd te muteren...

(helaas is deze optie in 10v1 nog niet uit te schakelen als layout optie)

Wim, kun je dit nader toelichten? Ik begrijp hier even niets van...

[SuperWimmie]

Jawel,

 

Ga eens in versie 10 in de browse mode naar de table-view (geen list-view, excuses).

Klik op de kolomkop van de velden eens met de rechtermuistoets en ziedaar...

Je krijgt de keuze voor Modify Table-view.

 

Vervolgens ontstaat er een klein schermpje met daarin de reeds opgenomen velden van de layout.

Tot nu toe geen probleem.

 

Maar er is ook een groene plus te vinden, om velden toe te voegen in de layout en vervolgens krijg je de hele database kado gedaan om uit te kiezen.

Ook nog niet echt een probleem.

 

Maar.... zijn ze opgenomen in de layout, dan zijn ze ook nog eens vrij muteerbaar en daar zit volgens mij een fors aandachtspunt.

De hele database ligt open om er een rommeltje van te maken.

 

Dit alles is door de gebruiker zelf in te stellen, het is een standaard fuctionaliteit in FM10.

 

Zelf vind ik het een lek van jewelste in FM10 die de integriteit van de database fors onderuit kan halen. Zaken als value lists zijn niet op te geven, zodat alle invoer (ongeconditioneerd) mogelijk is

Ik heb applicaties met honderden velden en die zijn via layoutafscherming netjes beveiligd. In FM10 niet meer.

 

Ik merk dat Privileges sets en bovenstaande oplossing niet toereikend kunnen zijn voor dit probleem.

Sleutels die via scripts of relaties worden aangemaakt zijn goed te ondervangen, maar een sturingsparameter wordt al snel heel lastig. Event-scripts zijn niet standaard in te stellen in de database, die liggen vast op layouts. De niet vooraf opgegeven velden zijn dus niet te voorzien van event scripts.

Gezien de zeer beperkte mogelijkheden van validatie in FM voorzie ik event-scripting als het antwoord voor validatieproblemen, maar dat gaat hier dus niet lekker werken.

 

 

Of ik moet de table-view weghalen, maar die heeft weer zo haar voordelen.

Edited January 9, 2009 by Guest

[hbrendel]

Ik heb dit nog niet geprobeerd, maar het lijkt me niet zo'n probleem. Gewoon table view uitschakelen. Dit deed ik toch al in alle solutions die ik tot nu toe gemaakt heb. Deze zijn bijna altijd bedoeld voor mensen die verder geen achtergrond op database- en/of computergebied hebben en de tableview is voor deze doelgroep veel te geavanceerd.

 

Wanneer je de table view wel wilt gebruiken, tja, dan...

 

Inderdaad een security flaw.

[JeanWM]

Inderdaad een security flaw.

 

FM10 geeft meer mogelijkheden in de handen van de 'gebruiker'.

 

Het is aan de developer om te beslissen of de gebruiker die mogelijkheden mag hebben.

 

Is dus geen security flaw, enkel als je er als developer niks aan doet, dan wel...

 

Het komt er dus op neer om de businessrules te herzien of als ze nog moeten geschreven worden, zeker de vrijheid van de gebruikers te behandelen en eventueel grondig te beperken.

 

Een FM10 toepassing vraagt dus nog meer voorbereidend werk....

[SuperWimmie]

Het is zo'n "lekje" die je als developer snel over het hoofd ziet.

Het maakt de Table-View tot een zwaar af te raden onderdeel.

[Joris Aarts]

Wimmie, je hebt zeker een punt. We moeten nog meer opletten wanneer we zouden overwegen om de table view in te schakelen. En dat betekent inderdaad het herzien van bestaande oplossingen bij upgrade naar FileMaker 10. Bedankt om dit te signaleren!

Wie weet komt FileMaker met een update om hier een mouw aan te passen. Het lijkt me niet logisch dat je nu in de layout-instellingen wél kan verhinderen dat gebruikers de kolombreedtes wijzigen maar niét dat dat er kolommen bijkomen. Het ziet ernaar uit dat ze de checkbox "Allow Column Changes" zijn vergeten in de table view properties

 

Spreken van een "lekje" of een "security flaw" vind ik in deze context dan weer overdreven. Je kan er als developer iets aan doen. Sowieso is vertrouwen op het afschermen van layouts onvoldoende als bescherming van je data. Denk je maar eens in dat een gebruiker met beperkte rechten op je db op het idee komt om een NIEUWE file te maken, een referentie naar jouw DB legt en zelf de layouts maakt die hij nodig heeft om zich te bedienen... De enige goede beveiliging is via de "Accounts en Privileges" en via veldvalidatie.

[SuperWimmie]

Mee eens, Joris.

Alleen voldoet Filemaker op dit punt niet, tenminste niet als je niet werkelijk alles wilt gaan scripten.

Maar goed, dat is een andere discussie. Ik merk bij mijn klanten tot nu toe weinig problemen en dat zou zelfs het geval kunnen zijn met de table-view inclusief haar "probleempje".

Zolang gebruikers de waarde van hun data beseffen, is er vaak weinig aan de hand.

 

En ook ik hoop op de aanpassing dat Filemaker de velden wel toelaat, maar niet het muteren toestaat. Dan is er al veel leed de wereld uit.

[edc]

Gewoon table view uitschakelen.

Misschien een domme vraag, maar hoe doe je dit?

Was inderdaad een domme vraag. Heb het ondertussen zelf al gevonden.

[SuperWimmie]

Scherm uitzetten, hbrendel, dan zie je geen problemen meer

[Peter Wagemans]

Schitterende thread.

Ik ben hier zelf nogal mee geconfronteerd geweest. Op een zeker ogenblik zie je die extra functionaliteit opduiken in de toolbar, en moet je bij alle klanten eerst alles gaan afschermen vooraleer je de clients overswitched naar 10.

 

Joris heeft inderdaad gelijk, "security through obscurity" is niet de aangewezen manier om je toepassing "idiot proof" te maken, maar ik moet eerlijk zeggen dat ik mij daaraan regelmatig schuldig maak. Heb eerder de neiging om nogal resultaatgericht te werken, en zolang de gebruiker niet op een voor de hand liggende manier kan gaan prutsen, maakte ik mij ook niet veel zorgen hierover.

De methode die Joris even later uit de doeken doet, is een truuk die de doorsnee gebruiker gelukkig niet kent. Maar hij heeft zoals we hier in België zeggen toch wel overschot aan gelijk.

De theorie komt niet altijd overeen met de praktijk. In theorie moet je alle velden afschermen, met privileges werken, met re-logins werken voor scripts die dan met "elevated privileges" velden kunnen aanpassen, enzovoort enzovoort. In de praktijk ben je al blij dat je de applicatie werkend krijgt binnen de deadline.

 

Zoals ik al eerder zei, ik ben er mee geconfronteerd geweest bij een klant. Een bedrijf waar zowat alles van de organisatie verloopt via FileMaker. 9 jaar scripts en layouts maken, bijna wekelijks. Daar waren we dus al zeer blij dat we alles gemigreerd hadden gekregen vanuit versie 6.

 

Ik heb het probleem met de botte bijl aangepakt. In alle files het ik de toolbar conditioneel (volgens access privs) uitgezet in het open script.

Vervolgens heb ik simpelweg gewacht tot de bug reports binnenkwamen, meestal in de stijl van:.

- "ik kan niet verder, er staat geen knopje om verder te gaan"

- "ik kan niet navigeren in mijn gevonden set"

Die problemen heb ik 1 voor 1 aangepakt, het is even een paar dagen lastig geweest dus. De oplossing bestond meestal uit even de toolbar te laten zien zodat de "Ga Verder" knop kon gebruikt worden, of extra knopjes en veldjes op layouts te zetten met de gevonden set, de huidige record, en vooruit en achteruit knopjes.

Heb de problemen dus gewoon laten escaleren, en ze pas opgelost als men ze rapporteerde. Ondertussen heb ik door alle gebruikerslayouts gefietst, en de opties in de layouts veranderd, zodat ze niet van view konden wisselen, als die toolbar dan toch getoont moest worden.

 

Door deze werkwijze heb ik nog een ander probleem kunnen oplossen. De FileMaker Pro 10 Toolbar staat bovenaan i.p.v. aan de linkerkant, en geen enkele layout paste meer op de schermen van de gebruikers.

Mensen in het bedrijf die meer vertrouwd konden worden, werkten echter dagelijks meer op de computer, en hadden daardoor ook modernere computers... met grotere schermen, waardoor ik die dan weer terug toolbar access kon geven.

In de files waar ik de toolbar access terug aanzet, zorg ik in 1 keer ook dat er een extended privilege wordt aangemaakt dat die toegang regelt, Dat is iets gemakkelijker om mee te werken.

 

Die operatie is nu stilaan achter de rug, binnen een tweetal weken installeren we FileMaker Pro 10 bij alle clients.

Wat ik hier beschreven heb is natuurlijk niet de mooiste en meest professionele manier om dit aan te pakken. Maar het is wel een oplossing die gewerkt heeft, en zonder teveel werkuren.

[SuperWimmie]

....

Joris heeft inderdaad gelijk, "security through obscurity" is niet de aangewezen manier om je toepassing "idiot proof" te maken, maar ik moet eerlijk zeggen dat ik mij daaraan regelmatig schuldig maak. Heb eerder de neiging om nogal resultaatgericht te werken, en zolang de gebruiker niet op een voor de hand liggende manier kan gaan prutsen, maakte ik mij ook niet veel zorgen hierover.

....

 

Eens, maar Filemaker heeft onvoldoende in huis om deze theorie in de praktijk toe te passen.

Een simpele validatiecontrole op basis van de normale Filemaker regels gaat gewoon al fout.

Met zo'n basis wordt je wel verplicht om het via de layouts te regelen en juist daar creeert Filemaker een gat.

 

Maar verder weinig aan de hand, ik verwacht dat Filemaker dit in een komende update wel gaat aanpassen. Zoals ik het zie is het echt een klein steekje dat ze hebben laten vallen, de schermen verraden al dat ze grotere plannen hebben.

[Joris Aarts]

Een simpele validatiecontrole op basis van de normale Filemaker regels gaat gewoon al fout.

 

Wat bedoel je daarmee?

[SuperWimmie]

Voorbeeld:

 

Ik heb een database waar een herkenbare code ingebracht moet worden om de regel:

a. uniek te maken

b. te sorteren in scherm en rapport

c. herkenning via telefoon, via 1 kleine code praat makkelijk

d. invoer optimalisatie.

 

Een belangrijke code, zoals je begrijpt.

Nou wil ik dat ding graag een aaneengesloten code laten zijn, dus zonder spaties en leestekens.

Via de veldopties Validation kan je via de formule bepalen welke tekens niet zijn toegestaan.

Helaas komt het regelmatig voor dat bij invoer via een portaal de foutmelding in een loop terecht komt waar de gebruiker nooit meer uit kan komen...

Sinds versie 9 kunnen we de foutmelding ondersteunen middels Conditional Formatting, waardoor het duidelijker wordt voor de gebruiker welk van de zojuist ingebrachte regels fout zijn.

Dat helpt al een heel stuk, maar de loop op de foutmelding ontstaat nog steeds op willekeurige momenten.

Eén van de problemen is dat FM sinds versie 7 het portaal als één record ziet samen met de mother-record, waardoor validatie pas plaats vindt tijdens de opslag en niet direct na de invoer.

 

De foutmelding die overigens ontstaat is verre van duidelijk. Je zou de opslag moeten gaan scripten om foutmeldingen af te vangen om daarmee gerichte foutmeldingen toe te staan.

Maar Filemaker is er op gericht dat veel basisfunctionaliteit niet geprogrammeerd hoeft te worden, en de invoer van nieuwe records in een massa-productie omgeving is daar één van.

Zet maar eens een vinkje in "not empty, unique, gecalculeerd geen spaties, leestekens en Enter etc, met een maximum van 12 karakters.

Leg in zo'n schermpje maar eens uit wat er fout is gegaan....

 

Het is deze te simpele validatie waarom je velden niet voldoende kan inrichten via de privileges en validatie.

Vandaar dat ik voorzie dat event-scripting tevens een oplossing is voor de validatie problemen, helaas is dat in FM10 layout georienteerd.

Het liefst heb ik de inrichting zo veel mogelijk op database nivo en niet op layout nivo.

Het spaart tijd, houdt de data beter in stand qua integriteit en het maakt de ontwikkeling van software een stuk gemakkelijker (mits je goed ontwerpt).

 

Mijn commentaar ziet er misschien kritisch uit en het zou mooi zijn als echt goed zou werken.

Gezien de heel veel andere grote voordelen van Filemaker ben ik er wel wijs mee.

Edited February 12, 2009 by Guest

[SuperWimmie]

Voorbeeld:

 

Ik heb een database waar een herkenbare code ingebracht moet worden om de regel:

a. uniek te maken

b. te sorteren in scherm en rapport

c. herkenning via telefoon, via 1 kleine code praat makkelijk

d. invoer optimalisatie.

 

Een belangrijke code, zoals je begrijpt.

Nou wil ik dat ding graag een aaneengesloten code laten zijn, dus zonder spaties en leestekens.

Via de veldopties Validation kan je via de formule bepalen welke tekens niet zijn toegestaan.

Helaas komt het regelmatig voor dat bij invoer via een portaal de foutmelding in een loop terecht komt waar de gebruiker nooit meer uit kan komen...

Sinds versie 9 kunnen we de foutmelding ondersteunen middels Conditional Formatting (layout georienteerd), waardoor het duidelijker wordt voor de gebruiker welk van de zojuist ingebrachte regels fout zijn.

Dat helpt al een heel stuk, maar de loop op de foutmelding ontstaat nog steeds op willekeurige momenten.

Eén van de problemen is dat FM sinds versie 7 het portaal als één record ziet samen met de mother-record, waardoor validatie pas plaats vindt tijdens de opslag en niet direct na de invoer.

 

De foutmelding die overigens ontstaat is verre van duidelijk. Je zou de opslag moeten gaan scripten om foutmeldingen af te vangen om daarmee gerichte foutmeldingen toe te staan.

Maar Filemaker is er op gericht dat veel basisfunctionaliteit niet geprogrammeerd hoeft te worden, en de invoer van nieuwe records in een massa-productie omgeving is daar één van.

Zet maar eens een vinkje in "not empty, unique, gecalculeerd geen spaties, leestekens en Enter etc, met een maximum van 12 karakters.

Leg in zo'n schermpje maar eens uit wat er fout is gegaan....

 

Het is deze te simpele validatie waarom je velden niet voldoende kan inrichten via de privileges en validatie.

Vandaar dat ik voorzie dat event-scripting tevens een oplossing is voor de validatie problemen, helaas is dat in FM10 layout georienteerd.

Het liefst heb ik de inrichting zo veel mogelijk op database nivo en niet op layout nivo.

Het spaart tijd, houdt de data beter in stand qua integriteit en het maakt de ontwikkeling van software een stuk gemakkelijker (mits je goed ontwerpt).

 

Mijn commentaar ziet er misschien kritisch uit en het zou mooi zijn als echt goed zou werken.

Gezien de heel veel andere grote voordelen van Filemaker ben ik er wel wijs mee.

[Joris Aarts]

wow wat een lang bericht en misschien wel voer voor een andere draad.

Als ik het goed begrijp heb je (onder andere) kritiek op het feit dat je in FM maar één validatie-bericht kan tonen terwijl je meerdere vaidatie-opties kan aanvinken. Korte reactie:

_Als de controle beperkt is tot uniek, niet leeg en enkel geldige tekens dan kan je met een foutbericht "ontbrekende of ongeldige invoer" toch wel uit de voeten.

_Als het ingewikkelder wordt qua controle dan zou ik de invoer van dat veld sowieso scripten via een pop-up layout. Op die manier kan je heel gedetailleerde feedback geven.

 

Als het een troost mag zijn: in MS Access is het al niet veel beter.

 

Los daarvan: gebruik script triggers nooit voor data-validatie (zie white paper).

Volledig akkoord dat kritische validatie in de data-laag moet zitten waar mogelijk.

 

Groetjes,

Joris

[SuperWimmie]

Als het een troost mag zijn: in MS Access is het al niet veel beter.

 

Daarom ook, zelfs in MySQL is het via de PHP code om te valideren. Hoezo database nivo?

 

Nee hoor, geef mij maar Filemaker