[
https://issues.apache.org/jira/browse/VCL-919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152817#comment-15152817
]
Josh Thompson commented on VCL-919:
-----------------------------------
Since it is vcld that needs to validate the variable substitution in the
messages, it would be helpful if there was a way for the frontend to signal to
vcld that there are messages needing to be validated. I propose the following
solution. We could add an extra entry to the variable table -
usermessage_needs_validating. It would have a value of 0 or 1. This would allow
vcld to periodically check a single entry in the variable table to see if there
are messages that need validating. When it gets set to 1, vcld could then query
for any messages with a timestamp within a few minutes of the timestamp on
usermessage_needs_validating, and then validate those messages. If any messages
have invalid substitutions, an additional field can be added to the YAML part
of those named "invalidfields" with a value that is an array of fields that
were in the message that are invalid.
This would allow the frontend to poll the updated messages for a few minutes
after a user has updated any of the messages, and then to notify the user if
vcld has flagged that any are invalid.
> 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)
