Allow sending Private Messages to Staff

I have a client who wants to have people send a form with some information on it. No problem, just Compose a new pre-filled personal message via URL!

But this client also wants to disable private messages for at least most users, so that won’t work. (I tried :frowning:)

One solution would be a site setting that would allow users to be able to send PMs to staff.

Perhaps I’m missing something, bu tI’m afraid the other solutions all require a plugin or some other app. (e.g., Canned replies works only for staff, right?)

3 curtidas

Why does this form need to be in Discourse? Just create a Google Docs form or something.

Yeah. That was my idea too. Crazy guy just doesn’t want to leave Discourse.

I’ve got two clients right now who are itching to do everything in Discourse and not have WordPress/Drupal/Squarespace to handle other stuff.

1 curtida

Right but at the point when you’re contorting the system into a :pretzel: maybe a simple Google Docs form would be better?

1 curtida

If I’m reading you right, you want to restrict the target of pms to staff only?

You could do this relatively easily in a standalone plugin. The plugin.rb would read:

# name: only-pms-to-staff
# about: You can only send pms to staff
# version: 0.1
# authors: pfaffman

after_initialize do
  add_to_class('guardian', :can_send_private_message?) do |target|
    target.is_a?(User) &&
    # User is authenticated
    authenticated? &&
    # Have to be a basic level at least
    @user.has_trust_level?(SiteSetting.min_trust_to_send_messages) &&
    # User disabled private message
    (is_staff? || target.user_option.allow_private_messages) &&
    # PMs are enabled
    (is_staff? || SiteSetting.enable_private_messages) &&
    # Can only send pms to staff
    target.staff?
  end
end

The original method is here.

See also: How do disable private messages between non staff users? - #10 by Mittineague

11 curtidas

Thanks, @angus!

Here’s what I ended up with. If I were better at understanding the distributed properties of and and or, I’d have moved target.staff? outside of those three expressions, but this seems to do what I wanted. My scant tests show that it allows sending to an admin and if you send to an admin and another user, it is denied.


after_initialize do
  add_to_class('guardian', :can_send_private_message?) do |target|
    target.is_a?(User) &&
      # User is authenticated
      authenticated? &&
      # Have to be a basic level at least
      (target.staff? || @user.has_trust_level?(SiteSetting.min_trust_to_send_messages)) &&
      # User disabled private message
      (target.staff? || is_staff? || target.user_option.allow_private_messages) &&
      # PMs are enabled
      (target.staff? || is_staff? || SiteSetting.enable_private_messages)
  end
end

it doesn’t quite meet my standards for posting to #plugins just yet, but if anyone stumbles here and wants to do this, here’s this:

10 curtidas

On the face of it, these changes allow:

  1. Any user who has the min trust level to send a pm, to send a message to any other user who has not disabled pms, regardless of whether or not they are staff.

    The issue is this line:

    target.staff? || is_staff? || SiteSetting.enable_private_messages

    The first alternative, i.e. target.staff?, is redundant, as the last alternative will always be true as long as pms are turned on.

    The is_staff? check here is used to ensure that staff members can still perform an action even if that action is disabled (this is normal practice in the Discourse code). Keep those two as the only alternatives in that line, i.e.

    (is_staff? || SiteSetting.enable_private_messages)

    There was an issue with my initial code, as it didn’t allow staff members to send messages to non-staff members. The way to fix that is by adding the is_staff? check to that line specifically, i.e.

    (is_staff? || target.staff)

  2. Any user of any trust level to send a message to a staff member (e.g. immediately after joining).

    The issue is this line:

    (target.staff? || @user.has_trust_level?(SiteSetting.min_trust_to_send_messages))

    This means that if the target is a staff member you don’t need the min trust level. Probably best to require the min trust level for all messages.

  3. If a staff member has specifically dis-allowed pms to be sent to them, you will still be able to send pms to them.

    The issue is this line:

    (target.staff? || is_staff? || target.user_option.allow_private_messages)

    Unless you want pms to reach staff members even if they have specifically disabled them, remove target.staff? from this check.

9 curtidas

First, I really appreciate your help.

But that didn’t seem to be the case, when I tested. I even tested sending to a staff and a non-staff person in a single message and it was rejected.

target.staff? || is_staff? || SiteSetting.enable_private_messages

The way I read that, it’s

  • the receiver is staff OR
  • the sender is staff OR
  • private messages are enabled (and they’re not for this site, which is what I’m trying to solve)

And I (or this client) want everyone to be able to send to staff.

Hooray! That’s what I wanted! :tada: (Of course, it could prove to be a problem, but we can solve it when there is one) It’s good advice to change that to TL1, though. I made a note of that too.

Ah, that’s (but one of the reasons) why I don’t think anyone should use this. For this site, I’m sure that no staff will be disallowing PMs. I should probably fix this one. I added a comment to remind me to do so when I can “test” – not to be confused with writing a proper test! (Or maybe I want to make sure that a staff member who needs to receive these messages doesn’t inadvertently disable PMs :slight_smile: – A documented bug is a feature!)

Thanks again, @angus! A couple more trivial plugins under my belt and I might do something useful!

5 curtidas

Ah, I had assumed you were going to keep the site setting on. That change in logic makes a bit more sense now :slight_smile:

However, I think you may want to keep the site setting on and restrict pms just via the guardian though. If the site setting is off this will also:

  1. Disable message-related elements in the UI, specifically the messages icon in the user menu will not appear and the private messages button will not appear in the user profile.

  2. Prevent the user from taking the notify_user and notify_moderator post actions (see here). These post actions require private messages.

