Insights / Technical notes

Import Profile Details as a Draft: Compare, Select, and Publish Deliberately

A generalized profile-import flow for text, CSV, static HTML, and shared JSON. Learn how it compares current values, lets people replace selected fields or undo changes, and keeps saving separate from publication.

  • Web
  • Import
  • Security
Import Profile Details as a Draft: Compare, Select, and Publish Deliberately
Table of contents
  1. Test preservation of edits with one biography field
  2. Choose supported input formats first
  3. Review candidates before replacing existing values
  4. Separate common JSON from service-specific support
  5. Do not infer qualifications or rights from imported text
  6. Keep saving and publication as separate decisions
  7. Related update: open HTTPS links from public calendar events
  8. What was verified and what comes next

When moving an existing profile into another editor, compare the current values with the import candidates before replacing anything. This anonymized example explains the boundaries between importing data and publishing a profile.

Test preservation of edits with one biography field

Manually edit an existing biography, then import a different candidate. Check that unselected fields remain, selected replacements can be reviewed, and cancellation restores the original. After applying, compare the draft with the public page to verify that importing alone does not change publication.

OWASP:Validating input format, values, and length

Choose supported input formats first

Alongside the original text, CSV, and static HTML paths, the flow now reads a shared JSON file and provides a downloadable template. Parsing pasted content or a file is different from visiting a URL to retrieve its contents. Service-specific export formats, automatic URL retrieval, image and audio migration, dynamic pages, and external-service APIs are not complete.

Treat HTML as input data. Do not execute scripts or render the imported HTML itself on the public page. Limit text length, fields, links, and input formats, then convert the source into text candidates suitable for a profile.

Review candidates before replacing existing values

Do not publish parsed results immediately. Compare them with current values first. The owner selects fields one by one and can edit candidate values before applying them to the editor. Applying a selected field replaces its current value, so review the differences on every import. The change can also be undone. These controls do not guarantee that conflicts with edits made elsewhere or by another person will be resolved automatically.

Separate common JSON from service-specific support

The interface shows support status for 7 activity services. Reading data in the shared format does not mean the flow can fetch a profile directly from each service URL. For unsupported URLs, it directs people to import by pasting content instead. A status list for all 7 services does not mean that dedicated exports or API integrations have been implemented for each one.

Synthetic data was used to check JSON import, comparison with existing values, applying selected fields, undo, and the mobile layout. Acceptance from import through save and publication in a real account still needs a separate check.

Do not infer qualifications or rights from imported text

Wording in a bio or on an external page does not establish a qualification, affiliation, category, or licence by itself. Keep descriptive text that can be imported as a candidate separate from information that requires identity checks or an application. Changes to external information do not automatically update or publish a profile the owner has confirmed.

Keep saving and publication as separate decisions

Applying import candidates, saving a draft, and updating the public snapshot are separate actions. Save conflicts also need acceptance testing; a successful save does not mean the profile has been published. Have the owner review links, including public calendar URLs, before making those values public, and keep private notes out of public data.

A separate editing update, independent of profile import, adds HTTPS links to public calendar events. An event opens its destination directly in a new tab. Events without a URL remain visible without an actionable link. Validate the URL format, reject embedded credentials, and limit input length. Add noopener noreferrer and include the new-tab behavior in the accessible name.

The related forms also remove an unnecessary title field for collaboration availability slots and fields for private notes. Database changes, CI, production deployment, and screens using verification data were checked. Acceptance by an owner signing in, saving an actual event, and publishing it remains unverified.

Boundaries for imports and calendar links These are separate editor functions. Logged-in acceptance of saving and publishing remains unverified.
  1. Profile import The user reviews and edits supported formats. Saving and publishing are separate actions.
  2. Public calendar link Open an HTTPS link in a safe new tab. Events without a link remain non-interactive.

What was verified and what comes next

Implementation, integration, and production deployment were confirmed for text, CSV, static HTML, and shared JSON import. An end-to-end test by a real user—from import through editing and saving to checking the published result—has not been completed. The broader idea of automatically building a full profile from an activity-service URL is not complete.

For boundaries around published CSS, see Safe user CSS and versioned public themes. For login boundaries, see Session lifecycles across services.