Hantera PrincipalObjectAccess-lagring

Användare i en miljö med databasen Microsoft Dataverse kan samarbeta med andra användare genom att ge åtkomst till en användarägd post. Användaren kan dela en post med en annan användare eller ett annat team, eller tilldela om en post till en annan användare eller ett annat team.

För att hantera det här samarbete på postnivå och ge användare åtkomst till delade poster, lagras all delning av poster och deras behörigheter i tabellen PrincipalObjectAccess (YDDS). När användare försöker komma åt en post som de inte äger eller inte har rätt privilegium i sin säkerhetsroll kontrollerar systemet IA-tabellen för att auktorisera användarens åtkomst.

Källor av POA

I följande avsnitt beskrivs de inställningar eller användning som skapar POA-poster när de aktiverar postdelning. Inställningarna bör granskas och uppdateras för att undvika överdelning och den ökade lagringen av POA.

Dela poster som har tilldelats om med den ursprungliga ägaren

Som standard är inställningen Ange om omtilldelade poster ska delas med den ursprungliga ägaren är Nej. Det är här som postens ursprungliga ägare inte längre har tillgång till posten när postägarskapet tilldelas en annan användare. När den här inställningen är Ja sedan skapas en post i POA-tabellen närhelst en användare tilldelar en post till en annan användare eller team. Den ursprungliga ägaren läggs automatiskt till som Dela i.

Åtkomstteam

När ett åtkomstteam används för postsamarbete skapas poster i POA-tabellen när en användare läggs till i åtkomstteamet. Det finns två typer av åtkomstteam:

• Systemhanterade: De skapas via mallar och är inbäddade i ett formulär så att användaren enkelt kan hantera medlemslistan. Systemet skapar automatiskt ett åtkomstteam för en post som delas. Konto #1 har till exempel ett åtkomstteam som skiljer sig från konto #2.

• Läggs till manuellt: Det här är enskilda åtkomstteam där en administratör/ägare för teamet hanterar listan med teammedlemmar.

Direkt delning

• När en användare uttryckligen delar en post med en annan användare, skapas en post i POA-tabellen.

Indirekt delning

• När en användare delar en post till ett team delas alla medlemmar i teamet indirekt med.

• Indirekt delning sker också med en post som har en kaskaddelningsrelation eller på en tabell med en överordnad/underordnad relation. När en överordnad post delas med en användare eller ett team har den delade användaren eller teamet åtkomst till alla överlappade poster eller underordnade poster. Alla dessa behörigheter för att få åtkomst till underordnade poster skapas i POA-tabellen.

  Exempel på tabellrelation

  En tabell kan ställas in så att den har relationer med andra tabeller (till exempel konto till ärende). Som standard anges relationen för alternativet Ny överordnad till Kaskad på alla. Alla relaterade underposter delas med ägaren till den överordnade posten.

  Exempel: Användare #1 äger Konto #1. Användare #1 delar Konto #1 med Användare #2. Användare #2 skapar ett ärende #1 under Konto #1. Med de färdiga alternativen för ny överordnad har Användare #1 tillgång till Ärende #1. Alla dessa användarbehörigheter finns med i POA-tabell.

Delar datakälla

RetrieveAccessOrigin API kan användas för att avgöra var en användare eller ett team åtkomst till en viss tabell kommer från. API kräver ett objectId, logicalName och principalId i begäran, och svaret är en sträng som beskriver var åtkomsten till tabellen erhölls.

Hantering av tillväxt av POA-tabell

• Utvärdera dina affärsbehov och aktivera Ange om poster som har tilldelats om ska delas med den ursprungliga ägaren där det behövs. Observera att det här är en systemomfattande inställning. När inställningen har aktiverats tillämpas den på alla poster.
• Dela med användare i samarbete där listan med användare inte är densamma i de olika poster du har delat.
• Använd teamet som postägare om du ofta delar poster med samma lista med användare eller delar posten med teamet.
• Om du har en komplex affärsenhetsstruktur och ofta använder dig av delning:
  • Dela endast där det behövs.
  • Minimera antalet affärsenheter.
  • Kontrollera att användarna är placerade i rätt affärsenhet.
  • Dela med teamet så att användare från olika affärsenheter kan komma åt poster.
• När en post kan nås av flera åtkomstteam, till exempel ett säljteam som bara kan läsa posten och ett annat säljchefsteam som har fullständig läs- och skrivbehörighet, kan du överväga att använda olika rollbaserade formulär för säljare och säljchefer.
• Hantera livscykeln för dina teammedlemmar. Ta bort användare som inte längre behövs för samarbetet.
• Ta bort alla teammedlemmar när samarbetet är över.

Ta bort POA-poster

POA-tabellen hanteras av systemet för att säkerställa att användare och team har rätt åtkomst till respektive post. Direkt borttagning i den här tabellen stöds inte eftersom den kan bryta den säkerhetsmodell som definierats för organisationen. Du kan enkelt rensa POA-tabellen genom att justera säkerhetsmodellen och ändra åtkomsten som tidigare getts.

Felsökningsguider

När kaskadkonfigurationen för en tabellrelation är ändrad från Byt överordnad eller Dela till Ingen överlappande, använd den här artikeln för att rensa upp den ärvda åtkomsten. Detta tar bort onödiga POA-poster. Mer information: Hur man rensar ärvd tillgång.

Rensning av ärvda åtkomstbehörigheter är en systemuppgift som rensar gamla ärvda åtkomstbehörigheter som kvarstår efter att kaskadfunktionen ändras till Kaskad på inga. Mer information: Rensning för ärvda åtkomsträttigheter

Information om om användaråtkomst har beviljats på grund av POA finns i Ta reda på varför en användare har åtkomst.

Se även

Dataverse lagringskapacitet