Plugin idea: import and export formats (LinkedIn data, JSON Resume, CSV mappings, other trackers) #1260

New issue

Open

opened 2026-11-13 10:51:54 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-11-13 10:51:54 +00:00

Owner

Idea

People arrive from somewhere: a LinkedIn data export, a JSON Resume file, a spreadsheet, another tracker's export (Huntr, Teal, Notion tables). The importer kind exists and Europass is a plugin; each of these would be a plugin that reads the file and proposes records to the person, as the Europass import does, and an export to the same formats where they are open.

What to settle

Formats with a documented structure and a licence that allows reading them; the person's own export only, never a scraped page.
The preview-then-accept flow of the existing importers: nothing is saved before the person sees what will be created and what it matches (duplicates, merges).
What cannot be mapped is listed, not dropped silently.

Wanted

A ranked list of formats with a sample of each, and a reference importer for JSON Resume and for the LinkedIn data export.

Rules that apply to every plugin

Off until the person enables it; a plugin that calls a service names the host and the data it sends in its manifest and on the consent screen (plugins/consent.py); nothing is fetched on page load.
Core keeps no import of it: the application runs with it absent, and data it created stays readable as plain data when it is removed.
The plugin surface (plugins/api.py, the published postulo.plugins.testing check) gets a contract test for any new kind; the plugin ships its own translation catalogues (the plugin locale rule); strings go through Weblate only.
Its own repository if it is not bundled (see the plugin repositories and #1170's shared CI).

Filed as an idea after a discussion on plugin kinds, with #1252 (reference data and lookups as plugins). Not started; the maintainer decides if and when.

## Idea People arrive from somewhere: a **LinkedIn data export**, a **JSON Resume** file, a spreadsheet, another tracker's export (Huntr, Teal, Notion tables). The importer kind exists and Europass is a plugin; each of these would be a plugin that reads the file and proposes records to the person, as the Europass import does, and an export to the same formats where they are open. ## What to settle - Formats with a documented structure and a licence that allows reading them; the person's own export only, never a scraped page. - The preview-then-accept flow of the existing importers: nothing is saved before the person sees what will be created and what it matches (duplicates, merges). - What cannot be mapped is listed, not dropped silently. ## Wanted A ranked list of formats with a sample of each, and a reference importer for JSON Resume and for the LinkedIn data export. ## Rules that apply to every plugin - Off until the person enables it; a plugin that calls a service names the host and the data it sends in its manifest and on the consent screen (`plugins/consent.py`); nothing is fetched on page load. - Core keeps no import of it: the application runs with it absent, and data it created stays readable as plain data when it is removed. - The plugin surface (`plugins/api.py`, the published `postulo.plugins.testing` check) gets a contract test for any new kind; the plugin ships its own translation catalogues (the plugin locale rule); strings go through Weblate only. - Its own repository if it is not bundled (see the plugin repositories and #1170's shared CI). Filed as an idea after a discussion on plugin kinds, with #1252 (reference data and lookups as plugins). **Not started; the maintainer decides if and when.**

tiagoagueda added the

enhancement

label

2026-11-13 10:51:54 +00:00