« first day (255 days earlier)      last day (412 days later) » 

1:39 PM
@gbianchi estuve pensando en el PR
y me parece que lo mejor es que si hagamos el upsert siempre
si no, al hacer log in con una cuenta nueva se rompe todo
pero tendríamos que evitar el demote (de reviewer a no reviewer)
 
@g3rv4 Por eso lo habia escrito de esa manera..
 
tiene sentido?
 
igual estoy chequeando.. mi idea es solo bloquear el upsert en desa...
 
sisi, lo que digo es que no bloqueemos el upsert
sino que bloqueemos el update del campo IsModerator
 
en el query... mmm...
 
1:40 PM
claro :) que si AVOID_MOD_DEMOTE es true, no se cambie ese campo
 
@g3rv4 mmmm... me parece que complica demasiado algo que es solo para dev...
 
es simplemente hacer esta línea
{shouldDemote ? "IsModerator = @IsModerator," : ""}
si la query usa interpolation
 
ah ah... sip.. eso ya lo hicimos por algun otro lado...
 
sacto :)
en realidad, sería más DO_NOT_UPDATE_ISMODERATOR la flag
 
en send_notification :)
@g3rv4 ese nombre me gusto mas...
 
1:43 PM
entonces, si la tenés en true, el sistema nunca toca esa field
 
ahi lo pruebo y lo subo...
igual en desa esta siempre en false...
 
:thumbsup: gracias totales!
 
o no existe, que es falso...
 
y perdón por romper tanto las pelotas
 
naaaaa
 
1:44 PM
la idea es que, por defecto, el comportamiento sea el que queremos en producción
 
yo tire una solucion y solo la estamos refinando.. la idea estaba...
 
y el que quiera jugar con esto, va y lo modifica en su entorno
 
si si.. lo que yo escribi en prod andaba...
 
sisi :) totalmente
 
porque si cambiabas el entorno de ASP ya daba siempre true y no le importaba el otro flag...
 
1:45 PM
claro :) el tema es para entornos de dev
por defecto, no hacía el upsert
tenías que ir y setear la variable en todos lados
 
sip.. eso es cierto...
en un solo lado era!!
jajaja..
 
no, en todos los entornos de desarrollo :)
de todas las personas que desarrollan
+ dev
no?
 
perate.. que no nos estamos quedando con configuration.. tengo que agregarlo tambien.. viene inyectado, pero solo tomamos algunas cosas y lo tiramos.. lo guardo o armo una variable para esto?? a mi me parece mejor guardar el entorno...
ahhh lo agregaste para webpush... :p... bueno.. agrego una variable mas...
 
estamos guardando una instancia a _configuration
yo diría que lo levantes de ahí
en vez de meter una variable nueva, así puede cambiar
lo de web push es distinto porque estoy guardando VapidDetails y WebPushClient (así no los construyo cada vez que voy a mandar una notificación)
 
@g3rv4 en esta clase no la estabamos guardando.. solo sacaste lo que querias y la tiraste.. por eso.. ahora la guardo...
 
1:49 PM
aaah tenés razón
guardá en _configuration :)
 
{!_configuration.GetValue<bool>("DO_NOT_UPDATE_ISMODERATOR") ? "IsModerator = @IsModerator," : ""}
pero no me gusta la doble negacion...
 
definiría una variable afuera para que quede más claro
 
si si.. queda feito asi...
 
que puede ser updateMod = !_configuration.GetValue<bool>("DO_NOT_UPDATE_ISMODERATOR")
es fea la doble negación, pero es por una buena causa
salgo por un rato que tengo una entrevista ;)
 
@g3rv4 vaya vaya, suerte!
 
 
1 hour later…
3:01 PM
back! salió hire :)
 
3:36 PM
@g3rv4 contrataste a alguien?
 
je, no es mi decisión... pero la entrevista salió bien :)
 
@g3rv4 bueno bien..
@g3rv4 Ahi cambie el PR.. tranqui que para este no hay apuro..
Git no te aviso de los problemas de dependencias? hace como una semana a mi me lleno de mails por un problema que encontraron en bootstrap...
 
nope... me imagino que es porque son devDependencies (se usan para hacer el build pero los usuarios no pueden ser afectados)
 
Bueno voy a hacer mi 3 PR del mes y estar a dos de ganarme la remera.. en un traducir.vue :p
 

« first day (255 days earlier)      last day (412 days later) »