Feature #76857
closed
EXT:form Dynamic Recipients Concept
100%
Description
The possibility to define a dynamic recipient for a contact form has been discussed in the past, and the 1st approach of defining this like it is possible for the sender (senderEmailField) leads to the problem that the form can be abused to send emails to anybody.
However, a usual requirement is that there are predefined recipients for departments, like sales, support, payments etc. or a selection of products which are accociated with the product managers.
My suggestion is to handle it like that:
The form contains a dropdown or radio buttons where the user can select between “Sales”, “Support” and “Payments” in our example, which define the values 1, 2 and 3.
In the form definition this fieldname is set as a keyfield, and the email addresses are defined as an array. So there’s no chance another email address can be entered by the website user.
Example code for the Combobox:
10 = SELECT
10 {
class = form-control
name = recipientkey
required = required
size = 1
label {
value = Recipient
}
10 = OPTION
10 {
text = Sales Department
selected = selected
value = 1
}
20 = OPTION
20 {
text = Support Team
value = 2
}
30 = OPTION
30 {
text = Payments related
value = 3
}
}
Example code for the post processor part:
1 = mail
1 {
recipientEmailKeyField = recipientkey
recipientEmail {
1 = sales@typo3.org
2 = support@typo3.org
3 = typo3@paymentprovider.org
}
}
I already implemented this in a project here and would like to add this feature after a short discussion.
Updated by Björn Jacob over 8 years ago
- Status changed from New to In Progress
- Assignee changed from Matthias Philipp to Björn Jacob
- Sprint Focus set to On Location Sprint
Updated by Björn Jacob over 8 years ago
- Status changed from In Progress to Needs Feedback
- Assignee changed from Björn Jacob to Matthias Philipp
- % Done changed from 70 to 100
I think, there is no need for coding a new postProcessor or something like that. Please check the following implementation. There are some prerequisites you have to take care of.
1) The form has to be stored outside the content element. Since 7.6 stdWrap is not allowed anymore as soon as the form is stored as content element. In TYPO3 v8 it is quite easy to have the form outside tt_content, since we have introduced the predefined form feature, see commit. If you are using TYPO3 v7 you have to find your own way to load the "external form". There are plans to release the backport of predefined forms soon as a separate extension.
2) If v8 is used, register a new predefined form via PageTS.
TCEFORM.tt_content.tx_form_predefinedform.addItems.dynamicRecipients = Dynamic Recipients
3) Add your form to your TypoScript. As said above, you can use the stdWrap feature. Most of the postProcessor settings are stwdWrap-able, see commit.
plugin.tx_form.predefinedForms.dynamicRecipients = FORM plugin.tx_form.predefinedForms.dynamicRecipients { enctype = multipart/form-data method = post confirmation = 1 postProcessor { 1 = mail 1 { senderEmail = test@example.com senderName = Sender Name subject = FormSubject recipientEmail = CASE recipientEmail { key.data = GP:tx_form_form|form|recipientkey key.intval = 1 default = sales@example.com 2 = TEXT 2.value = support@example.com 3 = TEXT 3.value = payments@example.com } priority = 1 organization = TYPO3 } } 10 = SELECT 10 { class = form-control name = recipientkey required = required size = 1 label { value = Recipient } 10 = OPTION 10 { text = Sales Department selected = selected value = 1 } 20 = OPTION 20 { text = Support Team value = 2 } 30 = OPTION 30 { text = Payments related value = 3 } } 20 = SUBMIT 20 { value = Submit } }
4) If v8 is used, open your content element and choose your predefined form.
That's it.
Updated by Matthias Philipp over 8 years ago
I coded the feature into the existing postProcessor because of the circumstances you mention in (1) - the form is a content element and cannot use stdWrap.
Your suggested workarounds are quite helpful for some situations, but not for the standard (=content element) case.
I did a lot of googleing and reading threads from other users having similar wishes, so I came to the conclusion that my suggestions would be a quite useful feature extension. Most users use the form as content element.
Updated by Björn Jacob over 8 years ago
- Status changed from Needs Feedback to Closed
Thank you for your fast reply. Your answer is 100% valid and I totally understand and agree. Soon we will release the predefined form feature as standalone extension for v7. As you know, features cannot be merged into LTS versions after their release. So this feature won't make it into v7. You could do the same as we will do: just release your own extension for this new postProcessor.
In v8 we've got the predefined form solution. For version 8, there will be a lot of deep architectonic changes. Your postProcessor will not work in v8 LTS. Unfortunately, it does not make sense to merge your code into 8.
Therefore I'm closing this issue. Hope this is fine with you. For sure, you can post the url to TER as soon as you've released your code ;)
Updated by Björn Jacob over 8 years ago
- Priority changed from Should have to Won't have this time