mirror of
https://github.com/Donkie/Spoolman.git
synced 2026-10-22 10:02:17 -05:00
github-sponsors-button
9
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Donkie
|
33ad8d7173 |
Show filaments you have no spools of
Grouping by filament aggregates over spools, so a filament you own no spools of could never produce a group and simply vanished from the library. A filtered view then looked fully stocked when it was the opposite, and the thing you needed to re-order was the one thing not on screen (#1092). GET /api/v1/spool/group takes include_empty, which inverts the query: spools are aggregated per filament in a subquery that the filament list is LEFT JOINed against, so filaments with no matching spools survive with their aggregates folded to zero. Which side of that join a filter goes is the whole subtlety, and the docstring spells it out - spool-scoped conditions have to stay in the subquery or they delete the very rows the flag exists to keep. The client asks for it while grouping by filament and every active filter is one a filament can answer on its own. "Which of these are on Shelf A" has no answer for a filament that is nowhere, and including them there would bury the shelf under the whole catalogue. Such a group renders as an out-of-stock row: no disclosure, no fetch, and a marker in place of the zeroes it would otherwise report. The group header also picks up the truncation tooltip added in the previous commit. Its title sits under a link stretched across the whole row, so the pointer never lands on the text itself and the tooltip has to hang off the row. |
||
|
Donkie
|
dd16672a4a |
Parse the datetime range grammar in one place
The previous commit claimed the built-in timestamps and the datetime extra fields share a grammar, then wrote that grammar out twice: once in add_where_clause_datetime_opt for the typed columns, once inline in add_where_clause_extra_field for the JSON-stored ones. Two copies of a grammar drift, which would quietly falsify the thing the change was for. The `<start>|<end>` split and its "at least one end" rule now live in split_datetime_range_filter, which both call. Only the parsing is shared, because only the parsing can be: an extra field is JSON text in a joined key/value table, reached through a subquery, while a built-in is a typed column on the row. The comparison that follows the split therefore stays separate, and the two are not equivalent. The built-in path parses the bound and compares real datetimes; the extra-field path compares decoded ISO strings, so an offset or a missing '.000' changes the answer there and not here. That asymmetry is now written down at both sites, and tracked in #1057. |
||
|
Donkie
|
dd39a11c7e |
Show every unassigned spool when grouping by an extra field
Fixes #1019. A dashboard card grouped by a custom spool field counted more spools than it listed: the group aggregate summed them, the card's own query returned a subset. Grouping and filtering disagreed about what "no value" means. group_by keys on the decoded value, so a spool holding the JSON empty string a cleared text box writes became its own group, separate from the null one; the client renders both as "unassigned" and adds the counts. The card then fetches its spools with `extra.<key>=`, whose empty branch matched only NULL and JSON null - never the empty string. Built-in string columns have matched both NULL and '' since forever (add_where_clause_str_opt), which is why grouping by location was fine. - The empty extra-field filter matches a stored empty string too. - Value-keyed group axes (extra fields, location, material) fold a blank into NULL, so "unassigned" is one group rather than two the client can only draw as one. - Emptying a text extra field clears it instead of storing "", so no new spool lands in the state above. - The dashboard clears an extra field with a real JSON null. It sent the string 'null', which the API rejects as not-a-string, so dragging a spool onto the unassigned card 400'd on every extra-field board. |
||
|
Donkie
|
c8be881e03 |
fix(sort): keep never-used spools and filaments at the bottom
Sorting the library by "last used" led with everything that had never been used, on PostgreSQL and CockroachDB. Those two default to NULLS FIRST on DESC, while SQLite and MySQL treat NULL as the lowest value and put it last; `last_used` is NULL until a spool is first used, so the default library ordering came out inverted for half the supported databases (#984, #985). Grouped views showed it worst: a group's date is the max over its spools, so a filament holding nothing but unused spools aggregates to NULL and floated to the top, above filaments used minutes ago. order_by_clauses() now orders on an explicit "is it null" flag ahead of the field itself, so an absent value sorts last in both directions everywhere. It is written as `expr IS NULL` rather than SQLAlchemy's nullslast(), which renders a literal NULLS LAST that MySQL and MariaDB reject. Applied to every sort site -- spools, groups, filaments, vendors, extra fields -- so ordering no longer depends on which database is underneath. Verified against all four: 438 integration tests pass on SQLite, PostgreSQL, MariaDB and CockroachDB, and both new regression tests fail on PostgreSQL without the fix. Claude-Session: https://claude.ai/code/session_01EaLK21WpQYDE1DkKwZHK3P |
||
|
Donkie
|
72daa29cd2 |
security: finish the audit's low-severity items
Task 10: config.js JSON-encodes the base path, so a backslash cannot escape the string literal the way the old " check allowed; search.py escapes LIKE wildcards at both its call sites, using a helper moved into database/utils.py so it and extra_field_query share one implementation. Task 9 was a pair of decisions rather than fixes. /info keeps its paths: both clients render them and removing response fields breaks API v1, while the disclosure buys nothing against an API that is unauthenticated anyway. /metrics keeps its shape but now says what it publishes when switched on. Also pins the unit tests to a throwaway data directory -- importing spoolman.main creates one as a side effect, and it was the real one. |
||
|
Donkie
|
aa447dd05b |
Let any spool field value be renamed everywhere at once
Renaming a dashboard card only worked for Location, which has a
server-side rename that moves every spool in one statement. A custom
field had no equivalent, so the card name was read-only unless the group
was empty -- renaming it from the client would have meant patching each
spool one at a time, and only the ones the board had actually paged in.
Generalise the location rename to the spool's other string fields:
PATCH /spool/field/{field} {"value": "Shelf A", "new_value": "Shelf B"}
-> {"spools_updated": 6}
where field is `location` or `extra.<key>`. Archived spools are included
-- the value is the value, and skipping them would leave half the spools
behind. Renaming onto a value already in use merges the two, though the
dashboard still refuses that so it can't happen by accident.
The old value travels in the body rather than the path, unlike
/location/{name}. Field keys are ^[a-z0-9_]+$ and so are path-safe, but
values are not: a location like "Rack A/B" needs an encoded slash, which
proxies routinely mangle. No reason to carry that flaw into the general
form.
Only fields the spool owns can be renamed. material/vendor/filament are
refused because they belong to another entity, and rewriting them "for
these spools" would change filaments that other spools share -- the same
rule that decides what the dashboard can group by, so grouping and
renaming now share one validator.
Like rename_location, no spool event is broadcast per row: the change is
one statement over what may be hundreds of spools, and that fan-out is
what the websocket layer avoids elsewhere.
Verified on all four databases, and in the browser on a 40-spool group
of which the board had loaded 30 -- all 40 moved, and the card renamed in
place without losing its position.
|
||
|
Donkie
|
21651216af |
Turn the locations page into a group-by-anything dashboard
The locations board could only ever answer one question: where is this spool. The same card-and-drag interaction works for any field a spool carries, so make the field a view mode and keep the rest. Location is still the default view and behaves exactly as before. The other views come from the user's own spool fields: any single-value text or choice field now appears in a Group-by menu. A choice field renders a card per choice, including the empty ones, which turns a "Status" field into a kanban board. Which field a card belongs to is decided by one small interface (src/lib/dashboard/fields.ts), so the page never special-cases a field. A field only qualifies if the SPOOL OWNS IT, because a drag moves one spool and must mean exactly one change. That rules out material and vendor, where writing one spool's card would silently rewrite every other spool of the same filament, and lot number, which is stamped on by the manufacturer and would be recording something untrue. Those stay library filters. It also rules out numbers, dates, booleans and multi-choice, whose values don't name a card you can drag into. Backing changes: - /spool/group grows group_by=extra.<key> for a spool's custom fields. The field table is aliased so it stays a distinct FROM element -- the extra-field filters reference the un-aliased table inside correlated subqueries, and without the alias those would correlate to this join instead of standing alone. Grouping is rejected for field types whose value isn't a single repeatable string. group_by is no longer a Literal, so an unsupported value is a 400 rather than a 422. - The saved layout is per field: dashboard_groups and dashboard_spoolorders replace the location-only pair. The old `locations` / `locations_spoolorders` are read once as a seed for the location view and never written back, so an upgrade keeps the shelves it had and the old client keeps working. - The view mode lives in the URL (?by=) so a board can be bookmarked and shared, and is mirrored to localStorage so a bare /dashboard resumes the last one looked at. The URL wins when it says something; a stale ?by= naming a deleted field falls back to location. Verified against SQLite, PostgreSQL, MariaDB and CockroachDB -- Postgres caught a real difference here, it sorts NULLs last where SQLite sorts them first, so the new group assertions are keyed rather than ordered. |
||
|
Donkie
|
d7486d5d51 | Improved filtering/sorting. Allows filtering/sorting by extra fields. | ||
|
|
470d8f3bcc |
Add filtering and sorting for custom fields (#773)
* Add filtering and sorting for custom fields * Fix tests and make code postgres compatible * Fix bugs and expand test coverage for custom field filter/sort * trigger CI * fix: address extra field filter review feedback * fix: clean up custom field table state handling * docs: update extra field table view description * fix: narrow boolean custom field filter syntax * Expand test coverage for all custom field types/entities and fix range filter/sort - Add comprehensive tests covering all 9 field types (text, integer, float, boolean, single-choice, multi-choice, datetime, integer_range, float_range) for filter and sort on spool, filament, and vendor entities - Add invalid-filter 400 tests for float, integer_range, and float_range - Fix integer_range/float_range filter to use LIKE pattern matching against Python's deterministic json.dumps output instead of fragile .contains() - Add integer_range/float_range sort support via a @compiles helper (_JsonArrayFirstElement) that emits CAST(col AS JSON)->>0 on PostgreSQL and JSON_EXTRACT(col, '$[0]') on SQLite/MariaDB - Add logger and __all__ to extra_fields.py (aligns with PR #893) - All tests verified passing on postgres, sqlite, and mariadb * Add filter UI for all custom field types and fix range filters - Add text input filter dropdown for text fields (substring search) - Add range input filter dropdowns (min/max) for integer, float, integer_range, and float_range fields - Add datetime picker filter dropdown for datetime fields - Fix boolean "No" filter to use empty value so it correctly matches unset/false fields - Fix integer_range/float_range filter to use numeric comparisons instead of LIKE-based exact matching (stored_min >= filter_min, stored_max <= filter_max) - Add range filter support for integer/float fields (min:max format) - Add _JsonArraySecondElement cross-database helper for extracting second JSON array element * Range filter for integer/float fields and fix range_field filter semantics Backend: - Add _JsonArraySecondElement cross-database helper (mirrors _JsonArrayFirstElement) - integer_range/float_range filter now uses numeric comparisons: stored_min >= filter_min and stored_max <= filter_max (was LIKE exact match) - integer/float filter now supports min:max range format in addition to exact match: stored_value >= min and/or stored_value <= max Frontend: - integer and float fields now use a range filter dropdown (min/max inputs) instead of a single exact-value input Tests: - Fix integer_range/float_range spool and vendor tests broken by new >= semantics (filter values updated to discriminate between test entries) - Add range filter tests (min only, max only, both) for integer and float fields * Replace 12 copy-pasted numeric field tests with 4 parametrized tests Introduce a _create_entity helper and @pytest.mark.parametrize("entity_type", ["spool", "filament", "vendor"]) to run each numeric field type test against all three entity types from a single test function. - Removes 12 individual tests (integer/float/integer_range/float_range × 3 entities) - Adds 4 parametrized tests covering the same ground plus the previously missing min-only / max-only range filter cases for filament and vendor - Uses try/finally for cleanup so entities are always deleted even on assertion failure * Add datetime range filter and restore integer/float range filter support - Backend: add datetime range filter using '|' separator (ISO dates contain ':') - Backend: restore integer/float range filter support (lost during attribution rewrite) - Frontend: replace single DateTimePicker with From/To range pickers for datetime fields * Use local timezone in filter picker; add range filter tests The DateTimeRangeFilterDropdown was initializing pickers with dayjs.utc(), causing them to display and accept UTC times directly. The entry form shows local time and converts to UTC, so the filter was inconsistent: entering the same displayed time would produce a filter value 2h offset from what was stored (in UTC+2), making exact boundaries fail unexpectedly. Fix: initialize picker values with dayjs() (local mode) so the filter picker behaves the same as the entry form — shows local times and converts to UTC. Tests: replace 3 separate entity-specific datetime tests with one parametrized test covering spool/filament/vendor, and add range filter cases (start|, |end, start|end). * Replace all entity-specific tests with parametrized tests Replace 16 separate spool/filament/vendor tests for text, boolean, single-choice, multi-choice, and empty-filter with 5 parametrized tests that run against all three entity types. Each test is now defined once and executed 3 times, eliminating copy-paste and ensuring consistent coverage across all entity types. Parametrize invalid-filter-value 400 tests across all entity types The non-numeric-value error uses "Invalid integer/float range filter value" while the missing-colon error uses "Invalid range filter value". Both contain "range filter value", so use that as the assertion substring. * Align custom filter dropdowns with Ant Design choice filter style All three custom filter dropdowns (text, number range, datetime range) now match the built-in choice filter footer: a border-top separator, Reset as a link button on the left (disabled when no filter is active), and OK as a primary button on the right. * fix(fields): correct custom-field filter edge cases across databases - Float exact-match filters now compare numerically (cast to Float) instead of by JSON string, so float fields stored as integer JSON (e.g. "2") or non-canonical decimals (e.g. "2.50") match an equivalent filter. - integer_range/float_range filter and sort no longer return HTTP 500 on CockroachDB: the PostgreSQL '->>' JSON extraction is now also registered for the cockroachdb dialect, which previously fell back to the unsupported JSON_EXTRACT function. - Text exact-match and single-choice equality use ensure_ascii=False so non-ASCII values match how the frontend's JSON.stringify stores them. Co-authored-by: Dieter Blomme <dieterblomme@gmail.com> * test(fields): expand custom-field filter/sort coverage Add tests covering filter composition (multiple extra fields, extra + built-in, filter one field / sort another), pagination total-count, unknown-field handling, text case-insensitivity/substring/non-ASCII, numeric multi-value OR, boolean empty semantics and token rejection, multi-choice substring collisions, empty filters on numeric fields, null-bounded ranges, and additional invalid-value 400 paths. Verified against sqlite, postgres, mariadb and cockroachdb. Co-authored-by: Dieter Blomme <dieterblomme@gmail.com> * style(client): format column.tsx with prettier The custom-field filter dropdowns' Reset buttons were written as one-line onClick handlers that prettier wraps across multiple lines. Apply prettier so the CI style check passes. Co-authored-by: Dieter Blomme <dieterblomme@gmail.com> * fix(fields): decode JSON scalars in-DB for text/choice/datetime custom-field filters Match text, single-choice and datetime custom-field filters against the database-decoded JSON scalar (new _JsonScalarText cross-dialect helper: #>> '{}' on postgres/cockroachdb, JSON_UNQUOTE(JSON_EXTRACT) on mysql, json_extract on sqlite) instead of reconstructing the exact JSON serialization the client wrote. This decouples matching from json.dumps/JSON.stringify encoding quirks (non-ASCII escaping, surrounding quotes). Also escape LIKE wildcards so '%' and '_' in text and multi-choice queries match literally rather than acting as wildcards. Verified against sqlite, postgres, mariadb and cockroachdb. Co-authored-by: Dieter Blomme <dieterblomme@gmail.com> * test(fields): cover LIKE-wildcard escaping in custom-field filters Add parametrized tests (spool/filament/vendor) asserting that '%' and '_' are matched literally in text and multi-choice filters, that a literal '/' (the internal LIKE escape char) matches literally, and that single-choice equality handles a '%' value exactly. Co-authored-by: Dieter Blomme <dieterblomme@gmail.com> --------- Co-authored-by: Donkie <daniel.cf.hultgren@gmail.com> Co-authored-by: akira69 <akira69@gmail.com> |