Planning for sending messages to roles.
| Project: | Privatemsg |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
From irc, litwol had the idea to have an extra column in the pm_index table - for the role.
Then to create a message index, it will be a simple matter of having a "WHERE pmi.uid = %d or pmi.rid IN '%s'" or something.
On the display side, the recipient/participant theming will also need to somehow be expanded to cover roles.
And on the sending side, there is still the question of *how* to send to a specific role. Another select box? different place?
A third question is one of threading - making sure the index table is not overloaded when replying to an existing conversation.
(A final issue is of not being able to see group messages once you leave the group - is that how it is supposed to work? or when people leave a group, will their threads need to have the index populated in the normal manner?)
#1
Hm.
I am not sure. The thing is, how do you then track who has seen/deleted a message? The only way I see right now is some sort of batch processing to add more users.
Another issue is with replying. Should you be allowed to reply to an group/role/all thread if you can't start one? Probably not... but how to track that and of course, every reply needs batch processing too.
#2
Group-wide replies can very quickly thrash the whole system. What if we do this communication as being one way only ? Some one of privilage can send a message to a group but replies will be disabled, until message is forwarded to other user(s).
As for tracking who read it, we could insert a row in pm_index upon reading a mesage that was sent to a group, so now you have 1 row for the group and 1 row for me. < This is just speculation.
#3
Hm. we could add another permission. For example. if you, as an admin send a message to a group, I consider it to be useful when you can send an update at a later point.
Your idea could work, we still end up with the same amount of entries in pm_index (actually, even one more), but it is not filled at once. However, there is one *huge* limitation. It would just work for roles. However, I'd like to see a way to do this for organic groups, your friends/fans, all users of a site and we would then provide two things:
a) An easy way to provide such a mass-sending facility.
b) A default implementation for roles and all users of a site
#4
I may not be fully grasping everything you guys are suggesting here though, so forgive me if my comments are off point at all. I know you are all deep in the privatemsg development and thank you for that. More than anything, I just wanted to point out my support for this idea...
Just wanted to comment that #2 above would work great and to add my support for the functionality of messaging to an entire role. The main reason I can see for using a pm to an entire role would be notificaiton, and one way messaging is fine in that instance.
In terms of tracking, I'm a little confused, however. Are you all suggesting that you would be able to see each person who has read the pm? If you are talking about sending to an entire role, that could be a very large number of users. And if that is listed somewhere in the messaging interface, it could potentially be overwhelming (ie listing each user who has read the message).
Also, is this something that can be started by using roles so that the functionality is available (even if somewhat limited), and then down the road add on support for organic groups, friends/fans, etc?
#5
1. No, the tracking is for the recipient. To mark messages as new, privatemsg.module needs to know if you have read it before, and it needs to do that for every user. Exactly the same for delete.
2. Well, imho, adding a role column would not make it easier to add support for other groups later on, as the functions, db column etc. couldn't be re-used. I would like to do this in a more generic way but I can't work on that any time soon, maybe for rc4.
#6
I can see the benefit of it being a more flexible function, especially with sites trying to create a more hierarchical user structure. I'll be looking forward to it and will be happy to do testing when patches are offered.
#7
subscribe
#8
subscribe, thx!
#9
subscribe
#10
subscribing
#11
subscribing - I find this an interesting/powerful feature and will be first to help testing =)