Message System / Script

[Anuviel]

Thank you in advance for help with this.

I set up a message system in my file. It is rather simple.

It consists of a table with two fields, message display and message input. It is related to another table via Foreign Key. Its purpose is to display "messages" on db home page through a portal.

Basically my main navigation has a message button which when clicked on brings up a custom dialog box where a user can enter their message and it will show up in a portal on the home page layout. It is scripted and once the message is entered and the user hits ok new record is created in message table and that record is displayed on the home page in a portal. Next to the message button is a global field that displays how many messages there is on the home page.

I would like to add one more field which would display how many "new" messages there are since the user last visited the home page. Something like 14 total 5 not seen.

Purpose: There will be 3 or 4 people working in the db most of the time., each person depends on the other for a part of what they need to do. For example: one person adds new items to the db, the other person, once the first person is done, will have to add to the records.

For example the purchaser when ordering from vendors can send a message saying item out of stock. The inventory and the sales person can then see that message and act accordingly.

The problem is that if I cannot alert them that a new message was received it will depend on when they will visit the home page again so that they will be able to see it.

Thank you.,

[T-Square]

I am thinking off the top of my head here:

I would set up a field that stores when each user last logged in, probably in some "User" table and update it in the startup script. Then a calc field that uses this date to count against the message table's create date field (which you will have added), using a relationship from user to message. Finally, a scripted search will select and display the messages in question.

HTH,

David

[comment]

Why not do what any mail client does: define a Read field, initially set to 0. When user clicks in the portal to read the message, set the Read field to 1.

[T-Square]

I think, based on the description, you have to assume that there's a single message table that shows for all users. I make this assumption since there is no To or From information captured in the message table, "just two fields" per OP. In that case, you have to have some mechanism to flag the read status of each message for each user. A single read flag won't provide that.

3:30am?!?! No wonder you have 6300 posts--you don't sleep!

[comment]

Actually, I assumed each message would have an author and a recipient. But your point is valid nevertheless, because in a more sophisticated system a message could have multiple recipients. In such case, you could have a ReadMessages field in the Users table, and clicking on a message would add the MessageID to this field.

[Anuviel]

Thank you. These are good examples and are pointing me in the right direction. The problem is that it is a quick message system such a simple messages for all user base. Some messages are short so that the user can read them in the portal without having to click on it. Also there is no to and from fields. I do not want to have them message each other and turn it into a chat of sorts.

There is a timestamp field which shows who created a message and when and the message itself.

I guess I could make it so that they need to click on the portal row and then display the message in a pop-up window and then set a field which wold count which user accessed the message and mark that appropriately.

I will give it a try.

Thank you.,

[T-Square]

I attach a goofy version of what I was thinking of. It's really simple: the messages get a timestamp, the user gets a timestamp; the portal only shows messages that are newer than the user's last message-reading, as defined simply by their having clicked the "I have read all these messages!" button. Straightforward, but perhaps extensible to what you're after.

The nice thing about this is it simply handles multiple users, and there's very little overhead. The downside is there's no way for someone to read some messages but not others, and there's no guarantee that they have actually read them all. The counter method doesn't prevent a user from clicking the same message 7 times just to get past the screen.

However, if your main point is to provide users with a quick and uncoerced update of the new messages in the system, this could work reasonably well. A lot depends on your particular situation.

David

usermessage.zip