Beskytte Form og View

View: Mens du designer et view, kan du i oversigtens Properties på sidste faneblad angive, hvem der må se den pågældende oversigt. Husk at inkludere dig selv eller "din gruppe".

Dokumenter: Ved at tilføje "Reader"-felter kan du styre hvem der kan se dokumenterne.

Felter: Hvis du vil beskytte visse felter på dokumeterne må du anvende kryptering på de enkelte felter.

Husk: udelukkelse fra et view er IKKE ens betydende med, at man ikke kan se data! De samme dokumenter kan f.eks. være tilgængelige i et andet view.

... samt brugerne kan ofte lave private oversigter, om ikke andet så ved at tage en kopi af databasen. Readernames og kryptering er mere sikre metoder.

...er lige med på en "lytter".
Har I nogle gode steder på nettet hvor man kan læse mere om kryptering af felter.
Go'Jul!
MvHans

Kryptering af felter var faktisk ikke svært i sig selv.

Hvad ville i gøre ? Kryptere felterne eller beskytte formen med Readers ?

Bemærk: der er MEGET stor forskel på 1) at kryptere felter og 2) at sætte readers felt på en form!
1) anvendes oftest når enkelte oplysninger er hemmelige, f.eks. løn oplysninger, mens resten af person oplysningerne er åbne for alle. Kræver bl.a. at der genereres en nøgle for de som må se de krypterede oplysninger
2) kan anvendes som ovenstående, men oftes lader man en "bagdør" stå åben for Administratorer, der altid indgår i feltet. Readers kan med fordel anvendes til at udelukke en række dokumenter fra generelle oversigter (du kan se dine, jeg kan se mine - samme oversigt). Readers felter kan have BETYDELIG performance impact!

1) Kan jeg sagtens få til at virke
2) Jeg har indsat et felt af typen Readers, men alle kan alligevel se dokumenterne !

et tomt Reader felt = intet Readers felt ;-)

Jeg fik vist ikke skrevet at jeg har også indtastet en person i feltet efter korrekt Notes metode dvs. Navn Efternavn/OU/Dom

Okay ! Jeg vælger krypteringen i første omgang !

Side spm. ? Kan man lave et felt unikt ? Dvs. at jeg fx. ikke kan oprette 2 dokumenter med samme telefonnummer ?

Hvis du ud over reader felter har author felter, som evt. giver adgang til et dokument, så har det forrang. Dvs at hvis du giver en bruger lov til at redigere et dokument så har pågældende automatisk læserettigheder. Men så snart der findes Reader-felter på dokumentet, så er det summen af navne i alle Author- og Reader-felter der udgør læseskaren.

Sidespørgsmålet: Nej, det er umuligt i Notes. Jeg mener virkelig 100% umulig, hvis det gælder om at garantere at det ikke kan lade sig gøre. Men man kan altid programmere sig til en kontrolfunktion. Bør man måske gøre, jeg mener dog at det for det meste er overflødig. Telefonnumre (og alle andre former for "unikke" værdier kan altid staves forkert, så funktionen er blot vejledende, men ingen garanti).

Hvis du er interesseret i løsninger til dit sidespørgsmål kan du jo altid oprette et rigtigt spørgsmål :-)

Glædelig Jul til allesammen

Underligt ! Jeg har nemlig kun readers på men ingen authors. Men alligevel har alle lov.

Hov, du har sikkert tilføjet feltet senere på formularen, men de gamle dokumenter har jo ikke "feltet" på sig endnu. Du skal rette i et dokument (fysisk <Ctrl E><Ctrl S><ESC>) eller via en agent (skal vistnok være LotusScript som sætter feltet og AUTHOR som felttype) eller køre handlingen "ToolsRefreshSelectedDocuments" (udfører CTRL E S ESC).

Men pas på, du bør tilføje et extra AuthorFelt med en eller anden administrator rolle på , således at du (eller nogen) senere kan få tildelt denne rolle og på denne måde skaffe sig adgang til dokumenterne. Det er det som cdl hentyder til længere opppe.

Det er også på nye dokumenter !

Så prøv at se på det felt som du opretter via DocumentProperties. Der skal være et FIELD FLAG på som hedder READER NAMES. Author felter har et READER-AUTHOR NAMES flag.

De er der ! Jeg tester videre efter jul !

vil du have point jogii ?

yderst underligt. men hvis du har lyst at sende mig en kopi af databasen så skal jeg nok kunne fortælle dig hvad der er galt.

Jeg tester lige et par ting. Vender lige tilbage !

Jeg har vist din mail adresse liggende, du sendte vist noget om Link Message.

Hmm ! Bare for at være sikker. Hvis en person sætter sig selv som Author på et dokument, så kan jeg stadig rette dokumentet ? Men det er vel så i min egenskab af Manager af databasen ?

Kan det endvidere passe at man ikke kan bruge gruppe navne i felterne ?

Gruppenavne er fint, bare basen er på en server.
Har du et felt af typen AuthorNames og f.eks. formlen @Username og du selv opretter et dokument, så vil du have retterettigheder til dokumentet, forudsat at din overordnede adgang er Author eller højere. Hvis du er Reader kan du stadig læse dokumentet, men ikke rette det. Den adgang du får i ACL er den overordnede adgang, mens Reader/Author-felter forfiner den overordnede adgang.

