Teknologi, AI og forretning er i centrum på Computerworlds Cloud og AI Festival i København d. 18. og 19. september. Se hele programmet for den store konference om strategisk brug af Cloud og AI på: www.cloud-festival.dk
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.
... 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.
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!
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).
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.
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.
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 ?
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.
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?
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:
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.
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 ?
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.