Customization of standard e-mail subjects for forms

[fredericalpers]

Customization of standard e-mail subjects for forms

Introduction

As a website owner, I would like to customize the standard e-mail subjects for various forms on my website and provide them with a fixed prefix so that the messages are easily recognizable in onOffice enterprise and at the same time there is the possibility to customize the subject lines.

User Story

The purpose of this user story is to customize the standard email subjects for various forms (owner form, prospect form, contact form, newsletter) on the website. The subject should contain a fixed prefix [onOffice-WP] by default. At the same time, the website operator should be able to customize the rest of the subject line. Dynamic content (such as the property ID) can be integrated via “tags/pills”, similar to the handling of meta tags in Yoast.

This customization aims to improve the clarity and precision of email subject lines generated by the forms on the website, while meeting the necessary technical requirements for integration with onOffice enterprise. The ability to insert dynamic content should ensure that the subject lines are relevant and informative.

Task / Requirements

• The subject of every e-mail sent from the forms on the website should contain the prefix “[onOffice-WP]”. This prefix should not be able to be changed by the website operator or other users.
• The website owner should have the option of overwriting the default subject (with the exception of the prefix).
• A character count of between 40 and 60 characters or up to ten words is recommended. Add information text: We recommend a maximum number of characters between 40 and 60 or up to 10 words.
• The handling of this dynamic content should work in a similar way to Yoast for meta tags. When writing a “%” symbol, a drop-down menu should appear showing the available tags/pills. Alternatively, a button should be available to select the possible tags/pills and insert them into the subject.

The following should be available for selection in the tags/pills:

• estateID (if applicable)
• All fields that were added to the form in the plugin backend, e.g. first name, surname, contact type and contact of origin.
• message field, GDPR checkbox and general terms and conditions should not be available for selection even if added to the form.

Standard subject lines for forms:
Owner form: Message from the owner form of your website.
Prospect form: Message from the interest form on your website.
Contact form: Message from the contact form of your website.
Newsletter form: New newsletter registration

Example for a subject:
EDIT: Inquiry form for the estate agent on a detail page changed to “Inquiry for property (Tag/Pill estateID)” in the e-mail it would be displayed as: "Inquiry for property 99".

[yeneastgate]

@fredericalpers After investigating, I need you to confirm the following:

• message field, GDPR checkbox and general terms and conditions should not be available for selection even if added to the form.

• Do you want to display all fields except for specific ones like message, GDPR (Checkbox), and GDPR status?
• If checkbox or radio values are displayed, how would you like them to display in the subject when send mail? Could you provide a specific example?

Inquiry form for the estate agent on a detail page changed to “Inquiry for property (Tag/Pill estateID)” in the backend would be displayed as: "Inquiry for property 99".

• The implementation as described is not feasible. When editing the subject, we cannot determine the exact estateID on the backend. We can only obtain the precise estateID on the frontend. As a result, we can only displaying only the Tags/Pills.

Please refer to the video for more information.

bandicam.2024-08-19.16-01-15-155.mp4

[fredericalpers]

Do you want to display all fields except for specific ones like message, GDPR (Checkbox), and GDPR status? If checkbox or radio values are displayed, how would you like them to display in the subject when send mail? Could you provide a specific example?

Yes all fields should be available except the mentioned ones above. For Radio buttons only the fields with value "1" should be available. For Checkboxes with multiples values such as the field "Beziehung" all values should be available. The fieldname does not have to be displayed, simply their values should be displayed.

The implementation as described is not feasible. When editing the subject, we cannot determine the exact estateID on the backend. We can only obtain the precise estateID on the frontend. As a result, we can only displaying only the Tags/Pills.

This had a typo and was supposed to be. "in the e-mail it would be displayed as: Inquiry for property 99." I have edited the initial issue.

[yeneastgate]

@fredericalpers I have implemented this feature and here is the demo video:

881_demo.mp4

However, I still need to confirm a few things to complete this task:

1. Regarding the interface:
   
   => Do you want to make any changes to the interface for this input subject email?

2. About the tags/pills: Will they be based on the fields config or all fields in the form?
   

[fredericalpers]

Do you want to make any changes to the interface for this input subject email?

the size of the subject field and the pills must be kept the same as the other fields.

About the tags/pills: Will they be based on the fields config or all fields in the form?

As mentioned in the task / requirements it should be the fields added to the form.

[yeneastgate]

the size of the subject field and the pills must be kept the same as the other fields.

I will refactor the CSS to ensure this.

As mentioned in the task / requirements it should be the fields added to the form.

I will research and find a solution for this functionality.

[yeneastgate]

@fredericalpers I have made the requested changes and here is the demo video: https://files.fm/f/56tdqchaw7

Please check and let me know your opinion. Thanks!

[fredericalpers]

Hi @yeneastgate,

The current implementation is working well, and I appreciate the progress so far. However, there are a few small adjustments that still need to be made.

According to the task and requirements, we need to add a button that allows users to insert variables directly, as not everyone may be aware that simply typing "%" in the input field is sufficient. Upon clicking this button, a dropdown should appear with the available options for selection. Please see the examples below.

• Button colors: color: #646970; border-color: #646970; background: #f6f7f7;

Please let me know if you need any further clarification on this.

Thanks for your effort!

[yeneastgate]

Hi @yeneastgate,

The current implementation is working well, and I appreciate the progress so far. However, there are a few small adjustments that still need to be made.

According to the task and requirements, we need to add a button that allows users to insert variables directly, as not everyone may be aware that simply typing "%" in the input field is sufficient. Upon clicking this button, a dropdown should appear with the available options for selection. Please see the examples below.

• Button colors: color: #646970; border-color: #646970; background: #f6f7f7;

Please let me know if you need any further clarification on this.

Thanks for your effort!

I got it! thanks

[yeneastgate]

@fredericalpers I added the button, please take a look at my demo video and let me know your opinions. Thanks!

issue.881.mp4