Standardadgang for almindelige brugere til databaser bør være Author. Dette giver dem ret til at rette udpegede dokumenter (dem som indeholder deres Navn, en Gruppe de er medlem af eller en Rolle de har fået tildelt), mens de normalt har læse-adgang til resten af dokumenter, pånær dem som har Reader-felter, hvor deres navn/gruppe/rolle ikke er angivet.

Men undgå grupper i felterne. Arbejd helst med roller istedetfor.

jogii -> Du tabte mig da du begyndte at snakke roller ! Skal jeg starte en ny tråd vedr. Roller ?

Nej. Roller defineres i ACL. Roller svarer til "kasketter". De kan anvendes for at "forfine" det overordnede adgangsbegreb.

Forestil dig en personaledatabase. Her ville du normalt give personaleafdelingen adgang til nogle ekstra knapper og evt. redigeringsadgang til lidt flere dokumenter (men måske ikke alle, derfor er deres overordnede adgang stadig forfatter/author)

For at give adgang til knapper og dokumenter tilføjer du gruppen "Lønkontorister" til et Author-felt eller hide-when-fanebladet for knappen.

"Nej" - siger du så, jeres personaleafdelingsguppe hedder ikke Lønkontorister, men "Personaleafdelingen". Forestil dig så at gruppen pga. en fusion med et andet firma ændrer navn til "Personaleafdeling". Prøv at se hvor mange steder du skal rette i koden og i Author-felter for at gruppeændringen træder i kraft.

Hvis nu du som programmør kunne kode op imod en "rolle", f.eks. "Personalemedarbejder" eller "PersonnelAdmin" eller lignende, og ikke behøvede at tage stilling til hvad/hvem der var "PersonaleAdministrator", så ville du kunne kode i fred og ro. Alle steder i Notes hvor du normalt ville henvise til gruppen "PersonaleLønKursusAdmin" så henviser du nu blot til rollen "[PersAdmin]" (navnet på rollen som den er navngivet i ACL, blot med kantede paranteser omkring). Nu vil enhver gruppenavnsændring, tilføjelse af en person eller ekstra gruppe foregå fra en NotesAdministrator i ACL. Ingen kodning nødvendig, ingen omdøbningsagent. Smart ikke?

Ahhh ! Jeg bliver jo snart haj til der her kode.

Hvis jeg gerne vil undgå at fx. personer som ikke er medlem af Rollen [PersonaleAdmin] eller [LønAdmin] kan oprette nye Personaledokumenter kan jeg så nøjes med at tilføje:

@Command([Compose];"";@If(@IsMember("[PersonaleAdmin]";"[LønAdmin]";@UserRoles);"Manager";
"Employee"))

Jeg ville hellere lave følgende:

_form := @If( @UserRoles *= "[PersonaleAdmin]" : "[LønAdmin]"; "Manager"; "Employee");
@Command([Compose]; ""; _form)

bemærk at '*=' laver en "permutationssammemligning", dvs. alle elementer til venstre for = bliver sammenlignet med alle elementer til højre for =. Hvis man kun laver en '='-sammenligning så laver man en parvis sammenligning, dvs. [PersonaleAdmin] bliver sammenlignet med med første element til højre og [LønAdmin] bliver sammenlignet med andet element fra højre side. @IsMember laver en permutationssammenligning, men den vil kun være sand hvis begge roller (både [PersonaleAdmin] OG [LønAdmin] er tildelt.

Bemærk at = operatoren er CaseSEnsitive, dvs. at [PersonaleAdmin] er ikke lig [Personaleadmin]

Hvor er det lige jeg skal smide de linier ? Hvis jeg smider dem ind på Hide-When så virker det ikke rigtigt og smider jeg dem ned i Click sker der ikke rigtigt noget.

I hidewhen skal der stå følgende:

  !( @UserRoles *= "[PersonaleAdmin]" : "[LønAdmin]" )

så vil paragrafen/elementet være skjult for alle personer der ikke har fået tildelt rollen


Koden i forrige indlæg burde virke i en knap. Men det den gør er følgende: Hvis en bruger med "admin"-rettigheder trykker på knappen, opretter et nyt dokument baseret på formularen "Manager", for alle andre et dokument med formularen "Employee". Jeg ved ikke om det var det du ville?

Det var noget kode jeg havde hugget fra Help i Designer !
_form := @If( @UserRoles *= "[PersonaleAdmin]" : "[LønAdmin]"; "Person"; "");
@Command([Compose]; ""; _form)

Virker fint nu da jeg fandt ud af den så brugte Person som form navn.

Men så kommer den bare op og spørger hvilken Form der skal bruges hvis personen ligger uden for gruppen PersonaleAdmin eller LønAdmin kan det ikke laves om ? Evt. lave et tjeck på formen Person som tjecker det ?

Så skal du lave følgende:

_admin := @UserRoles *= "[PersonaleAdmin]" : "[LønAdmin]";
@If(_admin; @Success; @Return(""));
@Command([Compose]; ""; "Person")

Cool ! Tak.

Vil du have lidt flere point ?

nej, behold dem bare . Godt nytår

Tak i lige måde !