Tus tareas, tus campos: campos personalizados por workspace
Hay una conversación que se repite: «esto me encaja, pero yo necesito apuntar el cliente en cada tarea». O el importe. O si ya está facturado. Cosas que no están en el modelo de un gestor de tareas y que, sin embargo, son la mitad de tu trabajo.
Hasta ahora la salida era meterlo en el título («[Acme] Revisar contrato») o en una etiqueta por cada cliente. Funciona hasta que quieres sumar importes, o filtrar por lo que falta por facturar, y descubres que tu dato vive dentro de una cadena de texto.
Desde hoy puedes definir tus propios campos.
Cinco tipos y ya
En Ajustes → Campos personalizados, un admin del workspace crea los campos que le hagan falta. Cada uno tiene un nombre y un tipo:
- Texto — un cliente, una referencia, un número de expediente.
- Número — importe, horas, puntos. Admite decimales y negativos.
- Fecha — entrega, vencimiento, firma.
- Miembro — quién responde de esto, sin robarle el sitio al asignado.
- Checkbox — facturado, aprobado, entregado.
No hay un catálogo infinito de tipos a propósito. Estos cinco cubren lo que la gente pedía de verdad, y cada uno guarda su dato como lo que es: un número se guarda como número, así que se puede ordenar y comparar; un miembro es una referencia real a esa persona, así que si un día se va del equipo el campo se vacía solo en vez de quedarse apuntando a un fantasma.
Es por workspace, y eso importa
La definición vive en el workspace, no en el proyecto. Un workspace puede tener diez campos y otro ninguno: una consultora que factura por cliente y un equipo de producto no necesitan lo mismo, y no tienen por qué verse los campos del otro.
Si un workspace no define ninguno, no aparece nada. Ni un bloque vacío, ni una sección en gris invitándote a rellenar algo. La funcionalidad no existe hasta que la usas.
Dónde aparecen
En la ficha de cada tarea, en la columna de la derecha, debajo de las propiedades de siempre. Cada campo con el control que le toca: un calendario para las fechas, el mismo selector de personas del asignado, un checkbox para el sí/no.
Como columna del listado, si tú las activas. Esto último es deliberado: los campos personalizados no salen por defecto. Crear un campo no debería reordenarle el listado a todo el equipo sin avisar.
Como filtro, con el operador que tiene sentido según el tipo: mayor que en un importe, antes de en una fecha, contiene en un texto, sí / no / sin valor en un checkbox. Y los filtros se guardan en tus vistas, así que «lo entregado y sin facturar» pasa a ser un clic, no una búsqueda a mano cada lunes.
También puedes agrupar por un campo de tipo checkbox o miembro. Por texto, número o fecha no te lo ofrecemos: agrupar por un campo con un valor distinto en cada tarea genera cien grupos de una tarea, que es una lista peor que la que tenías.
Vacío no es cero
Un detalle pequeño que se nota al usarlo: dejar un campo número en blanco no
guarda un 0. «No lo he rellenado» y «vale cero» son cosas distintas, y confundirlas
te cambia una media o un total sin que te enteres. Lo mismo con el checkbox: sin
marcar no es lo mismo que marcado en «no».
Por eso también, en el listado, un campo sin valor no pinta nada. Ni un guion, ni un cero de relleno.
El tipo no se cambia
Un campo creado como texto no se puede convertir en número. Podríamos haberlo permitido y convertir lo que se pudiera, pero eso significa decidir por ti qué pasa con los valores que no convierten: ¿se tiran?, ¿se quedan a medias? La alternativa honesta es que archives el campo (deja de ofrecerse, conserva todo lo escrito) y crees el nuevo.
Archivar, de hecho, es casi siempre lo que quieres en vez de borrar. Si borras, te avisamos de en cuántas tareas se va a perder el valor antes de hacerlo.
Tus agentes también los ven
Si trabajas con agentes por MCP, los campos personalizados son
suyos también: hay una herramienta que los descubre (nombre, tipo, identificador) y
save_issue los escribe igual que cualquier otro dato de la tarea. get_issue los
devuelve ya resueltos.
Con una regla que nos parece importante: el tipo se valida contra la definición. Si un agente intenta meter un texto en un campo de importe, falla con un error claro en vez de guardarlo torcido. Un dato mal tipado que entra en silencio es el que descubres tres meses después cuando un informe no cuadra.
Y cuando exportas un proyecto a CSV, cada campo es una columna más, con su nombre en la cabecera. Las fechas salen como fecha y los miembros con su nombre, no con un identificador que no le dice nada a quien abre el fichero en una hoja de cálculo.
Una cosa más: el orden es tuyo
El orden de los campos se arrastra en Ajustes, y ese es el orden por defecto del workspace. Pero cada proyecto puede tener el suyo: arrastras los campos en la ficha y ese proyecto los recuerda así. En el de facturación puede que lo primero sea el importe; en el de soporte, el cliente.
Está disponible ya. Si tenías un dato viviendo en el título de tus tareas, este es el momento de sacarlo de ahí.