Directory sync: three open questions, and three decisions the page had lost The open questions came from auditing this page's own 13-question list against the shipped code. All three are gaps against decisions recorded HERE, not new ideas - which is the point of keeping the list: 6. precedence between two directories holding the same person. §3.3 called multiple sources "already possible" and treated the plumbing as the easy part. The plumbing is fine; the policy was never decided. Every run claims the person, so values flap. Found by reading the code - a single-directory install never sees it. 7. custom attributes (§3.7) not built. 8. the users screen has one door, not the two §3.12 decided on, and §3.5's offboarding alert exists as a filter but not as a report. Separately: checking whether the page captured the reasoning found that it did not. Three decisions made DURING the build, all driven by using the thing rather than designing it, were missing entirely: 4.4 the modal was the wrong container - and the finding was not "it is cramped" but "I couldn't see the preview function". The button had been there the whole slice, below the fold. A feature that exists and cannot be found has not shipped, and neither the design nor the tests could detect that because both checked whether it worked. 4.5 "Everyone" must mean everyone. The filter quietly applied is_active = 1. The four scopes were named in the report itself and adopted verbatim; Holding equipment includes leavers because a leaver with a laptop is the most useful row on the screen. 4.6 a reporting line is stored once, pointing upwards, so "who does Bob manage" did not exist. Importing a hierarchy is only half of adopting one. Section 4 retitled, since half of it is no longer about the first answer being wrong.
Wiki: give importing people its own page It was a section two-thirds of the way down LDAP-and-Active-Directory, which is a page about signing in. Anybody sent that link had to read about bind accounts and group gating before reaching their answer, and the question people actually ask - "how do I import my AD users?" - was not the title of anything. Three pages, three jobs: LDAP-and-Active-Directory signing in Importing-People-from-a-Directory the how-to <- the one to send people Directory-Sync the design record The sign-in page keeps a short pointer explaining why importing exists at all (the people who hold equipment are largely the people who never log in), so the link is worth following rather than a bare cross-ref. Expanded on the way: prerequisites, step-by-step with the tree and the mapping test, the full table of what happens when somebody leaves or a branch is renamed, the CLI for scheduling until that is built, and a troubleshooting table keyed on what you actually see on screen. All links verified to resolve; sidebar updated.
Directory sync: record what shipped, and the design note that was half right Directory-Sync.md was a design record for something now built. §3.8, §3.9 and §3.11 say how each idea actually turned out, the slice table marks what is done, and scheduling is named as the only outstanding piece. §3.9 had warned that storing DNs breaks when an OU is renamed. It was right, and incomplete: it only considered a renamed INCLUDE. A renamed EXCLUDE is worse - the people you carved out silently start being imported, and the sanity brake cannot see it because the brake only guards against a sudden DROP. Both are now detected; the page says so, says GUID self-healing was not built, and says why detection came first. LDAP-and-Active-Directory.md had NO mention of importing at all, so pointing at it as "the manual" would have been false and anyone reading it would never learn the feature exists. Added the how-to: what comes across, choosing branches, checking the mapping, previewing, and the table of what happens when somebody leaves or a branch is renamed. Every file path and wiki link in both pages verified to resolve.
Directory sync: the full design conversation Records the whole thing rather than just the conclusions -- the request, what already exists, the thirteen questions and their answers with reasoning, the slicing, and the open questions. The most useful section is §4, "three things the first answer got wrong": - "two records unless you match on email" was IMPOSSIBLE -- users.email carries a UNIQUE index, so the second option could never have been built. The schema comment had already anticipated the entire question. Lesson: check the constraints before designing a setting that depends on them. - the setting that survived is better shaped: adopt an existing person or leave them alone and flag it -- with the consequence spelled out, that adopting kills their portal password. - usernames: a real problem but not the one it looked like. Global uniqueness exists BECAUSE the multi-company portal routes by email domain, so a mailbox-less user typing "smithj" has nothing to disambiguate them. Split into directory_username (per provider, never mangled) and username (global, only for people who actually sign in). Each of those was caught by a question rather than by testing, which is worth noting in itself. Linked from the sidebar under LDAP & Active Directory.