|
|
Posted by Mike on 10/10/92 11:52
Thanks Rik,
I did have another idea and that was when the user hits reply, the
message box he will write his reply in is already defaulted with the
existing message together with when it was sent, just like in outlook.
Then the user can either delete or keep that text. Also, the subject
is updated to prfix it with "RE:" to show its a reply.
I also plan to delete any messages over 30 days old but give the option
to the user to forward any messages to their own email account. After
all, I don't plan on being an email service!
Thanks
Mike
Rik wrote:
> Mike wrote:
> > Hi,
> >
> > I'm working on an internal messaging within a website.
> >
> > Basically, it will be like email but internal so a user logs in to the
> > site and can send a message to another user who has access to the
> > site. When a user logs into the site and visits their profile page,
> > they can see if they have any messages and choose to read, reply or
> > delete. All the messages are to be stored in a db.
> >
> > I've thought of a way to do it by creating 1 table with the following
> > fields..
> >
> > Unique id - increments on every new message
> > sender_id - taken from the id of the logged in person
> > receiver_id - taken from the id of the person he is sending to
> > subject - message subject
> > message - message body
> > read - flag to show if receiver has read the message or not
> > date_added - date the message is sent
> > reply_id - the unique_id of the message this message is a reply too,
> > if at all
> >
> > So if a new message is created, all the above will be filled in apart
> > from the reply_id.
> >
> > If the receiver replys then the reply_id will reference the message it
> > is responding to.
> >
> > Then by various searches, all messages can be shown, including any
> > previous relating messages.
> >
> > Although I have only planned it on paper, the logic seems to work
> > except I can't think of a way for a user to delete a message.
> >
> > As replys are read by the sender and the receiver, if the sender
> > deletes a message the reciever will then not see that particular
> > message.
> >
> > I did think that rather than having a reply_id, the reply message
> > simply takes the pervious message and adds it to the string but I
> > though this would duplicate data in the database.
> >
> > Is there another way to set up this type of system?
>
> Based on your plan I'd say use different tables:
> messages (message_id, bodey etc.)
> user_messages (message_id, user_id, sent/received)
>
> When deleting a message, sent or received, it's only deleted from the table
> user_messages. After that, a check can be done wether there is still a
> reference to it from other tables, if not, delete the message all together,
> if there is, leave te message itself be. Bonus in this scenario is messages
> can be sent to multiple users without doubling them in the main table.
>
> Offcourse, it might be usefull to keep a message history even though the
> users don't think so. A simple additional flag wether to display it for the
> particular user might be sufficient. Then you can apply your own logic to
> wether a thread of messages has been inactive long enough to delete them.
>
> Grtz,
> --
> Rik Wasmus
Navigation:
[Reply to this message]
|