Postulo/postulo

Fork 0

Parent and child companies #55

New issue

Closed

opened 2026-09-06 15:46:50 +00:00 by tiagoagueda · 2 comments

tiagoagueda commented

2026-09-06 15:46:50 +00:00

Owner

Observation

for target 0.3.0:
abble to have parent companies and child companies

Why

Applications land at a subsidiary — a national arm, a brand, a studio somebody bought — and
the person applying knows perfectly well that three of them are one group. Postulo does
not: Insights counts three unrelated employers, a rejection from one says nothing about the
others, and searching for the group's name finds none of them.

Shape

One nullable parent on Company, self-referential, owner-scoped like everything
else. A tree rather than a graph: a company has at most one parent, which is what an
ownership structure is, and it keeps every query answerable.
Refuse the obvious mistakes: a company cannot be its own parent, a cycle is refused
with a sentence saying which link would close it, and depth is capped so a mistake cannot
produce a thousand-deep chain.
Where it shows: the company page names its parent and lists its children; the
companies table can group by group; an application shows the group beside the company
when the two differ.
Insights gains the choice of counting by company or by group, which is the reason for
doing any of this.
In the export and the import, resolved by name within the file so a restored archive
keeps its tree.
Wikidata already knows most of these relations (P749 parent organization,
P355 subsidiary) and #42 means many companies already carry a Wikidata identifier — so
suggest the parent is the natural follow-up, and deliberately not part of this. The
relation gets recorded by hand first.

Classification

Enhancement, for 0.3.0. Not breaking: one nullable field.

Depends on

Nothing. #42 only if the Wikidata suggestion is built, and this does not build it.

Open questions

Does a child inherit anything — industries, a logo, notes? Proposal: nothing.
Inheritance is a rule people then have to hold in their heads; showing the parent's name
is enough.
Should a group be a thing of its own rather than a parent company? Proposal: no. A group
with no postings is a company with no postings, and one model is fewer than two.

## Observation > for target 0.3.0: > abble to have parent companies and child companies ## Why Applications land at a subsidiary — a national arm, a brand, a studio somebody bought — and the person applying knows perfectly well that three of them are one group. Postulo does not: Insights counts three unrelated employers, a rejection from one says nothing about the others, and searching for the group's name finds none of them. ## Shape - **One nullable `parent` on `Company`**, self-referential, owner-scoped like everything else. A tree rather than a graph: a company has at most one parent, which is what an ownership structure is, and it keeps every query answerable. - **Refuse the obvious mistakes**: a company cannot be its own parent, a cycle is refused with a sentence saying which link would close it, and depth is capped so a mistake cannot produce a thousand-deep chain. - **Where it shows**: the company page names its parent and lists its children; the companies table can group by group; an application shows the group beside the company when the two differ. - **Insights** gains the choice of counting by company or by group, which is the reason for doing any of this. - **In the export and the import**, resolved by name within the file so a restored archive keeps its tree. - **Wikidata already knows most of these relations** (`P749 parent organization`, `P355 subsidiary`) and #42 means many companies already carry a Wikidata identifier — so *suggest the parent* is the natural follow-up, and deliberately not part of this. The relation gets recorded by hand first. ## Classification Enhancement, for 0.3.0. Not breaking: one nullable field. ## Depends on Nothing. #42 only if the Wikidata suggestion is built, and this does not build it. ## Open questions 1. Does a child inherit anything — industries, a logo, notes? Proposal: nothing. Inheritance is a rule people then have to hold in their heads; showing the parent's name is enough. 2. Should a group be a thing of its own rather than a parent company? Proposal: no. A group with no postings is a company with no postings, and one model is fewer than two.

tiagoagueda added this to the 0.3.0 milestone

2026-09-06 15:46:50 +00:00

tiagoagueda added the

enhancement

label

2026-09-06 15:46:50 +00:00

tiagoagueda referenced this issue

2026-09-09 10:36:56 +00:00

An employer is a tree, and an application attaches to any part of it #138

tiagoagueda added a new dependency

2026-09-09 10:36:57 +00:00

#138 An employer is a tree, and an application attaches to any part of it

tiagoagueda commented

2026-09-09 10:36:58 +00:00

Author

Owner

Extended by #138, which keeps this issue's shape — one nullable self-referential parent, a tree rather than a graph, cycles refused — and adds two things to it: a Department between a company and its contacts (#137), and an application able to say which part of an employer it was aimed at.

This issue is not superseded. The parent-and-child relation is useful on its own and is the piece Insights actually needs; the rest builds on it. Worth noting for whoever picks this up: the open question here about whether a group should be a thing of its own gets a second data point from that issue — a department is not a company with a parent, for the reasons set out there, which is an argument that the answer to question 2 stays no.

Extended by #138, which keeps this issue's shape — one nullable self-referential `parent`, a tree rather than a graph, cycles refused — and adds two things to it: a `Department` between a company and its contacts (#137), and an application able to say which part of an employer it was aimed at. This issue is **not superseded**. The parent-and-child relation is useful on its own and is the piece Insights actually needs; the rest builds on it. Worth noting for whoever picks this up: the open question here about whether a group should be a thing of its own gets a second data point from that issue — a department is *not* a company with a parent, for the reasons set out there, which is an argument that the answer to question 2 stays *no*.

tiagoagueda added the

tier

label

2026-09-09 11:48:54 +00:00

tiagoagueda referenced this issue from a commit

2026-09-09 12:14:14 +00:00

Let a company be part of another one

tiagoagueda commented

2026-09-09 12:46:01 +00:00

Author

Owner

A company can now be part of another, parent pointing at a Company on the same owner's list. Walking up gives the group; walking down gives the descendants, and both are bounded at ten so a cycle somebody makes in the database cannot hang a page. Saving refuses a company as its own parent, refuses a cycle by naming the company that would close it, and refuses a group deeper than ten. The picker leaves out the company itself and everything below it, so the cycle mostly cannot be typed either.

Deleting a parent does not delete its children: SET_NULL leaves them where they are, as companies in their own right, because a company nobody applied to going away must not take the ones they did apply to with it.

The export carries the parent by name rather than by id — an id means nothing in another instance — and the import resolves those names in a second pass, after every company exists, so the order of the file does not decide what survives. FORMAT_VERSION is 5; every earlier format still imports.

Shipped in a3f6f20 on 0.3.0, with main kept level.

A company can now be part of another, `parent` pointing at a `Company` on the same owner's list. Walking up gives the group; walking down gives the descendants, and both are bounded at ten so a cycle somebody makes in the database cannot hang a page. Saving refuses a company as its own parent, refuses a cycle by naming the company that would close it, and refuses a group deeper than ten. The picker leaves out the company itself and everything below it, so the cycle mostly cannot be typed either. Deleting a parent does not delete its children: `SET_NULL` leaves them where they are, as companies in their own right, because a company nobody applied to going away must not take the ones they did apply to with it. The export carries the parent by name rather than by id — an id means nothing in another instance — and the import resolves those names in a second pass, after every company exists, so the order of the file does not decide what survives. `FORMAT_VERSION` is 5; every earlier format still imports. Shipped in `a3f6f20` on `0.3.0`, with `main` kept level.

tiagoagueda closed this issue

2026-09-09 12:46:01 +00:00

tiagoagueda referenced this issue

2026-09-09 12:46:05 +00:00

A department sits between a company and the people in it #137

tiagoagueda referenced this issue from a commit

2026-09-10 05:34:24 +00:00

Let an employer be a structure, and an application name part of it

tiagoagueda referenced this issue

2026-09-10 05:34:58 +00:00

An employer is a tree, and an application attaches to any part of it #138