[
https://issues.apache.org/jira/browse/VCL-919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16007001#comment-16007001
]
ASF subversion and git services commented on VCL-919:
-----------------------------------------------------
Commit 1794871 from [email protected] in branch 'vcl/trunk'
[ https://svn.apache.org/r1794871 ]
VCL-919
Removed all custom $substitution_hashref parameters in calls to
get_admin_message and get_user_message. The previous values have been added to
DataStructure.pm so all replacements are consistent.
Replaced substitution code in Module.pm::_get_message_variable with calls to
DataStructure.pm::substitute_string_variables. This code was mostly duplicated
and improved in DataStructure.pm.
Added the following keys to DataStructure.pm %SUBROUTINE_MAPPINGS. These allow
the backend code to update the values in $self->data and have them available to
be substituted in user and admin values:
* image_capture_type
* notice_interval
Added calls to set_notice_interval in inuse.pm::notify_user_future_endtime and
notify_user_endtime_imminent so that [notice_interval] is properly replaced in
messages.
Renamed keys in DataStructure.pm %SUBROUTINE_MAPPINGS:
* request_pid --> process_pid
* request_ppid --> process_ppid
Updated State.pm::initialize to call set_process_pid/ppid rather than passing
DataStructure object to clunky utils.pm::set_hash_process_id. Removed
utils.pm::set_hash_process_id.
Removed keys from DataStructure.pm %SUBROUTINE_MAPPINGS:
* request_is_cluster_parent (redundant, replaced calls with
is_parent_reservation)
* request_is_cluster_child (was not called)
> 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.3.15#6346)
