FusionAuth · Aaron-Ritter · May 19, 2025 · May 20, 2025 · May 20, 2025 · May 20, 2025
@@ -41,7 +41,8 @@ Here are some guidelines to follow when writing documentation (everything under
 
 ## Docs 
 - Don't use complex breadcrumbs styling in docs. Use `->`. Use the [Breadcrumb](astro/src/components/Breadcrumb.astro) component. Breadcrumbs should look like this `<Breadcrumb>foo -> bar -> baz</Breadcrumb>`.
-- If you are referencing a field in a form or JSON API doc, use the [InlineField](astro/src/components/InlineField.astro) component: `<InlineField>Issuer</InlineField>`.
+- If you are referencing a field in a form or JSON API doc, or a parameter use the [InlineField](astro/src/components/InlineField.astro) component: `<InlineField>Issuer</InlineField>`. The field can writable or read-only. It should be used for all fields, including those that are not editable in the UI.
+- If you are defining or describing an input or output to a inline field in a form or JSON API doc, or a parameter value use the [InlineFieldValue](astro/src/components/InlineFieldValue.astro) component: `<InlineFieldValue>acme</InlineFieldValue>`.
 - If you are referencing a UI element or button, use the [InlineUIElement](astro/src/components/InlineUIElement.astro) component: `Click the <InlineUIElement>Ok</InlineUIElement> button`.
 - If you are referencing a tab in the UI, use the [Breadcrumb](astro/src/components/Breadcrumb.astro) component: `On the <Breadcrumb>OAuth</Breadcrumb> tab`.
 - When you have a list of values, use this phrase to prefix it: "The possible values are:"

@@ -0,0 +1,3 @@
+---
+---
+<code><slot></slot></code>
@@ -1,6 +1,7 @@
 import APIBlock from 'src/components/api/APIBlock.astro';
 import APIField from 'src/components/api/APIField.astro';
 import InlineField from 'src/components/InlineField.astro';
+import InlineFieldValue from 'src/components/InlineFieldValue.astro';
 import PropertyMemory from 'src/content/docs/reference/_property-memory.mdx';
 
 export const addlJavaArgsText = 'Any additional arguments that you want to pass to the Java VM where this service will run.';
@@ -31,9 +32,9 @@ export const addlJavaArgsText = 'Any additional arguments that you want to pass
   </APIField>
 
   <APIField name="database.mysql.enforce-utf8mb4" type="String" defaults="true">
-    When set to `true` and using MySQL, a 4 byte UTF compatible character set configuration is enforced at startup.
+    When set to <InlineFieldValue>true</InlineFieldValue> and using MySQL, a 4 byte UTF compatible character set configuration is enforced at startup.
 
-    If this validation is not desired or not it is not possible to modify your MySQL configuration to satisfy the validation, disable this check by setting this value to `false`. If this is `false`, any attempt to store a 4 byte unicode character will cause the `INSERT` or `UPDATE` request to fail. The initial MySQL UTF-8 implementation only supported up to characters up to 3 bytes in length; utf8mb4 extends this to 4 byte characters.
+    If this validation is not desired or not it is not possible to modify your MySQL configuration to satisfy the validation, disable this check by setting this value to <InlineFieldValue>false</InlineFieldValue>. If this is <InlineFieldValue>false</InlineFieldValue>, any attempt to store a 4 byte unicode character will cause the `INSERT` or `UPDATE` request to fail. The initial MySQL UTF-8 implementation only supported up to characters up to 3 bytes in length; utf8mb4 extends this to 4 byte characters.
   </APIField>
 
   <APIField name="database.password" type="String">
@@ -119,9 +120,9 @@ export const addlJavaArgsText = 'Any additional arguments that you want to pass
   <APIField name="fusionauth-app.http.cookie-same-site-policy" type="String" since="1.16.0" deprecated>
     The value to use in the Same-Site cookie attribute for cookies set by FusionAuth.  Possible values are:
 
-    - `None`
-    - `Lax`
-    - `Strict`
+    - <InlineFieldValue>None</InlineFieldValue>
+    - <InlineFieldValue>Lax</InlineFieldValue>
+    - <InlineFieldValue>Strict</InlineFieldValue>
 
     <span class="text-red-700">Deprecated names:</span>
 
@@ -228,7 +229,7 @@ export const addlJavaArgsText = 'Any additional arguments that you want to pass
   </APIField>
 
   <APIField name="fusionauth-app.local-metrics.enabled" type="Boolean" defaults="false" since="1.46.0">
-    Set to `true` to allow unauthenticated access to `/api/prometheus/metrics` and `/api/status` from `localhost`. This can be used to allow the scraping of health and metrics data by local collector agents without the need to provide an API key.
+    Set to <InlineFieldValue>true</InlineFieldValue> to allow unauthenticated access to `/api/prometheus/metrics` and `/api/status` from `localhost`. This can be used to allow the scraping of health and metrics data by local collector agents without the need to provide an API key.
   </APIField>
 
   <APIField name="fusionauth-app.management.port" type="Integer" defaults="9010" deprecated>
@@ -275,7 +276,7 @@ export const addlJavaArgsText = 'Any additional arguments that you want to pass
   </APIField>
 
   <APIField name="fusionauth-app.silent-mode" type="Boolean" defaults="true" since="1.19.0">
-    Determines if FusionAuth should use [Silent Mode] during the startup process. Previous to version `1.19.0`, Silent Mode was only available when the [<InlineField>fusionauth-app.runtime-mode</InlineField>](/docs/get-started/download-and-install/silent-mode) was `development`. This has been changed so that FusionAuth can now automatically apply database migrations during the startup process.
+    Determines if FusionAuth should use [Silent Mode] during the startup process. Previous to version `1.19.0`, Silent Mode was only available when the <InlineField>fusionauth-app.runtime-mode</InlineField>(/docs/get-started/download-and-install/silent-mode) was <InlineFieldValue>development</InlineFieldValue>. This has been changed so that FusionAuth can now automatically apply database migrations during the startup process.
   </APIField>
 
   <APIField name="fusionauth-app.url" type="String" since="1.4.0">
@@ -395,7 +396,7 @@ export const addlJavaArgsText = 'Any additional arguments that you want to pass
   </APIField>
 
   <APIField name="search.sniffer" type="Boolean" defaults="false" since="1.19.8">
-    Set to `true` if you want to use the Elasticsearch sniffer configuration. If you are using a managed Elasticsearch service, or running Elasticsearch inside of a container, you should leave this value set to `false`.
+    Set to <InlineFieldValue>true</InlineFieldValue> if you want to use the Elasticsearch sniffer configuration. If you are using a managed Elasticsearch service, or running Elasticsearch inside of a container, you should leave this value set to <InlineFieldValue>false</InlineFieldValue>.
 
     This configuration can be helpful to allow FusionAuth to use a single connection to `localhost` and then allow the Elasticsearch REST client to discover all other nodes in the Elasticsearch cluster.
   </APIField>

@@ -10,6 +10,7 @@ dateModified: 2022-09-01
 ---
 import Breadcrumb from 'src/components/Breadcrumb.astro';
 import InlineField from 'src/components/InlineField.astro';
+import InlineFieldValue from 'src/components/InlineFieldValue.astro';
 import InlineUIElement from 'src/components/InlineUIElement.astro';
 
 OAuth (pronounced “oh-auth”) grants are various types of authorization methods that enable users to share information between services and across devices without entering or compromising their password or username.
@@ -84,7 +85,7 @@ Now that your Docker image for FusionAuth is running, you need to configure the
 Go to Applications on the navigation bar and click on "Create a new application". Name the application `Test Grant` and save it.
 
 
-Click on **Edit** to edit the application you’ve just created. Go to the Enabled Grants section and enable the Device type from the list, and put as verification URL `https://example.com/device`.
+Click on **Edit** to edit the application you’ve just created. Go to the <InlineField>Enabled grants</InlineField> section and enable the Device type from the list, and put as verification URL `https://example.com/device`.
 
 ![Adding an application.](/img/articles/device-grant-gaming/adding-application.png)
 

@@ -8,14 +8,15 @@ section: Identity Basics
 date: 2020-10-30
 dateModified: 2020-10-30
 ---
-import SlowMigrationHub from "../../../../public/img/articles/slow-migration-hub-svg.astro";
-import AuthBeforeBigBang from "../../../diagrams/articles/identity-basics/auth-before-big-bang.astro";
-import AuthDuringBigBang from "../../../diagrams/articles/identity-basics/auth-during-big-bang.astro";
 import AuthAfterBigBang from "../../../diagrams/articles/identity-basics/auth-after-big-bang.astro";
+import AuthAfterMigration from "../../../diagrams/articles/identity-basics/auth-after-migration.astro";
+import AuthBeforeBigBang from "../../../diagrams/articles/identity-basics/auth-before-big-bang.astro";
 import AuthBeforeMigration from "../../../diagrams/articles/identity-basics/auth-before-migration.astro";
+import AuthDuringBigBang from "../../../diagrams/articles/identity-basics/auth-during-big-bang.astro";
 import AuthDuringMigrationFirstAuth from "../../../diagrams/articles/identity-basics/auth-during-migration-first-auth.astro";
 import AuthDuringMigrationSecondAuth from "../../../diagrams/articles/identity-basics/auth-during-migration-second-auth.astro";
-import AuthAfterMigration from "../../../diagrams/articles/identity-basics/auth-after-migration.astro";
+import InlineField from 'src/components/InlineField.astro';
+import SlowMigrationHub from "../../../../public/img/articles/slow-migration-hub-svg.astro";
 
 Migrating data used for auth is a pain. People have to login to your application, and maintaining access is critical. User data is often siloed and changes at the whim of your users. 
 
@@ -146,9 +147,9 @@ When you are moving between them, you'll face three challenges.
 
 The first is converting from `fname` to `first_name` and `lname` to `last_name`. This is pretty easy. 
 
-The second is parsing the `birthdate` field into a date format to place in the `date_of_birth` field. Depending on how clean the original data is, this could be trivial or it could be painful. 
+The second is parsing the <InlineField>birthdate</InlineField> field into a date format to place in the <InlineField>date_of_birth</InlineField> field. Depending on how clean the original data is, this could be trivial or it could be painful.
 
-The last issue would be splitting the `phone_num` field into an `area_code` and a `phone_number`. 
+The last issue would be splitting the <InlineField>phone_num</InlineField> field into an `area_code` and a `phone_number`.
 
 As this example shows, getting ready for a migration consists of many tiny choices and design decisions. Make sure you understand the data model for your users before you start the migration. 
 
@@ -158,7 +159,7 @@ You'll also want to think about relationships between users and other objects. G
 
 There are two field types worth commenting on in more detail. The first is user ids. These are often referenced by other systems and are used for auditing, analytics or other historical purposes. If you can preserve user ids, do so. 
 
-If you cannot, plan accordingly. You may want to keep that field in the new system in an `old_user_id` field, accept the loss of this data, or build a system to map from old user ids to new user ids, to be used by any external party which depended on the old user id.
+If you cannot, plan accordingly. You may want to keep that field in the new system in an <InlineField>old_user_id</InlineField> field, accept the loss of this data, or build a system to map from old user ids to new user ids, to be used by any external party which depended on the old user id.
 
 The other notable attribute is the password, and any related fields such as a salt. Passwords don't have to be migrated in a slow migration. The user will provide the password during authentication, and it can be stored in the new auth system during that process.
 

@@ -10,6 +10,7 @@ dateModified: 2023-12-10
 ---
 import Aside from '/src/components/Aside.astro';
 import ExampleIdToken from 'src/content/docs/lifecycle/authenticate-users/oauth/_example_id_token.mdx';
+import InlineFieldValue from 'src/components/InlineFieldValue.astro';
 import OIDCFlow from "../../../diagrams/articles/identity-basics/oidc-flow.astro";
 
 
@@ -121,7 +122,7 @@ There are also user profile claims. Here's an incomplete list:
 * `name`, the full name, in a format displayable to humans.
 * `preferred_username`, a preferred username for the RP to use. This is not guaranteed to be unique.
 * `email`, the user's preferred email address. Again, this is not guaranteed to be unique.
-* `email_verified` which is `true` if the email address has been verified to be controlled by the end user, as defined by the OP.
+* `email_verified` which is <InlineFieldValue>true</InlineFieldValue> if the email address has been verified to be controlled by the end user, as defined by the OP.
 * `locale`, the end user's locale, like `en-US` or `fr-CA`.
 * `phone_number`, the user's preferred telephone number.
 * `updated_at`, the time the user's information was last updated.
@@ -165,7 +166,7 @@ The RP can request specific profile data. OIDC typically uses scopes to determin
 * `address` which requests access to the `address` claim. 
 * `phone` which requests access to the `phone_number` and `phone_number_verified` claims. 
 
-An OP may support zero, one or more of these scopes. These scopes are sent on the initial authorization request, just like any other OAuth scopes. So an RP can ask for just the `email` and `profile` scopes. Since the user has to consent to any information shared, requesting the minimum amount of profile data to fulfill the RP's needs is good practice.
+An OP may support zero, one or more of these scopes. These scopes are sent on the initial authorization request, just like any other OAuth scopes. So an RP can ask for just the `email` and <InlineFieldValue>profile</InlineFieldValue> scopes. Since the user has to consent to any information shared, requesting the minimum amount of profile data to fulfill the RP's needs is good practice.
 
 ## Response Types
 

@@ -8,6 +8,8 @@ section: Identity Basics
 date: 2022-10-10
 dateModified: 2022-10-10
 ---
+import InlineField from 'src/components/InlineField.astro';
+import InlineFieldValue from 'src/components/InlineFieldValue.astro';
 import ScimNewDeveloper from "../../../diagrams/articles/identity-basics/scim-new-developer.astro";
 
 SCIM, which stands for System for Cross-domain Identity Management, is a specification to add and remove users and groups using a standard protocol. 
@@ -71,11 +73,11 @@ Since SCIM is about identity, the `Users` concept is central.`Users` and `Enterp
 
 `Users` can also have emails, phone numbers, addresses and more. They can even have a list of x.509 certificates. Each user also has a password, which is write only.
 
-The required fields are few: the `userName` field is required. In addition, an `id` field must be created and assigned by the server.
+The required fields are few: the <InlineField>userName</InlineField> field is required. In addition, an <InlineField>id</InlineField> field must be created and assigned by the server.
 
 Review the [relevant section of the RFC](https://datatracker.ietf.org/doc/html/rfc7643#section-4.1) for the full list of attributes for this resource. 
 
-`Groups`, on the other hand, are much simpler. They have a required `displayName` and a list of members, as well as an `id`.
+`Groups`, on the other hand, are much simpler. They have a required `displayName` and a list of members, as well as an <InlineFieldValue>id</InlineFieldValue>.
 
 ### Schemas
 
@@ -89,7 +91,7 @@ Schemas support single value attributes like `name` and `userType` with a variet
 
 There are up to two identifiers for every resource in SCIM.
 
-The first is the `id`, which is a required attribute and is a globally unique identifier managed by the SCIM server. It must be stable and always refer to the same resource.
+The first is the <InlineFieldValue>id</InlineFieldValue>, which is a required attribute and is a globally unique identifier managed by the SCIM server. It must be stable and always refer to the same resource.
 
 The `externalId`, on the other hand, is provided by the client. It is optional and allows for identifiers from the provisioning process to be stored in the server.