@acvl/frontend-components 0.0.90 → 0.0.91

package/dist/index.d.ts

@@ -2246,6 +2246,11 @@ interface FieldProps {
  * (`renderEditCellWithErrorTooltip` con `mutationErrors`); la ficha, sobre el campo. La columna
  * `codigo` del listado no es filtrable, así que el backend no tiene que atender `codigo__in`.
  *
+ * **Los filtros del recurso aceptan `id__in`.** El listado filtra la columna `nombre` eligiendo
+ * registros, y el panel de filtros manda los ids elegidos como `id__in` —en django-filter,
+ * `"id": ["exact", "in"]`—. Donde no lo atiende, django-filter ignora el parámetro en silencio:
+ * el filtro se ofrece y no hace nada.
+ *
  * Y lo que ya pide cualquier pantalla de la librería:
  *
  * - El listado, paginado con `results` y `count`.
@@ -2257,13 +2262,19 @@ interface FieldProps {
  * - Guardar (POST o PATCH) contesta `{ detail, list }`: `manualCacheRefresh` copia `detail` en la
  *   caché del detalle y `list` en el renglón del listado, sin volver a pedirlos.
  *
- * Y lo que necesita quien lo referencie, aunque ni el listado ni la ficha lo consultan:
+ * Y `como_opciones`, con `{ value, label }` y el id como `value`. De ahí saca sus opciones
+ * cualquier selector que liste el catálogo (`ControlledAutocomplete` con
+ * `queryArgs: { endpoint }`), y ya no sólo los de otros modelos:
+ *
+ * - **el propio listado**, para su filtro por nombre: la columna `nombre` lleva `queryArgs` con
+ *   este `endpoint`, y lo que el usuario elige ahí se manda como `id__in` —por eso el `value`
+ *   tiene que ser el id—;
+ * - el campo con el que el formulario de otro modelo lo elige, o la columna que apunta a él en el
+ *   panel de filtros de otra grilla.
  *
- * - `como_opciones`, con `{ value, label }`. De ahí saca sus opciones cualquier selector que
- *   liste el catálogo (`ControlledAutocomplete` con `queryArgs: { endpoint }`): el campo con el
- *   que el formulario de otro modelo lo elige, o la columna que apunta a él en el panel de
- *   filtros de otra grilla. Sin esto el catálogo se administra, pero no se puede elegir desde
- *   ningún lado.
+ * Al teclear, el selector busca con `nombre__icontains` (su `searchField` por omisión), así que
+ * los filtros del recurso lo aceptan también. Sin `como_opciones` el filtro por nombre del
+ * listado sale vacío y el catálogo no se puede elegir desde ningún otro lado.
  */
 interface DefinicionDeCatalogo {
     /**
@@ -2368,6 +2379,12 @@ declare const crearFabricaDeCatalogos: <BaseQuery extends BaseQueryFn<string | F
  * Un catálogo puede omitir alguna de las de la base con `ocultarColumnas` — quitar, nunca cambiar
  * lo que hacen; ver `DefinicionDeCatalogo`.
  *
+ * `nombre` **se filtra eligiendo registros**. El panel de filtros convierte la columna `nombre`
+ * en `id__in` (`filterFieldFor`): la lista que se manda son ids, no nombres. Por eso lleva
+ * `extra.queryArgs` con el endpoint del catálogo: el selector saca sus opciones del
+ * `como_opciones` de ese mismo recurso, cuyo `value` es el id. Sin `queryArgs` el selector
+ * aparecía vacío. `extra` sólo lo lee el panel de filtros; la edición en línea no lo toca.
+ *
  * `codigo` **no es filtrable**. En el panel de filtros una columna de texto es un selector
  * múltiple que filtra por `<campo>__in`, y el contrato no le pide al backend `codigo__in`: donde
  * no lo atiende —django-filter ignora en silencio el parámetro que no conoce— el filtro se

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@acvl/frontend-components",
-    "version": "0.0.90",
+    "version": "0.0.91",
     "description": "Component library for ACV frontend projects.",
     "homepage": "https://github.com/ACV-Logistics/acv-frontend-components#readme",
     "access": "public",