Postulo/postulo

Fork 0

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

New issue

Closed

opened 2026-09-09 10:36:55 +00:00 by tiagoagueda · 1 comment

tiagoagueda commented

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

Owner

Observation

parent company > child company > departement > person of contact

Prerequisite for the employer-tree plugin. Three of those four exist; the department does
not, and it is the one that changes an existing model rather than adding beside it.

What exists

Contact — "Someone at a company: a recruiter, a hiring manager, a friend on the
inside" — hangs directly off Company through a nullable foreign key, and carries a free
text role. There is no department anywhere in the codebase.

So the structure a person can record today is two levels: a company, and the people at it.
Which team those people are in is either in role ("Engineering — hiring manager"), in
notes, or nowhere.

What this asks for

A department between the two, so that a contact belongs to a team and an application can
name the team it was for.

Worth being careful about

A department is not a small company, and modelling it as one would be tempting. It has
no website, no logo, no identifiers, no industries, and no postings of its own that are not
also the company's. If it is a Company with a parent, then the companies list fills with
things nobody applied to and every count has to learn to exclude them. A separate model is
more code and fewer lies.

Free text already holds this, badly. Some people have been putting the team in role
because there was nowhere else. A department that arrives with no way to promote that text
leaves the data in two places for ever; a migration cannot parse it, but the contact form
can offer it once, beside the new field.

Nullable in both directions, and that is the normal case. Most contacts will never have
a department, and a department with no contacts is perfectly ordinary — it is a team you
applied to before you knew anybody there. Neither side may be required.

Deleting. A department going away must not take its contacts with it: SET_NULL, so the
people survive with their company intact. A company going away already cascades to its
contacts, and departments follow that.

Uniqueness per company, per owner. Two departments called Engineering at one company
is a mistake worth refusing; the same name at two companies is not. Company already has
UniqueConstraint(fields=("owner", "name")) as the precedent.

This is one of the models the plugin would own, so what happens to a department when the
plugin is uninstalled is #128's question and not answerable here.

## Observation > parent company > child company > departement > person of contact Prerequisite for the employer-tree plugin. Three of those four exist; the department does not, and it is the one that changes an existing model rather than adding beside it. ## What exists `Contact` — *"Someone at a company: a recruiter, a hiring manager, a friend on the inside"* — hangs directly off `Company` through a nullable foreign key, and carries a free text `role`. There is no department anywhere in the codebase. So the structure a person can record today is two levels: a company, and the people at it. Which team those people are in is either in `role` ("Engineering — hiring manager"), in `notes`, or nowhere. ## What this asks for A department between the two, so that a contact belongs to a team and an application can name the team it was for. ## Worth being careful about **A department is not a small company, and modelling it as one would be tempting.** It has no website, no logo, no identifiers, no industries, and no postings of its own that are not also the company's. If it is a `Company` with a parent, then the companies list fills with things nobody applied to and every count has to learn to exclude them. A separate model is more code and fewer lies. **Free text already holds this, badly.** Some people have been putting the team in `role` because there was nowhere else. A department that arrives with no way to promote that text leaves the data in two places for ever; a migration cannot parse it, but the contact form can offer it once, beside the new field. **Nullable in both directions, and that is the normal case.** Most contacts will never have a department, and a department with no contacts is perfectly ordinary — it is a team you applied to before you knew anybody there. Neither side may be required. **Deleting.** A department going away must not take its contacts with it: `SET_NULL`, so the people survive with their company intact. A company going away already cascades to its contacts, and departments follow that. **Uniqueness per company, per owner.** Two departments called *Engineering* at one company is a mistake worth refusing; the same name at two companies is not. `Company` already has `UniqueConstraint(fields=("owner", "name"))` as the precedent. **This is one of the models the plugin would own**, so what happens to a department when the plugin is uninstalled is #128's question and not answerable here.

tiagoagueda added this to the 0.3.0 milestone

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

tiagoagueda added the

tier

enhancement

labels

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

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 referenced this issue

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

Parent and child companies #55

tiagoagueda added

tier

and removed

tier

labels

2026-09-09 11:49:14 +00:00

tiagoagueda referenced this issue from a commit

2026-09-09 12:27:02 +00:00

Put a team between a company and the people in it

tiagoagueda commented

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

Author

Owner

Department sits between a company and the people in it: typed on the contact form, reused when the name already exists, cleared by emptying the box.

Deliberately not a company with a parent, though the relation from #55 was right there. A department has no website, no logo, no identifiers, no industries and no postings of its own; modelling it as a company would fill the companies list with things nobody applied to and teach every count to exclude them.

Both ends optional. A department deleted leaves its people where they work; a company deleted takes its departments. A contact cannot borrow another company's department, and saying so is a sentence rather than a silent correction. Fifteen tests.

Shipped in 74b353d on 0.3.0, with main kept level.

`Department` sits between a company and the people in it: typed on the contact form, reused when the name already exists, cleared by emptying the box. Deliberately not a company with a parent, though the relation from #55 was right there. A department has no website, no logo, no identifiers, no industries and no postings of its own; modelling it as a company would fill the companies list with things nobody applied to and teach every count to exclude them. Both ends optional. A department deleted leaves its people where they work; a company deleted takes its departments. A contact cannot borrow another company's department, and saying so is a sentence rather than a silent correction. Fifteen tests. Shipped in `74b353d` on `0.3.0`, with `main` kept level.

tiagoagueda closed this issue

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

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