[jira] [Commented] (VCL-919) Allow customization of notification messages sent to users

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/VCL-919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16061432#comment-16061432 ] 

ASF subversion and git services commented on VCL-919:
-----------------------------------------------------

Commit 1799697 from [~jfthomps] in branch 'vcl/trunk'
[ https://svn.apache.org/r1799697 ]

VCL-919 - Allow customization of notification messages sent to users

siteconfig.php:
-modified Messages::getHTML: moved html for invalidmsgfieldspane to an earlier part of the html so that the box defaults to a higher position; it was a little out of the messages box
-modified AJvalidateMessagesPoll: no longer depend on usermessage_needs_validating (backend removed the entry); just look for and user message fields that were not set by the webcode and contain "invalidfields"

siteconfig.js: modified messages.prototype.updateInvalidContent: updated to handle invalid fields being separated into keys (i.e. message, subject, etc)

> Allow customization of notification messages sent to users
> ----------------------------------------------------------
>
>                 Key: VCL-919
>                 URL: https://issues.apache.org/jira/browse/VCL-919
>             Project: VCL
>          Issue Type: New Feature
>          Components: database, vcld (backend), web gui (frontend)
>            Reporter: Andy Kurth
>             Fix For: 2.5
>
>
> The backend code sends various messages to users.  Examples:
> * Email when reservation is ready
> * Email when image capture is complete or delayed
> * Terminal notification when a Linux reservation is about to timeout
> All of the messages are hard-coded in the backend code.  It would be an improvement to allow these messages to be customized without having to alter the source code.
> Proposed solution:
> A database table named *usermessage* would be added to the schema.  It would, at a minimum, contain:
> * id
> * key
> * affiliationid
> * deliverymethod
> * subject
> * message
> The *id* field is not absolutely necessary but keeps with the structure of most other tables in the schema.
> The *key* field would be a unique identifier string which is more convenient to use than a simple integer.  For example, _reservationready_ could correspond to the message sent to a user when the Connect button appears.  The backend code could call something like {code}my ($subject, $message) = get_user_message('reservationready', $user_affiliation_id);{code}
> The *affiliationid* field allows messages to be customized for different sets of users.  The messages currently hard coded would be added to the schema using the _global_ affiliation.  Users would be sent these by default unless a message exists specific to their affiliation.
> The *deliverymethod* field would be used to allow email messages, IM messages, and other types of messages to use different text.  There would be situations where you'd want to send the same message but some methods may have constraints.  This could also facilitate a mobile text message feature in the future.  The backend code could specify which type of message to retrieve:
> {code}my ($subject, $message) = get_user_message('reservationready', $user_affiliation_id, 'sms');{code}
> The backend code and database are fairly straightforward to implement.  A web frontend feature would need to be added to allow system administrators to modify the messages.
> There needs to be a mechanism to specify variables in the subject and message fields so the backend can dynamically generate the message with the correct IP address, image name, etc.  The syntax and vocabulary need to be determined so the backend and frontend are aligned.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)