Re: Personal messages
Reply #2 –
Don't forget that newsletters can be sent in the same fashion too.
Re: Personal messages
Reply #3 –
I like it, but to clarify,
If I send a message to Eman, Spuds, Arantor,
Eman replied to me, Spuds but NOT Arantor (Sorry Pete!) = Possible or would it be truly like a topic, whoever could see it to begin without would always be able to see replies?
Re: Personal messages
Reply #7 –
What TestMonkey said, plus...I was considering the possibility to "invite" and "kick" (with some alternative ways, i.e. requiring majority, or requiring unanimous decision, at discretion of the starter or of a sort of moderator, etc. I think there are many alternatives here) so that invited members would be allowed to see the entire discussion and kicked wouldn't be able to access it any more.
Re: Personal messages
Reply #9 –
Even if I still use the single pm view I'd be OK with that move.
Re: Personal messages
Reply #11 –
Just testing a bit, I didn't change anything important yet.
Removed the menu with the labels and added it on the side.
In fact it reminds a bit a webmail... lol
Re: Personal messages
Reply #13 –
I think "kicking" is getting a little far with it. I think adding and leaving a conversation makes sense. Trying to think of a schema for this... convo is short for conversation, can use either one.
pm_conversations
convo_id
starter_id
start_datetime
first_message_id
last_message_id
last_message_member_id
num_messages
num_members
label_id
convo_members
convo_id
member_id
convo_messages
message_id
message
sender_id
message_datetime
num_attach
convo_message_attachments
attach_id
message_id
[more stuff about the attachment]
convo_labels
mem_id
label_id
label
num_convo
convo_rules
[stuff]
Maybe another table to show history of when people enter and leave the conversation? Or maybe this is just a "special" message in the messages table? I actually like #2 better
convo_history
event_id
event (enum) [joined, left, invited]
member_id
extra (text, usually the id of the other member)