2c016de59eb8632baea27b31f99957083c88a16d
647 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
cproudlock
|
2c016de59e |
Guides answer the search box, and proofing catches what spellcheck cannot
A guide was invisible to global search. Core search has a hardcoded block per domain rather than a hook, so a new plugin stays unreachable until someone adds one - which is the same shape as the gap this test file already documents for USB devices and printed parts: records with a list page, labels in the world, and no way to find them from the search box. Guides are searched by title, summary, tags AND body. The body matters more here than elsewhere: people look for a procedure by something written halfway down it, not by a title they never read. PUBLISHED ONLY - a draft is deliberately invisible to readers, and search is exactly where that rule leaks if nobody writes it down. The test proves it with a draft sharing a tag and a body word with a published guide, so a missing filter would show up as a ride-along. PROOFING catches what a spellchecker cannot, because none of these are spelling: a smart quote in a command so it will not run, a checklist item with no text so a step is silently missing, a heading left with nothing under it after a reorganise, an image with no alt text, a TODO published by accident. Warnings, never blocks - somebody publishing at 14:40 with one empty bullet should be told, not stopped, and a procedure that exists imperfectly beats one nobody wrote. The smart-character issue reports once per block with a one-click fix, rather than once per offending character: an opening and a closing quote are one problem, and listing both makes the panel look like it is nagging. The character table itself is written as escapes. The style gate forbids non-ASCII in source, and a file whose job is detecting smart quotes cannot contain any - which the gate caught, correctly. |
||
|
cproudlock
|
a52437b40b |
Make writing a guide less like operating an editor
Seven changes, all aimed at the same thing: think about the procedure, not about blocks. Live preview beside the editor, rendered with the SAME component readers get, so what an author sees is what will be published - a separate preview implementation would drift within a month. Formatting buttons wrap the selection, so nobody needs to know the markup is Markdown. New blocks and pasted images land AFTER the block being worked on rather than at the bottom of the document, which removes the scroll-back that made adding a screenshot mid-guide annoying. Enter in a list makes the next item and focuses it, the way every other list in every other tool behaves; backspace on an already-empty item removes it and steps back up. Typing a ten-item checklist no longer needs the mouse. Templates, because the blank page is the real barrier to somebody writing a procedure down at all. The shapes are lifted from the KB articles the team already writes, so guides written here read like the ones written before them. Autosave on a three-second debounce with an honest status line, safe precisely because the server dedups on content - an autosave that changed nothing writes no version. Leaving with unsaved work now asks first. CLIPBOARD: the code block no longer writes to the clipboard. A page that programmatically copies a shell command is the exact shape of a ClickFix attack, where malware plants a command in your clipboard and talks you into pasting it into Run - and uBlock Origin blocked ours, correctly, because it was writing PowerShell on click. The button now SELECTS the code and says to press Ctrl+C: same convenience, decision back with the person, and nothing for security tooling to object to. AUTOCORRECT is on for prose and off for code and table cells. A code block that autocorrects produces a guide telling somebody to run a command that does not work - smart quotes replacing a straight one, an autocapitalised cmdlet - and it still LOOKS right to the author. The person at the bay gets the syntax error. |
||
|
cproudlock
|
cc1f8ff9fd |
Print a guide light, whatever the screen theme is
Printing a dark-mode page lays a full page of toner down for the background and knocks the text out of it in white. On a shopfloor printer that is a cartridge for a handful of guides, and the result is harder to read than the plain version. Somebody would have found this the expensive way. The theme tokens are redefined for print only, in an unscoped block because overriding them has to reach :root. Every guide element already renders through those variables rather than literal colours, so this is a dozen lines instead of a rewrite - the same discipline that made dark mode work without dark-mode code. Backgrounds are dropped rather than printed grey: a callout is identified by its rule and its heading, which cost nothing. Checkboxes print EMPTY even where they are ticked on screen, because a printed guide is a worksheet somebody carries to the bay, and one person's progress is not part of the procedure. The footer gains the print date beside the version, so a stale copy pinned to a noticeboard can be spotted. Also corrects the model and migration found by running this against a real database rather than SQLite: BaseModel contributes createddate, modifieddate and isactive to every table and the migration never created them, so the first read failed on unknown columns; the model had also declared duplicate timestamps on top, now removed with the API field names kept stable. And the slug is 191 characters, not 300 - it is UNIQUE-indexed, MySQL caps an index key at 767 bytes, and utf8mb4 is 4 bytes per character. |
||
|
cproudlock
|
38d1e367fc |
Guides: write a procedure in ShopDB, not beside it
The knowledgebase plugin is a link registry - a description, a URL and some keywords pointing at a document held somewhere else. That leaves the documents themselves as HTML files on a share: no search, no history, no way to know whether the copy pinned to a noticeboard is current, and no way for a technician to tick off where they are. A guide is stored as an ordered list of typed blocks rather than a blob of HTML, because three of the four things this feature exists for depend on it. A tickable step needs a stable id to be remembered; dark mode needs semantic markup rather than pasted colours; and print needs to know where a step begins so it does not split one across a page. Free HTML gives none of that and lets pasted styling fight the theme. Inline text is a restricted Markdown subset - bold, italic, inline code, links, line breaks - escaped BEFORE formatting, so nothing an author pasted can reach the DOM as markup. No fonts, sizes or colours: emphasis is semantic and the theme decides how it looks. That is what makes a guide written next year match one written today, and dark mode work without an author thinking about it. DRAFTS AND VERSIONS. The guide row is the working copy; every save that changes something writes an immutable revision; and a separate pointer says which revision READERS get. Without that pointer, editing a live procedure changes it under a technician who is halfway through following it. Publishing promotes an existing revision rather than snapshotting, so a publish with unsaved edits cannot ship a version nobody reviewed. Restoring writes a new revision with old content, so the record of what people were told in between survives. Saves dedup on a content hash covering title, summary, tags and blocks, so an autosave that changed nothing writes no version - otherwise the history fills with identical entries and hides the three edits that mattered. Progress lives in the browser, not the database: shopfloor PCs share a login, so per-user ticks would show one technician's progress to the next person on that bay, which reads as "already done". Keyed by guide and version, because step 4 of version 3 is not step 4 of version 2. Five permissions, and the split between edit and publish is the point: a technician can write a procedure up while somebody else decides it is fit for the floor. create-without-edit works too - an author may edit their own guide until it is published, after which other people are following it. |
||
|
cproudlock
|
28af92aaec |
An unmeasurable backup must not hide a working one
CI caught this: judging a host by its stalest kind treated a never-confirmed revision (lastseenat NULL) as the worst case, so it won. The verdict for a NULL confirmation is tri-state None, which renders as NO BADGE - so a host with a healthy ntlars backup and one backfilled row showed nothing at all. Hiding a working backup is the one thing that badge must never do. A NULL confirmation is not stale, it is unmeasurable. The stalest kind is now chosen among kinds that can actually be judged, which is the rule staleness.py already applies: a chain becomes measurable the first time its PC posts and says nothing until then. If every kind is unmeasurable the host still reports which kind it has, with a None verdict and no badge. The test that caught it pinned the old newest-wins behaviour, which part markers made wrong; it now pins stalest-measurable-wins and keeps its NULL clause, which was right all along and is what found the bug. Also worth recording how it was missed: the change was verified against test_geenforce_reporting.py and test_backups.py, and this assertion lives in test_geenforce_publish_gate.py, which was never run. |
||
|
cproudlock
|
52b9fa1ec1 |
Keep the site hostname out of the repair script test
The publication scrub gate rejects internal references, and a real site hostname in a test is still one in the published repo. The rewrite does not care which server it is. |
||
|
cproudlock
|
315d4f46ce |
Repair backup revisions that recorded a mapped drive
Snapshots written before the client was fixed stored "W:\backup\partmarker\..." as their location. That mapping exists only inside the SYSTEM logon session, only during an enforcement cycle, and only on the bay that wrote it, so the path recorded against a marker resolved to nothing for the person most likely to open it. The script rewrites backuprevisions.sharepath and nothing else - no revision is created, deleted, re-filed or re-hashed, and no file on the share moves, since the bytes are already where the UNC will point. Dry run by default. It matches on the drive letter alone and leaves everything else untouched, including paths that are already UNC and paths on another drive. This repairs a specific known mistake rather than normalising whatever it can reach, which is the version of this script that would eventually rewrite something it should not have. rewrite() is kept pure so the decision of WHICH paths to touch is testable without an app context; the tests cover the already-UNC, other-drive, empty, case-difference and trailing-separator cases. |
||
|
cproudlock
|
500f7d6ad6 |
Give the backups plugin a settings page, and show where a snapshot is
The plugin shipped five settings and no page for any of them. The core settings catalog is a hardcoded list a plugin cannot extend, so backups_shareroot and the collection interval were reachable only through the API or a flask shell on the server - which is not a configurable setting in any useful sense, and it is how today went: the setting simply was not there to set. The page is contributed the ADR-010 way rather than by editing core - a card from get_settings_cards plus a route in the plugin's own routes.js, both of which disappear when the plugin is disabled. Filed under Machines, next to Machine Types, because that is where the assets these back up live. It also states the two things the settings do not say for themselves: that health is judged on when a backup was last CONFIRMED rather than when it last changed, and that retention prunes database revisions only - files on the share stay, so enabling it on a share-backed kind leaves orphaned snapshot directories. Snapshot paths are now shown as full UNC text in both places: a Snapshot row on the Marker Contents card, and the existing path on the history page, which gains a copy button. Deliberately NOT a link - browsers refuse to navigate from an https page to file://, so a clickable path looks actionable and silently does nothing, which is worse than no link. Copy, then paste into Explorer. The path comes off the revision, never composed from the configured share root: a snapshot written before the layout changed still lives where it was put. |
||
|
cproudlock
|
ee208808f4 |
Judge a PC's backup by its stalest kind, not its newest
Until part markers, a PC reported exactly one backup kind and "newest revision wins" was the same thing as the truth. A marker bay reports two: ntlars for the machine's DNC settings, partmarker for the controller's patterns. With newest-wins, the daily ntlars post keeps the badge green while the marker backup has been failing for a month. The failure shows only on that marker's asset page, which is not where anyone looks to find out something stopped - and "is this still being checked" is the one question this badge exists to answer. So a host is green only when everything it backs up is current, and the badge names the kind that is not. Freshest revision per kind first, because lastseenat only ever moves on the newest revision of a chain; judging every row would report a healthy, frequently changing config as permanently stale. Known consequence, and the right direction to err: a device retired from a PC leaves its last revision behind, so that host stays stale until the revision is pruned. It complains about a backup that genuinely is not running rather than staying quiet about one. The dashboard card needed no change - it already lists every stale chain independently, so a stale partmarker chain was never hidden there. |
||
|
cproudlock
|
512cc9be76 |
Let a share-backed backup say what is in it
A 'share' kind keeps its bytes on the file share and gives ShopDB only a hash and a UNC path. That is right for an opaque vendor file, but it means the app cannot answer the question a tech actually arrives with - what does this part marker hold, and which pattern disappeared last month. Reading the share from the app server is not an option: the download routes refuse to mount it on purpose, because a permissions slip there becomes an unexplained empty panel. So the collector now accepts an optional manifest alongside the hash: the index, not the content. Names, sizes, per-file hashes, and the marking system each pattern was authored for. Advisory throughout - a client that sends none behaves exactly as before, and dedup still keys on contenthash. The marker asset gains a Marker Contents card built from it: counts by type, the controller family, and a diff against the previous snapshot in the same source chain. Removed files are named rather than counted, because "1 removed" only tells someone to go and look. Files edited in place are named too - the file set can be identical while the content hash moved, and reporting no change there would contradict the reason the revision exists. The manifest is deliberately NOT covered by contenthash, which attests the bytes on the share. A client that starts describing itself therefore posts an unchanged hash, so a no-op backfills a manifest the row does not yet have - otherwise the card would appear only on markers that had recently changed, and stay hidden on every healthy one. The same no-op refreshes sharepath, so a snapshot that moved on the share stops being pointed at where it used to be. Manifests are validated at ingest rather than at render: a malformed one would otherwise become the latest revision and fail every view of the asset page until the content next changed, outliving the client bug that caused it. sharedir() for the marker kind is overridden to the layout the site actually uses, so what ShopDB displays and validates matches what the collector writes. |
||
|
cproudlock
|
9d61e52ca7 | Record the vendor naming cleanup in the changelog | ||
|
cproudlock
|
23784b8199 |
Ship one name per vendor, and stop shipping a test row
Canonical names chosen by the site: Dell Inc., HP, Zebra. The rule is the same in each case - keep the spelling that holds the entries - it just lands on a different form per company. Dell Inc. carries 310 references and 33 models against 1 apiece for Dell and DellInc.; HP carries 51 and 24 while HP Inc. has none; Zebra carries 7 and 2 while Zebra Technologies has none. So HP Inc. and Zebra Technologies are gone from the shipped catalog. Both were empty rows that only ever offered a second way to spell a vendor already present, and neither exists in this site's database at all - they would have arrived as duplicates at a NEW site and nowhere else. Also removed UnscopedLiveVendor, which is a test artifact. It reached the catalog because export_catalog.py reads the live development database, so a row left behind by a lab run was published as reference data and has shipped to every site seeded since. Vendors 51 to 48. Verified nothing referenced any of the three before removing them, and the catalog still has no duplicates by any spelling. |
||
|
cproudlock
|
790ff3de38 | Correct the foreign-key count in the catalog changelog entry | ||
|
cproudlock
|
8bf2b8515f | Record the catalog dedupe commands and the seed cleanup in the changelog | ||
|
cproudlock
|
6106f4c5f4 |
Stop shipping duplicate vendors, models and operating systems
The seed catalog is what a new site inherits, so its duplicates propagate. Removed the four space-stripped twins it carried: vendor 'DellInc.', model 'OptiPlex7080', and operating systems 'MicrosoftWindows10Enterprise' and 'Windows10', each of which had a correctly spaced original already present. 'OptiPlex5000' was NOT a duplicate - no spaced twin existed - so it was renamed to 'OptiPlex 5000' rather than dropped, matching every sibling in the list. Its vendor moved to 'Dell Inc.', which this site treats as the one canonical Dell. Vendors 53 to 51, models 128 to 127, operating systems 14 to 12. Verified afterwards: no exact duplicate rows, no near-duplicates, no orphaned model-to-vendor or supply-to-model reference. |
||
|
cproudlock
|
d51127841d |
Merge catalog rows that are the same name typed two ways
The legacy data carried space-stripped twins: 'DellInc.' beside 'Dell Inc.', 'Windows10' beside 'Windows 10', 'OptiPlex7080' beside 'OptiPlex 7080'. They rode into the shipped seed catalog, so every site that ran `seed catalog` inherited them, and they stay invisible until somebody opens a vendor picker and finds the same company listed twice. Not a code fault. The collector strips only leading and trailing whitespace, matches with ilike, and treats the OS list as lookup-only, so it can neither have created these nor be creating more. They arrived with the classic-ASP import, which holds the same three pairs today. `flask catalog dedupe` merges only whitespace-and-punctuation twins, because those are one name typed two ways. 'Dell' and 'Dell Inc.' normalise apart and are left alone: that is a naming choice and only a person can make it. The surviving row is the most referenced, tie-broken toward the spaced spelling, which is the one somebody pressed the space bar for. `flask catalog merge` makes that judgment call explicitly, and refuses to invent a target that does not exist, so a typo cannot move rows into a new vendor. `flask catalog rename` handles the case neither can reach: a stripped name with NO twin, where there is nothing to merge into. All three report and change nothing unless --apply is passed, and dedupe is idempotent so it is safe in a deploy script. References are discovered from the LIVE schema rather than listed in code. There are 15 foreign keys into these three tables across 7 tables, and machines.controllervendorid and printerdrivers.modelnumberid are not ones anybody would enumerate by hand. Every reference is repointed before the row is deleted, so nothing is orphaned, and a plugin adding a table is covered without editing this command. |
||
|
cproudlock
|
7fb6bdba07 | Regenerate the project map for the new script tests | ||
|
cproudlock
|
13d951ea77 | Record the maintenance-script .env fix in the changelog | ||
|
cproudlock
|
7d7caba56b |
Let a maintenance script find the database the site actually uses
Running `python scripts/export_catalog.py` on a deployed site died with 1045 "Access denied for user 'root'@'localhost'", naming a user that site does not have. Nothing loads .env for a plain script run. wsgi.py calls load_dotenv() for the served app and the flask CLI loads .env for itself, so both reach the real database; a bare `python scripts/...` gets neither. DATABASE_URL then stays unset, FLASK_ENV defaults to development, and config.py falls back to a hardcoded root@localhost URL. The read-only failure above is the harmless version. Six of these seven scripts WRITE - backfill, reclassify, retype, collapse, refile, import - and on any box where those fallback root credentials happen to resolve, they would have silently rewritten the wrong database with no error at all. That is also why this survived: the dev .env points at root, so the fallback matched what the developer expected and nothing ever looked wrong here. All seven now load .env from the repo root, resolved from __file__ rather than the working directory, since these are run by hand during a deployment and rarely from the repo root. tests/test_maintenance_scripts.py pins it for any future script: every script that calls create_app must call load_dotenv, before create_app rather than after it, and with an explicit path rather than a cwd-relative search. |
||
|
cproudlock
|
5f915310c9 |
Point the lab's reference table at main too
The header stopped claiming the deleted feat/printedparts-plugin branch; its "where to look" table at the bottom still did. |
||
|
cproudlock
|
e90176d639 | Record the search-result and scaffolder fixes in the changelog | ||
|
cproudlock
|
90da0a1c09 |
Write down the plugin nobody documented, and stop pointing at a deleted branch
PLUGINS.md listed 14 of the 15 bundled plugins. `backups` had no row: the
per-asset configuration backups the collector takes off shopfloor machines,
kind-pluggable, with view and download as separate permissions because a .reg
is a restorable artifact. Added, with the pointer that separates it from
BACKUP-RESTORE.md, which is the database and a different subject.
PLUGIN-LAB-PRINTEDPARTS said the finished implementation lives on branch
feat/printedparts-plugin. That branch was deleted in the v0.8.0 cleanup; only
the 17 lab-stage tags survived, and they are enough. Says so now, and warns
that the tags are a record of contract 0.11-0.13 rather than today's
conventions. Its manifest example carried core_version >=0.12.0 against a
shipped >=0.16.0.
The printer-assignment proposal still said the client script is not built. It
shipped and released, across v0.11.3 and v0.12.0, and the collector half that
contradicted the assigned-vs-observed split was retired in
|
||
|
cproudlock
|
7b79a444b8 |
Scaffold a plugin's frontend into the plugin, so it can be pruned
`flask plugin new` wrote views to frontend/src/views/<name>/ and a route file to frontend/src/router/routes/<name>.js. Every one of the 16 bundled plugins keeps its frontend in plugins/<name>/frontend/ instead, staged into .plugins-staged by stage-frontend.mjs and aggregated into routes.gen.js. It was not visibly broken, which is why it lasted: the router still globs ./routes/*.js during the Phase 4 dual-location transition, so a scaffolded plugin's pages loaded. What a new plugin author silently lost was ADR-013 lean builds. Pruning works off the staged tree, so a frontend in the core tree cannot be excluded from a site build, and deleting the plugin strands its views behind. The templates for the correct layout already existed; only the output paths were wrong. Also fixed the imports they carry: core imports now use the @ alias (@/api, @/components/...), which resolves both before and after staging, where the previous ../../api was correct only in the old location. Sibling views stay relative and travel with the route file. frontend_dir is gone from scaffold_plugin. There is no second output tree to point at, and a plugin developed in its own repo now gets the same frontend as a bundled one rather than being skipped. Proven end to end: scaffolded a throwaway plugin, confirmed it stages, builds real chunks, and that SITE_PLUGINS=network prunes it, which is what the old layout could not do. |
||
|
cproudlock
|
eecb0595dd |
Open the record a search result found, not the list it sits in
A NOTICE result linked to /notifications, so clicking the row search had already identified dropped the reader on the list page to find it again by hand. The id was in the payload the whole time; only the URL ignored it. `/notifications/<id>` is the existing notification-detail route. The subnet searcher had the same defect two functions away: an IP search resolves which subnet the address falls inside, then linked to /network, the hub. It now links to /networks/<id>, the subnet detail route. Every other search result type already carried its id. These were the only two that did not. |
||
|
cproudlock
|
adc7ef43f9 |
Stop the collector being able to set a printer assignment
The printer feature rests on one rule: a collector report is OBSERVED state and never ASSIGNED state. If a drifted bay's own state can become what it is told to install, enforcement stops meaning anything, because a bay that installed the wrong printer makes itself right simply by reporting it. _sync_printer_links broke that rule. It ran on every collector PC push and, when the payload carried defaultprinter or printers, wrote defaultprinter and connectedto rows from the report - defaultprinter being one of the two types _reconcile_edges is meant to own alone, from authenticated routes a human calls. It was recorded as dormant. It was not. The collector schema ADVERTISED both keys and the example client in COLLECTOR-INTEGRATION.md set $payload['defaultprinter'], so the documentation was recruiting callers for it - while the same document, under "Observed is not assigned", promised that nothing on this path writes a usesprinter or defaultprinter row. The document contradicted itself and the code followed the wrong half. Nothing in the fleet armed it, because the first-party reporter never sent those fields, but any third-party client written from the docs would have. Retired the function, its _sync_one helper and the now-unused PRINTER_LINK_ORIGIN label, and removed both keys from the schema. IGNORED, NOT REJECTED. Unknown payload keys are not validated, so a client written against the old docs keeps pushing successfully and only its printer keys stop doing anything. The response warns, naming the keys and pointing at POST /api/collector/printers for reporting queues and seed-from-observed for adopting them. Dropping them in silence would leave an integrator believing assignments were still being written, which is a worse failure than the one being fixed. The docs were the larger half of this. The schema table rows are gone, the "PC -> printer relationship sync" section is replaced by a note saying what happens now to anyone still sending the keys, and the example client no longer enumerates Win32_Printer at all - it points at Report-PrintersToShopDB.ps1, which posts to the observed endpoint and posts NOTHING on a failed enumeration, since an empty list would erase the host's rows. test_collector_printers.py pinned the old behaviour, so it now pins the opposite: the keys create no relationships, the push still succeeds and says why, a payload without them stays quiet, a human-made default survives a report naming a different printer, and the schema no longer offers the keys. |
||
|
cproudlock
|
24435e6359 |
Let the warranty search find a machine number
Reported: the warranty page cannot be searched by machine number. It was there to be found. _related_machine puts the machine's number in the payload, and it does so for a stated reason - a shopfloor PC is bought, warranted and replaced as a PC, but it is FOUND by the machine it drives, and nobody walks the floor looking for an asset number. The table renders it as a chip. The filter looked at vendor, service level, service tag and asset number, and never at the machine. So the one identifier the feature was designed around was the one thing the search box could not match. This is how a field list goes wrong: a column was added to the table and not to the filter, and nothing connects the two. Moved the field list into warrantySearch.js so a test can see it, following controllingPc.js and labelPages.js. Machine name is searched as well - somebody who knows the bay by "the Makino" should not have to look up its number to find its warranty. The specs also pin the case that made the old inline version fragile: a covered asset whose machine is null, which is every printer and any PC nobody has linked yet, must not throw. And a missing field must not match: String(undefined) is 'undefined', so a naive coercion makes a search for "und" hit every row with an empty vendor. Not changed, worth knowing: the covered asset's NAME is still not searched, only its number. That looks like the same omission, but it is a wider change than the report - the placeholder has always said "asset" without saying which half - so it is left for a deliberate decision rather than folded in here. |
||
|
cproudlock
|
b96637e1a1 |
Let a baseline meet a table that is already there
Reported: `flask plugin upgrade-all` failed the tools plugin with "table securesendsecrets already exists". Every post-cutover baseline emitted a plain op.create_table. That is correct only while a table's existence and its plugin's Alembic stamp can never disagree, and they can. Anything that builds tables from the models - db.create_all(), which `flask db-utils create-all` calls - creates them and stamps nothing. A run that creates a table and then fails before its stamp commits leaves the same split, and re-running is the obvious thing to try. In both cases upgrade-all meets existing tables with an unstamped chain and the create is fatal. Nothing caught it because the migration test DROPS the post-cutover tables db.create_all() built before running upgrade-all. That arranges the one state where an unguarded create works, and never the state the report came from. The new test is the same sequence with the drop removed for the plugin under test. create_table_if_missing and create_index_if_missing are in alembic_template.py next to create_plugin_tables, which had the idempotency rule right and turns out to be called by nobody - its docstring claimed every 0001 used it. Fixed the docstring rather than rewiring the baselines onto it, because the reason they hand-write their DDL still stands: the helper's per-plugin MetaData cannot resolve a foreign key to a core table at CreateTable-compile time. INDEXES ARE MATCHED ON COLUMNS, NOT NAME, and that distinction matters. The two creators disagree about names - db.create_all() takes SQLAlchemy's default convention (ix_securesendsecrets_token) and a baseline spells it the way this repo's naming rules require (ixsecuresendsecretstoken). A name-keyed guard would have called the index missing and added a second one over the same column, which MySQL permits with a warning, so every affected site would have quietly grown duplicates. The test asserts no table ends up with two indexes over the same columns. Applied to all nine table-creating plugin migrations, not just the tools baseline that was reported: the four later migrations that create tables have the same exposure, and geenforce, measuringtools, printedparts and backups are the same defect waiting for a different site. WHAT THIS DOES NOT FIX. It makes a baseline idempotent, not a whole chain. A longer chain can still meet an ALTER whose column is already present - printedparts adding gagelabtag to a table create_all built at head is the case that showed up while testing. Guarding every op one at a time is the wrong answer to that; a database built from the models is already AT head and its chains want stamping rather than replaying, and there is no `flask plugin stamp` today. Left alone deliberately rather than half-built, and the new test is scoped to single-baseline plugins so it does not pretend otherwise. |
||
|
cproudlock
|
de3c5aa562 |
Stop re-creating a controlling-PC link that was already there
Reported: moving machine 3016 on the map and saving answered "this relationship already exists" and refused the save. The map had nothing to do with it. Every save of the machine form re-POSTed the controlling-PC link, and the server was right to refuse it - the row was already active, and assetrelationships is unique on (source, target, type). Any edit to a machine that has a controlling PC hit this; a position change is just the one somebody happened to be making. The form asked the wrong question. It used "do I know the existing link's id" as a stand-in for "is there an existing link", and read that id from rel.assetrelationshipid - a key the API has never emitted. to_dict serialises column names and the column is relationshipid, so the read was undefined on every load while controllingPcId was populated from the same relationship. The two answers disagreed, and the disagreement was invisible: undefined is not an error, it is just a falsy id. That single conflation caused both failures. Saving anything re-created the link, and CLEARING the controlling PC did nothing at all, because "no selection and no known id" reads as "nothing to do" - so removing a machine's controlling PC silently kept it. Only the first of those was reported, and the second is the one somebody would have trusted. Fixed by making the LOADED PC the authority on whether a link exists, with the relationship id used only to delete a row. If that id ever goes missing again the worst case is a link that cannot be removed, never a duplicate create. The decision moved to controllingPc.js as a pure function so it could be pinned by tests, following labelPages.js. Unchanged is now explicitly no-op rather than delete-then-create: re-linking a machine to the same PC opens a window where it has no controlling PC at all, and resolve_asset_position walks that edge, so a failure between the two calls would drop the machine's inherited position along with its link. The specs also cover a select handing back '42' against an API that gave 42, which would make an untouched link look like a swap and reach the same duplicate POST by another route. Not the printer assignment, which was the first guess: PrinterAssignmentPicker makes no relationship calls, and its save is wrapped in a catch that only logs, so it cannot surface an error from this form at all. |
||
|
cproudlock
|
ad9210b84a |
Write down the tool that was built, not the one that was tabled
Secure Send shipped on 21 August and nothing outside the code caught up. The roadmap still listed it under Deferred as "tabled", and gave as the reason that the tools plugin is browser-only by design with get_blueprint and get_models both empty - which stopped being true in the same day's commits that gave it a blueprint, a table, a migration chain, a permission and a setting. A reader following the roadmap would have concluded the feature does not exist. The generated API docs were fine: api-inventory.json and openapi.json both carry /api/tools/secrets, so the contract gates did their job. What was missing was every word written for a person, and that is the half where the security properties live. docs/SECURE-SEND.md is the new page. The parts worth having in prose rather than inferring from the code: that a lost secret is lost to everybody including an administrator, which is the same property as "a compromised database yields nothing" seen from the other side; that the 4096-character limit is the entire server-side enforcement, because a server that cannot read what it holds cannot have an opinion about content, so raising it turns a password tool into an unaudited file transfer; that redeeming is a POST because preview prefetch in chat and mail clients would otherwise spend a one-view secret before the recipient ever sees it; and that somebody should send a link to themselves through their own mail or chat client and confirm the key survives after the # before a real credential goes through it, because a product that rewrites links can strip the fragment and nothing on this side can help. securesend_allow_guests was in the database, on a settings page, and in no document. It is now in CONFIG.md with what it actually does - an unauthenticated write endpoint, rate limited per address, failing closed - rather than only its one-line description. Also corrected along the way: site_base_url was documented as scheme + host while the code deliberately tolerates a subpath in it, and the bundled plugin table in PLUGINS.md had no row for tools at all. Still missing after this: PLUGINS.md has no row for backups either. |
||
|
cproudlock
|
81575e46ca |
Give the guest setting somewhere to be changed
Reported: no Tools section in Settings. The setting existed in the database and had no page, which from a person's side is indistinguishable from the feature not existing. get_settings_defaults SEEDS a setting. get_settings_cards (ADR-010) is what puts it in the rail. Declaring only the first is a silent half-feature: nothing fails, no test notices, and the switch is unreachable. The page states the cost where the DECISION is made rather than in a document nobody opens - turn it on and it says a guest-created link records no creator, so the audit trail can say when and from where but never who. Admin-only, like every other settings page, because this one decides whether an unauthenticated caller may write to the site. Also caught while wiring it: the card asked for a 'shield' icon, which is not in the settings iconMap, so it would have rendered the fallback puzzle piece - the glyph that reads as "nobody chose this". Uses wrench, matching Tech Tools. The row still comes from `flask plugin upgrade-all`; the card appears either way, and without the row the page loads empty. |
||
|
cproudlock
|
92cf1d71f0 |
Stop making people sign in to reach tools that need no account
/tools, /tools/codes and /tools/secure-send were all behind requiresAuth. None of them needed to be, and one of them actively contradicted a setting added an hour earlier: securesend_allow_guests lets somebody with no account create a link, and the page they would create it on was behind a login wall. The label generator runs entirely in the browser - no API, no data, nothing to protect - so gating it only ever cost a guest the use of it. THE SERVER STILL DECIDES who may create a secret. A signed-in user needs tools.secrets; a guest needs the site to have opened guest creation. Making the page reachable is not the same as making the action allowed, and the two were conflated. The page now reads the setting on load, so a guest at a site that has NOT opened guest creation is told to sign in instead of being handed a form that was always going to be refused - with a line saying that receiving a link never needs an account, because somebody who lands there confused usually has a link they should be opening instead. A signed-in user always sees the form, even without the permission: the server's "you do not have permission" is a different answer from "sign in", and collapsing them would send somebody to a login page they are already past. |
||
|
cproudlock
|
8750ba2e74 |
Let a site open secure send to guests, and choose how many times a link opens
Two asks, and the first is a real security decision so it is a SETTING that defaults to the safe answer rather than a code change somebody inherits. securesend_allow_guests, OFF by default. With it off the model is unchanged: a login plus tools.secrets. With it on, somebody with no account - at a shared bay terminal, a contractor - can create a link too. The cost is named in the setting's own description and pinned by a test: a guest secret has NO CREATOR, so the audit trail can say when and from where but never who. That is the whole reason it is a switch a person turns on deliberately. IT FAILS CLOSED. A missing row, a half-migrated site, an unhappy database - the answer is no. An error must never be the thing that opens an unauthenticated write endpoint. A SIGNED-IN USER STILL NEEDS THE PERMISSION even when guests are allowed, which is surprising enough that a test pins it: opening the door to guests is a decision about the door, not about revoking what a role holds. Guest creation is rate limited per address, same shape as the login limiter. Not a security boundary - a determined person has more addresses - but an open endpoint should not be an easy place to park data or fill a disk. VIEWS ARE NOW A NUMBER, 1 to 100, instead of a four-item dropdown. How many people need a password is the sender's business: a shift handover is not one colleague on a call. The floor is what matters, not the ceiling - unlimited views would just be a password on a web page. Also folded in, from the retention question: nothing removed a secret that EXPIRED WITHOUT BEING OPENED. The recipient goes on holiday, the link is never clicked, and the ciphertext sat there for good - not readable, but it made "nothing lingers" untrue and grew the table in exactly the case where the feature failed. Any create now sweeps expired rows and a late click tidies its own, so it stays bounded without a scheduler an air-gapped site would never add. Two gates caught mistakes on the way: current_user is a LocalProxy and is never None, so `current_user is None` silently took the signed-in branch for a guest; and cache was imported straight from shopdb.extensions when it is already on the shopdb.api contract surface. 1836 tests green. |
||
|
cproudlock
|
fc46bab72d |
Say that the subpath belongs in site_base_url, because it does
Answering "did I set it wrong": no. The setting was right and the description was misleading, which is what sent the last two commits chasing the wrong fix. It said "Public base URL of this site (scheme + host), e.g. https://shopdb.example.net". That is true only of a site mounted at the root. Both existing consumers append the in-app route to this value and add nothing themselves: `${await getSiteBaseUrl()}${config.detailPath(detailId)}` asset labels `${baseUrl}${defaultPath}` QR codes so a site served at /shopdb must carry that here or every QR code it prints 404s. The email copy of the same setting has always documented it correctly, as https://host/ops. The description now says so, and the comment above the defaults records why - including that a subpath left out produces links that fail rather than anything that looks like a configuration error. Existing rows keep the old text until a site reseeds; the value is unaffected. |
||
|
cproudlock
|
e8920b2cf3 |
Do not add the mount to a site URL that already has it
|
||
|
cproudlock
|
a3811740bb |
Build a secret's link from the site's URL, not the browser's
Reported from production: clicking a secret link gave an IIS 404, and the link read /s/<token> where the site lives at /shopdb/s/<token>. The link was assembled from window.location.origin, which is scheme and host only. site_base_url already exists for this and says so in its own description - "used for QR codes and any absolute link the app emits" - with getSiteBaseUrl() as the helper the QR pages use. This reached past all of it. Both halves were wrong, and the second is worse because it fails silently: MOUNT PATH. A site served under /shopdb or /ops carries that in front of every route. Leaving it off is the reported 404. HOST. Whoever creates a secret may have reached the app by an IP, a short hostname, or a name that resolves in one VLAN, and the recipient opens the link from somewhere else entirely. The configured site URL is the one address known to work for both of them. The shape of this failure is what makes it worth spelling out: the secret was created SUCCESSFULLY and the sender was handed a link that could never work, so the failure landed on the recipient, the sender had no reason to doubt it, and the secret expired unread. A 500 would have been kinder. Falls back to the browsing origin when a site has not set site_base_url, which is what every other absolute link here does. BASE_URL is injected at build time, so the subpath half of this cannot show up in dev and only appears on a subpath deployment. |
||
|
cproudlock
|
7fc109d91a |
Give secure send a card, a form, and a page for the person receiving it
The backend has been there since
|
||
|
cproudlock
|
d4b49b91b4 |
Move secure send into Tech Tools, where somebody would look for it
|
||
|
cproudlock
|
98458672eb |
Hand somebody a password without leaving it in a chat window
The habit this replaces is pasting a credential into Teams, where it stays until someone deletes the conversation. Tabled on 2026-08-21 pending a decision about scope; the decision was text only, so this is the half that survives it. BACKEND ONLY. There is no page yet, so nothing here is reachable by a person. TEXT, NOT DOCUMENTS, and that shapes everything. Dropping files removed the export-control question entirely - a password is not technical data - along with blob storage, size and MIME handling, and the need to authenticate the recipient so a document fetch could be pinned to a name. TWO DOORS. Creating needs a login AND securesend.create: anonymous creation would be an untraceable way to move data out of a system that otherwise records who did what, and the creator is the only person these rows can ever name. Reading needs neither, because the recipient usually has no account here and the link is handed over on a call - the unguessable token IS the authorisation, which is why it is 128 bits of randomness and why the row is spent on first read. REDEEMING IS A POST, and that is the detail that would have broken this in practice. Teams, Outlook and Safe Links prefetch GET urls to build previews and scan for malware, so a GET that redeemed would let a preview window consume a secret before its recipient ever saw it. The GET route that remains reports only whether a link is still live, so the read page can say "opening this will destroy it" without spending the only view to find out. THE SIZE LIMIT IS THE WHOLE ENFORCEMENT. The key lives in the URL fragment, which browsers never transmit, so the server holds ciphertext it cannot read and cannot tell a password from a page of a drawing. MAX_CIPHERTEXT is therefore not a tuning knob: raising it quietly turns this into the document transfer it was scoped not to be. The refusal says what the limit is FOR, because somebody hitting it is usually trying to send a file and the answer is a different tool. Line counts, file signatures and refusing a pasted file belong in the browser, guide an honest person, and are bypassable by anyone willing to POST directly. NOT ENUMERABLE. Missing, expired and spent all answer identically - telling them apart would confirm to anyone holding a guessed token whether it ever named anything. A spent or expired row is deleted on the way past rather than waiting for a sweeper, because it has no reason to keep its ciphertext. Its own plugin rather than a Tech Tool: that plugin is browser-only by design, and this needs storage, expiry and a view counter. Not an asset extension either, so no assetid and no asset type - the scaffold assumes one and it was removed. FOUND BY ITS OWN TESTS: expiryhours=0 returned 201. `int(x or DEFAULT)` treats an explicit zero as absent, so "expire immediately" silently became "expire in a day". A caller who sends a number is now told when it is not allowed rather than quietly given a different one. BEFORE ANYONE RELIES ON THIS, test that your link rewriter preserves URL fragments: create a secret, send the link to yourself in Teams, click it from the message, and check the key is still after the #. If Safe Links strips it the secret is unrecoverable and the server cannot help, which is the point of the design. The fallback is passphrase mode, worth building only if that test says so. Three product gates caught what a new plugin has to declare, and each was right to: the route-parity gate wanted the endpoints described in api-inventory.json, the lean-build guard wanted the plugin listed in the universal profile the released installer builds from, and the authz sweep wanted the public redeem route named in EXEMPT_ENDPOINTS with a reason. That last one matters most - a mutating route that answers an unauthenticated caller is a decision somebody has to write down, not a default, and reading a secret is a mutation because it spends it. |
||
|
cproudlock
|
f09d14d28c |
Refuse a measurement that makes the label stop existing
Reported as a barcode rendering 176 by 0. A bar height of zero is what does it: the number went straight into a CSS length, height: 0in is perfectly valid, and an image sized height: 100% of a zero-height box is zero pixels tall. The label comes out full width with nothing on it, which reads as a rendering failure rather than as a field doing exactly what it was told. A cleared field was the same bug wearing a different hat. An emptied number input holds '', not 0, so the page emitted `NaNin`; the browser dropped the declaration and the box fell back to auto height. That one merely looked wrong instead of vanishing, which is arguably worse for finding it. Measurements now go through labelVars(), which will not emit NaN, an empty length, or a zero for anything whose zero means the box stops existing. Padding, the quiet zone and the gap still take zero, because there zero is a real answer, and offsets stay signed. It is a separate module because this is exactly the kind of arithmetic that needs tests rather than a preview: every case in labelVars.spec.js is a value a number input can actually hold. The stylesheet now carries fallbacks on its var() reads as well, but they are a net, not the fix: a custom property set to garbage is substituted and then dropped at computed value time, and the fallback does not apply - it only covers a property that is absent entirely. |
||
|
cproudlock
|
3703412baf |
Only zero is empty, and the last day is worth reading
Two separate floors were collapsing a live cartridge into a spent one, and removing either alone changes nothing. EMPTY_LEVEL was 5, so everything at or below 5% was assigned daysleft 0 outright. The reasoning was that a printer at 1% is out of toner as far as anyone standing at it is concerned. But the row exists to say how long is left, and 2% draining a point a day has two days in it. Flooring put that cartridge beside ones that genuinely are empty with no way back to the difference. It is 0 now: empty means empty. int(level / rate) then truncated the division, so anything under a full day arrived as 0 whatever the floor did - a cartridge with six hours in it was indistinguishable from one with nothing, and the band read it as empty. daysleft is fractional now, rounded to two places, which is about a quarter of an hour: finer than the estimate deserves, but it costs nothing and keeps the ordering of two nearly-spent cartridges meaningful. daysText reads in whatever unit carries meaning: "6 hours", "1 hour", "29 min", "4 days". Below an hour it goes to minutes with a floor of one, because rounding hours would land back on "empty" - the same bug one rung down. BEHAVIOUR CHANGE worth knowing: a cartridge at 1-5% with NO history used to get daysleft 0 from the floor and land on the order list. A rate needs two readings; with none there is nothing to divide, and the old answer was right by accident - it said "empty" about a level nobody had watched move. It now reports 'no history' and shows under "No estimate yet". This reaches only printers newly added to Zabbix; anything that got to 3% the ordinary way has the history to forecast from. Five existing tests pinned the old rule. They recorded a real decision, so they are rewritten to the new one rather than deleted. One of them was passing for the wrong reason: its series (2.0, 1.7, 1.4, 1.1) drops 0.9, under MIN_DROP_FOR_ESTIMATE, so it never had a rate at all and only passed because the floor short-circuited ahead of the rate check. It now uses a real 20-day drop at a tenth of a point a day and asserts the ten days its docstring always described. The forecast fixture's black cartridge moves from 1% to 0% so the empty band keeps its API-level coverage, and a magenta at 3% covers hours-left end to end. |
||
|
cproudlock
|
e9fcd1e598 |
Stop a caption from eating the barcode, and put the labels beside the settings
Reported as the CODE128 not appearing in the preview. It was appearing, in 44 of the 45 preset and layout combinations swept - as a 36 pixel stub. The code box and the caption were both allowed to grow, so a caption of any length took half the label and then kept taking, and on 1.00 x 0.50in stock a few words of caption left a barcode too narrow to scan. Present, useless, and indisinguishable from a failed render. The caption now takes the room it needs and no more, and a CODE128 holds at least 40% of the label, or all of it when stacked: past that there are too few narrow bars left to read, and a caption that wraps or clips is the better trade. So that a real failure can never again look like this one, an empty code box now says so in red in the preview. It is screen-only - the marker must never reach a printed label. The settings were a narrow column with the preview trailing below them, which put the labels being adjusted off the bottom of the screen. Settings on the left, labels on the right in a column that stays in view and scrolls on its own, folding back to one column on a narrow window. That scrolling column is a print hazard worth naming: an ancestor with its own overflow clips a multi-page print to whatever happened to be on screen. Print resets it, and the check is a six-page two-sided run coming out as six pages with the label as the only clipping box in the chain. |
||
|
cproudlock
|
b7cfd2b198 |
A supply nobody could read is unknown, not empty
Reported as "CSF04 now reports all 0%", on the printer's own page as well as
the reports. Every supply on one host reading zero at the same instant is not
what a set of cartridges does; it is what a host that stopped answering looks
like.
getsuppliesbyip turned every unreadable item into 0:
try:
level = int(float(item.get("lastvalue", 0)))
except (ValueError, TypeError):
level = 0
An item that has never collected returns lastvalue as an EMPTY STRING, so
float('') raised and the handler substituted zero. lastclock was fetched in the
same request and read by nothing at all, so a reading from three weeks ago was
presented as current.
Zero is a legitimate level meaning spent, which is what made the substitution
dangerous rather than merely wrong. Downstream it reached `level <=
EMPTY_LEVEL`, which set daysleft to 0, which put the printer on the order list:
the report asked purchasing to buy a full set of cartridges for a printer
nobody had measured. On a waste container it was worse - waste is scored as
100 - level, so an unreadable one read as 100% full, the alarm state.
_readlevel now returns (level, lastseen) with level None for no usable reading:
empty, missing or unparseable lastvalue, or a lastclock older than 24h. A
lastclock that is absent is not treated as stale - a reading that cannot be
aged is not thereby wrong, and discarding it would lose real levels. A genuine
"0" is still 0, which is the half that keeps an actually-empty cartridge on the
order list.
classifysupply gains an 'unknown' status with remaining None. It is not
critical: critical is a claim someone acts on, and it may not be made about a
supply nobody measured.
The low-supplies report skips unknown rather than listing it as needing
replacement, and counts it in summary.unknown - a printer that has gone quiet
should be visible as that, not absent and not masquerading as empty.
_annotate_supply reads .get('level') with no 0 default, which would have put
the whole bug back.
PrinterDetail already rendered `level !== null ? ... : 'N/A'`, so it starts
telling the truth as soon as the backend sends null; the UI had been written
for a case the service never produced. It gains the unknown style - muted, not
a severity colour - and a tooltip separating "no reading at all" from "no
reading since <date>", which are different faults with different fixes.
Alerts needed no change: float(None) raises and that loop already continues,
so unknown supplies stop firing low-toner emails as a consequence.
12 of the 16 new tests fail on the old code. The 4 that pass either way pin
that real zeros still behave, which is the regression this fix could cause.
Not verified against CSF04's actual Zabbix data - dev has no reachable Zabbix.
This fixes the mechanism that turns unknown into 0%; /api/printers/<id>/supplies
now distinguishes them, with null for no reading and 0 for a measured zero.
|
||
|
cproudlock
|
f9d298c7f0 |
Name the toner on the forecast, keep the number on the hover
The forecast identified a cartridge by its part number alone. 'W2020X' only tells you which toner it is once you already know, and both places that name a supply - the Order now list and the Part column - showed nothing else, so the report read as a list of codes. Both now show marketingname, which is what the box says: '414X Black'. The part number moves to the title attribute, one hover away, because it is still the thing an order is placed against. A supply with no name on file falls back to the number rather than showing an empty cell; marketingname is nullable. 'Copy list' is deliberately untouched. It writes the part number verbatim, which is what purchasing pastes into an order, and a spec pins that the name does NOT reach that text. firstPart() now returns the whole part row rather than its number, since the cell needs both halves. It has one caller. Dropped the .partnumber style with its .unmapped variant: nothing renders that class any more, and the variant was already dead - the unmapped block lists no part number by definition. Verified by mounting the component against a fixture. The dev box has no Zabbix, so the page itself has no rows to look at there. |
||
|
cproudlock
|
5001aedcf9 |
Offer a spelling on every list, not just the global search
Correction only helped on the global search page, and people search from the list they are already on. Extending it turned out to be a shape question rather than a volume one: thirty routes take a search parameter across a dozen files, so carrying a suggestion in each of their responses is a large change today and one more thing every future plugin author has to remember. So the suggestion moved to ITS OWN ENDPOINT, /api/search/suggest, which any page can call after rendering no rows. A page that has not adopted it shows nothing, which is exactly what it showed before - nothing breaks by omission. The plumbing lives in useListQuery, which already owned the search term, so a list needs three lines: take `suggestion` and `reportCount` from the composable, call reportCount(rows.length) after a fetch, and drop SearchSuggestion into the empty state it already has. A list that never calls reportCount never offers a suggestion. Wired: global search, machines, printers, PCs, network devices, measuring tools, knowledge base, vendors. NOT wired, deliberately: the type and reference lists (machine types, PC types, VLANs, subnets, operating systems and the rest), which are small controlled vocabularies nobody typo-searches, and USB, whose empty state has a different shape and wants doing by hand rather than by pattern. TRAP FOUND WHILE WIRING IT, and left commented in every page: applying a suggestion by calling setSearch alone updates the box and the URL and does NOT reload the list. setSearch only syncs the URL, and the watcher that would reload is suppressed because search.value already holds the new term - the same trap the global search page documents in performSearch. Each page calls its own load function directly. The composable guards a stale answer arriving after a newer search was typed, never offers back the word that was typed, and swallows its own errors: a search that found nothing is already the answer, and failing to improve on it is not worth an error in front of anyone. The route-parity gate caught the new endpoint being served without an entry in docs/api-inventory.json, which is hand-written on purpose; added, and the spec regenerated from it (283 paths, 418 operations). That regeneration also carries the openapi version to 0.12.0, left over from the release. |
||
|
cproudlock
|
1abb6430f5 |
Put a code on the back of a card, a picture on the front, and the page in the app
The back side landed last commit carrying text by default, and a back laid out as text-only renders no code box at all. So a two-sided run came out with a blank reverse, which reads as the code having failed rather than as a setting doing exactly what it said. The back now defaults to carrying a code, takes its own content per row, and chooses its own symbology - a QR on the front that opens the record, a CODE128 on the back that the bench scanner already reads. Text-only is refused while the back carries a code, and the contradiction is reconciled on load, so a saved setting from the broken combination repairs itself rather than printing another blank box of cards. A picture can go on a label: above the code, beside it, or behind everything as a watermark, on either side or both. The file is read in the browser and never sent anywhere, which is what makes it usable at an air-gapped site, and it is deliberately not saved between visits - a data URL runs to megabytes and would take every sizing value with it when the quota gave out. The watermark says plainly that it costs the scanner contrast. The generator was a full-screen route with no navigation and a narrow column of controls against the left edge. That shape exists so a print cannot put the sidebar on label stock, which is a real hazard and the reason core's label pages are built that way - but it is a hazard the print stylesheet can answer, and style.css now hides the shell at print time. A tool someone spends ten minutes in gets the navigation and the full width; the stock still gets nothing but labels, confirmed against a print PDF rather than a preview. Two smaller things found while checking the above. A test print paired each page with a rendered code by loop position, while the codes are keyed to position in the whole run, so a two-sided test card could carry the wrong code; the index now travels with the page. And the back's dotted preview outline outspecified the print reset, drawing a dashed rule down the edge of every second card. |
||
|
cproudlock
|
1593ee8204 |
Offer a spelling when a search finds nothing
The corrector landed in
|
||
|
cproudlock
|
fa0f6d7ebc |
Record what nobody can find, and a spelling corrector that refuses to guess
Two halves of one question - how to handle a misspelled search - deliberately kept separate, because only one of them should be turned on today. WHAT NOBODY CAN FIND IS NOT RECORDED ANYWHERE. A search returning zero results is the only evidence of the gap between what people look for and what is there, and it vanished. Logged now at INFO with a stable prefix, so a week of it greps into a list. That list is what should decide whether correction is worth wiring in: multi-word matching and cross-field matching both changed in the last day, so a good share of what used to fail may already be found. The failures left over might be typos, or vocabulary nobody has entered, or records that genuinely do not exist - and each wants a different answer. THE CORRECTOR IS BUILT AND NOT WIRED IN. shopdb/core/services/spellfix.py, with tests, ready to attach in about ten lines once there is evidence about what to attach it to. NOT SOUNDEX, which was the obvious candidate. MySQL has it and SQLite does not, and the suite runs on SQLite while production runs MySQL - so a SOUNDEX() in a query is either an error in every test or a production path no test executes. It is also wrong for this data: soundex is English-name phonetics, four characters wide, and it DISCARDS DIGITS, so CSF16 and CSF17 hash identically. Half of what people search here is an identifier. So: character distance in Python, same behaviour on both dialects. THE VOCABULARY IS THE DATA. No dictionary holds Genspect, Telesis, Keyence or wax-trace. Terms come from the columns being searched, which also means a vendor added this morning is correctable this morning. TWO GUARDS, and they are the point rather than a detail. Digits must match EXACTLY: CSF16 to CSF17 is one edit and a different bay, so anything carrying digits is either right or not correctable - while cfs16 to csf16 still works, because the guard is on the digits and not on identifiers wholesale. And the first character must match, since typos land mid-word far more often than on the first key, which costs almost no recall. Distance is Damerau-Levenshtein so a transposition costs one edit rather than two - Keyecne for Keyence is the commonest error there is, and plain Levenshtein pushes it past the threshold on short words. Allowed distance scales with length. A tie returns NOTHING: two equally good candidates means there is no answer, and offering either implies a confidence that is not there. It suggests; it never rewrites. Silently searching for something else is how somebody orders the wrong cartridge. 13 tests, weighted toward the refusals, because those are the cases where being wrong costs something. |
||
|
cproudlock
|
41d875da4e |
Put the hover marker back in the box's coordinate space, letterbox and all
|
||
|
cproudlock
|
2bf1531d5b |
Measure a hover marker against the drawing, not the box around it
Reported from the floor: some assets showed their hover mini-map marker way off to the left, outside the map, while the SAME asset sat correctly on the main map. The data was right; the preview was drawing it wrong. The preview is a fixed 390x300 box and the drawing was painted into it with object-fit: contain, which letterboxes or pillarboxes to keep the drawing's own aspect ratio. The marker, though, was positioned at a percentage of the BOX. So the marker and the drawing were measured in two different coordinate spaces, and they only agreed when the level's aspect ratio happened to be 390:300. A level near that ratio looked perfect - 3300x2550 is 1.294 against the box's 1.300 - which is why this read as "some devices" rather than "the feature is broken". A taller drawing pillarboxes, every marker's x shifts, and one near the left edge lands in the grey gutter beside the map. The image now SIZES the frame instead of filling it: the transform box shrink-wraps the image and the image scales down to fit. A percentage of the frame is therefore a percentage of the drawing by construction, at any aspect ratio, and the letterboxing moves out to the preview around it where it does no harm. dimensionsFor still converts the stored pixels to percentages - that part was always right. NOT visually confirmed against a live instance. The reasoning is traced and the build is clean, but the shape of this bug is that it looks correct on any level close to the old box ratio, so it wants a look at an asset that was landing left and one that was already fine. Related and NOT addressed: the wheel zoom applies translate percentages that resolve against the element and are then multiplied by scale, so a zoomed preview may still drift. At rest, which is the reported case, it is exact. |
||
|
cproudlock
|
d0eeaa08d5 |
Find a knowledge base article by words from different fields
An article's searchable text lives in three places: its title, its keywords,
and the name of its topic. Nobody typing a search knows or cares which word
came from which, so 'CMM Community' means "the article tagged community, under
the CMM topic". Both search paths returned nothing for it.
The plugin's own listing, which is what the KB page calls, built a single
ilike('%CMM Community%'). That needs the whole phrase contiguous in ONE field,
and no article has it: 'CMM' is only in the topic's name, 'Community' only in
the keywords. Global search already split the query into words but only ever
looked at title and keywords, so a word that only the topic could satisfy
failed there too - the same bug wearing a different face.
Every word must now be found somewhere across all three fields, in any order.
_word_match gains an `extra` hook for a word that a RELATED row satisfies
rather than a column of this table, which is how the topic joins in without
colliding with the sort=='topic' join.
The retired-topic rule is unchanged and pinned on both paths: matching more
words is not a way past it.
Verified against the 235-article dev library, where all three of these
returned nothing before: 'Fieldglass Jefferson' (title word plus topic word),
'outage notification' (two keywords, not adjacent), 'compucom Jefferson'.
The same phrase-only pattern is repeated in about ten other list endpoints
(computers, machines, printers, network, printedparts, measuringtools, usb,
notifications). Left alone here - fixing them properly means promoting the
word-match helper onto the shopdb.api contract surface rather than copying it
per plugin, which is a contract bump.
|