Company social profiles: LinkedIn builds a person's /in/ address instead of /company/ #932

New issue

Closed

opened 2026-10-15 17:41:47 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-10-15 17:41:47 +00:00

Owner

On a company's social profiles, choosing LinkedIn puts https://www.linkedin.com/in/ in front of the name. A company's LinkedIn page lives under https://www.linkedin.com/company/, so the address the row builds is a person's profile and leads nowhere.

What exists today

One prefix for every holder. src/postulo/plugins/link_services/services.py declares the LinkedIn LinkService with a single prefix="https://www.linkedin.com/in/" (#678). The row asks for the name alone and puts that prefix in front of it, whoever owns the row.
Company pages are already recognised. The service's path pattern accepts /in/, /pub/, /company/, /school/ and /showcase/ addresses. The comment beside it says a company, school or showcase page "stay[s] a stored address, or Other". That held while only people had social profiles. Since #906, companies have them too, and the person's prefix is offered to a company.
Identifiers already make the distinction. The LinkedIn identifier scheme (src/postulo/plugins/identifiers/schemes.py) has link="https://www.linkedin.com/company/{value}/" for a company and person_link="https://www.linkedin.com/in/{value}/" for a person.

What would change

A prefix per kind of holder. LinkService gets a prefix per kind of holder, mirroring link and person_link on Scheme: a person's prefix and a company's. For LinkedIn these are https://www.linkedin.com/in/ and https://www.linkedin.com/company/. The row offers the one that matches who owns it.
Other services check theirs too. Any other service whose company pages live under a different path gets the same treatment, and the service list should be checked for this.
Existing addresses are recognised as they are. A company row that already holds a full /in/ address, or a /company/ address stored as typed, is still recognised. Nothing stored is rewritten.
Tests. A company's LinkedIn row builds /company/name, a person's builds /in/name, and both still recognise each other's full addresses when pasted.

On a company's social profiles, choosing LinkedIn puts `https://www.linkedin.com/in/` in front of the name. A company's LinkedIn page lives under `https://www.linkedin.com/company/`, so the address the row builds is a person's profile and leads nowhere. ## What exists today - **One prefix for every holder.** `src/postulo/plugins/link_services/services.py` declares the LinkedIn `LinkService` with a single `prefix="https://www.linkedin.com/in/"` (#678). The row asks for the name alone and puts that prefix in front of it, whoever owns the row. - **Company pages are already recognised.** The service's path pattern accepts `/in/`, `/pub/`, `/company/`, `/school/` and `/showcase/` addresses. The comment beside it says a company, school or showcase page "stay[s] a stored address, or *Other*". That held while only people had social profiles. Since #906, companies have them too, and the person's prefix is offered to a company. - **Identifiers already make the distinction.** The LinkedIn identifier scheme (`src/postulo/plugins/identifiers/schemes.py`) has `link="https://www.linkedin.com/company/{value}/"` for a company and `person_link="https://www.linkedin.com/in/{value}/"` for a person. ## What would change - **A prefix per kind of holder.** `LinkService` gets a prefix per kind of holder, mirroring `link` and `person_link` on `Scheme`: a person's prefix and a company's. For LinkedIn these are `https://www.linkedin.com/in/` and `https://www.linkedin.com/company/`. The row offers the one that matches who owns it. - **Other services check theirs too.** Any other service whose company pages live under a different path gets the same treatment, and the service list should be checked for this. - **Existing addresses are recognised as they are.** A company row that already holds a full `/in/` address, or a `/company/` address stored as typed, is still recognised. Nothing stored is rewritten. - **Tests.** A company's LinkedIn row builds `/company/name`, a person's builds `/in/name`, and both still recognise each other's full addresses when pasted.

tiagoagueda added the

bug

interface

labels

2026-10-15 17:41:53 +00:00

tiagoagueda referenced this issue

2026-10-16 13:22:16 +00:00

Phones, addresses and social profiles: one behaviour for companies, contacts and Your details #934

tiagoagueda referenced this issue from a commit

2026-10-18 18:04:25 +00:00

Link services: a company's LinkedIn row builds /company/, not /in/

tiagoagueda referenced this issue from a pull request that will close it,