[
https://issues.apache.org/jira/browse/VCL-919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15038636#comment-15038636
]
Andy Kurth commented on VCL-919:
--------------------------------
The variable table will work fine. I'd like to prefix *variable.name* with
*usermessage|* to make it easier to keep track of what the variable table
entries are for.
The majority of the messages sent by the backend are email. Whenever an
IM/console message is sent, it is always accompanied by an email message
(unless the user disabled email messages). There are some cases where the same
message is sent for both email and IM and other cases where a different,
shorter message is sent for IM/console messages.
After thinking about this, I don't think it's very important to know the
delivery method. All the backend really needs is a long and short version of
the message.
How about simply naming the variables:
*usermessage|key|affiliation.name*
Example:
*usermessage|timeout|Global*
The variable.value would contain a YAML hash with the following keys:
* *subject* (required)
* *message* (required)
* *short_message* (optional)
We'll need to allow variables within the subject and message text. Some of the
substitutions come directly from the backend code such as the number of minutes
before a timeout occurs. For these, how about enclosing an upper-case string
in square brackets:
{noformat}You have [TIMEOUT_MINUTES] minutes...{noformat}
Each part of the backend code which requests a user message would look for
specific upper-case strings it expects to be in the text and replace them. The
messages in the default schema would contain all of these strings. It would be
up to the administrator creating custom messages using the frontend to make
sure these strings exist if they want the text included.
Others substitutions come from the reservation data such as
_affiliation.sitewwwaddress_. The backend's DataStructure.pm module maps each
piece of information available to a function name which corresponds to a
database value:
*image_prettyname --> get_image_prettyname() --> image.prettyname*
I would like to allow the first part of this to be specified in square brackets
in the subject and message text:
{noformat}VCL -- [image_prettyname] reservation reinstalled...{noformat}
This would make things easy on the backend because the code would just have to
find the lower-case string, prefix _get\__, and call the subroutine to retrieve
the data.
Thoughts?
> 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
>
> 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.4#6332)
