24 July 2026¶
1 change:
- User list queries now share the framework list engine
User list queries now share the framework list engine¶
Pramnos\User\User::_getApiList() no longer carries its own hand-written
search/paging/format code. User now implements the new ApiListSource
contract and delegates to the shared Pramnos\Application\ApiList\ApiListQuery
engine — the same one Model::_getApiList() uses — so both go through one
implementation instead of two copies that could drift.
Changed¶
User::_getApiList()now honours$filter. Previously the flat users implementation ignored$filter(and$join/$group/…); it now applies a$filter(raw WHERE fragment or structured-conditions array) to the users query, matchingModel::_getApiList(). The generated foreign-key picker passes no filter, so that path is unchanged.- Default ordering. With no
$order, the result now defaults touserid DESC(the engine's default), instead of the database's natural order. Explicit orders (username asc,-userid, comma-separated, …) work as before and now accept the engine's full order syntax. - Field defaults are unchanged and still safe. With no fields requested the
response still defaults to the curated
userid, username, emailset and never exposes the password column — preserved through a newapiListDefaultFields()seam so a source can validate against its whole schema yet default to a safe subset.
Internal¶
This completes the ApiListQuery extraction: the list-query building blocks
(ApiListSqlBuilder), the response envelopes (ApiListResponse), the
orchestration engine (ApiListQuery) and the ApiListSource contract are now
shared by Model and User. Verified against the full framework suite and the
reference application's suite (which drives the user foreign-key picker).