But this client also wants to disable private messages for at least most users, so that won’t work. (I tried )
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?)
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
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:
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 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.
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)
Any user of any trust level to send a message to a staff member (e.g. immediately after joining).
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! (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 – A documented bug is a feature!)
Thanks again, @angus! A couple more trivial plugins under my belt and I might do something useful!
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.
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.
As-tu déjà trouvé une solution à ce problème, Jay ?
Je rencontre un problème similaire qui serait résolu très élégamment en empêchant les messages privés (MP) 1:1 normaux. Il s’agit d’une organisation bénévole où les bénévoles doivent communiquer avec les coordonnateurs, mais idéalement pas entre eux.
Le plugin mentionné ci-dessus (https://github.com/pfaffman/discourse-allow-pm-to-staff) fonctionne. Je ne fais aucune promesse, mais le client qui l’a commandé l’utilise toujours, il est donc activement maintenu et dispose même de tests exécutés sur travis.
Je comprends que cela ait été fourni gratuitement sans aucune garantie, ce qui est vraiment apprécié.
Juste pour te prévenir, il semble que cela ne fonctionne pas actuellement. Sauf si j’ai mal configuré quelque chose, le plugin est installé et activé.
J’ai testé avec « niveau de confiance minimum pour envoyer des messages » défini à 1, avec un utilisateur TL0 tentant d’envoyer un MP à un membre du personnel. J’ai aussi testé avec « niveau de confiance minimum pour envoyer des messages » défini à 2, avec un utilisateur TL1 tentant d’envoyer un MP à un membre du personnel.
Dans les deux cas, le bouton de message privé était masqué sur les profils des membres du personnel pour le compte utilisateur standard si leur niveau de confiance était inférieur au paramètre « niveau de confiance minimum pour envoyer des messages ». La réception de MP est également activée dans les paramètres de l’utilisateur membre du personnel ciblé.
C’est le cas pour moi, aussi bien sur la version stable 2.5.0 que sur la version 2.6.0.beta1 (tests-passés).
Sur la version stable, j’ai également testé la composition manuelle d’un message depuis la page /u/nom_utilisateur/messages en saisissant le membre du personnel comme destinataire, mais le message a été rejeté lors de la soumission.
Eh bien, cela semble fonctionner sur mon instance de développement exécutant 2.6.0.beta1 ainsi que sur une instance de production en 2.5.0.beta4, et les tests continuent de passer sur Travis.
Ma seule hypothèse est que cela ne fonctionne pas pour les multisites et que vous utilisez un multisite ?
C’est super d’entendre que ça fonctionne ! Peut-être que j’oublie quelque chose d’évident. Ce n’était pas sur des installations multisites, mais sur des installations Docker standard.
Les étapes suivies étaient les suivantes :
Installation du plugin depuis https://github.com/pfaffman/discourse-allow-pm-to-staff.git. Je n’ai pas activé spécifiquement ce plugin ni défini d’options propres au plugin. Cependant, dans /admin/plugins, le champ ‘enabled?’ est défini sur O.
Ajustement de ‘niveau de confiance minimum pour envoyer des messages’ et test avec un compte utilisateur standard dont le niveau de confiance est inférieur à ce TL sélectionné, en tentant d’envoyer un message au personnel.
J’ai essayé de supprimer tous les plugins sauf celui-ci sur la version stable 2.5.0, au cas où il y aurait un conflit, mais cela n’a fait aucune différence.
Je n’avais pas personnalisé/configuré les tests Travis, ce qui semble avoir empêché le plugin de fonctionner.
J’ai donc essayé de supprimer tout sauf le fichier plugin.rb et cela a commencé à fonctionner pour moi. J’ai également légèrement modifié la logique pour mon cas d’utilisation.
Actuellement, les utilisateurs de niveau de confiance TL0+ peuvent envoyer un message à un administrateur si leur niveau de confiance tombe en dessous du « niveau de confiance minimum pour envoyer des messages » configuré, mais ils ne peuvent pas envoyer de message à un modérateur.
Pour modifier cela, cette section doit être changée très légèrement (j’apprécie les commentaires clairs ) :
# Il faut être au moins de niveau de base -- et maintenant : OU ENVOI À UN ADMINISTRATEUR
(is_group || @user.has_trust_level?(SiteSetting.min_trust_to_send_messages) || notify_moderators || target.admin) &&
Si vous souhaitez autoriser l’envoi de messages à n’importe quel membre du personnel (qui n’a pas spécifiquement désactivé la réception de messages personnels), changez-le en :
# Il faut être au moins de niveau de base -- et maintenant : OU ENVOI AU PERSONNEL
(is_group || @user.has_trust_level?(SiteSetting.min_trust_to_send_messages) || notify_moderators || target.staff?) &&
Si vous souhaitez activer l’envoi de messages uniquement aux modérateurs et non aux administrateurs :
# Il faut être au moins de niveau de base -- et maintenant : OU ENVOI À UN MODÉRATEUR
(is_group || @user.has_trust_level?(SiteSetting.min_trust_to_send_messages) || notify_moderators || target.moderator) &&
)
maybe a simple Google Docs form would be better?
(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.
– A documented bug is a feature!)
