6d006e55fe133e81d8aa1ddf431497d2a740056f
163 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| 917911457e |
Stop the seed handing out addresses that look like real ones
Every employee address in the database sat on test.manner.at, a domain that reads like a company one. employees.email is the *private* address, so an address shaped like a company mailbox invites being taken for one — and eventually being written to. All 856 rows now sit on privat.alpenwerk-test.at, rebuilt from first and last name, and the seed generates the same domain so a reseed does not bring the old one back. Umlauts are spelled out the way they are here (Höller becomes hoeller), other accents are flattened, and where two people share a name the personnel number is appended. The first attempt got this wrong in a way worth recording. It wrote ma<number>@ for all 856 rows instead of the intended name form, and the check I had built only asked whether the results were unique and well-formed — which they were. Two defects, both invisible to that check: '\.+' inside a SQL literal was read as "any character, one or more" and collapsed the whole local part to a single dot, and the replacement string for the accent mapping had one character too many, so the mapping was shifted. The fix uses '[.]+', a character class needing no escape at all, so it no longer depends on how the connection treats backslashes. Untouched on purpose: app_users.email and profiles.email are the sign-in accounts, and rewriting those would lock people out. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| 64eb155dda |
Write down what is actually in the database
The one document describing the schema, docs/data-model.md, predates two rebuilds. It names divisions/departments/teams and a positions table that no longer exist, describes Supabase auth with an anon key and a service role that were removed, and puts the policy count at 58 when it is 21. Anyone reading it to understand the data would have been misled on every count. docs/datenkatalog.md replaces it, and was not typed up from memory: the columns, defaults, keys and check constraints were read out of information_schema and pg_catalog on the running database. Fifteen tables, 142 columns, ten enum types, 21 policies. Where a rule appears in prose, the constraint it comes from is named next to it. Some of it only became visible by asking the database rather than the migrations. generate_company_email and the is_hr_admin pair are still defined but nothing calls them any more. Position numbers look like a six followed by seven digits because the generator builds them that way, not because anything enforces it — the column requires only uniqueness. monthly_salary_gross is dead weight kept in case old rows hold data. Three claims I drafted were wrong and the database said so: the position number format, the event trigger's name (ensure_rls, the function behind it is rls_auto_enable), and which tables deviate from the plain is_hr_user() policy. The old document keeps a pointer at the top instead of being deleted — it is linked from the security review, and a stale document that says so is more useful than a dead link. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| 0b8f874fa5 |
Let the export select on everything the data model holds
The export offered four criteria — unit, location, status, employment type — while the employee record carries around twenty selectable attributes. Anything else had to be filtered by hand in Excel afterwards, which is how a payroll hand-off stops matching the application it came from. All of them are now filters: contract type, blue/white collar, collective agreement, paygrade, internal/external, gender, company car and its drivetrain, works council, lateral leadership, C-level, type of long-term absence, weekday worked, dependents on file, and open ranges for entry, exit, birth date and weekly hours. The unit filter covers every level rather than only divisions, so a single department can be selected without going the long way round. They live in one table in lib/report-criteria.ts, which the filter panel builds itself from, the parser validates against, and the query turns into conditions. A new criterion is one entry there and nothing else — and it cannot end up working in the report while being silently ignored by the export. The two export links and the saved-report config now carry the query string through as it stands instead of listing the parameters they know about. That enumeration was the actual defect: adding a filter meant remembering three separate places, and forgetting one produced an export that quietly disagreed with the figure on screen. Validation is not housekeeping here. These values reach SQL comparisons and the download filename, i.e. a Content-Disposition header; what is not in the list does not get through. The company car dropdown leaves the employee list. It is one of twenty equals under Berichte now, where the selection can also be exported — which was the point of asking in the first place. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| f14f1cb8df |
Keep the org chart inside the page it is printed on
Six divisions, each with its departments beside it, ran off the edge of the sheet. The cause was structural, not cosmetic: every level spread horizontally, so width multiplied with depth. Six divisions times three departments is eighteen boxes across a landscape A4 — about two millimetres each, if they had fitted at all, which they did not. They overlapped and were clipped at the margin. Now only one level spreads sideways. The divisions stand in a row and everything below them hangs lengthwise off a vertical line, so width is the number of divisions and nothing else. Depth costs height instead, and on a landscape page height is what there is to spare. What still overhangs is scaled down as a whole. The sheet in the preview now carries the print area's exact dimensions rather than growing with its contents, so the fit is measured against the real page: what you see is what the printer gets. If a sheet has to shrink below 55% to fit, it says so and points at A3, instead of quietly producing something nobody can read. With names switched on, each department gets its own sheet — a whole division with every name was never going to be legible on one page — and long name lists set in two columns so the box grows sideways rather than pushing the scale down. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| 3151f32404 |
Print the org chart as an org chart, and ask first what to print
The chart on screen is an infinite canvas: you zoom in, drag around, and look at one corner at a time. Paper has none of that. Printing the canvas means scaling 850 people onto one sheet, which yields boxes two millimetres wide — technically the whole company, practically nothing. So the print view is rebuilt rather than shrunk, and it does two things the canvas cannot. It asks before it prints. Depth (bereiche, abteilungen, teams, or teams with every name) and which divisions, each one selectable. Whoever needs Produktion for a meeting gets two sheets instead of forty, and the page count is on the button before anything reaches the printer. And it draws the hierarchy as a hierarchy: boxes joined by connecting lines, not a column of cards. Superior and subordinate are the entire point of an org chart; a tidy list of the same units simply does not say it. The lines come from borders on pseudo-elements, so the PDF keeps them as vectors and they stay sharp when someone zooms in. Header shading gets weaker with each level down, which survives the black-and- white printer that most of these end up on. Overview sheet first, then one sheet per selected division, each carrying its own heading and headcount so page seven is still readable on its own. A4 or A3, landscape. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| c23df08648 |
Ask for the optional things separately, and stop claiming numbers are issued
A round of interface corrections from use, plus one schema change behind them. The private email address is now optional. It was NOT NULL — the wrong default for a private detail: someone without one had to invent one, and invented data in a personnel file is worse than missing data. Both fields are relabelled to say whose they are, "Private E-Mail" and "Private Telefonnummer", because the company address does not exist until the person starts. Uniqueness stays; several NULLs coexist in a Postgres unique index, which is exactly what is wanted. The summary step still promised that "Personalnummer und Firmen-E-Mail-Adresse werden automatisch vergeben". Neither is true any more. Removed rather than reworded — the step lists what was entered, and a banner claiming otherwise is worse than no banner. Dependents move into the wizard as step three, optional. They can only be attached after the hire, because add_employee_dependent needs an id that does not exist while the form is open, so they are collected in the draft and written afterwards. That puts them outside the transaction the person is created in: if one fails the person still exists, so the message names who is missing instead of failing silently, and the SV number is checked in the step rather than after. The emergency contact gets its own step, second to last, and its relationship is a dropdown of the common ones rather than free text — otherwise "Gattin", "Ehefrau" and "Frau" end up side by side and nothing can be counted. "Sonstige" is there because a closed list would otherwise be presumptuous. On the master-data tab it now sits below the dependents rather than above: both are people around the employee, and this is the one you reach for in a hurry. Returning from a long absence: the choice read "unverändert", which made you open the file to find out what you were agreeing to. It now reads "Wie vor Abwesenheit (38,5 h)" with the hours actually worked, and the alternative is "Reduziert" — whose hours field starts empty on purpose. A number already filled in gets confirmed rather than read off the agreement it comes from. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| 4eba557121 |
Show every field the edit dialog can change
The master-data tab summarised where the edit dialog itemises. Titles were
collapsed into one line, street, postcode and town were fused into a single
"Adresse", and first and last name appeared only in the page header — so
checking a value meant opening the change dialog to see it, which puts you
inside a form when you only wanted to look.
The tab now mirrors the dialog's "Person" section field for field and in the
same order, personnel number included.
Two deliberate departures from a literal mirror:
- Standort sits at the end rather than between Adresse and Land. It is the
workplace, not part of the person's address, and next to the postal
fields it reads as though it were.
- The emergency contact keeps the separate block it got earlier today,
with its phone number as a tel: link. In an emergency someone reaches
for it in a hurry; it should not be one cell among fourteen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
|||
| 9d754359e0 |
Enter the personnel number, tell the two kinds of company car apart, record who to call
Three requests from use, one of which changes the schema's mind about
something.
The personnel number is no longer issued. It was GENERATED ALWAYS AS
IDENTITY, which refuses a supplied value outright — but it has to match Loga
and Interflex, and a number this application invents is unknown there, so the
same person ends up with two. Identity dropped, entered everywhere instead:
in the wizard, in the import, and validated against a duplicate with a
message that names the number.
Worth stating plainly: the column had no unique constraint. The identity
prevented collisions as a side effect, and once the value comes from outside
that side effect is gone. The constraint is the point now, and it was
missing.
Company cars distinguish Verbrenner from Elektro, tied to has_dienstwagen by
a CHECK so "E-KFZ" cannot appear against someone without a car. The list
filters on it — with, without, only electric, only combustion — which is the
question the report was really about; it was answerable before only through
an export and manual work.
Emergency contact is name, phone and relationship. Relationship stays free
text: the examples given — Gattin/Gatte, Schwester/Bruder, Freund — are not
a list that closes without telling someone their arrangement does not count.
Name and phone are all-or-nothing, in the database and in both forms: a name
without a number helps nobody, a number without a name does not say who
answers.
Two mistakes of mine on the way, both caught by checks I had written into
the migrations rather than by me:
- The first CHECK on the car type would have permitted exactly the case it
was written against. `art in (…)` yields NULL rather than false when the
column is null, and a CHECK counts NULL as satisfied. It needs an
explicit `is not null` in front.
- The constraint was added before the backfill, so it rejected every
existing row with a car.
Existing cars are recorded as Verbrenner, which is an assumption — but a
visible one: "Elektro" appears nowhere nobody confirmed it.
hire_employee and change_employee_data both had to learn the new columns.
They name their columns one by one, and what is missing there is dropped in
silence — the interface would have collected the fields and thrown them
away, which is what happened to the email address this morning.
Verified against the live database, all rolled back: a hire without a number
is refused, a duplicate is refused naming it, a freely chosen one goes
through; E-KFZ plus contact arrive intact; a contact without a phone is
refused. A change records both, with before and after in the audit detail.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
|||
| 53d5d41784 |
Search a name by any of its words, in any order
Reported from use: typing "Winkler micha" suggests there is no Winkler at all, when there are fourteen. The search compared the whole term against each field separately, so a two-word entry matched nothing — neither the first name nor the last name contains "Michael Winkler" as a string. Both orders failed; the report noticed one of them. The term is now split on whitespace and every word must match somewhere. That is more than was asked — the request was to search surname first — but reversing the expected order only mirrors the problem: you would still have to remember which way round it goes. "Winkler kath" and "kath Winkler" both find the two Katharina Winklers now, and "Winkler Produktmanager" finds the two in that job. Matching runs against the concatenated name rather than the separate columns, because that is exactly what idx_employees_name_trgm indexes. The old query could not use it. A second defect in the same block: the personnel-number branch tested /^d+$/ — a missing backslash, so it matched strings of the letter d and never a number. Searching "3488" fell through to the name search and found nothing. It now reaches Peter Bauer. Verified against the live database, before and after, for both orders and for a plain surname, which still returns all fourteen. One thing the report's screenshot cannot show any more: there is no Michael Winkler in the current data. The database was reseeded, and those names are from the previous set — worth knowing before checking with that exact name. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| f28fd2da60 |
Let a rehire choose the position, and make it work at all
Clicking "Wiedereinstellen" could never succeed. rehire_employee has always
demanded a position and refuses without one, but the panel offered only a
date and sent only a date — so every rehire ended on an error the dialog
gave no way to fix.
The panel now picks from the open positions, the same list and layout the
transfer panel uses, and warns before submitting when the date falls outside
the chosen position's validity. The old position is deliberately not a
silent default: it may since have been filled, ended, or gone.
Behind that sat a second fault, hidden by the first: the status assignment
status = case when v_date <= current_date then 'Aktiv' else 'Geplant' end
is text, and the column is employment_status. Postgres refuses that outright,
so the function would have failed even with a position. It surfaced only once
the earlier check stopped firing — the same pattern as hire_employee this
morning, where three faults sat in a queue.
rehire_employee also placed people without checking anything. It now applies
the rule from 20260810100000: the date must lie in the position's validity,
and no assignment may still stand. A rehire could otherwise land on an
occupied position and be caught by the partial index, with a message that
explains nothing.
My first verification of the cast was wrong and passed a broken state:
plpgsql converts silently when assigning to a variable, so the probe proved
nothing. Redone as an UPDATE against a column, which is the case that fails.
Verified end to end against the live database, rolled back: Stefan Egger
returns as Aktiv on a free position, with the assignment and the
Wiedereintritt entry. Without a position, on an occupied one, and on one not
yet valid, it is refused — each with its own message.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
|||
| 27e0e8a8ce |
Ask for someone's organisation on a day they actually have one
An employee starting 01.09. showed "Keine Führungskraft (Geschäftsführung)" although their team has one — Josef Bauer, on chief position 60000752. The reporting line was requested as of today, and today that person holds no assignment, so om_reporting_lines() returned no row at all. The database function was right; the caller asked the wrong question. What made it look like a data problem rather than a date problem: the header did show the unit and the position, because pickPlacements() falls back to the next best assignment when none is current. Two notions of where someone sits — one forgiving, one strict — sitting next to each other on the same page. orgAsOf() pulls the date into the employment: the first day for someone not yet started, the last for someone who has left, today otherwise. Exit dates are exclusive throughout the model, so the last working day is the day before. Anyone already gone had the same defect for the same reason, which is why the rule covers both ends rather than special-casing the case that was reported. Verified against the live database: as of today no row, as of 2026-09-01 the manager is Josef Bauer. Six unit tests over the boundaries, checked by mutation — remove the future-entry branch and one fails. Open positions still resolve as of today: they belong to the organisation, not to the person whose file is open. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| 92685f0ac0 |
Only staff a position while it exists
hire_employee and transfer_employee checked whether the position was free,
never whether it was there. Someone could be hired today onto a position
that starts in October, or onto one that lapsed in spring: the assignment
sat in the database while the position was absent from the org chart, and
the person hung off a structure that did not exist on their entry date.
That stopped being theoretical when the positions view began showing future
positions — they now appear in the same picker the hire wizard uses. This is
the rule that makes showing them safe.
The date of the assignment must fall in [valid_from, valid_to). valid_to is
exclusive throughout the model, as in lib/positions.ts.
Second correction in the same place: occupancy only looked at assignments
with an open end, so one ending later was invisible and the position could
be double-booked — the same gap the vacancy list had.
And a defect the verification exposed rather than the report: the work_days
default in hire_employee never applied. `array(select …)` over a missing key
yields an empty array, not null, so coalesce kept `{}` and the CHECK
constraint refused the row. Invisible through the wizard, which always sends
them and will not proceed without — but a default that defaults to nothing
is worse than none, because it reads as though the case was considered.
Verified against the live database, all rolled back: a hire onto a future
position is refused naming the date it begins, a transfer likewise, a hire
onto a currently valid one succeeds — and now also succeeds without
work_days, arriving with Mo–Fr.
The migrations match on a pattern rather than literal text: the function
bodies carry CRLF, and a literal search would have found nothing while the
migration reported success. Both refuse to proceed if the pattern matches
nothing.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
|||
| d8a1fdf43b |
Reinstate the Vercel build settings
Reverts |
|||
| 780f8fe2b7 |
Write down what an internal deployment actually needs
The target is a VM inside the company network, reachable only from there. Two consequences decide whether this works at all, and both are easy to discover too late — after the firewall rules are already written. The server needs outbound access even though nothing comes in. Auth.js exchanges the authorisation code for a token server-side and fetches the issuer's configuration, so login.microsoftonline.com must be reachable from the VM; the database likewise. That the person signs in through their own browser is not enough, which is the assumption worth naming before someone builds a closed network around it. HTTPS is not optional either: Entra accepts http only for localhost. The practical route without public reachability is a public DNS name pointing at a private address and a certificate obtained through the DNS challenge — allowed, common, and it yields a normally trusted certificate while the server stays unreachable from outside. deploy/Caddyfile does that, and the alternative (self-signed, trusted on every workstation) is written down with its cost. docker-compose now publishes port 3000 on 127.0.0.1 only. It was on every interface, so the same service also stood there unencrypted, and one gap in the firewall was enough. The proxy is the only way in. AUTH_URL is documented for the same reason a comment sits in the Caddyfile: behind a proxy the container does not see the name the browser used, and the callback would point somewhere nobody can reach. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| 56662c0775 |
Describe what is actually deployed, now that the target is a Linux server
The revert restored three statements that stopped being true earlier today. "Nicht containerisiert: Supabase (Datenbank + Auth)" — authentication is no longer Supabase, it is Entra ID with an Auth.js session cookie, and the database is any PostgreSQL 15 or later reached through DATABASE_URL. Supabase is one option among several now, not the architecture. The CI/CD note told the reader to pass --build-arg values for NEXT_PUBLIC_*. Those variables no longer exist and the Dockerfile stopped taking build arguments today. Following it would produce a puzzling failure; the point now is the opposite one, that no build arguments are needed at all and the same image runs everywhere. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| 61ccce5456 |
Revert "Make the build fit Vercel without breaking the container"
This reverts commit
|
|||
| ecbda3f3a5 |
Make the build fit Vercel without breaking the container
Two settings were wrong for a platform build. output: "standalone" tells Next.js to emit a self-contained server, which is what the Dockerfile copies in — and what Vercel neither needs nor expects, since it builds and packages the app itself. It is now conditional on the VERCEL variable, which every build there sets, so each path gets what it wants. Verified both ways: with VERCEL=1 no standalone directory appears, without it one does. /api/import declared maxDuration = 120. The free tier caps at 60 and refuses anything higher, so the deployment would have failed on a value chosen for a self-hosted server. Lowered, with the reason and the Pro ceiling written next to it. DEPLOYMENT.md now covers both paths, and says plainly that the repository cannot be connected: git.elycon.solutions is self-hosted, and Vercel's git integration only speaks GitHub, GitLab and Bitbucket. Deploying from the workstation with the CLI works with any repository and is the shorter road; mirroring to GitHub is written down as the alternative, with its cost — two remotes to keep in step. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| 27cfd6431f |
Let a second person be activated at all
profiles.id referenced auth.users. Sign-in goes through Auth.js now and creates nothing there, so a new colleague could sign in, receive an app_users row, and then be impossible to authorise: the profiles row needed to grant HR access could not be inserted. She would see "Kein HR-Zugriff" with no way to change it. All eight foreign keys in the public schema now point at app_users, walked from the catalogue rather than written out — their names come from different migrations and one transcribed wrongly means it silently stays behind. The delete behaviour is preserved: profiles still cascades from the account, audit and note fields do not, because an entry must not vanish when an account is removed. Every referenced value was already present in app_users, so nothing moved; only the guarantee changed. A backfill from profiles runs first anyway, for copies of this database where someone created something in between. The check at the end does the thing that matters: it creates a second account with a profile and removes it again. Counting constraints would have passed while the actual case still failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| 0d8af7cdf0 |
Refuse a save that changes nothing instead of reporting success
update_position returned quietly when no field differed, and the interface answered "Planstelle geändert." — a confirmation for something that had not happened. It now raises, and the message says so. This is reachable without the user doing anything wrong: the chief checkbox is dropped on the way out when the unit already has a chief position, so a save consisting only of that tick arrives as an empty change set. The reply was a green toast and an unchanged list, which sends someone looking in the wrong place. It also separates the two explanations for "I saved and nothing happened", which is why it went in now: an empty change set is refused in red, so a green confirmation with a stale card can only mean the page did not reload. Verified against the live database: an unchanged payload is refused, a changed one goes through. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| a87c688c0a |
Show positions that do not exist yet, and let them be corrected
Two gaps in the positions view, both reported from use.
A position dated into the future was invisible. loadOpenPositions required
valid_from <= today, so a position decided now and effective at the quarter
boundary appeared nowhere until the day it began. The database already held
one — 60000824 "Neue Position", effective 01.09. — created through the
application and shown on no screen since.
Future positions now have their own section rather than joining the vacancy
list. They are a different statement: "nobody is here" and "this does not
exist yet" should not be counted together, and a position starting 01.10.
read as a vacancy nobody was filling.
Positions could only be created and deleted. Fixing a typo in the job title
meant deleting and recreating — with a new position number, which appears in
job postings, budgets and audit entries, and whose trail then breaks.
update_position keeps the number and records old and new values per field,
using the audit detail added earlier today.
Three things it refuses, as guards rather than remarks:
- Moving an occupied position to another unit. That is a transfer, with
history and reporting line, and belongs to the person — otherwise
someone changes department silently.
- Ending an occupied position, which would leave an assignment without
one.
- A second chief position in a unit, or an end before the start.
Verified against the live database, all rolled back: each guard fires with
its own message, the permitted edits go through, the audit entry carries the
changed fields. Open positions stay at 9 and the future one now appears in
its own section.
ESLint caught me priming the dialog's fields from an effect. Replaced by a
key on the component, so React rebuilds it per position and the fields
initialise from props — which also removes the flash of the previous
position's values on second open.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
|||
| e44f71a60d |
Stop offering positions that are already spoken for, and let hiring work again
Two reports, four defects, all of them in the way of ordinary use.
A position with a signed starter is not vacant. loadOpenPositions asked "is
anyone on it today?", so three positions whose new holders begin in
September and October were listed as open, labelled "vacant for 2 days".
That same list feeds the hire wizard, so it invited filling a position a
second time — discovered at the partial unique index, after the second
interview. Vacancy now means no assignment that still stands, including one
that has not started. An assignment that ended still frees the position.
Hiring was broken three times over, each fault hidden behind the previous
one:
1. hire_employee cast to ::weekday[], a type that no longer exists — it
was replaced by text plus a CHECK constraint and the function was never
updated. apply_due_pending_changes had the same problem with
::relationship_type, which would have broken the nightly run.
PL/pgSQL resolves types in embedded statements at execution time, so
both functions were created without complaint and failed only in use.
2. Fourteen functions called auth.uid(). The application connects as a
role with no rights on the auth schema, so every write — hire,
transfer, promote, exit, notes, positions — failed with "permission
denied for schema auth". They now use app_current_user_id(), which is
where #23 was heading anyway. Its own fallback also caught only
"function missing" and now catches the privilege error too, so a call
without session context returns null instead of raising.
3. The audit line built a name as `payload->>'a' || ' ' || payload->>'b'`.
`||` binds tighter than `->>`, so Postgres reads
`payload ->> ('a' || ' ' || payload) ->> 'b'`. The ACL failure above
had aborted analysis before the parser ever reached it.
And the wizard collected an email, showed it in the summary, and dropped it:
the server action's signature had no such field. employees.email is NOT
NULL, so every hire that got past the three faults above would have failed
there. It is now passed through and required in step one, rather than
refused by the database at the end of step four.
Verified against the live database, each rolled back: a hire now creates the
employee, the assignment, the history entry and an audit line reading "Probe
Einstellung"; open positions drop from 13 to 10, and the three that
disappear are exactly the ones with a starter.
Migrations rewrite the affected functions in place rather than restating
them — retyping 165 lines of working PL/pgSQL to change two words is the
larger risk. Each one asserts the result afterwards.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
|||
| 1271cef879 |
Record what a change was, not only which field it touched
The audit log said "Adresse, wirksam ab 30.07.2026". That names the field
and hides the answer: what did it say before? For a personnel record that is
the question the log exists to answer.
Both values are in hand at the moment of the change — v_old holds the row as
it was, the payload holds what is being written. change_employee_data
already compared them to decide whether to mention the field at all, then
dropped them. It now keeps them in audit_log.changes as
[{feld, vorher, nachher}], and derives the old one-line text from the same
array so existing views are unaffected.
Clicking a row opens the detail. Fields with no previous value read "leer"
rather than showing an empty cell, because "was not set" is itself a
statement.
Two honest limits, both stated in the panel rather than left to look like a
bug:
- Existing entries cannot be enriched. The values were never captured;
there is nothing to recover.
- Hire, exit and import record no individual fields, so they show none.
The rewritten function also drops auth.uid() for app_current_user_id(),
which works on either system — one of the last few call sites before #23.
Caught while writing this: my scripted edit of types.ts silently did nothing
and my own check reported success, because the pattern matched
pending_org_changes. Redone with the editor. That is the second time a
regex-driven edit has lied about its result in this project.
Not verified end to end: the migration needs privileges I no longer hold
after the database password was rotated. Until it is applied the audit page
will not load, since it selects a column that does not exist yet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
|||
| 3926f1bb80 |
Load a whole organisation from a file, or none of it
Second half of the mass import: the transactional loader, the /import page
and a template generated from the same schema the validation uses.
Everything happens in one transaction. A half-loaded organisation — areas
without departments, positions without people — is worse than none, because
it looks like data. The dry run is the same code path with a rollback at the
end, so the report is built against the real current state rather than a
copy, and nothing is cached between checking and committing: the file is
sent twice. That costs one upload and avoids server-side state that can
expire, fill up, or be confused between two people.
Personnel numbers are taken from the file, not reassigned. personnel_number
is GENERATED ALWAYS AS IDENTITY, so this needs OVERRIDING SYSTEM VALUE and a
hand-written insert — worth it, because the number is on payslips, in files
and on badges. An import that reissues it is not a migration. The identity
counter is advanced afterwards; without that the next hire draws a number
the import already used, and the unique index refuses it weeks later, far
from the cause.
Three defects the first real run against the database exposed, none of which
typecheck, lint or 231 tests could have found:
- weekly_hours is bound to employment type by a CHECK constraint: full time
is exactly 38.5. The import reached the insert and was rolled back. Now
it is a finding with a row number.
- Titles are restricted to a fixed list by another CHECK. Same treatment.
- setval() needs UPDATE on the sequence, which `usage, select` does not
grant. Migration 20260803120000 adds it; until it is applied, an import
containing people will fail at the last step and take itself back.
I also had exit_date > entry_date where the database has >=. Someone who
never starts enters and leaves the same day; the stricter rule would have
rejected a real case.
Verified against the live database through the actual route and session: a
file with four deliberate faults produced exactly four findings, each with
sheet, row and column, and the rollback left nothing behind.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
|||
| 16b37244c8 |
Read an import file without guessing what it means
First half of the mass import: a file becomes named sheets with typed rows,
and every rule that could reject a row is stated in one place.
Nothing here touches a database. The parser turns bytes into sheets, the
schema says which columns exist, and validation reports findings — the
existing state is passed in as a parameter. That is what makes 36 tests
possible without a connection, and the rules are the part worth testing.
Three decisions where the easy choice would have been silent corruption:
- A two-digit year is refused. "15.08.68" is 1968 as a birth date and 2068
as a contract end, and any rule invented here creates people not yet
born.
- "31.02.2026" is refused. Date turns it into March 3rd without complaint.
- An unrecognised value in a yes/no column is an error, not "no". Read the
other way, a typo in "Betriebsrat" quietly removes someone's dismissal
protection.
CSV is parsed rather than split. German Excel writes semicolons because the
comma is the decimal separator, so the delimiter is sniffed from the header;
a semicolon inside a quoted address would otherwise shift every following
column and import the row plausibly wrong. Quoted newlines, doubled quotes
and the byte-order mark Excel prepends are all handled — the last one makes
the first column read as "?Personalnummer", which is invisible in an editor.
Validation collects every finding instead of stopping at the first. With 800
rows that is the difference between correcting once and uploading eight
hundred times.
One rule earns its place from experience: a history event dated before the
entry it belongs to is refused here, with a row number, because the database
refuses it too — mid-insert, without one.
My own slip, caught by the type checker: `a ?? b ? c : d` does not mean what
it looks like; ?? binds tighter than the conditional.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
|||
| 73656461d1 |
Catch a seed event dated before the entry it belongs to
pruefeInvarianten() checked that no history event falls after an exit, but not that none falls before an entry — and the database enforces exactly that, in trg_history_not_before_entry. That gap explains why the live database holds 852 people and no history at all. employee_history is the last table the seed writes and insertInChunks throws on the first rejected chunk, so everything before it was already committed while every one of the ~950 events was lost. The result did not look like an aborted run. It looked like an application that shows little history. The cause was the timezone bug in isoDate() that this seed already documents: dates built from local parts but formatted through UTC land a day early in Austria, which put every "Eintritt" one day before the entry date it was derived from. That is fixed; the database was simply never rebuilt. A dry run now reports 951 events and no violation, so the current code is sound. The check stays because it turns this class of failure into a refusal before the wipe instead of an abort halfway through it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| 99e50fbbf9 |
Stop hoarding connections the provider will not give twice
The app died with "max clients reached in session mode - pool_size: 15". Two causes, both real, neither visible without a live database. The connection string pointed at the pooler's session mode, which pins one backend per client and caps at 15 on Supabase. Every query here already runs inside a transaction and the session context is set transaction-locally, so transaction mode is not a workaround but the mode this design was written for. Verified: 20 concurrent transactions, all 852 rows, 0.4s — and still nothing without a session context. The second cause was the dev server. Next.js re-evaluates changed modules, so a module-local `let` was empty afterwards while the previous pool stayed alive holding its connections. An afternoon of editing exhausted the quota. The pool now hangs off globalThis, which is inert in production where nothing reloads. Documented in .env.example and DEPLOYMENT.md, because a deployment that picks port 5432 fails this way under load and not before. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| 4d8e3f7154 |
Restore the shapes the application was written against
The app runs against a real database for the first time since the port, and two things were broken. Both were invisible to typecheck, lint, 192 tests and the build. Sign-in looped. Auth.js created the session and app_upsert_user() adopted the existing profiles id correctly — the row was in app_users, right id and all — but the proxy builds its own Auth.js instance from lib/auth/config.ts alone, and the session callback that copies token.uid onto session.user.id lived in auth.ts. So the proxy saw a session without an id, treated every signed-in user as signed out, and sent them back to /login. Click, flash, login page: from the outside it looked like the button did nothing. The callback moves to the config both instances share. auth.ts now spreads the base callbacks instead of replacing them, which is the mistake that would reintroduce this. The proxy test did not catch it because its fixture hands the handler a session that already has user.id — it tested the routing, not the shape Auth.js actually produces. Then the dashboard crashed on a.date.localeCompare. PostgREST returned JSON: a `date` arrived as "2026-08-03", a `numeric` as a number, and that is what lib/supabase/types.ts declares and what every sort, every date comparison and every status derivation assumes. The pg driver does the opposite — Date object and string respectively. The declarations stayed true to what the code believes; only the runtime value changed, which is why nothing flagged it. The driver is configured back to the declared shapes in lib/db/pool.ts, rather than rewriting 49 call sites. That also removes a timezone hazard: `date` is a calendar day, and as a Date object it acquires midnight in the server's zone — a birth date would shift by a day in Austria, always. The same class of bug as in the seed. int8 stays a string on purpose: it only comes from count() and is read through Number() everywhere; parsed as a number it would quietly lose precision past 2^53. A missing sign-in error now reaches the server log. Auth.js was failing silently — a 302 back to /login and nothing to read. That was its own defect, and it is the reason the first diagnosis took as long as it did. Verified against the live database: all six pages render, 797 active of 852 records, 744.4 FTE, and a detail page shows birth date 15.08.1968 against SV number 7960 150868 — the digits agree, so no day has shifted. Both new tests were checked by mutation: remove the fix and they fail. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| b9efe81bec |
Keep database snapshots out of the repository
Before applying the five pending migrations I took a full snapshot of the live database — every table plus the source of all 61 functions. It sits in .backups/ and holds 852 personnel records, so it must never be committed. The ignore rule comes first, on its own, rather than riding along with the next change: a snapshot that is already staged when someone remembers to add the rule is a snapshot that has been in a commit. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| 4c5bfc223f | README.md aktualisiert | |||
| 2ba9b37aa7 |
Hand the front door to Entra, and keep the keys out of the build
Auth.js replaces GoTrue. The sign-in still goes to the same Entra tenant,
but nothing sits between the app and the identity provider any more — the
code exchange, state, nonce and the session cookie are ours.
lib/auth/session.ts stays the only place that knows where a user id comes
from, which is why this was one file and not fifty. What it returns is now
app_users.id. app_upsert_user() maps the Entra `oid` onto it, and for an
address that already has a profiles row it adopts that id instead of
minting a new one — otherwise everyone would have been signed in and cut
off from their own notes, drafts and audit trail at the same time.
That upsert is the one write that cannot have a session context yet: the
id is what it produces. It runs as a SECURITY DEFINER function that may
touch app_users and nothing else, which is a far smaller lever than the
service key that used to answer this class of problem.
The proxy no longer checks HR rights. It has no database connection, and
putting role/is_active in the token would have frozen the claim until the
next sign-in. The check moved to where it can read the current truth: the
app layout on every render, requireHrUser() for the export routes, and
underneath both, RLS.
Two things only came out by running it:
- `export const proxy = auth(…)` is not a function declaration, so
Next.js never found it and every request 404'd. `next build` reported
success and listed the proxy. In the function config form auth() also
returns the handler as a promise, so it needs an await. The proxy test
now mocks it as a promise for that reason — a friendlier mock would
let the same bug back in.
- A missing AUTH_MICROSOFT_ENTRA_ID_ISSUER silently falls back to
/common/, and the redirect really did go there. That would let any
Microsoft account sign in, including a private one, and it would never
look broken. It now refuses to start in production.
Neither build nor image needs credentials any more: the pool is created on
first use, the auth config is evaluated per request, and there are no
NEXT_PUBLIC_* values left to bake in. One image now runs in every
environment.
Verified: typecheck, lint, 187 tests, build, and by hand in the browser —
/employees redirects to /login, and the sign-in button reaches the Entra
page with PKCE and the callback URL that goes into the app registration.
Not verified against a real database; there is still no DATABASE_URL.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
|||
| b3a0af2b8f |
Talk to PostgreSQL directly, and let the pooled connection forget
Zweiter Schritt weg von Supabase. Sämtliche 49 Lesezugriffe und alle
Mutationen laufen jetzt über lib/db statt über die REST-Schicht: Kysely auf
einem pg-Pool, jede Abfrage in einer Transaktion, in der zuerst
app.user_id gesetzt wird. Die Anmeldung hängt noch an GoTrue — sie liefert
die Kennung, die in withUser() geht. Damit war der Umbau in zwei Hälften
teilbar und die Anwendung durchgehend lauffähig.
Was dabei ersatzlos verschwindet:
- fetchAllRows. Es gab die Funktion nur, weil PostgREST jede Antwort bei
1000 Zeilen still abschneidet und ein Bericht dann leise falsch war.
Am direkten Zugang ist eine Abfrage eine Abfrage.
- sanitizeIlikeTerm samt Test. Sie entschärfte Zeichen, die in der
Filtersyntax strukturelle Bedeutung hatten; jetzt wird der Suchbegriff
als Parameter gebunden und ein Komma ist ein Komma. Die Lücke ist nicht
abgesichert, sondern weg.
- lib/supabase/admin.ts. Der Dienstschlüssel, der RLS aushebelte, hatte
genau einen Aufrufer — den nächtlichen Lauf. Der benutzt jetzt dieselbe
Rolle ohne BYPASSRLS und ruft eine SECURITY-DEFINER-Funktion auf, die
selbst prüft, was sie tut. Es gibt keinen privilegierten Zugang mehr.
Nebenbei besser geworden, weil der direkte Zugang es erlaubt:
- Eine Seite ist eine Transaktion. Das Layout etwa liest Profil,
Planstellen, Standorte, Entwürfe und Notizen auf einem einheitlichen
Lesestand statt in fünf unabhängigen Anfragen.
- Der Bereichsfilter der Mitarbeiterliste ist ein EXISTS statt einer
eingebetteten Ressource mit !inner — eine Person mit mehreren
Zuordnungen über die Zeit erschien dort mehrfach.
- Seitenweise Listen sortieren zusätzlich nach id. Bei gleichem Nachnamen
oder gleichem Zeitstempel war die Reihenfolge vorher unbestimmt, und
dieselbe Zeile konnte auf zwei Seiten erscheinen oder auf keiner.
- Angehörige werden in der Datenbank gezählt statt alle Zeilen zu holen.
- Namen an Ereigniszeilen kommen aus einem Join statt aus einem
Nachschlag, der ausserhalb der Transaktion lag.
Der Statusfilter ist mitgezogen: dieselbe Regel wie deriveStatusAsOf,
Klausel für Klausel, jetzt als Kysely-Ausdruck. Der Integrationstest, der
beide über den gesamten Bestand vergleicht, läuft weiter — mit eigener
Verbindung, denn geprüft wird die Bedingung, nicht die Berechtigung.
Zwei Fehler auf dem Weg, beide vom Typprüfer gefangen: apply_due_pending_
changes() nimmt kein Argument, wurde von callFunction aber mit jsonb
aufgerufen — Postgres hätte keine passende Signatur gefunden. Und der
Sicherheitstest lädt jetzt Module mit `import "server-only"`, was ausserhalb
der Server-Übersetzung wirft.
Typecheck, Lint, Build und 180 Tests sind grün. Ungeprüft bleibt der Lauf
gegen eine echte Datenbank — dafür fehlt eine DATABASE_URL.
|
|||
| a66263a96e |
Put the session context under the app's own control
Erster Schritt weg von Supabase hin zu "läuft auf jedem PostgreSQL".
Gemessen sitzt die Kopplung nicht dort, wo der Begriff "Supabase-Projekt"
sie vermuten lässt: das Schema ist reines PostgreSQL, und von 58 RLS-Policies
rufen nur fünf auth.uid() direkt auf. Die übrigen 53 gehen über is_hr_user().
Diese eine Funktion ist die Brücke — wird sie umgelegt, folgt der Rest.
Die Migration legt sie um. app_current_user_id() liest jetzt zuerst
current_setting('app.user_id') und fällt nur ersatzweise auf auth.uid()
zurück. Deshalb plpgsql statt language sql: eine SQL-Funktion wird beim
Anlegen geparst, und auth.uid() gibt es auf einem gewöhnlichen PostgreSQL
nicht — die Migration liesse sich dort gar nicht erst anwenden. Der
Ausnahmeblock fängt das ab, und damit läuft dieselbe Migration auf beiden
Systemen. Der Rückfall verschwindet mit der Abschlussmigration.
Dazu app_users als Nachfolger von auth.users, external_id ist die oid des
Anbieters statt der E-Mail: eine Namensänderung darf kein zweites Konto
erzeugen.
Die neue Zugriffsschicht ist Kysely auf einem pg-Pool. Was daran zählt, ist
nicht der Query-Builder, sondern was er verhindert:
- Die Kysely-Instanz wird nicht exportiert. Wer abfragen will, geht durch
withUser() — und das öffnet immer eine Transaktion.
- set_config(..., true) ist transaktionslokal. Ohne das dritte Argument
bliebe die Kennung an der gepoolten Verbindung kleben und die nächste
Anfrage liefe im Namen der vorherigen Person. In einer Personaldatenbank.
- Eine ESLint-Regel verbietet den Import von pg und von lib/db/pool
ausserhalb von lib/db. Nachgewiesen: eine Testdatei mit beiden Importen
erzeugt zwei Fehler.
- Einen privilegierten Zugang gibt es nicht mehr. asSystem() benutzt
dieselbe Rolle ohne BYPASSRLS; was ohne angemeldete Person laufen darf,
muss als SECURITY-DEFINER-Funktion in der Datenbank stehen.
tests/integration/session-context.test.ts läuft gegen einen Pool mit genau
einer Verbindung — sonst träfe er die Lücke mal und mal nicht. Er prüft, dass
nach Commit *und* nach Rollback nichts an der Verbindung zurückbleibt, und
belegt in einer Gegenprobe, dass eine Einstellung ohne Transaktion tatsächlich
hängen bleibt. Ein Sicherheitstest, der sich mangels DATABASE_URL selbst
überspringt, wäre schlimmer als keiner: in der CI schlägt schon das Fehlen
des Verbindungsstrings fehl.
Beim Schreiben der Migration stellte sich heraus, dass die Policies
hire_drafts_owner und saved_reports_owner heissen, nicht _own. Mit dem
geratenen Namen hätte drop policy nichts getroffen und create policy wäre mit
"already exists" abgebrochen.
Typecheck, Lint und 182 Tests sind grün. Die Anwendung läuft unverändert
weiter — sie benutzt die neue Schicht noch nicht.
|
|||
| 730521ee79 |
Keep the environment's identifiers out of the repository
Projekt-Ref, Entra-Client- und Tenant-ID standen im Klartext in der SSO-Anleitung. Geheimnisse sind das nicht — ohne Schlüssel gibt eine Projekt-URL nichts her, und RLS greift unabhängig davon. Sie zeigen aber auf die laufende Umgebung, und dieses Repository wandert weiter als sie: es geht gleich auf einen eigenen Git-Server und später an den Kunden. Jetzt Platzhalter; die Werte gehören in die Übergabedokumentation. In der Historie stehen sie weiterhin — das sauber zu entfernen hiesse, die Historie neu zu schreiben, und das passiert nicht nebenbei. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| acbb03c4f5 |
Record the supported Node range in the lockfile
package.json declares engines: node >=22 <25; npm writes that into the lockfile on the next install. Committing it keeps a fresh clone from producing a diff on the first npm ci. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
|||
| ee1a38492c |
Pin search_path, and close a write path that needed no login
Der Security Advisor meldete 34 Warnungen; nach dem Festnageln des search_path sind es zehn. Von diesen zehn ist eine einzige ein echter Befund — aber die hätte man in den 34 nicht gesehen. search_path (34 Warnungen) Alle betroffenen Funktionen sind SECURITY INVOKER, laufen also mit den Rechten der aufrufenden Person; ein manipulierter Pfad bringt dort nichts zu holen. Die vier DEFINER-Funktionen setzen ihn längst. Festgenagelt wird es trotzdem, für den Tag, an dem jemand eine davon auf SECURITY DEFINER umstellt, weil eine Mutation an RLS vorbei schreiben muss — dann wäre es eine Rechteausweitung, und an den search_path denkt in dem Moment niemand. Als Schleife statt als Liste von 34 Signaturen: die würde beim nächsten Umbau veralten. Sie lässt Erweiterungen in Ruhe (pg_trgm legt show_trgm und show_limit ebenfalls in public ab) und prüft am Ende selbst nach. pg_temp steht ausdrücklich am Pfadende — ohne die Angabe durchsucht Postgres das temporäre Schema zuerst, und dort darf jede Sitzung anlegen, was sie will. Ausführungsrechte (8 Warnungen) Hier trennt sich der Befund vom Rauschen, und zwar durch Messen mit dem anon-Schlüssel gegen die laufende Datenbank: anon.rpc(is_hr_user) -> false anon.rpc(current_hr_user_id) -> null anon.rpc(apply_due_pending_changes) -> 0 Die ersten beiden bleiben offen, und das ist keine Nachlässigkeit: sie werden aus den RLS-Policies heraus aufgerufen, und ein Policy-Ausdruck wird mit den Rechten der abfragenden Rolle ausgewertet. Ohne EXECUTE scheitert jede Abfrage auf jeder Tabelle. Preisgegeben wird nichts — beide nehmen keine Argumente und beantworten nur eine Frage über die aufrufende Person selbst. Der dritte ist der Befund. apply_due_pending_changes() wendet vorgemerkte Versetzungen, Beförderungen und Abwesenheiten an, ist SECURITY DEFINER, umgeht damit RLS — und war ohne Anmeldung aufrufbar. Der anon-Schlüssel steht im ausgelieferten Browser-Bündel. Der Schaden wäre begrenzt, weil nur ohnehin fällige Änderungen angewandt werden, aber es ist ein Schreibpfad für Fremde und macht das Geheimnis der Cron-Route wirkungslos. Entzogen für anon und authenticated; die Route benutzt die service_role und läuft weiter. rls_auto_enable() stammt nicht aus diesen Migrationen und wird nirgends aufgerufen. Der Entzug ist risikolos und beantwortet die Frage, was sie tut, notfalls mit einer klaren Fehlermeldung. Zwei Warnungen bleiben bewusst stehen pg_trgm in public trägt die Operatorklasse gin_trgm_ops, auf der zwei GIN-Indizes auf employees liegen. Ein Schemawechsel müsste Indizes und jeden search_path mitziehen — Risiko für eine Konvention, keine Rechteausweitung. „Leaked Password Protection" ist gegenstandslos: die Passwort-Anmeldung ist abgeschaltet, eine Anmeldung gegen die API antwortet mit email_provider_disabled. Es gibt kein Passwort, das kompromittiert sein könnte. |
|||
| 2cce101c4b |
Sign in with Entra ID, and give the login screen something to look at
Die Anmeldung läuft über das Firmenkonto. Supabase Auth bleibt dabei die
Sitzungsverwaltung — Entra ist der Anbieter, nicht der Ersatz. Genau deshalb
ist der Eingriff klein: auth.uid() liefert weiterhin eine UUID, profiles.id
trägt weiterhin role und is_active, und damit bleiben is_hr_user() und alle
58 RLS-Policies unverändert gültig. Die Sicherheitsgrenze wandert nicht in
den Anwendungscode.
Der Passwort-Pfad ist weg, nicht deaktiviert. Ein zweiter Anmeldeweg neben dem
Firmenkonto hebelt jede Vorgabe des Mandanten aus — Mehrfaktor, bedingten
Zugriff, Sperrung beim Austritt.
Dazu die Rückweg-Route /auth/callback, die den PKCE-Code gegen eine Sitzung
tauscht, und eine Ausnahme im Proxy: ohne sie leitet der Gate den Code nach
/login um, weil es die Sitzung ja erst danach gibt, und die Anmeldung kommt
nie zustande. Ob jemand HR-Zugriff hat, entscheidet weiterhin nicht die Route,
sondern profiles.role/is_active und darunter die Policies.
Zwei Werkzeuge für die Umstellung:
- relink-profile.ts hängt eine bestehende profiles-Zeile auf die
Entra-Identität um. Ein Passwort-Konto und das Entra-Konto derselben
Person sind für Supabase zwei Benutzer mit verschiedenen IDs; ohne das
zeigt die profiles-Zeile nach der ersten SSO-Anmeldung ins Leere und man
sperrt sich aus. Die Fremdschlüssel auf auth.users wandern mit, sonst
stünde in der Historie eine Kennung ohne Konto dahinter.
- entra-claims.ts zeigt, was der Anbieter tatsächlich mitgeschickt hat.
Die geplante Freischaltung über eine Entra-Gruppe hängt daran, wie der
Anspruch heisst und aussieht, und das unterscheidet sich je nach
Tokenkonfiguration des Mandanten. Der Trigger wird erst danach gebaut,
sonst wäre er geraten.
Beim Auswerten der Gruppe später gilt: die Quelle ist auth.identities.
identity_data, nie raw_user_meta_data. Letzteres beschreibt die angemeldete
Person über updateUser() selbst — läse die Freischaltung von dort, könnte sich
jede:r Angemeldete HR-Rechte eintragen. Steht so in docs/entra-sso.md.
Die Anmeldeseite war eine Box im leeren Rosa. Jetzt zweispaltig: links eine
Markenfläche, rechts die Anmeldung; unter 1024px fällt die Fläche weg und die
Wortmarke rückt über die Karte. Die Microsoft-Schaltfläche ist bewusst nicht
mehr in der Hausfarbe — magenta las sich als Aktion *innerhalb* dieser
Anwendung, während sie auf eine fremde Anmeldeseite springt. Weiss mit
grauem Rand ist Microsofts eigene Vorgabe und das Muster, das man
wiedererkennt. Dazu ein Wartezustand für den Sprung und eine Fehlermeldung,
die erklärt, was zu tun ist, statt nur "Kein HR-Zugriff" zu behaupten.
Nachgemessen im laufenden Server statt geschätzt: 656/624 auf 1280px,
Markenfläche in brand-700, Schaltfläche 45px hoch, kein Querlauf auf 375px.
Typecheck, Lint, Build und 182 Tests sind grün.
|
|||
| 27669e0359 |
Put the whole application on the OM model, and delete what it replaced
Die Datenbank stand seit dem Cut-over auf org_units/om_positions/
position_assignments, die Anwendung fragte weiter nach employees.division_id,
team_id und manager_id — Spalten, die es nicht mehr gab. Die Oberfläche war
deshalb leer, obwohl die Daten vollständig da waren. Das ist jetzt behoben,
und zwar nicht durch Nachbau der alten Begriffe, sondern indem sie verschwinden.
Neu ist eine dünne Schicht, die die Verkettung Person → Besetzung →
Planstelle → Einheit einmal auflöst (lib/placement.ts) und der Baum als reine
Funktionen darauf (lib/org.ts): Vorfahrenkette, Teilbaum, Brotkrume. Alles
Weitere hängt daran.
Was sich dadurch von selbst erledigt hat:
- Das Organigramm musste drei Quellen versöhnen, weil keine den ganzen
Zeitstrahl abdeckte. position_assignments ist zeitabhängig, also
beantwortet eine Abfrage "wer besetzte am Stichtag welche Planstelle" —
für Vergangenheit und Zukunft gleichermassen. Wer keine Planstelle hatte,
war nicht da; eine zweite Zugehörigkeitsregel braucht es nicht mehr.
- Die Struktursicht war auf genau vier Ebenen verdrahtet und rendert jetzt
rekursiv über parent_id. Liste und Grafik entstehen aus *einem* Baum;
vorher lag dieselbe Hierarchie zweimal vor und konnte auseinanderlaufen.
- Eine offene Stelle ist keine eigene Tabelle mehr, sondern eine Planstelle
ohne laufende Besetzung — das Komplement kann nicht aus dem Tritt geraten.
- Eine Versetzung ist der Wechsel auf eine Zielplanstelle statt Zielteam
plus frei getipptem Titel. Sie kann damit nicht mehr dort landen, wo es
keine Stelle gibt, und die Tätigkeit kommt aus dem Job-Katalog.
- Beim Anlegen einer Planstelle entfällt die Suche nach der vorgesetzten
Person: sie ergibt sich aus der Einheit, die Frage kann nicht mehr falsch
beantwortet werden.
Zwei Auswertungen werden dabei richtiger, nicht nur anders. Ein
Stichtagsbericht gruppierte bisher nach der *heutigen* Zuordnung, weil es
keine Historie gab; er löst sie jetzt zum Stichtag auf. Und ein Ereignis
trägt die Einheit, in der die Person am Tag des Ereignisses sass — vorher
stand ein Austritt von vor zwei Jahren unter einem Team, in das sie nie
versetzt worden war. Der Bereichsfilter greift überall auf den ganzen
Teilbaum; auf den Bereich allein angewandt lieferte er nur die
Bereichsleitung.
Gelöscht: die Reorganisations-Werkbank samt Szenarien und Zügen (sie
verschob Teams und Abteilungen zwischen Bereichen — Objekte, die es nicht
mehr gibt; im OM-Modell ist das ein Umhängen von parent_id), die
Mitarbeiter- und Vorgesetztensuche, die nur sie und die Ausschreibung
brauchten, und aus lib/supabase/types.ts die Tabellen divisions,
departments, teams, positions und employee_assignments.
Die beiliegende Migration räumt die Datenbank entsprechend auf. Sie entfernt
auch Funktionen, die der Cut-over verfehlt hat: create_position,
delete_position und undo_reorg existierten zusätzlich in einer
jsonb-Variante und tauchen deshalb weiter in der PostgREST-Schnittstelle auf,
obwohl ihre Tabellen weg sind — ein Aufruf wäre erst zur Laufzeit
gescheitert. An ihre Stelle treten create_position und delete_position im
OM-Sinn; letzteres schliesst eine früher besetzte Planstelle, statt sie zu
löschen, sonst verschwände mit ihr die Besetzungshistorie.
Typecheck, Lint, Build und 182 Tests sind grün. Die Integrationstests sind
mitgezogen, aber weiterhin ungelaufen — dafür braucht es eine laufende
lokale Datenbank.
|
|||
| 4929252f45 |
Seed the OM model from scratch, and stop writing dates through UTC
Alle Daten gelöscht und neu aufgebaut: 60 Organisationseinheiten, 133 Jobs,
823 Planstellen, 852 Personen, 852 Besetzungen. Die Anmeldekonten bleiben
stehen — ein Seed, der sich selbst aus der Anwendung aussperrt, ist keiner.
Der Baum kommt aus buildOrg(); der Seed entscheidet nur noch, wer welche
Planstelle besetzt. Damit fällt die halbe Datei weg: keine division_id,
team_id, manager_id, org_level, is_lead mehr auf der Person.
Zwei Dinge, die das Altmodell nicht abbilden konnte, stehen jetzt bewusst in
den Daten:
- Vakanz ist eine Planstelle ohne laufende Besetzung, keine eigene Tabelle.
14 Planstellen sind heute unbesetzt, drei davon mit einem Eintritt in der
Zukunft — die Besetzung beginnt später, die Planstelle existiert schon.
- Ausgetretene sind Vorgänger:innen auf heute besetzten Planstellen, nicht
Karteileichen an einem Team. Vorher liessen sie deren Planstellen als
vakant erscheinen.
Drei Teamleitungen sind unbesetzt und zwei langzeitabwesend, damit die
Hochroll-Regel überhaupt Daten hat: 76 der 809 Berichtslinien weichen von der
formalen ab. Genau eine Person hat keine Vorgesetzte, die Geschäftsführung.
Beim ersten scharfen Lauf hat der SVNR-Trigger mitten im Einfügen abgebrochen,
mit bereits geleerter Datenbank. Ursache war nicht die Prüfziffer, sondern
isoDate(): es ging über toISOString(), während makeSvNummer die lokalen
Datumsteile liest. In Österreich verschiebt das jedes Datum um einen Tag — das
gespeicherte Geburtsdatum passte nicht mehr zu dem in der SV-Nummer codierten.
isoDate rechnet jetzt lokal, wie der Rest des Seeds auch.
Damit so etwas nicht wieder erst die Datenbank leerräumt: pruefeInvarianten()
läuft *vor* dem Löschen und prüft, was sonst erst die Unique-Indizes und
Trigger abfangen — doppelte Besetzungen, überlappende Historie, Ereignisse
nach dem Austritt, und jede SV-Nummer gegen ihr Geburtsdatum. Mit --dry-run
schreibt der Seed gar nichts und meldet nur, was entstehen würde.
|
|||
| c2366e3408 |
Make the cut-over script safe to paste, and record the Azure design
The mapping table was declared ON COMMIT DROP. In the Supabase SQL editor the transaction boundaries are not ours to assume, and a mapping table that vanished between the two inserts would leave positions without assignments and be miserable to diagnose. It is now dropped explicitly once both inserts have run. docs/azure-migration.md is the design for the Azure move, for review before any code changes. Its main finding corrects what I said when I laid out the options: I claimed that dropping Supabase would push the security boundary into application code. It does not. auth.uid() appears 70 times, but only one of them matters — inside is_hr_user(), which all 58 policies call. Swapping the source of the user id there leaves every policy valid, so the database stays the boundary. The risk moves elsewhere, and the design says so plainly: the user id arrives via set_config(..., true), which is transaction-local. Outside a transaction it sticks to the pooled connection, and the next request on that connection runs as the previous user. So the plan makes that structurally impossible — a single access function that owns the transaction, a lint rule against importing the pool anywhere else, a database role without BYPASSRLS so a missing context returns nothing rather than everything, and a test that sends two requests over one pooled connection to prove the second cannot see the first. |
|||
| cce5c6b0ce |
Cut-over SQL: migrate the existing org data into the OM model, drop the old
One script for the Supabase SQL editor. It transforms rather than wipes: divisions/departments/teams become org_units, every employee gets a position and an assignment, so the org chart is populated the moment it finishes. The Abteilungsleitung positions are created *vacant*. Nobody holds them, and inventing holders would be worse than a visible gap — the upward rule skips an unfilled chief, so the reporting line stays unbroken either way. Mutations are rewritten onto the model. The reporting line is derived now, which removes manager bookkeeping from all of them: terminate_employee no longer reassigns direct reports at all, because they roll up on their own. Transfer becomes what it is in OM — end one assignment, begin another. apply_reorg, undo_reorg, create_position, delete_position and staff_position_internally are dropped rather than rewritten: they need the UI to move to org units first, so rewriting them now would be guesswork. Those screens are out until the port. Written by inspection, not by running it — Docker is not up and the project is not linked, so this is unverified SQL. Re-reading the first draft caught five defects that would each have aborted it: a window function inside a JOIN condition, a jobs insert placed after the positions referencing it, row_number() computed twice for a mapping that has to agree, a DROP VIEW naming a view that does not exist while the real one (employees_directory) depends on the columns being dropped, and exit_date = entry_date violating the assignment range check. There may be more. |
|||
| 35f17858d8 |
Build the org tree in the OM model as a tested pure function
Constructing the tree is where parent links, chief positions and number ranges get wired up wrongly without anyone noticing — a team under the wrong Bereich looks perfectly plausible in the org chart. So the construction is a pure function taking an id generator, and the checks that matter are asserted rather than eyeballed: exactly one root, every unit's parent of the expected type, every unit reaching the root, one chief position per unit, unique numbers in the right ranges, and every position pointing at a real unit and a real job. Also introduces the job catalogue this model needs. job_title was free text per person, so "Schlosser:in" and "Schlosser" could coexist and no breakdown by occupation was possible; jobs are now deduplicated by title and shared across positions. Every Abteilung gets a chief position, which is the level the old three-table model had no room for. Correction to the previous commit message: it claimed the cut-over could follow later while the old tables kept working. It cannot. The legacy resolve_manager_for() finds a Bereichsleitung by "division_id = X and team_id is null and org_level = 1", and an Abteilungsleitung satisfies the same predicate — its LIMIT 1 would then pick one of the two arbitrarily. The two models cannot both be correct once the new level is populated, so the remaining work is a single cut across the 11 RPCs that read the legacy columns, not a gradual migration. |
|||
| 4b9c23472c |
SAP OM: org units, jobs, positions, and a derived reporting line
The org structure was three fixed tables — divisions -> departments -> teams — with people hanging directly off them and a hand-maintained manager_id. The depth was therefore wired into the schema: an Abteilungsleitung could not exist without a migration, and a team directly under a Bereich not at all. That is what this replaces. The SAP OM object types, one table each: O org_units recursive over parent_id C jobs catalogue, so many positions can share a job S om_positions belongs to exactly one org unit P employees existing table A012 om_positions.is_chief "ist Leiter von" A008 position_assignments "Inhaber ist", time-dependent Two consequences worth stating, because they are the point of the exercise: - GF/Bereich/Abteilung/Team are now a label (unit_type), not a structure. Adding a fifth level, or hanging a team straight off a Bereich, becomes a data question rather than a migration. - Nobody hangs off an org unit any more: person -> position -> unit. A vacancy stops being its own concept — it is a position with no current assignment. The reporting line is derived rather than stored: an ordinary position reports to the chief of its own unit, a chief to the chief of the parent unit, and if that chief is vacant or on a long-term absence it keeps climbing. An unfilled Abteilungsleitung therefore needs no special case — it is simply skipped. Both ids come back, formal and acting, so the UI can show a stand-in as a stand-in instead of passing it off as the real manager. The rule exists twice, as om_reporting_lines() in SQL and resolveReportingLines() in TypeScript, because the as-of chart computes it per date in the app and a round trip per date change would buy nothing. Two copies drift silently — the org chart would just show a different manager than the export — so an integration test runs both over the whole roster and requires identical answers, plus that every line terminates at the top. Unit tests cover the rule itself: unfilled levels, several absent levels in a row, nobody above, a chief who also leads the parent unit, and a cycle in parent_id, which is an ordinary column an import could get wrong. Additive so far. The old tables still stand and the app still reads them; the cut-over follows. |
|||
| 2776c33d08 |
Roll reporting up past an absent manager, and say so on both sides
While somebody is on a long-term absence their reports report to the next
management level, and it keeps rolling up until it reaches somebody present.
Derived at read time in lib/acting-manager.ts rather than written to
employees.manager_id: the absent person stays formally in charge, so the
stand-in has to be visible as a stand-in rather than quietly replacing them.
Both ids therefore travel to the UI, and both sides carry a badge — the
absent person ("Abwesend · Vertretung: X") and anyone now reporting
elsewhere ("Vertretung für Y").
Three cases the walk has to survive, all covered by tests:
- Several absent levels in a row — it keeps climbing, and still names the
*recorded* manager as the one being covered for, not the level skipped.
- Everyone above absent — it stops and keeps the recorded manager. Re-rooting
a team to the top of the chart would distort more than showing an absent
manager whose absence is labelled anyway.
- A manager_id cycle, which nothing in the schema forbids.
An absent lead needs no separate deputy field: their stand-in is simply
their own acting manager, the same one their reports moved to.
|
|||
| a0973cff66 |
Show the absence type in the employee list again
The three pending migrations have been applied, so absence_type exists and
the workaround that kept it out of this select can go. The status chip in
the list shows the specific kind again ("Bildungskarenz" rather than the
generic "Langzeitabwesenheit"), matching the detail page.
Verified against the database rather than by typecheck: employee_assignments
holds 809 rows for 809 employees with exactly one open interval each,
is_valid_svnr() agrees with the TypeScript implementation on all nine
documented cases, and the list, org-chart and detail queries all return rows.
|
|||
| a9bf439624 |
Collapse sequential query waves, and stop selecting an unshipped column
Against the hosted database a round trip costs about as much as the queries themselves (~90ms), so page time was dominated by how many waves ran in sequence rather than by the SQL. Measured with the median of five runs: - Employee list 244ms -> 101ms. It awaited loadOrgMaps and only then the page of employees; the lookup tables are needed to label rows, not to build the query, so both now go out together. - Employee detail 120ms -> 62ms. Nine of the ten queries key off the id already in the URL and had no reason to wait for the employee row. The manager comes back as an embedded resource on that row instead of a follow-up query, which is what makes it one wave rather than two — an intermediate version that merely reordered the waves measured *slower*, and the embed is the part that actually helps. - Reports 197ms -> 180ms. Three waves became two. Modest, and worth saying so: the snapshot query itself dominates that page, not the wave count. Also fixes a blank employee list I caused. `absence_type` was added to the list's explicit column list ahead of its migration, and PostgREST rejects the *entire* query for one unknown column — so `data` came back null and the page rendered zero of 809 employees rather than just dropping a chip label. The column is out of that select until 20260726120000_absence_type.sql is applied; the detail page selects "*" and shows the kind once it exists. Verified against the real database rather than by typecheck alone, which is what would have caught it in the first place. |
|||
| 8282d7f581 |
Rename Karenz to Langzeitabwesenheit and record its type
Karenz was doing duty as the name for every kind of extended absence, but the cases behave differently in payroll and reporting — Wochenhilfe, a Präsenzdienst, a long sick leave and a sabbatical are not the same thing. The concept is now called Langzeitabwesenheit and carries which kind it is. - employees.absence_type, constrained to the thirteen kinds. start_karenz stores it on both paths (written straight away, or parked in the pending_org_changes payload when the absence starts later); record_karenz_return and the karenz_return branch of apply_due_pending_changes clear it, so a returned employee does not keep looking like they are still away. It also reaches employee_history, the audit log and the employee export. - The status enum value stays 'Karenz'. Postgres can rename an enum value in place, but every stored function body that spells it would then reference a value that no longer exists — a dozen functions across fifteen migrations, rewritten for a label. The mapping lives in lib/absence.ts instead, which is the single place the UI reads the display name from. - Where a kind is recorded the chip shows it — "Bildungskarenz" says more than "Langzeitabwesenheit". Absences predating the field have none and fall back to the generic name rather than to a guess, and a value outside the list is dropped rather than echoed into the UI. - The export prints the display name, not the raw enum: a payroll hand-off reading "Karenz" for what the app calls Langzeitabwesenheit only causes questions. Audit filter options keep their stored values and change only their labels. - The seed spreads the twelve absences across the kinds; all of them being Karenz would leave any breakdown by kind invisible. |
|||
| 37bb107cd4 |
Visual pass, clickable KPI tiles, and one consistent definition of status
Visual - `--radius: 8px` in @theme collapsed Tailwind v4's whole radius scale onto a single value: `rounded` and `rounded-lg` both measured 8px, so a chip, an input and a card could not be told apart. Named steps restore the gradation (6 / 8 / 12px, measured in the browser). - Cards were a 1px border and nothing else. Added warm, brand-tinted elevation tokens — a neutral black shadow over the pink surface reads as dirt — in three steps for cards, dropdowns and overlays, collected behind components/ui/Card.tsx so the 26 hand-copied card class chains have one definition. - KPI tiles lead with the number and carry a tone accent; tables got denser rows, subtle row rules (the full border strength made 800 rows read as a grid), tabular figures in numeric columns and a brand-tinted hover. KPI tiles now link to the view that shows what they count. Making those links honest surfaced two reasons the numbers did not agree with their destinations: - The dashboard read `employees.status`, while every report derives status from entry/exit/karenz dates. A hire whose start date had passed before the cron ran was counted differently on the two pages. The dashboard now uses the same derivation — and one query instead of five. - Eintritte/Austritte counted `entry_date`/`exit_date` while the linked report counts `employee_history`; rehire_employee sets entry_date but logs the event as 'Wiedereintritt', so rehires were missing from the target. Both now count history events. - The employee list filtered on the status column, so it disagreed too. It now filters on derived status in SQL (lib/employee-status-filter.ts). That restates deriveStatusAsOf a second time, in a second language, so an integration test runs both over the full roster and requires identical id sets — drift here is otherwise invisible. Status semantics, per the domain correction: "aktiv" means status Aktiv alone. Karenz is employed but not active, and has its own tile. The active headcount, FTE (Karenz contributes no capacity) and the division bars all follow that; the bars are labelled "Aktive nach Bereich" rather than "Headcount" to say so. The employee filter still offers the combination, named after the two statuses it selects instead of calling the pair active. DEFAULT_STATUSES in lib/reports.ts is deliberately left at Aktiv + Karenz: it governs what the Berichte page shows without an explicit status filter, and therefore what already-saved reports and exports mean. |
|||
| d9367a8ce4 |
Form primitives, keyboard-operable comboboxes, dialog focus, route states
Accessibility work on the UI layer, all of it rooted in one structural gap: there were no form primitives, so every field was hand-assembled and every field got the same details wrong. Form primitives - components/ui/Field.tsx (Field/TextField/SelectField/TextareaField) and Button.tsx. Field generates the control id with useId and derives htmlFor from it, which is what makes the association impossible to omit rather than merely conventional. - 92 labels existed, 4 used htmlFor, and no input carried an id at all: a screen reader announced an unnamed edit box and clicking a label focused nothing. Now every label resolves to its control (0 unassociated), and the input class chain that appeared verbatim 85 times appears zero times. - Field also takes a render prop, so Lookup, CountryPicker and Picklist get the same wiring instead of a second, partial solution. - SearchInput replaces three hand-rolled copies of the icon-in-a-box search whose input had only a placeholder — not a label — and killed its own focus ring with outline-none and nothing in its place. - Toggle groups (workdays, reorg change type) became fieldsets with aria-pressed; colour alone was carrying the selected state. Comboboxes - Lookup and CountryPicker were text inputs with a div of clickable buttons underneath: typeable, but no keyboard path to a result and nothing telling a screen reader a list had appeared. Both now carry role=combobox, aria-expanded/controls/activedescendant and listbox semantics, with arrow keys, Enter and Escape. Escape stops propagation, or it would close the surrounding dialog along with the dropdown. Dialogs - useDialogFocus centralises what Modal and SlideOver each owed the keyboard and neither provided beyond Escape: focus into the dialog on open, Tab and Shift+Tab cycling within it, focus restored to the trigger on close. - SlideOver stays mounted for its transition, and aria-hidden does not remove anything from the tab order — so every closed panel was leaving invisible tab stops at the end of the page. `inert` fixes that. Route states - loading.tsx, error.tsx, not-found.tsx and global-error.tsx. Every page in the (app) group is server-rendered per request, so without loading.tsx a navigation showed nothing at all until the server answered, and a render error dropped the user on Next's own screen with no way back. Tests - 22 component tests (vitest jsdom project). Two of them found limits of the environment rather than of the code: jsdom implements neither `inert` nor scrollIntoView, so the inert test asserts the attribute and the missing scrollIntoView — which was taking the whole render down from inside an effect — is stubbed in the setup file. |
|||
| 4be5f2264e |
Drop agent tooling files and neutralise spec references
- Removed CLAUDE.md, AGENTS.md and NEXTJS_REBUILD_SUPERPROMPT.md, and untracked .claude/ (now ignored locally via .git/info/exclude rather than .gitignore, so the repo carries no reference to it either). - The Next.js 16 warning that lived in AGENTS.md is kept where it is actually useful, in the README tech-stack section. - Source and migration comments referred to "the consolidation master prompt" and "NEXTJS_REBUILD_SUPERPROMPT.md" by name; both now read "spec", keeping the section numbers that made the cross-references worth having. - README no longer lists Playwright, which is not installed, and now describes the three test layers that actually exist. |
|||
| 8d978981b0 |
SVNR validation, CI, and a dependency/security pass
Positions
- Removed the "Besetzen" action, the StaffInternallyModal behind it and the
now-unreachable staffPositionInternally server action: a position is filled
through the hire process, not from the positions list. Note that
transfer_employee has no position_id at all and never touched `positions`,
so with staff_position_internally out of the UI, hire_employee is the only
thing that closes a position — a transfer into an open one leaves it open.
The RPC itself is still in the database and still covered by its tests.
SVNR
- Austrian social security numbers are now validated: ten digits, weighted
check digit mod 11, and the TTMMJJ tail cross-checked against birth_date,
which is what catches a transposed date that a valid check digit would let
through. A serial whose weighted sum lands on 11 is rejected rather than
wrapped — those are never issued.
- Applies to Austrian locations only; the German/Czech/Slovenian equivalents
have their own formats and stay free-form.
- Enforced by a trigger, not inside hire_employee/change_employee_data, for
the same reason as the assignment history: both have been redefined by
half a dozen migrations. Only a *newly written* value is checked, so a
legacy number never blocks an unrelated transfer or address change.
- The seed drew a random four-digit prefix, so its check digit was right
only by chance and every seeded Austrian row would now be rejected;
it computes the check digit properly now.
Tech stack
- next 16.2.11 closes nine advisories against 16.2.10, including a
middleware/proxy bypass in App Router apps on Turbopack — proxy.ts is this
app's entry gate. RLS remains the real boundary, so the blast radius was a
blank page rather than data, but it is a patch-level fix. Also react
19.2.8, tailwind 4.3.3, lucide-react 1.26, supabase-js/ssr, postcss.
- CI runs lint, typecheck, schema/type drift, tests and build; a second job
replays every migration onto an empty database and runs the integration
suite against it, so a migration that cannot be replayed from scratch
fails here instead of during a restore.
- scripts/check-schema-types.mjs diffs the hand-written lib/supabase/types.ts
against the migrations. Reading the SQL rather than a live database keeps
Postgres out of the fast CI job. Verified in both directions.
- vitest now runs two projects: node for logic, jsdom for components. The
first component test covers the org chart expand control, which broke
earlier this session when elementsSelectable={false} made React Flow
compute pointer-events:none for the whole node; re-introducing that prop
fails three of these tests.
- Content-Security-Policy is emitted report-only. Enforcing a policy derived
from inspection rather than from violation reports risks blanking the app;
'unsafe-inline' on script-src is required until a nonce is threaded through
proxy.ts, which is a separate change.
- Fixed supabase/seed.ts, which this session's SVNR change had broken: the
extensionless "../lib/svnr" import does not resolve under Node's ESM
loader, so the seed failed at startup.
- engines pinned to node >=22 <25, tsconfig target ES2022, and the dead
test:e2e script removed (no Playwright is installed).
|
