@hostwebhook/node-types 1.75.1 → 1.75.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -62,11 +62,29 @@ const eventConfigParams = () => [
|
|
|
62
62
|
entera de la regla de ambigüedad ANTES de mandar el payload. `05-06-2026`
|
|
63
63
|
se rechaza en ejecución (ver `normalizeDate`), y un rechazo que sólo
|
|
64
64
|
aparece en el log del run llega tarde: aquí se dice al lado del campo.
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
65
|
+
🔴 [2026-09-09] Y ya no dan la clase de formatos. Decían qué formas de
|
|
66
|
+
fecha se aceptan y cuáles se rechazan por ambiguas — un párrafo cada uno,
|
|
67
|
+
debajo de cada campo. Ariel: «quítame esos mensajes».
|
|
68
|
+
|
|
69
|
+
Tenía razón, y lo que los mató fue el propio producto: el campo lleva un
|
|
70
|
+
calendario que ESCRIBE la fecha y la hora, así que la forma ya no la teclea
|
|
71
|
+
nadie. Un texto que explica cómo escribir a mano lo que se elige con un
|
|
72
|
+
clic no es ayuda, es ruido — y encima ocupa el sitio donde se lee lo que sí
|
|
73
|
+
importa.
|
|
74
|
+
|
|
75
|
+
Y no se quedó ninguna suelta: las dos fechas se leen JUNTAS —una es el
|
|
76
|
+
principio y la otra el final de lo mismo—, así que la pantalla las mete en
|
|
77
|
+
un bloque con una regla arriba y otra abajo y pone la nota UNA vez al pie
|
|
78
|
+
(`NOTA_DE_LAS_FECHAS`, en `CalendarActionDetail.tsx` del dashboard). Ariel:
|
|
79
|
+
«crea una sección para el start y end date… y en esa sección agregas el
|
|
80
|
+
mensaje, para no repetir información».
|
|
81
|
+
|
|
82
|
+
⚠️ Ahí sigue entera la frase del ÚLTIMO DÍA INCLUIDO, que es la única que
|
|
83
|
+
no es de formato y la única que no se puede recortar: el `+1` de la
|
|
84
|
+
exclusividad de `end.date` en Google lo pone HostWebhook, no da error, y
|
|
85
|
+
quien lo sepa y no lo lea lo suma otra vez. */
|
|
86
|
+
{ name: 'startTemplate', target: 'eventConfig', label: 'Start Date', type: 'template', placeholder: '{{payload.startTime}}', execKey: 'start' },
|
|
87
|
+
{ name: 'endTemplate', target: 'eventConfig', label: 'End Date', type: 'template', placeholder: '{{payload.endTime}}', execKey: 'end' },
|
|
70
88
|
{
|
|
71
89
|
name: 'attendeesTemplate',
|
|
72
90
|
target: 'eventConfig',
|
|
@@ -109,6 +127,15 @@ exports.GOOGLE_CALENDAR_OPERATION_SPECS = {
|
|
|
109
127
|
{ name: 'timeMaxTemplate', target: 'listConfig', label: 'End Date', type: 'template', placeholder: '{{payload.to}}', execKey: 'timeMax' },
|
|
110
128
|
{ name: 'maxResults', target: 'listConfig', label: 'Max Results', type: 'number', min: 1, max: 2500, default: 10 },
|
|
111
129
|
{ name: 'query', target: 'listConfig', label: 'Search Query', type: 'template', placeholder: 'meeting' },
|
|
130
|
+
/* 🔴 La zona con la que se leen los dos extremos del rango.
|
|
131
|
+
`findFreeSlots` la tenía y ésta no, así que un «del 18 al 21» se leía
|
|
132
|
+
SIEMPRE en UTC: ni la elección de quien lo escribe ni la zona del
|
|
133
|
+
workspace entraban en la cuenta. Reportado por Ariel — «no sigue
|
|
134
|
+
respetando la zona horaria que seleccionan en la página; si no
|
|
135
|
+
seleccionan, que use el del workspace».
|
|
136
|
+
Vacía sigue cayendo al defecto del workspace, y sin workspace a UTC,
|
|
137
|
+
que es lo que hacía antes: un nodo ya guardado no cambia. */
|
|
138
|
+
{ name: 'timeZone', target: 'listConfig', label: 'Time Zone', type: 'timezone', description: 'IANA zone used to read the range bounds. Empty uses the workspace zone.', execKey: 'timeZone' },
|
|
112
139
|
],
|
|
113
140
|
},
|
|
114
141
|
getEvent: {
|
|
@@ -58,11 +58,29 @@ const eventConfigParams = () => [
|
|
|
58
58
|
entera de la regla de ambigüedad ANTES de mandar el payload. `05-06-2026`
|
|
59
59
|
se rechaza en ejecución (ver `normalizeDate`), y un rechazo que sólo
|
|
60
60
|
aparece en el log del run llega tarde: aquí se dice al lado del campo.
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
61
|
+
🔴 [2026-09-09] Y ya no dan la clase de formatos. Decían qué formas de
|
|
62
|
+
fecha se aceptan y cuáles se rechazan por ambiguas — un párrafo cada uno,
|
|
63
|
+
debajo de cada campo. Ariel: «quítame esos mensajes».
|
|
64
|
+
|
|
65
|
+
Tenía razón, y lo que los mató fue el propio producto: el campo lleva un
|
|
66
|
+
calendario que ESCRIBE la fecha y la hora, así que la forma ya no la teclea
|
|
67
|
+
nadie. Un texto que explica cómo escribir a mano lo que se elige con un
|
|
68
|
+
clic no es ayuda, es ruido — y encima ocupa el sitio donde se lee lo que sí
|
|
69
|
+
importa.
|
|
70
|
+
|
|
71
|
+
Y no se quedó ninguna suelta: las dos fechas se leen JUNTAS —una es el
|
|
72
|
+
principio y la otra el final de lo mismo—, así que la pantalla las mete en
|
|
73
|
+
un bloque con una regla arriba y otra abajo y pone la nota UNA vez al pie
|
|
74
|
+
(`NOTA_DE_LAS_FECHAS`, en `CalendarActionDetail.tsx` del dashboard). Ariel:
|
|
75
|
+
«crea una sección para el start y end date… y en esa sección agregas el
|
|
76
|
+
mensaje, para no repetir información».
|
|
77
|
+
|
|
78
|
+
⚠️ Ahí sigue entera la frase del ÚLTIMO DÍA INCLUIDO, que es la única que
|
|
79
|
+
no es de formato y la única que no se puede recortar: el `+1` de la
|
|
80
|
+
exclusividad de `end.date` en Google lo pone HostWebhook, no da error, y
|
|
81
|
+
quien lo sepa y no lo lea lo suma otra vez. */
|
|
82
|
+
{ name: 'startTemplate', target: 'eventConfig', label: 'Start Date', type: 'template', placeholder: '{{payload.startTime}}', execKey: 'start' },
|
|
83
|
+
{ name: 'endTemplate', target: 'eventConfig', label: 'End Date', type: 'template', placeholder: '{{payload.endTime}}', execKey: 'end' },
|
|
66
84
|
{
|
|
67
85
|
name: 'attendeesTemplate',
|
|
68
86
|
target: 'eventConfig',
|
|
@@ -105,6 +123,15 @@ export const GOOGLE_CALENDAR_OPERATION_SPECS = {
|
|
|
105
123
|
{ name: 'timeMaxTemplate', target: 'listConfig', label: 'End Date', type: 'template', placeholder: '{{payload.to}}', execKey: 'timeMax' },
|
|
106
124
|
{ name: 'maxResults', target: 'listConfig', label: 'Max Results', type: 'number', min: 1, max: 2500, default: 10 },
|
|
107
125
|
{ name: 'query', target: 'listConfig', label: 'Search Query', type: 'template', placeholder: 'meeting' },
|
|
126
|
+
/* 🔴 La zona con la que se leen los dos extremos del rango.
|
|
127
|
+
`findFreeSlots` la tenía y ésta no, así que un «del 18 al 21» se leía
|
|
128
|
+
SIEMPRE en UTC: ni la elección de quien lo escribe ni la zona del
|
|
129
|
+
workspace entraban en la cuenta. Reportado por Ariel — «no sigue
|
|
130
|
+
respetando la zona horaria que seleccionan en la página; si no
|
|
131
|
+
seleccionan, que use el del workspace».
|
|
132
|
+
Vacía sigue cayendo al defecto del workspace, y sin workspace a UTC,
|
|
133
|
+
que es lo que hacía antes: un nodo ya guardado no cambia. */
|
|
134
|
+
{ name: 'timeZone', target: 'listConfig', label: 'Time Zone', type: 'timezone', description: 'IANA zone used to read the range bounds. Empty uses the workspace zone.', execKey: 'timeZone' },
|
|
108
135
|
],
|
|
109
136
|
},
|
|
110
137
|
getEvent: {
|
package/package.json
CHANGED