fix: stop stripping objectName prefix from record detail URL IDs

[Copilot]

Navigating from a list page to a record detail page shows "Record not found" because RecordDetailView strips the objectName- prefix from the URL recordId before calling findOne. The navigation code puts record._id directly into the URL — no prefix is added artificially — so stripping it truncates backend-generated IDs like opportunity-1772370455623-1 → 1772370455623-1, which doesn't match.

Changes

• RecordDetailView.tsx — Remove prefix stripping; pass URL recordId through as-is
• DetailView.tsx — Add ID format fallback: if findOne returns null, retry with the alternate format (strip or prepend objectName- prefix) for backward compatibility with either ID convention
• RecordDetailEdit.test.tsx — Update expectations to assert findOne receives the full URL recordId

Before/After

URL: /apps/crm_app/opportunity/record/opportunity-1772370455623-1

Before: findOne("opportunity", "1772370455623-1")  → null → "Record not found"
After:  findOne("opportunity", "opportunity-1772370455623-1") → record ✓

The DetailView fallback ensures both ID formats resolve correctly regardless of backend convention:

dataSource.findOne(objectName, resourceId).then((result) => {
  if (result) { setData(result); return; }
  // Fallback: try alternate ID format
  const altId = resourceId.startsWith(prefix)
    ? resourceId.slice(prefix.length)
    : `${prefix}${resourceId}`;
  return dataSource.findOne(objectName, altId)...
});

Original prompt

你是顶牛的低代码企业管理软件设计专家，列表页点击进入记录，详情页报错，请完整的评估，目前的路由及处理流程是否合理？

https://demo.objectui.org/apps/crm_app/opportunity/record/opportunity-1772370455623-1

Record not found
The record you are looking for does not exist or may have been deleted.
Go back

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
objectui	Canceled		Mar 1, 2026 1:30pm
objectui-demo	Ready	Preview, Comment	Mar 1, 2026 1:30pm
objectui-storybook	Ready	Preview, Comment	Mar 1, 2026 1:30pm

[Copilot]

Pull request overview

Fixes record detail navigation failures caused by stripping the objectName- prefix from URL record IDs, while keeping compatibility with mixed ID conventions across deployments.

Changes:

• Stop stripping the objectName- prefix from recordId in the console’s RecordDetailView.
• Add a fallback retry in DetailView to resolve records using either prefixed or unprefixed ID formats.
• Update console tests to assert findOne receives the full URL recordId.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.

File	Description
packages/plugin-detail/src/DetailView.tsx	Adds findOne fallback retry with alternate ID format when the initial lookup returns null.
apps/console/src/components/RecordDetailView.tsx	Stops stripping objectName- from the URL recordId before passing it downstream.
apps/console/src/tests/RecordDetailEdit.test.tsx	Updates expectations to match the new “pass-through” recordId behavior.

Comments suppressed due to low confidence (1)

packages/plugin-detail/src/DetailView.tsx:112

• If the initial findOne call rejects, the catch handler only sets loading to false and leaves data unchanged. If the component previously showed another record, this can incorrectly keep rendering the old record after a navigation/fetch failure. Consider clearing data (e.g., set it to null) in this error path so the UI can transition to the not-found/error state consistently.

      }).catch((err) => {
         console.error('Failed to fetch detail data:', err);
         setLoading(false);
      });

[Copilot]

The new alternate-ID retry logic isn’t covered by the existing DetailView tests (there are tests for the null/not-found state, but none assert that a second findOne call is attempted with the computed alternate ID). Adding a focused test for the retry behavior would help prevent regressions across the supported ID conventions.

[Copilot]

pureRecordId is no longer “pure”/stripped (it’s now the raw recordId). Renaming this to something like resourceId/urlRecordId would reduce confusion for future readers since it’s used for presence/comments thread IDs, DetailView.resourceId, and the onEdit payload.

[Copilot]

With pureRecordId = recordId and the new DetailView fallback that may resolve a record using an alternate ID format, downstream uses of pureRecordId (presence recordId filter, comment threadId, and the onEdit payload) can become inconsistent with the ID that actually exists in the backend (e.g., when the URL uses a prefixed ID but the backend record ID is unprefixed, or vice versa). Consider deriving these downstream identifiers from the resolved record (or querying both threadId/recordId variants for backward compatibility) so edit/comments/presence stay aligned with whichever ID format was found.

[Copilot]

This effect now reads schema.objectName, schema.resourceId, and dataSource (captured into locals here), but the effect’s dependency array doesn’t include schema.objectName or dataSource. If those values change while schema.resourceId stays the same, the fetch won’t rerun and the view can show stale data. Consider updating the effect dependencies (or restructuring the fetch) so it re-triggers whenever the inputs used for findOne change.

[Copilot]

schema.resourceId is typed as string | number in DetailViewSchema, but this fallback logic calls resourceId.startsWith(prefix), which will throw if resourceId is a number. Consider normalizing resourceId to a string (or guarding by type) before using string methods and constructing altId.