fix: fixes format issues with cardbox uses (#617)

docs/content/interacting/managing-group-access.mdx

@@ -23,7 +23,7 @@ import {
 
 In this guide you will learn how to grant a group of users access to a particular object.
 
-<CardBox title="When to use" appearance="filled" description={<div>
+<CardBox title="When to use" appearance="filled">
 
 Adding a relationship tuple specifying that a group has a relation to an object is helpful in cases where you want to encompass a set of users with the same relation to an object. For example:
 
@@ -34,7 +34,7 @@ Adding a relationship tuple specifying that a group has a relation to an object
 - Making a `file` viewable for all `users` within an `organization`
 - Restricting access from or to `users` in a certain `locale`
 
-</div>} />
+</CardBox>
 
 ## Before You Start
 

docs/content/interacting/managing-group-membership.mdx

@@ -23,7 +23,7 @@ import {
 
 In this guide you will learn how to update a user's membership to a group by adding and removing them from it.
 
-<CardBox title="When to use" appearance="filled" description={<div>
+<CardBox title="When to use" appearance="filled">
 
 Suppose:
 
@@ -34,7 +34,7 @@ Suppose:
 
 These are cases where using group membership can be helpful as you do not need to iterate over all of the group's resources to add or revoke access to particular objects. You can add a relationship tuple indicating that a user belongs to a group, or delete a tuple to indicate that a user is no longer part of the group.
 
-</div>} />
+</CardBox>
 
 ## Before You Start
 

docs/content/interacting/managing-relationships-between-objects.mdx

@@ -22,14 +22,14 @@ import {
 
 In this guide you will learn how to grant a user access to a particular object through a relationship with another object.
 
-<CardBox title="When to use" appearance="filled" description={<div>
+<CardBox title="When to use" appearance="filled">
 
 Giving user access through a relationship with another object is helpful because it allows scaling as the number of object grows. For example:
 
 - organization that owns many repos
 - team that administers many documents
 
-</div>} />
+</CardBox>
 
 ## Before you start
 

docs/content/interacting/managing-user-access.mdx

@@ -23,14 +23,14 @@ import {
 
 In this guide you will learn how to grant a <ProductConcept section="what-is-a-user" linkName="user" /> access to a particular <ProductConcept section="what-is-an-object" linkName="object" />.
 
-<CardBox title="When to use" appearance="filled" description={<div>
+<CardBox title="When to use" appearance="filled">
 
 Granting access with a _<ProductConcept section="what-is-a-relationship-tuple" linkName="relationship tuple" />_ is a core part of <ProductName format={ProductNameFormat.ShortForm}/>. Without any relationship tuples, any _<ProductConcept section="what-is-a-check-request" linkName="check" />_ will fail. You should use:
 
 - _authorization model_ to represent what **relation**s are possible between the users and objects in your system
 - _relationship tuples_ to represent the facts about the relationships between users and objects in your system.
 
-</div>} />
+</CardBox>
 
 ## Before You Start
 

docs/content/interacting/transactional-writes.mdx

@@ -23,11 +23,11 @@ import {
 
 In this guide you will learn how to update multiple <ProductConcept section="what-is-a-relationship-tuple" linkName="relationship tuples" /> in a single transaction.
 
-<CardBox title="When to use" appearance="filled" description={<div>
+<CardBox title="When to use" appearance="filled">
 
 Updating multiple relationship tuples is useful to keep system state consistent.
 
-</div>} />
+</CardBox>
 
 ## Before You Start
 

docs/content/modeling/blocklists.mdx

@@ -24,7 +24,7 @@ import {
 
 In this guide you'll see how to model preventing users from accessing objects using <ProductName format={ProductNameFormat.ProductLink}/>. For example, `blocking` users from accessing a `document`, even if it has been already shared with them.
 
-<CardBox title="When to use" appearance="filled" description={<div>
+<CardBox title="When to use" appearance="filled">
 
 Exclusion is useful while building applications. You may need to support access patterns like granting access to some users, but excluding specific people or groups, similar to how users can block others from following them on social media, or prevent them from sharing documents on Google Drive.
 
@@ -33,7 +33,7 @@ This is useful when:
 - Implementing the "blocking" feature, such as the profile blocking commonly present on social media platforms (e.g. Instagram and Twitter).
 - Reduce a user's access if they are part of a particular group (e.g. restricting access to members who are also guests, or restricting access to users in a certain locality).
 
-</div>} />
+</CardBox>
 
 ## Before You Start
 

docs/content/modeling/building-blocks/concentric-relationships.mdx

@@ -25,7 +25,7 @@ In this short guide, you'll learn how to represent a concentric <ProductConcept
 
 For example, if you want to have all editors of a document also be viewers of said document.
 
-<CardBox title="When to use" appearance="filled" description={<div>
+<CardBox title="When to use" appearance="filled">
 
 Concentric relations make the most sense when your domain logic has nested relations, where one having relation implies having another relation.
 
@@ -37,7 +37,7 @@ For example:
 
 This allows you to only create a single _relationship tuple_ rather than creating n _relationship tuples_ for each relation.
 
-</div>} />
+</CardBox>
 
 ## Before You Start
 

docs/content/modeling/building-blocks/direct-relationships.mdx

@@ -25,15 +25,15 @@ import TabItem from '@theme/TabItem';
 
 In this guide you'll learn how to model relationships that may or may not be assigned directly to individual users.
 
-<CardBox title="When to use" appearance="filled" description={<div>
+<CardBox title="When to use" appearance="filled">
 
 Disabling _direct relationships_ for a certain relation on an objects are useful especially in cases where you are trying to model some permissions that are not usually granted individually to a user.
 
 This is useful when:
 
 - For security reason, not permitting permissions assigned directly to individuals without associating roles
 
-</div>} />
+</CardBox>
 
 ## Before You Start
 

docs/content/modeling/building-blocks/object-to-object-relationships.mdx

@@ -23,7 +23,7 @@ import {
 
 In this guide you'll learn how to model your application with <ProductConcept section="what-is-an-object" linkName="objects" /> that are not specifically tied to a user. For example, a `folder` is a `parent` of a `document`.
 
-<CardBox title="When to use" appearance="filled" description={<div>
+<CardBox title="When to use" appearance="filled">
 
 This design pattern is helpful in the case where there are relationships between different objects. With <ProductName format={ProductNameFormat.LongForm}/>, so long as both objects are in a type defined in the <ProductConcept section="what-is-an-authorization-model" linkName="authorization model" />, relationship tuples can be added to indicate a relationship between them.
 
@@ -38,7 +38,7 @@ For example:
 - `account` can contain `transactions`
 - `buildings` can have `doors`
 
-</div>} />
+</CardBox>
 
 ## Before You Start
 

docs/content/modeling/contextual-time-based-authorization.mdx

@@ -25,14 +25,15 @@ import {
 
 This section explores some methods available to you to tackle some use-cases where the expected authorization check may depend on certain dynamic or contextual data (such as time, location, ip address, weather) that have not been written to the <ProductName format={ProductNameFormat.ShortForm}/> store.
 
-<CardBox title="When to use" appearance="filled" description={<div>
+<CardBox title="When to use" appearance="filled">
+
 Contextual Tuples should be used when modeling cases where a user's access to an object depends on the context of their request. For example:
 
 - An employee’s ability to access a document when they are connected to the company VPN or the api call is originating from an internal IP address.
 - A support engineer is only able to access a user's account during office hours.
 - If a user belongs to multiple organizations, they are only able to access a resource if they set a specific organization in their current context.
 
-</div>} />
+</CardBox>
 
 ## Before You Start
 

docs/content/modeling/custom-roles.mdx

@@ -25,7 +25,7 @@ In this guide you'll learn how to model custom roles in your system using <Produ
 
 For example, a Business-to-Business (B2B) application could allow customers to create their own custom roles on the application to grant their users.
 
-<CardBox title="When to use" appearance="filled" description={<div>
+<CardBox title="When to use" appearance="filled">
 
 In many cases, roles would fit in well as relations on an object type, as seen in [Modeling Roles and Permissions](./roles-and-permissions.mdx). In some cases, however, they may not be enough.
 
@@ -35,7 +35,7 @@ Custom roles are useful when:
 - It is not known beforehand (at the time of Authorization Model creation) what the application roles are.
 - The team responsible for building the authorization model is different from the teams responsible for defining roles and access to the application.
 
-</div>} />
+</CardBox>
 
 ## Before you start
 

docs/content/modeling/direct-access.mdx

@@ -23,14 +23,14 @@ import {
 
 In this guide you will learn how to grant a <ProductConcept section="what-is-a-user" linkName="user" /> access to an <ProductConcept section="what-is-an-object" linkName="object" /> (such as a certain document) in <ProductName format={ProductNameFormat.ProductLink}/>.
 
-<CardBox title="When to use" appearance="filled" description={<div>
+<CardBox title="When to use" appearance="filled">
 
 Granting access with _<ProductConcept section="what-is-a-relationship-tuple" linkName="relationship tuple" />_ is a core part of <ProductName format={ProductNameFormat.ShortForm}/>. Without them, any _<ProductConcept section="what-is-a-check-request" linkName="checks" />_ will fail. You should use:
 
 - _authorization model_ to represent what **relation**s are possible between the users and objects in the system
 - _relationship tuples_ to represent the facts about the relationships between users and objects in your system.
 
-</div>} />
+</CardBox>
 
 ## Before you start
 

docs/content/modeling/getting-started.mdx

@@ -53,45 +53,23 @@ If that sounds hard, don't worry! We'll guide you through it.
 ReBAC systems determine access from a <ProductConcept section="what-is-a-user" linkName="user's" /> <ProductConcept section="what-is-a-relation" linkName="relation" /> to an <ProductConcept section="what-is-an-object" linkName="object" />. Authorization decisions are then yes or no answers to the question: "Does user U have relation R with object O?".
 
 <ColumnLayout cols={2} style={{ marginTop: '2rem', marginBottom: '2rem' }}>
-  <CardBox
-    title="General Authorization Check"
-    description={
-      <p>
-        "Can user <b>U</b> <u>perform an action</u> <b>A</b> on object <b>O</b>?"
-      </p>
-    }
-    appearance="filled"
-  />
-  <CardBox
-    title="{ProductName} (ReBAC) Authorization Check"
-    description={
-      <p>
-        "Does user <b>U</b> <u>have relation</u> <b>R</b> with object <b>O</b>?"
-      </p>
-    }
-  />
+  <CardBox title="General Authorization Check" appearance="filled">
+    "Can user <b>U</b> <u>perform an action</u> <b>A</b> on object <b>O</b>?"
+  </CardBox>
+  <CardBox title="{ProductName} (ReBAC) Authorization Check">
+    "Does user <b>U</b> <u>have relation</u> <b>R</b> with object <b>O</b>?"
+  </CardBox>
 </ColumnLayout>
 
 In the previous example, a relation R should be defined that implies permission to action A. For example:
 
 <ColumnLayout cols={2} style={{ marginTop: '2rem', marginBottom: '2rem' }}>
-  <CardBox
-    title="General Authorization Check"
-    description={
-      <p>
-        "Can user <b>Jane</b> <u>perform action</u> <b>view</b> on object <b>project sandcastle</b>?"
-      </p>
-    }
-    appearance="filled"
-  />
-  <CardBox
-    title="{ProductName} (ReBAC) Authorization Check"
-    description={
-      <p>
-        "Can user <b>Jane</b> <u>have relation</u> <b>view</b> with object <b>project sandcastle</b>?"
-      </p>
-    }
-  />
+  <CardBox title="General Authorization Check" appearance="filled">
+    "Can user <b>Jane</b> <u>perform action</u> <b>view</b> on object <b>project sandcastle</b>?"
+  </CardBox>
+  <CardBox title="{ProductName} (ReBAC) Authorization Check">
+    "Can user <b>Jane</b> <u>have relation</u> <b>view</b> with object <b>project sandcastle</b>?"
+  </CardBox>
 </ColumnLayout>
 
 We'll provide more detailed examples throughout this article.
@@ -1387,23 +1365,12 @@ How? Remember from the introduction that **<ProductName format={ProductNameForma
 The <ProductName format={ProductNameFormat.ShortForm}/> service does that by checking if a user has a particular relationship to an object, based on your authorization model and relationship tuples.
 
 <ColumnLayout cols={2} style={{ marginTop: '2rem', marginBottom: '2rem' }}>
-  <CardBox
-    title="General Authorization Check"
-    description={
-      <p>
-        "Can user <b>U</b> <u>perform action</u> <b>A</b> on object <b>O</b>?"
-      </p>
-    }
-    appearance="filled"
-  />
-  <CardBox
-    title="{ProductName} (ReBAC) Authorization Check"
-    description={
-      <p>
-        "Can user <b>U</b> <u>have relation</u> <b>R</b> with object <b>O</b>?"
-      </p>
-    }
-  />
+  <CardBox title="General Authorization Check" appearance="filled">
+    "Can user <b>U</b> <u>perform action</u> <b>A</b> on object <b>O</b>?"
+  </CardBox>
+  <CardBox title="{ProductName} (ReBAC) Authorization Check">
+    "Can user <b>U</b> <u>have relation</u> <b>R</b> with object <b>O</b>?"
+  </CardBox>
 </ColumnLayout>
 
 What we want is to ensure that given our current authorization model and some sample relationship tuples, we get the expected results for those questions.

docs/content/modeling/multiple-restrictions.mdx

@@ -28,14 +28,14 @@ For example, _<ProductConcept section="what-is-a-user" linkName="users" />_ are
 
 In this way, we prevent other users from deleting such document.
 
-<CardBox title="When to use" appearance="filled" description={<div>
+<CardBox title="When to use" appearance="filled">
 
 This is useful when:
 
 - Limiting certain actions (such as deleting or reading sensitive document) to privileged users.
 - Adding restrictions and requiring multiple authorization paths before granting access.
 
-</div>} />
+</CardBox>
 
 ## Before You Start
 

docs/content/modeling/organization-context-authorization.mdx

@@ -25,14 +25,14 @@ import {
 
 This section tackles cases where a user may have access to a particular resource through their presence in a particular organization, and they should have that access only when logged in within the context of that organization.
 
-<CardBox title="When to use" appearance="filled" description={<div>
+<CardBox title="When to use" appearance="filled">
 Contextual Tuples should be used when modeling cases where a user's access to an object depends on the context of their request. For example:
 
 - An employee’s ability to access a document when they are connected to the organization VPN or the api call is originating from an internal IP address.
 - A support engineer is only able to access a user's account during office hours.
 - If a user belongs to multiple organizations, they are only able to access a resource if they set a specific organization in their current context.
 
-</div>} />
+</CardBox>
 
 ## Before You Start
 

docs/content/modeling/parent-child.mdx

@@ -23,7 +23,7 @@ import {
 
 In this guide you will learn how to indicate <ProductConcept section="what-is-a-relationship" linkName="relationships" /> between <ProductConcept section="what-is-an-object" linkName="objects" />, and how users' relationships to one object can affect their relationship with another. For example: how a `editor` of a `folder` can be an `editor` of all `documents` the `folder` is a `parent` of.
 
-<CardBox title="When to use" appearance="filled" description={<div>
+<CardBox title="When to use" appearance="filled">
 
 Object-to-Object relationships, combined with a configured authorization model can be used to indicate that a user's relation with one object can influence their relationship with another object. This can also be used in some cases to remove the need to modify relations between objects using [user groups](./user-groups.mdx#03-assign-the-team-members-a-relation-to-an-object).
 
@@ -33,7 +33,7 @@ Object-to-object relationships can be used:
 - To indicate that users who have a repository admin role (`repo_admin`) in an organization automatically have `admin` access to all repositories in that organization
 - To indicate that users who are `subscribed` to a `plan`, get access to all the `features` in that `plan`
 
-</div>} />
+</CardBox>
 
 ## Before You Start
 

docs/content/modeling/public-access.mdx

@@ -24,7 +24,7 @@ import {
 
 In this guide you will learn how to grant public access to an <ProductConcept section="what-is-an-object" linkName="object" />, such as a certain document, using <ProductConcept section="what-is-type-bound-public-access" linkName="type bound public access" />.
 
-<CardBox title="When to use" appearance="filled" description={<div>
+<CardBox title="When to use" appearance="filled">
 
 Public access allows your application to grant every user in the system access to an object. You would add a relationship tuple with type-bound public access when:
 
@@ -33,7 +33,7 @@ Public access allows your application to grant every user in the system access t
 - a blog `post` is published and anyone should be able to `read` it
 - a `video` is made public for anyone to `watch`
 
-</div>} />
+</CardBox>
 
 ## Before You Start
 

docs/content/modeling/roles-and-permissions.mdx

@@ -28,7 +28,7 @@ In this guide you will learn how to model roles and permissions model within <Pr
 
 For example, the role `viewer` of a `trip` can have **permissions to view bookings** or the role `owners` can have **permissions to add/view bookings to a trip.**
 
-<CardBox title="When to use" appearance="filled" description={<div>
+<CardBox title="When to use" appearance="filled">
 
 When trying to create a role and permissions model within <ProductName format={ProductNameFormat.ShortForm}/>.:
 
@@ -46,7 +46,7 @@ There are advantages to implementing roles and permissions within <ProductName f
 - Breaking down existing roles to have more fine grained permissions. This allows your application to check whether a _user_ has access to a certain object without having to explicitly check that specific _users_ role.
 - Introduce new roles/permissions or consolidate roles without affecting your application behavior. For example: if in your app all the checks are for the fine permissions `check('bob', 'booking_adder', 'trip:Europe')` instead of `check('bob', 'owner', 'trip:Europe')`, and then you later decide `owners` can no longer add bookings to a `trip`, you can remove the relation within the `trip` type with no code changes in your application, and all the permissions will automatically honor the change.
 
-</div>} />
+</CardBox>
 
 ## Before you start