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.
Running into a similar problem that would be solved very neatly by preventing normal 1:1 PM’s. It’s a volunteer organisation and they need volunteers to communicate with coordinators, but ideally not amongst themselves.
The plugin mentioned above (https://github.com/pfaffman/discourse-allow-pm-to-staff) works. I don’t make any promises, but the client who commissioned it still uses it, so it’s activtely maintained, and even has tests that are run on travis.
So che è stato fornito gratuitamente senza alcuna garanzia, il che è davvero apprezzato.
Solo per avvisarti, sembra che al momento non funzioni. A meno che non abbia configurato qualcosa in modo errato, il plugin è installato e abilitato.
Ho testato impostando ‘min trust to send messages’ a 1, con un utente TL0 che tenta di inviare un messaggio privato a un membro dello staff. Ho anche testato con ‘min trust to send messages’ impostato a 2, con un utente TL1 che tenta di inviare un messaggio privato a un membro dello staff.
In entrambi i casi, il pulsante per i messaggi privati era nascosto sui profili dello staff per l’account utente regolare se il suo livello di fiducia (TL) era inferiore all’impostazione ‘min trust to send messages’. Anche l’opzione per ricevere messaggi privati è abilitata nelle impostazioni dell’utente staff destinatario.
Questo è il mio caso, sia per la versione stabile 2.5.0 che per la 2.6.0.beta1 (test superati).
Sulla versione stabile ho anche testato la composizione manuale di un messaggio dalla pagina /u/username/messages, inserendo il membro dello staff come destinatario, ma il messaggio è stato rifiutato al momento dell’invio.
Bene, sembra funzionare sulla mia istanza di sviluppo in esecuzione su 2.6.0.beta1 e anche su un’istanza di produzione a 2.5.0.beta4, e i test su Travis continuano ad avere esito positivo.
L’unica mia ipotesi è che non funzioni per i multisiti e tu stia usando un multisito?
È fantastico sentire che funziona! Forse mi sfugge qualcosa di ovvio. Non si trattava di multisiti, ma solo di installazioni Docker standard.
I passaggi eseguiti sono stati:
Installazione del plugin da https://github.com/pfaffman/discourse-allow-pm-to-staff.git. Non ho abilitato specificamente questo plugin né impostato opzioni specifiche per il plugin. Tuttavia, in /admin/plugins la voce ‘enabled?’ risulta impostata su Y.
Modifica di ‘min trust to send messages’ e test con un account utente regolare che rientra al di sotto del livello di fiducia (TL) selezionato, tentando di inviare un messaggio allo staff.
Ho provato a rimuovere tutti i plugin tranne questo sulla versione stabile 2.5.0, nel caso ci fosse qualche conflitto, ma non ha fatto alcuna differenza.
Non avevo personalizzato/configurato i test Travis, quindi sembra che questo abbia impedito al plugin di funzionare.
Quindi ho provato a rimuovere tutto tranne il file plugin.rb e ha iniziato a funzionare per me. Ho anche modificato leggermente la logica per il mio caso d’uso.
Allo stato attuale, i utenti con livello di fiducia TL0+ possono inviare un messaggio a un amministratore se il loro livello di fiducia scende sotto il “minimo richiesto per inviare messaggi” configurato, ma non possono scrivere a un moderatore.
Per modificare questo comportamento, è necessario cambiare leggermente questa sezione (grazie per i commenti chiari ):
# Devi avere almeno un livello base -- e ora: OPPURE STAI SCRIVENDO A UN AMMINISTRATORE
(is_group || @user.has_trust_level?(SiteSetting.min_trust_to_send_messages) || notify_moderators || target.admin) &&
Se vuoi consentire l’invio di messaggi a qualsiasi membro dello staff (che non abbia disabilitato specificamente la ricezione di messaggi privati), modifica così:
# Devi avere almeno un livello base -- e ora: OPPURE STAI SCRIVENDO ALLO STAFF
(is_group || @user.has_trust_level?(SiteSetting.min_trust_to_send_messages) || notify_moderators || target.staff?) &&
Se vuoi abilitare l’invio di messaggi solo ai moderatori e non agli amministratori:
# Devi avere almeno un livello base -- e ora: OPPURE STAI SCRIVENDO A UN MODERATORE
(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!)
