Package Specification Summary for Package: messages
|Summary:||This package allows users interact with other course/community members by sending private messages.|
|Maturity:||New Submission or Maturity Unknown|
|This package depends on:||dotlrn ajaxhelper|
|Packages that depend on messages:||messages-portlet|
Bug Tracker Summary for Package: messages
There is no package with the name "messages" known to bug-tracker.
Code Metrics Summary for Package: messages
|# Tcl Procs||0|
|# Tcl Lines||0|
|# Tcl Blank Lines||1|
|# Tcl Comment Lines||0|
|# Automated Tests||0|
|# Stored Procedures||PG: 0 ORA: 0|
|# SQL Lines||PG: 0 (blank 1 comments 0) ORA: 0 (blank 1 comments 0)|
|# ADP pages||0|
|# ADP lines||0|
|# Include pages (messages/lib/)||0|
|# Documentation pages||0|
|# Documentation lines||0|
|Browse Source||Not installed|
not to be confused with PrivateMessaging
Package: Private Message
en:ecommerce-g2 project will need a private messaging service. From ec g2 page:
Check applicability of a private-message package as an interOpenACS messaging package for sending private messages to users (and between users?). This becomes significant for
1. cases where one needs to retain strict privacy and email addresses may be shared (not private). See http://openacs.org/forums/message-view?message%5fid=387304#387964 (skip first line)
2. keeping an online log of messages that need to be reported to admins (similar to the Problem Reports messaging that is used in the ecommerce package).
3. ecommerce Problem Reports could use that fancy, green alert bar to alert package admins to items that need immediate attention. (add this ability to notifications or some intra-site mail package instead? NO. that functionality only applies to existing sessions.
There are 2 user-to-user message package available, and also something called acs-messaging which seems to have the underlying functionality). Maybe the green bar could notify of new messages in the private messaging system...
Following is edited material about an intrasite-message package with similar goals:
Richard Hamilton wrote an intrasite-message package that allowed what looked like webmail but done so that the message never leaves the database. Needed to work with OpenACS 4.6.2. Because there is no list builder on that version, it uses Jon Griffin's paginator procs for the message folder display functionality which works very well but is not really part of the OpenACS and you would need to install his procs in order to use it.The OpenACS object model is not used. You absolutely do not want to be having to set permissions on messages or adding multiple entries (per message) to the permissions lookup view because as message numbers grow this would be a sure fire way to clog everything up big time. Code assumes recipients are allowed to see the messages and others cannot.
RH's module provides the basic folders (in-box, sent, deleted, draft) and allows users to add additional custom folders and move messages around between them just like in Outlook Express. Mesages are addressed by user_id by use of the user lookup code from the admin pages (with mods). The module takes care of the fact that a single message can exist in a different folder for each user, and allows for replies, copying the text and indenting with '>' just as Outlook Express does.
Intrasite-message has been used for a security conscious deployment where public email was not favored. Consequently, RH also hacked package calls to ns_sendmail such that messages were sent using intrasite-message instead of through the smtp server. Such a re-direction should be made an option in the parameters for applications that send notifications, that the messaging module can be selected instead of the system smtp server. However it needs to be implemented properly using callbacks instead of with ugly cross package hacks :-). Intrasite-message also grabs unread message numbers data for display on the user home page etc.
Intrasite-message is not implemented (and it makes no sense really to permit) messages being forwarded out of the private message module to public email because that breaches the very privacy that you are trying to achieve, but notifications of a message could be valuable. Also, an incoming message function might be an interesting adjuct in future for emails sent to [username]@[website].
a general purpose, properly supported, OpenACS module for private (intra-site) messages would need these improvements:
- 1) Use list builder for message box display.
- 2) Re-do the UI so that it is 100% style sheet rather than using ad_table tables withing template tables!
- 3) implement callbacks for integration with any other package that needs to send or receive messages.