chore: bump to docusaurus 3.0.1

See https://docusaurus.io/blog/preparing-your-site-for-docusaurus-v3

blog/conditional-tuples-announcement.md

@@ -40,7 +40,7 @@ If we write the following tuples:
 | user | relation| object| condition | 
 |------|---------|-------|---|
 | user:bob | viewer| document:1| |
-| user:anne | viewer| document:1| `name` : `non_expired_grant`, `context` : { `grant_time` : `2023-01-01T00:00:00Z`, `grant_duration` : `1h` } |
+| user:anne | viewer| document:1| `name` : `non_expired_grant`, `context` : \{ `grant_time` : `2023-01-01T00:00:00Z`, `grant_duration` : `1h` \} |
 
 You'll get the following results for the [Check](https://openfga.dev/api/service#/Relationship%20Queries/Check) operations below:
 

docs/content/getting-started/install-sdk.mdx

@@ -9,6 +9,7 @@ import {
   SupportedLanguage,
   languageLabelMap,
   DocumentationNotice,
+  ProductConcept,
   ProductName,
   ProductNameFormat,
   RelatedSection,

docs/content/getting-started/update-tuples.mdx

@@ -81,7 +81,7 @@ This section will illustrate how to update _<ProductConcept section="what-is-a-r
 
 Assume that you want to add user `user:anne` to have relationship `reader` with object `document:Z`
 
-```json5
+```json
 {
   user: 'user:anne',
   relation: 'reader',
@@ -157,7 +157,7 @@ To delete relationship tuples, we can invoke the write API.
 
 Assume that you want to delete user `user:anne`'s `reader` relationship with object `document:Z`
 
-```json5
+```json
 {
   user: 'user:anne',
   relation: 'reader',

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" description={<div>
 
 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> />
+</div>} />
 
 ## 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" description={<div>
 
 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> />
+</div>} />
 
 ## 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" description={<div>
 
 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> />
+</div>} />
 
 ## 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" description={<div>
 
 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> />
+</div>} />
 
 ## Before You Start
 

docs/content/interacting/relationship-queries.mdx

