fix: add environment scope, Expo SDK version, user blocking (gap report)#697
fix: add environment scope, Expo SDK version, user blocking (gap report)#697tamalchowdhury wants to merge 5 commits intomainfrom
Conversation
…org notes (gap report) Made-with: Cursor
Deploying kinde-docs-preview with
|
| Latest commit: |
d85d492
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://1391c379.kinde-docs-preview.pages.dev |
| Branch Preview URL: | https://tamal-update-tier2-roles-per.kinde-docs-preview.pages.dev |
WalkthroughFive documentation pages had frontmatter dates updated to 2026-03-26 and content edits: Home Realm Discovery wording and HRD behavior, Expo SDK prerequisites and install instructions, added user-suspension FAQ with workarounds, and heading/FAQ adjustments for roles and permissions. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
src/content/docs/manage-users/roles-and-permissions/user-roles.mdx (1)
126-128: Clarify scope to avoid cross-business ambiguity.The FAQ is helpful, but the sentence about dev/staging/prod could be read as applying across different Kinde businesses. Consider explicitly repeating “within the same Kinde business” in that sentence too.
Proposed wording tweak
-Yes. Roles and permissions are defined at the **business level**, not per environment. A role created in your development environment is the same role in staging and production — there is no per-environment isolation. If your team needs to test role changes without affecting production, manage each environment in a separate Kinde business. +Yes. Roles and permissions are defined at the **business level**, not per environment. Within the same Kinde business, a role created in your development environment is the same role in staging and production — there is no per-environment isolation. If your team needs to test role changes without affecting production, manage each environment in a separate Kinde business.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/content/docs/manage-users/roles-and-permissions/user-roles.mdx` around lines 126 - 128, Update the FAQ sentence that currently reads "A role created in your development environment is the same role in staging and production — there is no per-environment isolation." to explicitly state the business-scoped boundary by adding "within the same Kinde business" (e.g., "A role created in your development environment within the same Kinde business is the same role in staging and production — there is no per-environment isolation"). Edit the text under the "Are Kinde roles and permissions shared across environments?" section in user-roles.mdx so the clarification appears in both the first and second sentences for consistency.src/content/docs/manage-users/roles-and-permissions/user-permissions.mdx (1)
79-79: Consider adding a trailing newline.The file ends without a newline character. While not critical for MDX files, adding a trailing newline follows POSIX standards and is expected by many text editors and tools.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/content/docs/manage-users/roles-and-permissions/user-permissions.mdx` at line 79, Add a POSIX-compliant trailing newline to the end of the MDX file user-permissions.mdx by editing the file (user-permissions.mdx) and inserting a single newline character after the final sentence so the file ends with a newline; no content changes required—just ensure the file's EOF has a newline.src/content/docs/authenticate/enterprise-connections/home-realm-discovery.mdx (1)
58-58: Align scope wording for consistency.Line 58 starts with “SAML users” but the explanation describes behavior for enterprise connections using HRD more broadly. Consider making the lead phrase match that broader scope to avoid ambiguity.
✏️ Suggested edit
-- **Setting a default organization for SAML users is not supported** — Because HRD routes users before org selection occurs, passing `org_code` to override the destination organization is not supported for enterprise connections using home realm discovery. +- **Setting a default organization for enterprise users with HRD is not supported** — Because HRD routes users before org selection occurs, passing `org_code` to override the destination organization is not supported for enterprise connections using home realm discovery.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/content/docs/authenticate/enterprise-connections/home-realm-discovery.mdx` at line 58, The lead phrase currently reads "SAML users" but the explanation applies to enterprise connections using Home Realm Discovery (HRD); update the sentence that begins with "SAML users" to a broader, consistent scope such as "Enterprise connections using Home Realm Discovery (HRD) users" or simply "Users routed by Home Realm Discovery (HRD)" so the lead matches the rest of the sentence describing that passing `org_code` is not supported and the user will land in the organization linked to the matching enterprise connection.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@src/content/docs/authenticate/enterprise-connections/home-realm-discovery.mdx`:
- Around line 48-50: Update the compound adjective "sign in" to the hyphenated
form "sign-in" in the document: change the heading "## How to show or hide the
sign in buttons?" to use "sign-in" and also update the sentence "you can choose
to show an SSO sign in button" to "SSO sign-in button" so both adjective uses
are hyphenated (search for the heading text and the sentence fragment "SSO sign
in button" to locate the spots).
In `@src/content/docs/manage-users/access-control/delete-or-suspend-users.mdx`:
- Around line 79-80: The text claims enforcement happens "immediately" when
using the user.created webhook plus the Management API, which is misleading for
an asynchronous webhook flow; update the copy near the 'user.created' webhook
mention and the '`PATCH /api/v1/user`' reference to remove "immediately" and
replace it with a softer, accurate phrase such as "as soon as possible",
"promptly", or "upon receipt" to reflect potential delivery/retry latency and
async processing delays.
---
Nitpick comments:
In
`@src/content/docs/authenticate/enterprise-connections/home-realm-discovery.mdx`:
- Line 58: The lead phrase currently reads "SAML users" but the explanation
applies to enterprise connections using Home Realm Discovery (HRD); update the
sentence that begins with "SAML users" to a broader, consistent scope such as
"Enterprise connections using Home Realm Discovery (HRD) users" or simply "Users
routed by Home Realm Discovery (HRD)" so the lead matches the rest of the
sentence describing that passing `org_code` is not supported and the user will
land in the organization linked to the matching enterprise connection.
In `@src/content/docs/manage-users/roles-and-permissions/user-permissions.mdx`:
- Line 79: Add a POSIX-compliant trailing newline to the end of the MDX file
user-permissions.mdx by editing the file (user-permissions.mdx) and inserting a
single newline character after the final sentence so the file ends with a
newline; no content changes required—just ensure the file's EOF has a newline.
In `@src/content/docs/manage-users/roles-and-permissions/user-roles.mdx`:
- Around line 126-128: Update the FAQ sentence that currently reads "A role
created in your development environment is the same role in staging and
production — there is no per-environment isolation." to explicitly state the
business-scoped boundary by adding "within the same Kinde business" (e.g., "A
role created in your development environment within the same Kinde business is
the same role in staging and production — there is no per-environment
isolation"). Edit the text under the "Are Kinde roles and permissions shared
across environments?" section in user-roles.mdx so the clarification appears in
both the first and second sentences for consistency.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: b3368d7c-ac9d-48e6-9d15-e973b48f20f5
📒 Files selected for processing (5)
src/content/docs/authenticate/enterprise-connections/home-realm-discovery.mdxsrc/content/docs/developer-tools/sdks/native/expo.mdxsrc/content/docs/manage-users/access-control/delete-or-suspend-users.mdxsrc/content/docs/manage-users/roles-and-permissions/user-permissions.mdxsrc/content/docs/manage-users/roles-and-permissions/user-roles.mdx
src/content/docs/authenticate/enterprise-connections/home-realm-discovery.mdx
Outdated
Show resolved
Hide resolved
src/content/docs/manage-users/access-control/delete-or-suspend-users.mdx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
src/content/docs/authenticate/enterprise-connections/home-realm-discovery.mdx (1)
31-31: Polish the section heading phrasing.The heading reads awkwardly as a question. Consider either a statement or a properly formed question.
✏️ Suggested edit
-## How Home Realm Discovery works at Kinde? +## How Home Realm Discovery works in Kindeor
-## How Home Realm Discovery works at Kinde? +## How does Home Realm Discovery work in Kinde?🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/content/docs/authenticate/enterprise-connections/home-realm-discovery.mdx` at line 31, The heading "How Home Realm Discovery works at Kinde?" is awkwardly phrased—replace it with a concise, properly formed heading such as "How Home Realm Discovery Works at Kinde" (statement) or "How does Home Realm Discovery work at Kinde?" (question) by updating the header text in the document where the heading "How Home Realm Discovery works at Kinde?" appears.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@src/content/docs/authenticate/enterprise-connections/home-realm-discovery.mdx`:
- Line 58: The bullet that begins "Setting a default organization for SAML users
is not supported" uses "SAML users" but the rule applies to enterprise
connections using home realm discovery (HRD); change the wording to reference
enterprise connections/HRD instead of SAML to avoid implying SAML-only
behavior—e.g., rephrase to "Setting a default organization for enterprise
connections using home realm discovery (HRD) is not supported" and keep the
remainder of the sentence about org_code and destination organization intact.
In `@src/content/docs/manage-users/access-control/delete-or-suspend-users.mdx`:
- Around line 76-84: The opening sentence "To block a specific identifier from
being used to create new accounts, use one of these workarounds:" is misleading
because these approaches only act after sign-up; update that sentence to
explicitly state these are post-sign-up/workaround enforcement methods (e.g.,
"To prevent access from specific identifiers after sign-up, use one of these
workarounds:") and adjust the three bullets (Workflows, Webhooks, Management
API) to start with phrasing like "Post-sign-up — Use..." or "After sign-up —
Use..." so it's clear they don't prevent initial registration; also slightly
reword the <Aside type="warning"> content to reiterate this is enforcement after
the sign-up event so readers aren't led to expect registration-time blocking.
---
Nitpick comments:
In
`@src/content/docs/authenticate/enterprise-connections/home-realm-discovery.mdx`:
- Line 31: The heading "How Home Realm Discovery works at Kinde?" is awkwardly
phrased—replace it with a concise, properly formed heading such as "How Home
Realm Discovery Works at Kinde" (statement) or "How does Home Realm Discovery
work at Kinde?" (question) by updating the header text in the document where the
heading "How Home Realm Discovery works at Kinde?" appears.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 0d399ab1-2803-43ce-bb1f-581da0aafb33
📒 Files selected for processing (2)
src/content/docs/authenticate/enterprise-connections/home-realm-discovery.mdxsrc/content/docs/manage-users/access-control/delete-or-suspend-users.mdx
src/content/docs/authenticate/enterprise-connections/home-realm-discovery.mdx
Outdated
Show resolved
Hide resolved
src/content/docs/manage-users/access-control/delete-or-suspend-users.mdx
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/content/docs/developer-tools/sdks/native/expo.mdx (1)
58-68:⚠️ Potential issue | 🟡 MinorDuplicate installation instructions create confusion.
The new "Install dependencies" section (lines 60-62) duplicates the existing "Installation with Expo Managed Workflow > Install package" section (lines 66-68). Both install the same
@kinde/expopackage. Consider removing one to avoid redundancy—the<PackageManagers>component in the existing section likely already provides multiple package manager options.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/content/docs/developer-tools/sdks/native/expo.mdx` around lines 58 - 68, Remove the duplicate "Install dependencies" block so there's only one install instruction for `@kinde/expo`; keep the existing "Installation with Expo Managed Workflow" section that uses the <PackageManagers pkg="@kinde/expo" /> component and delete the standalone "### Install dependencies" heading and the npm install snippet to avoid redundancy.
🧹 Nitpick comments (3)
src/content/docs/developer-tools/sdks/native/expo.mdx (1)
155-166: Example import path only covers Expo 53+.The guidance correctly notes different import paths for Expo 51/52 vs 53+, but the example (line 159) only shows the Expo 53+ path. Consider adding an example for Expo 51/52 users who need to import from
@kinde/js-utils:import { getUserProfile, getFlag, getRoles } from "@kinde/expo/utils"; +// For Expo 51 and 52: +// import { getUserProfile, getFlag, getRoles } from "@kinde/js-utils";🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/content/docs/developer-tools/sdks/native/expo.mdx` around lines 155 - 166, Add a second example showing the Expo 51/52 import path: duplicate the existing code block and change the import to import { getUserProfile, getFlag, getRoles } from "@kinde/js-utils"; keep the same example usage (checkUserProfile async function) so users of Expo 51/52 see a concrete import + usage example; ensure both examples are clearly labeled (Expo 51/52 and Expo 53+) and include references to the same helper functions (getUserProfile, getFlag, getRoles) and the useKindeAuth hook where appropriate.src/content/docs/manage-users/access-control/delete-or-suspend-users.mdx (1)
79-80: Clarify webhook limitation for imported users.Consider adding a short note that
user.createddoes not fire for imported users, so this workaround applies to sign-up flows rather than imports.Suggested wording tweak
-- **Webhooks** — Subscribe to the `user.created` event via [webhooks](/integrate/webhooks/about-webhooks/). When a new user signs up with a blocked identifier, call the [Management API](/kinde-apis/management#tag/users/patch/api/v1/user) to suspend or delete them as soon as the event is processed. +- **Webhooks** — Subscribe to the `user.created` event via [webhooks](/integrate/webhooks/about-webhooks/). When a new user signs up with a blocked identifier, call the [Management API](/kinde-apis/management#tag/users/patch/api/v1/user) to suspend or delete them as soon as the event is processed. (Note: `user.created` does not fire for imported users.)🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/content/docs/manage-users/access-control/delete-or-suspend-users.mdx` around lines 79 - 80, Add a short note under the "Webhooks" bullet clarifying that the user.created webhook does not fire for imported users, so the suggested webhook + Management API workaround (subscribe to the user.created event and call PATCH /api/v1/user to suspend/delete) only applies to sign-up flows and not to import flows; place this sentence directly after the "Webhooks — Subscribe to the user.created event…" line and reference "user.created" and the "PATCH /api/v1/user" endpoint so readers know the limitation and the alternative still requires reacting to sign-ups rather than imports.src/content/docs/authenticate/enterprise-connections/home-realm-discovery.mdx (1)
52-58: Consider adding an HRD exception note to theorg_codedocumentation inorgs-for-developers.mdx.The general
org_codedocumentation describes its behavior for organization selection but doesn't mention that it's not supported under home realm discovery. Developers reading that page may miss this limitation. Add a brief note or cross-reference link when documentingorg_codeparameter behavior to flag that HRD users cannot useorg_codeto override organization routing.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/content/docs/authenticate/enterprise-connections/home-realm-discovery.mdx` around lines 52 - 58, Update the orgs-for-developers.mdx documentation for the org_code parameter to explicitly state that org_code cannot override routing when Home Realm Discovery (HRD) is active; add a concise note or cross-reference to the Home Realm Discovery page (home-realm-discovery.mdx) clarifying that HRD routes users to the enterprise connection's configured org based on email domain and therefore ignores org_code, and ensure the note uses the exact term "Home Realm Discovery (HRD)" and the parameter name "org_code" so readers can find the limitation easily.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@src/content/docs/authenticate/enterprise-connections/home-realm-discovery.mdx`:
- Line 31: The heading "## How Home Realm Discovery works at Kinde?" mixes
statement word order with a question mark; fix by either removing the question
mark to make it a statement ("## How Home Realm Discovery works at Kinde") or
rephrasing to a proper question ("## How does Home Realm Discovery work at
Kinde?") — update the heading text in the MDX file so it uses one consistent
form.
In `@src/content/docs/developer-tools/sdks/native/expo.mdx`:
- Around line 453-456: Update the "Version compatibility" text to state that
`@kinde/expo` recommends Expo SDK 53+ for full/optimal utility imports while
noting that SDK 51 and 52 remain compatible but require alternative import
paths, replacing the current "requires Expo SDK 51 or later" wording; also
ensure the file ends with a trailing newline.
---
Outside diff comments:
In `@src/content/docs/developer-tools/sdks/native/expo.mdx`:
- Around line 58-68: Remove the duplicate "Install dependencies" block so
there's only one install instruction for `@kinde/expo`; keep the existing
"Installation with Expo Managed Workflow" section that uses the <PackageManagers
pkg="@kinde/expo" /> component and delete the standalone "### Install
dependencies" heading and the npm install snippet to avoid redundancy.
---
Nitpick comments:
In
`@src/content/docs/authenticate/enterprise-connections/home-realm-discovery.mdx`:
- Around line 52-58: Update the orgs-for-developers.mdx documentation for the
org_code parameter to explicitly state that org_code cannot override routing
when Home Realm Discovery (HRD) is active; add a concise note or cross-reference
to the Home Realm Discovery page (home-realm-discovery.mdx) clarifying that HRD
routes users to the enterprise connection's configured org based on email domain
and therefore ignores org_code, and ensure the note uses the exact term "Home
Realm Discovery (HRD)" and the parameter name "org_code" so readers can find the
limitation easily.
In `@src/content/docs/developer-tools/sdks/native/expo.mdx`:
- Around line 155-166: Add a second example showing the Expo 51/52 import path:
duplicate the existing code block and change the import to import {
getUserProfile, getFlag, getRoles } from "@kinde/js-utils"; keep the same
example usage (checkUserProfile async function) so users of Expo 51/52 see a
concrete import + usage example; ensure both examples are clearly labeled (Expo
51/52 and Expo 53+) and include references to the same helper functions
(getUserProfile, getFlag, getRoles) and the useKindeAuth hook where appropriate.
In `@src/content/docs/manage-users/access-control/delete-or-suspend-users.mdx`:
- Around line 79-80: Add a short note under the "Webhooks" bullet clarifying
that the user.created webhook does not fire for imported users, so the suggested
webhook + Management API workaround (subscribe to the user.created event and
call PATCH /api/v1/user to suspend/delete) only applies to sign-up flows and not
to import flows; place this sentence directly after the "Webhooks — Subscribe to
the user.created event…" line and reference "user.created" and the "PATCH
/api/v1/user" endpoint so readers know the limitation and the alternative still
requires reacting to sign-ups rather than imports.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 328fd7e7-0f06-4edd-8517-7599fb319695
📒 Files selected for processing (3)
src/content/docs/authenticate/enterprise-connections/home-realm-discovery.mdxsrc/content/docs/developer-tools/sdks/native/expo.mdxsrc/content/docs/manage-users/access-control/delete-or-suspend-users.mdx
Description (required)
Related issues & labels (optional)
Summary by CodeRabbit
npm install @kinde/expo), and Expo SDK 53+ compatibility.