And there may be more instances of that setting being used to disable functionality in the future.

If I’m reading you right, your case is one of permissions, not one of functionality? You still want the functionality, just a restricted version of it.

edit: re-reading your first post, maybe you do want to disable the functionality entirely! Well at least we thought this through.

7 curtidas

This is how my naive solution is so lucky! The plan is to use a URL to generate the initial message, so not being able to see the PM interface is a bonus!

That’s pretty fine too, as this is basically doing the same thing as using a Google form would be. It’s mostly for a one-way initiation of a conversation. I should check what happens if someone replies to the PM, though.

Ah, yes. The Royal “We”. Thanks very much for your help. You’ve taught me a lot and I appreciate it.

3 curtidas

Você já encontrou uma solução para isso, Jay?

Estou enfrentando um problema semelhante que seria resolvido de forma muito elegante impedindo mensagens diretas (PMs) 1:1 normais. É uma organização de voluntários e eles precisam que os voluntários se comuniquem com os coordenadores, mas idealmente não entre si.

4 curtidas

O plugin mencionado acima (https://github.com/pfaffman/discourse-allow-pm-to-staff) funciona. Não faço nenhuma promessa, mas o cliente que o encomendou ainda o utiliza, então ele é mantido ativamente e até possui testes que são executados no travis.

4 curtidas

Obrigado por compartilhar, @pfaffman e @angus!

Conseguiu fazer funcionar, @Stephen?

Entendo que isso foi fornecido gratuitamente, sem garantias, o que é muito apreciado. :slight_smile:

Só um aviso: parece que não está funcionando no momento. A menos que eu tenha configurado algo errado, o plugin está instalado e ativado.

Testei com ‘confiança mínima para enviar mensagens’ definido como 1, com um usuário TL0 tentando enviar uma mensagem privada a um membro da equipe. Também testei com ‘confiança mínima para enviar mensagens’ definido como 2, com um usuário TL1 tentando enviar uma mensagem privada a um membro da equipe.

Em ambos os casos, o botão de mensagem privada estava oculto nos perfis dos membros da equipe para a conta de usuário comum, caso o nível de confiança (TL) estivesse abaixo da configuração de ‘confiança mínima para enviar mensagens’. A recepção de mensagens privadas também está habilitada nas configurações do usuário da equipe destinatário.

Esse é o meu caso, tanto na versão 2.5.0 estável quanto na 2.6.0.beta1 (testes aprovados).

Na versão estável, também testei a composição manual de uma mensagem na página /u/nome de usuário/mensagens, inserindo o membro da equipe como destinatário, mas a mensagem foi rejeitada ao ser enviada.

2 curtidas

Bem, parece que está funcionando na minha instância de desenvolvimento rodando 2.6.0.beta1 e também na instância de produção em 2.5.0.beta4, e os testes no Travis continuam passando.

Minha única suposição é que não funcione para multisite e você esteja rodando multisite?

2 curtidas

Que ótimo saber que está funcionando! Talvez eu esteja perdendo algo óbvio. Isso não era em multisites, apenas instalações padrão do Docker.

Os passos seguidos foram:

  • Instalar o plugin de https://github.com/pfaffman/discourse-allow-pm-to-staff.git. Não ativei especificamente este plugin nem configurei nenhuma opção específica dele. No /admin/plugins, o campo ‘enabled?’ aparece como Y.

  • Ajustei o ‘nível de confiança mínimo para enviar mensagens’ e testei com uma conta de usuário comum que está abaixo desse nível de confiança (TL) tentando enviar mensagem para a equipe.

  • Tentei remover todos os plugins exceto este na versão estável 2.5.0, caso houvesse algum conflito, mas não fez diferença.

1 curtida

Descobri o que estava errado :partying_face:

Eu não configurei/customizei os testes do Travis, então parece que isso impediu o funcionamento do plugin.

Então, tentei remover tudo, exceto o arquivo plugin.rb, e começou a funcionar para mim. Também modifiquei a lógica levemente para o meu caso de uso.

No estado atual, usuários com nível de confiança TL0+ podem enviar mensagens a um administrador se seu nível de confiança cair abaixo do ‘mínimo de confiança para enviar mensagens’ configurado, mas não podem enviar mensagens a um moderador.

Para modificar isso, esta seção precisa ser alterada levemente (agradeço pelos comentários claros :slight_smile: ):

# É necessário ter pelo menos um nível básico -- e agora: OU ENVIANDO PARA ADMINISTRADOR
(is_group || @user.has_trust_level?(SiteSetting.min_trust_to_send_messages) || notify_moderators || target.admin) &&

Se você quiser permitir mensagens para qualquer membro da equipe (que não tenha desativado especificamente a recepção de mensagens pessoais), altere para:

# É necessário ter pelo menos um nível básico -- e agora: OU ENVIANDO PARA MEMBRO DA EQUIPE
(is_group || @user.has_trust_level?(SiteSetting.min_trust_to_send_messages) || notify_moderators || target.staff?) &&

Se você quiser permitir mensagens apenas para moderadores e não para administradores:

# É necessário ter pelo menos um nível básico -- e agora: OU ENVIANDO PARA MODERADOR
(is_group || @user.has_trust_level?(SiteSetting.min_trust_to_send_messages) || notify_moderators || target.moderator) &&

Obrigado novamente @pfaffman e @angus!
:100:

2 curtidas

Isso é estranho. Não sei como isso poderia ter acontecido.

1 curtida