@@ -229,7 +229,7 @@ For example, to understand why `bob` can have a `reader` relationship with `docu
 
 The result of this call will be like
 
-```json5
+```json
 {
   "tree":{
     "root":{
@@ -251,7 +251,7 @@ The returned tree will contain `writer`, for which we will call
 
 The result of this call will be like
 
-```json5
+```json
 {
   "tree":{
     "root":{

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" description={<div>
 
 Updating multiple relationship tuples is useful to keep system state consistent.
 
-</div> />
+</div>} />
 
 ## Before You Start
 

docs/content/modeling/advanced/entitlements.mdx

@@ -299,7 +299,7 @@ For example, the relationship tuple indicating that _anne is a member of organiz
 
 #### Verification
 
-Now that you have some data, you can start using it to ask is ${USER} related to ${OBJECT} as ${RELATION}?
+Now that you have some data, you can start using it to ask is $\{USER\} related to $\{OBJECT\} as $\{RELATION\}?
 
 First, you will <ProductConcept section="what-is-a-check-request" linkName="check" /> if `anne` is a member of `organization:alpha`. This is one of the relationship tuples you previously added, you will make sure <ProductName format={ProductNameFormat.ShortForm}/> can detect a relation in this case.
 

docs/content/modeling/advanced/slack.mdx

@@ -326,7 +326,7 @@ Catherine, on the other hand, is not a legacy_admin of workspace:sandcastle.
 
 Repeat this process for the other relationships
 
-```json5
+```json
 [
   {
     // Bob is a Channels Admin in the Sandcastle workspace

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" description={<div>
 
 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> />
+</div>} />
 
 ## 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" description={<div>
 
 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> />
+</div>} />
 
 ## 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" description={<div>
 
 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> />
+</div>} />
 
 ## 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" description={<div>
 
 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> />
+</div>} />
 
 ## Before You Start
 

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

@@ -25,14 +25,14 @@ 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" description={<div>
 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> />
+</div>} />
 
 ## 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" description={<div>
 
 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> />
+</div>} />
 
 ## 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" description={<div>
 
 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> />
+</div>} />
 
 ## Before you start
 

docs/content/modeling/getting-started.mdx

@@ -284,7 +284,7 @@ Let's highlight all object types in <span className="blue-highlight-text">blue</
 </CardBox>
 </div>
 
-However, the list of object types is not finished. To complete the list of object types you must also add all the second nouns that appear in conditions as part of expressions of this format: **"{first noun} of a/the {second noun}"**.
+However, the list of object types is not finished. To complete the list of object types you must also add all the second nouns that appear in conditions as part of expressions of this format: **"\{first noun\} of a/the \{second noun\}"**.
 
 <div style={{ marginBottom: '2rem' }}>
   <CardBox centerTitle title="... IF {first noun} of a/the {second noun}" appearance="filled" />
@@ -394,10 +394,10 @@ Each of the previously defined types has a set of relations. <ProductConcept sec
 
 To identify relations for a type we in the write-up we can perform an exercise similar to the one we did in [list the type of objects in your system](#02-list-the-object-types).
 
-Relations for a type {type} will be all of these:
+Relations for a type \{type\} will be all of these:
 
-- any noun that is the {noun} of a "{noun} of a/an/the {type}" expression. **These are typically the Foreign Keys in a database.** We'll highlight these in <span className="green-highlight-text">green</span>.
-- any verb or action that is the {action} of a "can {action} (in) a/an {type}" expression. **These are typically the permissions for a type.** We'll highlight these in <span className="yellow-highlight-text">yellow</span>.
+- any noun that is the \{noun\} of a "\{noun\} of a/an/the \{type\}" expression. **These are typically the Foreign Keys in a database.** We'll highlight these in <span className="green-highlight-text">green</span>.
+- any verb or action that is the \{action\} of a "can \{action\} (in) a/an \{type\}" expression. **These are typically the permissions for a type.** We'll highlight these in <span className="yellow-highlight-text">yellow</span>.
 
 <div style={{ marginTop: '2rem', marginBottom: '2rem' }}>
 <CardBox monoFontChildren appearance='filled'>
@@ -599,12 +599,12 @@ Remember _"How a user is added as a member to an organization is beyond the scop
 Why? This relation definition states:
 
 - That organizations have members
-- That the members of an organization with id {id} are all users described by tuples of the form:
+- That the members of an organization with id \{id\} are all users described by tuples of the form:
 
-  `{ user: {user-id}, relation: "member", object: "organization:{id}" }`
+  `{ user: {user-id}, relation: "member", object: "organization:\{id\}" }`
 
 :::info Important
-Relation definitions of the form “define {relation}: [user, organization#member]" are fairly common. They are used to express that relationships "to the object with that relation" (e.g. "users" of type user or "member of organization") can be assigned by your system and that only the users that have that relation are those with a [direct relationship](./building-blocks/direct-relationships.mdx).
+Relation definitions of the form “define \{relation\}: [user, organization#member]" are fairly common. They are used to express that relationships "to the object with that relation" (e.g. "users" of type user or "member of organization") can be assigned by your system and that only the users that have that relation are those with a [direct relationship](./building-blocks/direct-relationships.mdx).
 :::
 
 You can read more about group membership and types in [Modeling User Groups](./user-groups.mdx).
@@ -705,7 +705,7 @@ Why? This <ProductConcept section="what-is-a-relation" linkName="relation defini
 
 - each document can have one or more owners
 - owners of a document are assignable by creating a tuple of the format
-  `{ user: "{user_id}", relation: "owner", object: "document:{id}" }` for individual users
+  `{ user: "{user_id}", relation: "owner", object: "document:\{id\}" }` for individual users
 
 ##### Relation: Editor
 
@@ -740,7 +740,7 @@ Why? This relation definition states that:
 
 - each document can have editors
 - the editor(s) of a document are assignable by creating a tuple with shape
-  `{ user: "{user_id}", relation: "editor", object: "document:{id}" }` for individual users
+  `{ user: "{user_id}", relation: "editor", object: "document:\{id\}" }` for individual users
 
 This also supports making all members in an organization editors of the document, through a [group to object relationship](./user-groups.mdx). A relationship tuple like the following one states that the members of organization A are editors of document 0001.
 
@@ -813,9 +813,9 @@ When a document is created a relationship tuple will be stored in <ProductName f
 Why? This relation definition states that:
 
 - documents may have a parent
-- the parent(s) of a document with id {id} is either a folder or a drive, described by one of these relationship tuples:
-  - `{ user: "folder:{id}", relation: "parent", object: "document:{id}" }`
-  - `{ user: "drive:{id}", relation: "parent", object: "document:{id}" }`
+- the parent(s) of a document with id \{id\} is either a folder or a drive, described by one of these relationship tuples:
+  - `{ user: "folder:\{id\}", relation: "parent", object: "document:\{id\}" }`
+  - `{ user: "drive:\{id\}", relation: "parent", object: "document:\{id\}" }`
 
 
 We can use [direct type restriction](../configuration-language.mdx#the-direct-relationship-type-restrictions) to ensure a document's parent can only be an object of type either drive or folder.

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" description={<div>
 
 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> />
+</div>} />
 
 ## Before You Start