Inundação inadvertida de e-mails/notificações ao tentar mover Tópicos silenciosamente entre categorias

Acabei de ter problemas ao mover 30 tópicos entre categorias devido a uma tempestade de e-mails para meus usuários mais valiosos.

Notei que após a última atualização, o texto mudou para o recurso que permite a supressão de notificações quando um grupo de Tópicos selecionado em massa tem sua Categoria alterada. Agora ele mostra isto:

Eu deixei isso desmarcado, e ele os notificou como louco! A categoria de destino está configurada como Observando primeiro post, mas antes dessa mudança, eles teriam sido suprimidos.

O que está acontecendo aqui?

5 curtidas

Desculpe por isso @nathank :frowning:

[quote=“nathank, post:1, topic:390993”]A categoria de destino está configurada como Watching first post, mas antes desta alteração elas seriam suprimidas.
[/quote]

Eu tentei reproduzir localmente e melhorei nossa cobertura de especificações para garantir que lidássemos com este caso…

… mas tudo parece estar funcionando como esperado :thinking:

Alguma chance de você encontrar algumas etapas de reprodução?

1 curtida

@zogstrip Não vejo cobertura de teste para este caso.

Na minha leitura, as especificações describe "silent option" cobrem apenas os cenários em que o tópico que está sendo movido já está sendo observado (watched).

O caso descrito aqui é para o cenário em que a categoria de destino está como “observada” (watched) ou “observando a primeira postagem” (watching first post).

@nathank, até onde sei, nunca fizemos isso silenciosamente.

Acho que o que está acontecendo aqui é que o modal para o recurso que adicionamos faz parecer que isso também deveria ser silenciado. Acho que mudamos as expectativas com este modal e agora não as estamos cumprindo.

Essa é a minha suposição, de qualquer forma.

Acho que este é um pedido legítimo de #recurso ou UX, e eu apoio totalmente fazê-lo. Mas não acho que seja tecnicamente um bug ou uma regressão.

2 curtidas

(postagem excluída pelo autor)

Eu pensei que esta era parte do propósito de incluir isso como uma opção em ações em massa (para corresponder ao comportamento de Desativar notificações de edição de categoria e Desativar notificações de edição de tag de forma ad hoc).

Sem isso, o recurso seria bem limitado.

2 curtidas

Ponto justo. Honestamente, não tenho certeza.

Eu vejo que esse é exatamente o caso de uso descrito na solicitação de recurso original:

Eu também vejo que várias pessoas pensaram a mesma coisa quando viram a nova caixa de seleção: Bulk editing topic categories should not trigger thousands of email notifications - #12 by mbauman

O próprio PR também faz parecer que essa era a intenção:

Quando a caixa de seleção “Executar esta ação silenciosamente” tiver sido marcada, o job :notify_category_change sidekiq não deve ser enfileirado.

Mas não estou vendo cobertura de especificação explícita para este caso.

Admito que estou um pouco enferrujado em preparar especificações ruby, já que não escrevo código diariamente nos últimos anos, mas isso parece ser uma possível lacuna.

Cheira mais a bug para mim agora. Não sei se é regressão ou não, mas parece que estamos perdendo cobertura para este caso.

3 curtidas

Ahah! Acho que encontrei o problema :bug:

A opção @silent não estava se propagando corretamente, o que fazia com que os usuários que acompanhavam a categoria de destino recebessem notificações mesmo quando a caixa de seleção “Executar esta ação silenciosamente” estava marcada.

6 curtidas

Brilhante! E obrigado por levar isso a sério e pela correção super rápida! Acabei de testar e tudo parece bom.

Eu só queria notar que o texto na interface do usuário (UI) está diferente/invertido agora - de modo que marcar a caixa de seleção faz exatamente o oposto do que costumava fazer. Mas esse lado das coisas parece estar funcionando bem, então espero que esteja tudo certo.

Costumava ser:

Agora é:

1 curtida

:telephone: Por favor, ouça atentamente, pois nossas opções de menu mudaram…

2 curtidas