Hvis brugere tillades sende aftaler fra mere end én gruppe, kan administratorer stærkt knytte biblioteksskabeloner, modtagergodkendelse og signaturkrav til én gruppe, så workflowet definerer gruppens type i stedet for brugerne i den.
Når der oprettes en aftale, er det gruppeindstillingerne, der primært dikterer de tilgængelige aktiver (skabeloner/workflows) og systemtilførte egenskaber for aftalen (branding, modtagerroller, godkendelsesmetoder, PDF-sikkerhed/-tilbageholdelse osv.).
At være låst i én gruppe betyder, at ethvert individuelt bruger-id er låst i ét sæt standardindstillinger, én række skabeloner og workflows og ét koncept for signaturoverholdelse.
Ved at give brugere adgang til flere grupper åbnes døren for administratorer til at tænke på grupper som mere end en samling af brugere. Grupper kan ses som et miljø for specifikke dokumentunderskrivelsesskrav, som du giver brugere adgang til.
For eksempel kan én gruppe designes omkring et sæt meget strenge overholdelsesrelaterede signatur- og distributionsregler, og en anden kan konfigureres til interne, lave godkendelsesworkflows og -skabeloner. En bruger, der er tildelt begge grupper, har adgang til alle ressourcerne for hver gruppe.
Administratorer på gruppeniveau har også mulighed for at administrere mere end én gruppe, hvilket forbedrer den praktiske anvendelighed af administratorrollen på gruppeniveau.
Dette dokument er designet til at fremhæve de ændringer, som UMG bringer til brugerfladen/funktionaliteten for brugere, og identificere de overvejelser, som migrering til UMG udløser for administratorer.
Alle brugere under UMG-regler tildeles en "primær gruppe". Den primære gruppe er:
Objekter og nedarvning (over- og underordnede objekter)
"Objekt" er et udtryk, der bruges til at beskrive en samling egenskaber, der repræsenterer én idé. Din Konto er en type objekt ligesom din Bruger.
I et program som Acrobat Sign kan objekter bruges som skabeloner til at bygge andre objekter, og når ét objekt er bygget fra et "skabelon"-objekt, siges det, at disse to objekter har en overordnet-underordnet relation.
Da et underordnet objekt er en direkte kopi af det overordnede, er indstillingerne identiske. Det underordnede objekt nedarver det overordnedes egenskabsværdier. Hvis en overordnet værdi ændres, arves denne ændring også af den underordnede.
Ét objekttræ i Acrobat Sign er Konto > Gruppe > Bruger-egenskabsgruppen.
I kæden Konto > Gruppe > Bruger kan du nemt se, hvordan flytning af en bruger til en ny gruppe ændrer brugerens "standard"-funktionalitet på grund af de nye parametre, der er nedarvet fra gruppen.
Ændring af en egenskabsværdi af et underordnet objekt er tilladt, og denne eksplicitte ændring bryder generelt nedarvningen af den egenskabsværdi fra det overordnede objekt. Hvis det overordnede objekt ændrer værdien for en sådan egenskab, nedarver det underordnede objekt ikke den nye værdi, da den eksplicit indstillede værdi har forrang.
Dette kan bedst ses, når administratorer på gruppeniveau tilsidesætter kontoindstillingerne for deres gruppe. Og eftersom brugerne i gruppen er underordnede objekter for den gruppe, de er i, ændres brugeroplevelsen tilsvarende.
Brugere, der har adgang til flere grupper, ændrer deres nedarvede egenskaber, når de ændrer den gruppe, som de handler fra. Du vil bemærke, at når en bruger ændrer sin gruppe på Send-siden, opdateres siden, da de nye gruppeegenskaber indlæses. Dette er tydeligst, hvis du har unik logobranding pr. gruppe.
Objekt Id'er
Hvert objekt har et unikt id-nummer i baggrunden. Dette unikke id er måden, hvorpå programmet differentierer objekter af samme type og relaterer objekterne til hinanden.
Implikationerne af bruger- og gruppe-id'er bliver mere tydelige under UMG-reglerne, især vedr. rapportering. Når en bruger opretter et aktiv i systemet (aftale, skabelon, webformular), kodes bruger-id'et for opretteren og det gruppe-id, som aktivet blev oprettet i, til aktivet.
Når en bruger kører en rapport for sine aftaler, returnerer programmet de data, der er relateret til dennes bruger-id. Gruppe-id er ikke relevant for søgningen (medmindre der anvendes et filter).
Men når en gruppeadministrator kører en rapport for en gruppe, returnerer programmet de data, der relaterer sig til gruppe-id'et (uanset hvilket bruger-id, der oprettede det)
Når brugere kun kunne eksistere i én gruppe, kunne der generelt ikke ses nogen forskel. Når brugere opretter aktiver i flere grupper, er det muligt, at én brugers indhold kan spænde over grupperne på mere end én gruppeadministrator.
Administratorer på gruppeniveau kan kun få adgang til det indhold, der genereres inden for de gruppe-id'er, som de har autoritet i (undtagen det indhold, de personligt opretter). Hvis en gruppeadministrator rapporterer om indholdet for ét bruger-id, inkluderer det returnerede datasæt kun indholdet (oprettet af bruger-id'et) i den eller de grupper, hvor denne er administrator.
Aftaler, webformularer og Send i massevis-hændelser oprettet før aktivering af UMG er kun relateret til oprettelse af brugerID.
Aftaler, webformularer og Send i massevis-hændelser oprettet efter UMG er aktiveret er relateret til gruppe-id'et, de blev oprettet ud over det bruger-id, der oprettede dem.
I praksis betyder det, at de aktiver, der er oprettet før UMG aktiveres, flytter med brugeren, hvis du ændrer brugerens primære gruppe. Brugere, der ser gruppen (gennem kontodeling), mister synligheden af disse aktiver, når brugeren flyttes ud af den delte gruppe.
Aktiver oprettet efter UMG er aktiveret forbliver relateret til gruppen. Brugere, der ser gruppen, vil fortsat se de aktiver, der er oprettet i gruppen, efter at den oprettende bruger er flyttet til en ny primær gruppe.
Aktivering eller deaktivering af UMG kan kun ske via en administrator på kontoniveau. Se denne artikel for instruktioner til at opgradere din konto.
Det er muligt at vende tilbage fra UMG med nedenstående bemærkelsesværdige effekter:
En bruger kan maksimalt have et medlemskab på 100 grupper.
Ændringer på brugerniveau er allestedsnærværende. Alle brugere, der kan logge på Acrobat Sign, vil opleve nedenstående ændringer:
Hvad er anderledes:
Brugerens profil viser fuldt ud alle grupper, som brugeren er inkluderet i, og markerer specifikt den primære gruppe.
Når UMG er aktiveret:
Hvad er anderledes:
Eftersom brugeren har adgang til flere grupper, grupperes de skabeloner og workflows, der er tilgængelige for brugeren, efter den Gruppe, som skabelonen/workflowet er relateret til.
Hvis der anvendes en skabelon på gruppeniveau, indsættes gruppen på Send-siden, og muligheden for at redigere gruppen undertrykkes:
Hvis der bruges en skabelon på kontoniveau, kan gruppen vælges (blandt de grupper, som brugeren er medlem af):
Hvad er anderledes:
Send-siden introducerer en rullemenu øverst på siden: Send fra
Denne vælger giver afsenderen mulighed for at vælge den gruppe (og alle relaterede egenskaber på gruppeniveau), der styrer egenskaberne og indstillingerne for transaktionen.
Ting at overveje:
Indstil Send fra-vælgeren først.
Hvad er anderledes:
Meget i stil med Send-siden introducerer Selvunderskrivelse en rullemenu øverst på siden: Vælg gruppe
Denne vælger giver afsenderen mulighed for at vælge den gruppe (og alle relaterede egenskaber på gruppeniveau), der styrer transaktionens egenskaber og indstillinger.
Ting at overveje:
Indstil Send ved hjælp af-vælgeren først.
Hvad er anderledes:
En identificerende etiket er blevet føjet til aftalens kontekstmenu for at angive, hvilken gruppe en aftale blev sendt fra.
Ting at overveje:
Nogle funktioner er stærkt knyttet til gruppen (f.eks. rapporteringsparametre og tilbageholdelsesregler).
Hvad er anderledes:
En kolonne er blevet tilføjet til tabellen over aftaler, der er produceret på Administrer-siden.
Hvad er anderledes:
Der er et nyt filter tilgængeligt til at filtrere Administrer-sidens datasæt efter Gruppe
Hvad er anderledes:
Når der oprettes en biblioteksskabelon, har opretteren mulighed for at indstille skabelonadgangsegenskaberne og dele aftalen med enhver gruppe, som opretteren er medlem af.
Ting at overveje:
Én bruger med adgang til alle grupper kan bruges som en central dokumentadministrator.
En bruger med autoritet til at oprette webformularer kan knytte deres formular til enhver gruppe, som brugeren er medlem af.
Hvad er anderledes:
Et filter er blevet føjet til siden Rapporter, så rapporten kan indskrænkes til aftaler, der er relateret til én eller flere grupper.
.csv-rapporten har fortsat den samme Afsendergruppe-kolonne, der sporer korrekt, når én afsender skifter mellem grupper:
Hvis en bruger fjernes fra en gruppe, som denne tidligere har sendt aftaler fra, kan brugeren ikke rapportere om disse transaktioner.
Disse grænsefladeændringer kan kun ses af kontoens administratorer (som tilladt af administratorkontroller på kontoniveau):
Gruppeadministratorens rolle forbedres betydeligt, da én bruger kan være administrator for flere grupper og ikke behøver at være administrator for alle grupper, som brugeren er medlem af.
Gruppeadministratorer i flere grupper kan bedre administrere dokumenter og workflows for bredere teams og rapportere om indholdet af flere grupper uden at få adgang til kontoens fulde datasæt.
Hvad er anderledes:
Hvis brugeren er administrator af mere end en gruppe, er Workflows og Delte biblioteker blevet flyttet fra det øverste niveau i gruppeadministratorens menupunkter for at være undermenuer for hver enkelt gruppe:
Når UMG er aktiveret, skal du først vælge gruppen og åbne gruppeindstillingerne for at få adgang til de gruppespecifikke menupunkter og indstillinger:
Hvad er anderledes:
Når en gruppeadministrator har administrative tilladelser til mere end en gruppe, skal administratoren først vælge hvilken gruppe, de vil konfigurere:
Hvad er anderledes:
Gruppeadministratoren har ikke længere mulighed for at tvinge en visning af aftalerne for nyoprettede brugere.
Hvad er anderledes:
For at tilføje en bruger til din konto skal du først vælge en gruppe for at få adgang til menupunktet Brugere i gruppe
Når der oprettes individuelle brugere, definerer den valgte gruppe den primære gruppe for brugeren.
Administratorer på gruppeniveau har ikke autoritet til at redigere den primære gruppe, efter at brugeren er oprettet.
Processen med at oprette en bruger er den samme minus muligheden for at tvinge en vis deling til brugerens aftaler (se ovenfor).
Ting at overveje:
Oprettelse af brugere individuelt tillader ikke muligheden for at inkludere brugeren i flere grupper som del af oprettelsesprocessen.
Når brugeren er oprettet, kan gruppeadministratoren redigere brugerprofilen for at inkludere brugeren i flere grupper og redigere brugerens afsendelsesautoritet.
Hvad er anderledes:
Autoriteten til at afgøre, om et bruger-id kan underskrive aftaler, og muligheden for at installere en automatisk delegeringsregel for et bruger-id er fjernet fra gruppeadministratorens grænseflade.
Gruppeadministratorer har autoritet til at tillade eller afvise en brugers medlemskab af hver gruppe, som de administrerer, via brugerens profil.
Sådan tilføjes gruppemedlemskab:
Brugere, der for nyligt er placeret i en gruppe, vil bevare to autoritetsværdier:
Vælg eller fravælg værdierne per gruppe efter behov
Administratorer på gruppeniveau har ikke beføjelse til at redigere den primære gruppe for et bruger-id, medmindre de har administrativ tilladelse i både den oprindelige primære gruppe og den nye gruppe.
Sådan fjerner du en bruger fra gruppemedlemskab:
Hvis en bruger har sit gruppemedlemskab tilbagekaldt for alle grupper:
Gruppeadministratorer, der opretter webhooks, kan vælge enhver gruppe, som de er administrator for, når de indstiller gruppefeltværdien:
Hvad er anderledes:
Formatet for den uploadede .csv-fil, der bruges til at oprette/opdatere flere brugere, er ændret for at imødekomme brugere med flere grupper og gruppespecifik autoritet. Til dette formål er tre kolonner blevet fjernet i UMG-oplevelsen:
Der er tilføjet en kolonne: Grupper
Gruppeadministratorer har ikke autoriteten til at manipulere brugere med kolonnen Grupper.
Når en administrator på gruppeniveau opretter nye brugere via masseupload:
Nedenstående indhold gives til orientering, da uploadskabelonen inkluderer kolonnen Grupper.
Kolonnen Grupper indeholder én eller flere Gruppedefinitioner. Hver Gruppedefinition indeholder navnet på én gruppe efterfulgt af én eller flere statusværdier indeholdt i firkantede parenteser. f.eks: Gruppenavn[Status]
I ovenstående eksempel:
Hvad er anderledes:
Handlingen med at deaktivere et bruger-id har været begrænset for administratorer på gruppeniveau for at sikre, at de ikke deaktiverer brugere i grupper, hvor de ikke har nogen autoritet.
Gruppeadministratorer kan kun deaktivere en bruger, der kun har medlemskab inden for administratorens grupper og/eller Standard-gruppen.
Kun administratorer på kontoniveau har adgang til nedenstående:
Hvad er anderledes:
Når du opretter en individuel bruger, er feltet Brugergruppe blevet omdøbt til Primær gruppe
Hvad er anderledes:
Som det blev bemærket i afsnittet for gruppeadministratorer, er formatet for den uploadede .csv, der bruges til at oprette/opdatere flere brugere, blevet ændret for at imødekomme brugere med flere grupper og gruppespecifik autoritet. Til dette formål er tre kolonner blevet fjernet i UMG-oplevelsen:
Der er tilføjet en kolonne: Grupper
Kolonnen Grupper indeholder én eller flere Gruppedefinitioner. Hver Gruppedefinition indeholder navnet på én gruppe efterfulgt af én eller flere statusværdier indeholdt i firkantede parenteser. f.eks: Gruppenavn[Status]
I ovenstående eksempel:
Hvad er anderledes:
Den autoritet, der gives til gruppeadministratorer (af kontoadministratorer) har tilføjet granularitet under UMG.
Den tidligere mulighed for at "tilføje nye brugere til grupper" er opdelt i to muligheder:
Administratorværktøjer på privatlivsniveau ændres i øjeblikket ikke af UMG-indstillingerne.
Kun v6 i REST API opdateres til at rumme UMG.
Den ældre SOAP API opdateres ikke til at rumme UMG.
Brug af SOAP API'er eller v5 REST (og ældre) virker ikke uden UMG-opmærksomhed, og brugerens primære gruppe vil være i kraft.
v6 REST API-slutpunkter, der udføres i forbindelse med en specifik gruppe, er blevet udvidet til at inkludere en valgfri groupId-identifikator, der kan sendes til en anmodning som forespørgselsparameter, overskrift eller som del af anmodningens brødtekst.
Denne parameter er valgfri, og hvis den udelades, er koden som standard brugerens primære gruppe.
Gruppespecifikke handlinger er i to kategorier:
Ændring i brugeradministration indeholdes i evnen til at administrere flere gruppemedlemskaber i ét API-kald og udvidelsen af den sikkerhedsmodel, som påvirker gruppeadministratorens evner, dvs. sørger for, at gruppeadministratoren ikke forårsager en ændring i en gruppe uden for deres rækkevidde.
Ændring i ressourcehandlinger er det ekstra gruppe-id-parameter til anmodnings-/svarmodeller, der giver en gruppekontekst for aftaler, webformularer og Send i massevis-hændelser.
gruppe-id-parameteren tilføjes kun i v6 REST API. Versioner under v6 REST bruger den primære gruppe til bagudkompatibilitet.
En almindelig fejlsvarkode "INVALID_GROUP_ID"udløses, når:
Hvis UMG ikke er aktiveret, opfører alle eksisterende slutpunkter sig som før. Brugerens primære gruppe bruges som det eneste gyldige gruppemedlemskab, og hvis et andet gruppe-id sendes til et slutpunkt, returneres INVALID_GROUP_ID.
Tilføjelse af en bruger til flere grupper sker på én af to måder:
Redigering af en individuel bruger – Dette gøres via:
Enkeltklik på brugeren for at vise muligheden Rediger bruger; Klik på Rediger bruger
Overlejringen for gruppeadministration åbnes, og administratoren kan frit føje brugeren til enhver gruppe, hvor brugeren har administratorautoritet, ved at klikke på plusikonet.
Når gruppemedlemskabet er føjet til brugeren, kan administratoren aktivere/deaktivere brugerens autoritet inden for gruppen ved at vælge/fravælge afkrydsningsfelterne under kolonneoverskrifterne Gruppeadministrator og Kan sende.
Ved at bruge funktionen Opret/opdater brugere på én gang kan kontoadministratorer hurtigt opdatere alle bruger-id'erne på deres konto.
Oprettelse og redigering af brugere på én gang er en mulighed, der er tilgængelig for gruppeadministratorer for funktioner som redigering af navn, firma, titel og lignende oplysninger. Gruppemedlemskab er ikke en værdi, som gruppeadministratorer kan manipulere via den uploadede csv-funktion.
Du kan klikke på linket download CSV-eksempelfil for at downloade en eksempel-CSV med de forskellige egenskaber inkluderet.
Formatet for den uploadede .csv-fil, der bruges til at oprette/opdatere flere brugere, er ændret for at imødekomme brugere med flere grupper og gruppespecifik autoritet. Til dette formål er tre kolonner blevet fjernet i UMG-oplevelsen:
Den nye kolonne Grupper
Kolonnen Grupper indeholder én eller flere Gruppedefinitioner. Hver Gruppedefinition indeholder navnet på én gruppe efterfulgt af én eller flere statusværdier indeholdt i firkantede parenteser. f.eks: Gruppenavn[Status]
I ovenstående eksempel:
UMG-regler kan ses helt i starten af processen med at oprette en ny aftale.
Hvis en bruger starter processen ved at vælge en skabelon eller et workflow fra Hjem-siden > Start fra bibliotek, skal brugeren først udvide den gruppe, som brugeren sender fra, og derefter vælge skabelonen/workflowet blandt de tilgængelige indstillinger i gruppen.
Ved at vælge skabelonen/workflowet og klikke på Start åbnes Send-siden, hvor brugeren kan fuldføre konfigurationen.
Ved at starte aftalen fra en skabelon eller et workflow på gruppeniveau indsættes gruppens værdi på Send-siden, og muligheden for at redigere gruppen undertrykkes.
Hvis der vælges et workflow eller en arbejdsgang på kontoniveau, har afsenderen mulighed for at vælge gruppeværdien.
Hvis brugeren starter processen fra Send-siden, definerer rullefeltet Send fra den gruppe, aftalen er tilknyttet.
Ved at vælge gruppen begrænses aftalen til de biblioteksskabeloner, der er tilgængelige for den valgte gruppe.
Ændring af gruppen ændrer de egenskaber, der er anvendt på aftalen. Dette tvinger siden til at opdateres, og alt feltindhold, der blev angivet, går tabt.
Oprettelse og administration af brugerdefinerede workflows er indtil videre ikke påvirket af UMG-regler:
I fremtidige opdateringer får administratorer grænseflademulighederne til at knytte de workflows, de opretter, til individuelle grupper, som de har administratorautoritet i, uanset deres primære gruppe.
Oprettelse af en genanvendelig biblioteksskabelon under UMG-regler har et ekstra trin, når der gives adgangstilladelse på gruppeniveau til skabelonen:
Definér den gruppe, som biblioteksskabelonen er tilknyttet.
Det oprindelige bruger-id, der opretter en skabelon, forstås som "ejeren" af den skabelon.
Skabelonejeren har altid adgang til skabelonen til at Sende eller Redigere. Det er underordnet, hvilken autoritetsgrad det ejende bruger-id har, eller om ejeren er tilknyttet den gruppe, skabelonen vises for.
Eksisterende biblioteksskabeloners egenskaber kan redigeres via siden Administrer.
Åbn skabelonen til redigering, og hvis skabelonen deles med Enhver bruger i min gruppe, kan redaktøren ændre gruppetilknytningen:
Ændring af gruppetilknytningen påvirker ikke gruppetilknytningen for aftaler, der allerede er oprettet.
Oprettelse af en webformular under UMG-regler har et ekstra trin:
Definér den gruppe, som webformularen er tilknyttet. Dette gøres øverst på siden.
Den tilknyttede gruppe kan ikke redigeres, efter webformularen er oprettet.
UMG-regler påvirker ikke, hvordan eksisterende webformularer administreres (da den tilknyttede gruppe ikke kan redigeres).
Rapportering mod webformularen kræver enten, at skaberen enten kører rapporten, eller kræver en administrator med autoritet til rapportdataene i gruppen.
Deling af en individuel aftale eller skabelon påvirkes ikke af UMG-regler.
Konti, der bruger standardkontodeling (kun Bruger til Bruger-deling), påvirkes ikke af UMG-regler.
Avanceret kontodeling tillader deling mellem Brugere, mellem Grupper og mellem Brugere og Grupper:
Bruger til bruger-deling ændres ikke under UMG-regler:
Når en BrugerA deles med GruppeX:
Når GruppeA er delt til BrugerX:
Når GruppeA deler til GruppeB:
Forventes der ingen ændring af GDPR-værktøjssættet med hensyn til UMG-ændringerne?
Alle Enterprise-konti kan aktivere UMG, selv hvis én (eller flere) integrationer er konfigureret.
De nuværende Acrobat Sign-integrationspakker tager ikke højde for UMG på nogen måde. Derfor opfattes alle brugere, der sender aftaler gennem en integration, som værende kun i deres primære gruppe, og afsendelsesparametre tilpasses tilsvarende den primære gruppes indstillinger.
Mange af REST v6 API-slutpunkterne har fået en valgfri parameter til ggruppe-id føjet til metoden.
Den nuværende forventning er, at ethvert eksisterende REST v6 API-kald fortsætter med at virke, uanset om UMG er aktiveret eller ej.
Tidligere API-versioner (både SOAP og REST) virker fortsat som forventet og forstår kun brugeren som medlem af deres primære gruppe.
Log ind på din konto