Web Services Wiki
Welcome Guest: Login
Particularly on the webmaster comments form it would be nice to have dynamic recipients for the Email Owner Form Action and Email Owner Document Form Action.
Note: the method described here for dynamic form recipients exposes the form recipient emails in the html form. This may not be desired, since these email addresses can be pulled and harvested.
When editing the Email Owner X form action in the SMI, there is a field "list of E-mails to send to". Above this, there will be a select combo or radio group: "recipients type" with options "static list" and "choice from form field". The "static list" option is the default, and will display the "list of e-mails to send to" field below it.
When the "choice from form" option is chosen, instead of the "list of E-mails to send to" field, there will be a "form field for choice" select combo box. The first item is "not set" with a value of "". The rest of the items are the form fields, the title of each is the label (or name if label is empty), and the value is the name of the form field.
Now, when the form is submitted and this action is run, if the "recipients" property is set to "choice from form field":
There are a few places that need to be changed. The configuration screen for the form, and the form action itself. All paths are assumed to be relative to the Tropos' Product directory. It'd complete the entire process for one of these actions, and then move onto the other.
The configuration screens are located in the "form" widget, here:widgets/top/ect/form. The "mode_edit" directory contains the code for the edit screen. Within it is a "manage" directory, which contains a template for the configuration screen for each action. You'll need to edit the "email_owner_action.pt" and "email_owner_document_action.pt".
Find the <tr> for the "list of e-mails to send to". Add above it another row for the new "recipients type". The "list of ..." should now be made conditional, so add a "tal:condition" onto the <tr>. It's condition should inspect the action_config attribute for this new property, and only display this row of the property value means that the static list should be used. Also, the default if this attribute is either not set or has no value should be to display this row.
Copy/paste the "list of..." row. This copy will become the "choice from form" property. See the standard_settings.pt for examples on how to generate a select box containing the form fields in the form (fname_field, mname_field and lname_field do this).
The mode_edit/save_help.py python script is called when the user clicks "save" or "save and exit". This script does the work of saving the configuration settings back to the silva xml of the form and actions. In the first part of the script, the valid options for the two email_owner actions will need to have the two new properties added to them.
You should be able to test this in your Zope development environment without restarting zope. Changes should appear with a refresh.
All form actions are located in "FormActions.py". Each form action is a class that either directly or indirectly inherits from "FormAction" (the first class in this file). The two actions that need to be modified are "EmailOwnerAction" and "EmailOwnerDocumentAction". All of these objects are callable. This means that you can do action_instance_variable() to "call" the action. The method in the class is "def __call__".
Notice that each of these class inherits from both "FormAction" and "StandardEmailMixin". All email actions, including the confirmation email action, inherit from this mixin, which contains shared email-related functions. In the "def standardEmailParams" method, the "form_recipients_email" is set. The form_recipients_email is used for the "to: " mail header (where to deliver the email).
This needs to be changed so that:
If the action_config has the "recipients type" attribute, and the value of that attribute means "choice from form":
Documentation should be written in the Tropos — Silva HTML Forms area of the wiki detailing how to use this new feature.
Need to test to ensure that email addresses can't be submitted (and delivered to) which aren't values of this choice. If it is possible to do this, then it is possible to use forms employing this feature to spam arbitrary email addresses.