There's no way to jump from a record in the admin interface to its public detail page, or from a front-end detail page back to the admin record form. Both directions would save time for researchers who work across both interfaces.
Admin → front end ("View on site"): Add a site_url field to the Project model (similar to the existing faircopy_cloud_url). The link would be {site_url}/{lang}/{project_model.slug}/{record.uuid}. The UUID and model slug are already available in the admin's ItemContext and ProjectContext. The change touches core-data-connector (migration) and core-data-cloud (project settings form + button on record page).
Front end → admin ("Edit in FairData"): The front end only has UUIDs, but admin URLs use integer IDs. The cleanest approach: add a UUID-based redirect route in the admin (e.g., /projects/:projectId/records/:uuid resolves the record and redirects to the correct page). The front end constructs the link from config.core_data.url and the record UUID.
This link should only be visible to logged-in users. Clerk is currently only loaded in the TinaCMS admin panel, not on public pages. It would need to be loaded on detail pages (not every page) to check session state client-side. If the user is already logged into Clerk, the button appears; otherwise nothing is rendered.
Front end → FairCopy ("Edit in FairCopy"): On detail pages that display text from a TEI document, a FairData record may carry a FairCopy document identifier. If so, an additional "Edit in FairCopy" button could open the document in the FairCopy desktop editor. This would also be gated on Clerk auth. Needs investigation into how FairCopy handles deep links from the browser to the desktop app.
The changes touch core-data-cloud (redirect route), core-data-connector (migration for site_url), and core-data-places (load Clerk on detail pages, conditionally render edit buttons).
There's no way to jump from a record in the admin interface to its public detail page, or from a front-end detail page back to the admin record form. Both directions would save time for researchers who work across both interfaces.
Admin → front end ("View on site"): Add a
site_urlfield to the Project model (similar to the existingfaircopy_cloud_url). The link would be{site_url}/{lang}/{project_model.slug}/{record.uuid}. The UUID and model slug are already available in the admin'sItemContextandProjectContext. The change touches core-data-connector (migration) and core-data-cloud (project settings form + button on record page).Front end → admin ("Edit in FairData"): The front end only has UUIDs, but admin URLs use integer IDs. The cleanest approach: add a UUID-based redirect route in the admin (e.g.,
/projects/:projectId/records/:uuidresolves the record and redirects to the correct page). The front end constructs the link fromconfig.core_data.urland the record UUID.This link should only be visible to logged-in users. Clerk is currently only loaded in the TinaCMS admin panel, not on public pages. It would need to be loaded on detail pages (not every page) to check session state client-side. If the user is already logged into Clerk, the button appears; otherwise nothing is rendered.
Front end → FairCopy ("Edit in FairCopy"): On detail pages that display text from a TEI document, a FairData record may carry a FairCopy document identifier. If so, an additional "Edit in FairCopy" button could open the document in the FairCopy desktop editor. This would also be gated on Clerk auth. Needs investigation into how FairCopy handles deep links from the browser to the desktop app.
The changes touch core-data-cloud (redirect route), core-data-connector (migration for
site_url), and core-data-places (load Clerk on detail pages, conditionally render edit buttons).