Äldre modellkontext

Förstå hur den äldre modellen hanterade ärvd inställningar, användare-överskrivningar, primära grupper, lås och konfliktlösning.

Hur grupphantering fungerade före den nya upplevelsen

Zooms inställningshierarki fungerar på tre nivåer: konto, grupp och användare

Zooms administrativa inställningar är organiserade i en tre-nivåhierarki:

1. Kontonivåinställningar är de mest övergripande och tillämpas som standardvärden för hela kontot.

2. Gruppnivåinställningar tillåter administratörer att anpassa inställningar för samlingar av användare.

3. Användarnivåinställningar är de mest specifika och tillämpas på enskilda användare.

Inställningar kaskaderar nedåt genom denna hierarki: standardvärden på kontonivå överförs till alla grupper och användare under dem.

När en inställning konfigureras på kontonivå ärver grupper och användare det värdet automatiskt, om det inte skrivs över på grupp- eller användarnivå.

För mer information om hur nivåuppdelade inställningar fungerar i Zoom, se artikeln i Zoom Support Använda nivåuppdelade inställningar. För ett exempel på hur denna hierarki tillämpas på en specifik produkt, se artikeln i Zoom Support hantering av grupp i Zoom Phone.

En användare som har ändrat en olåst inställning behåller det värdet om det inte skrivs över av en låsning

När en användare manuellt ändrar en inställning som inte är låst, får användarens valda värde företräde framför gruppnivå- och kontonivåvärdena för den inställningen. Detta kallas statusen "ändrad". En ändrad inställning på användarnivå fortsätter att ha företräde framför gruppnivå- och kontonivåvärdena om inte en administratör låser inställningen på kontonivå eller gruppnivå. Vid det laget skriver det låsta värdet över användarens ändring.

Detta beteende gäller både i den äldre modellen för grupphantering och i den nya upplevelsen för hantering av grupper och inställningar. Det är inte specifikt för den ena eller den andra modellen.

I den äldre modellen avgjorde den primära gruppen och låsstatusen vilka inställningar som trädde i kraft för användare i flera grupper

När en användare tillhörde mer än en grupp i den äldre modellen utsåg systemet en grupp som primär grupp och alla andra som sekundära grupper. Den primära gruppens inställningar hade i allmänhet företräde framför de sekundära gruppers inställningar. När låskonflikter fanns mellan grupper — till exempel att en grupp låste en inställning på och en annan låste den av — använde systemet en kombination av den primära gruppens beteckning och den ordning i vilken användaren lades till i grupperna för att avgöra vilket värde som gällde.

För vissa produkter tillämpade den äldre modellen den mest restriktiva inställningen över alla grupper som en användare tillhörde. Om en användare fanns i en grupp där Zoom Chatt var aktiverad och i en annan där den var inaktiverad, skulle Zoom Chatt vara inaktiverad för den användaren eftersom systemet som standard använde det mer restriktiva värdet.

Funktionslås på kontonivå tvingade inställningar uppifrån och ned utan undantag på gruppnivå

När en administratör låste en inställning på kontonivå i den äldre modellen gällde det låsta värdet för varje grupp och varje användare i kontot, utan något sätt att skapa undantag. Om en administratör ville aktivera en funktion för en specifik grupp användare samtidigt som den var inaktiverad för alla andra, var de tvungna att låsa upp inställningen på kontonivå och sedan manuellt låsa det önskade värdet i varje enskild grupp. Denna åtgärd tog omedelbart bort det skyddet för alla användare.

Detta tillvägagångssätt krävde att administratörer skapade parvisa grupper för varje funktionsvariant: en grupp med funktionen låst på och en annan med funktionen låst av.

I takt med att organisationer behövde mer detaljerad kontroll över fler funktioner ökade antalet nödvändiga grupper, vilket ökade komplexiteten i hanteringen. Varje nytt funktionsundantag krävde ytterligare grupper, och varje grupp innehöll alla produktflikar för inställningar oavsett gruppens syfte.