Plugin idea: company enrichment (website, industry, size, logo) from open sources #1256

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

A company is entered by name; more of it could be filled from open sources when the person presses for it: website, careers page, industry, size band, founding date, headquarters, a logo. Wikidata and the registers already give part (see #1252); logo fetching is still in core (jobs/logos.py). A company-enrichment kind would let each source be a plugin and let the person choose which fill what.

What to settle

Sources and licences (Wikidata, registers, OpenStreetMap/Nominatim for a place, a company's own /.well-known or schema.org markup, favicon of its site).
The suggestion model: a source offers values with their origin, the person accepts each; nothing is applied silently (the rule of #879) and a typed value is never overwritten.
Logo handling stays as decided in #1238: vector first, the licence of each logo shown.

Wanted

The kind's contract (what a source returns, how the source of each value is shown) and a reference source. Move logo fetching onto it.

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 A company is entered by name; more of it could be filled from open sources when the person presses for it: website, careers page, industry, size band, founding date, headquarters, a logo. Wikidata and the registers already give part (see #1252); logo fetching is still in core (`jobs/logos.py`). A `company-enrichment` kind would let each source be a plugin and let the person choose which fill what. ## What to settle - Sources and licences (Wikidata, registers, OpenStreetMap/Nominatim for a place, a company's own `/.well-known` or `schema.org` markup, favicon of its site). - The suggestion model: a source offers values with their origin, the person accepts each; nothing is applied silently (the rule of #879) and a typed value is never overwritten. - Logo handling stays as decided in #1238: vector first, the licence of each logo shown. ## Wanted The kind's contract (what a source returns, how the source of each value is shown) and a reference source. Move logo fetching onto it. ## 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