Refactoring, improvements to "E-mail Templates" section

[Alexander Obuhovich]

form has 2 variants:
1. developer mode - some form part is visible in debug mode only
2. administrator mode - only useful to end user functionality

1. refactor FromToUserId field this way (form layout):
- Manual Sender: [x]
- Sender: [____________] or [_________][user selector image] - visible when "Manual Sender" checkbox is used
- Manual Recipients: [x]
- Recipient Type: (*) To ( ) Cc ( ) Bcc - visible when "Manual Recipients" checkbox is used
- Recipient Name: [_____________________] - visible when "Manual Recipients" checkbox is used
- Recipient Email: [____________________] - visible when "Manual Recipients" checkbox is used
- Recipients: [ ....... ] - multi input control (like on custom field editing) - visible when "Manual Recipients" checkbox is used

Fields "Manual Sender" and "Manual Recipients" will be visible/changable only in debug mode. All current email events will be converted this way:
* all email events will have "Manual Sender" checked
* email events sent to admin will have "Manual Recipients" checked

By default, when developer is adding new email event both "Manual" checkboxes will be checked.

2. add a way to edit ReplacementTags field
- Tag: [____________________]
- Replacement: [____________________]
- Replacement Tags: [ ....... ] - multi input control (like on custom field editing)

3. remove "E-mail Settings" section, that each module have, since it only duplicates "E-mail Templates" section.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Alexander Obuhovich]

Also in developer mode we should display email message text using simple textarea with "Open In HTML Editor" button (as in Regional section for now), but in administrator mode we will display inline HTML editor as for now in "Email Templates".

[Dmitry Andrejev]

hi Alex,

Looks interested, but I had a hard time understanding this.

If you don't mind providing some more basic explanation of what each field means.

Thanks!

DA.

[Alexander Obuhovich]

What exactly don't you understand:

• the way I depicted form controls using text
• what control does what
  

Try to read my original post again, maybe it becomes more clear to you then. I've tested my post on 2 people before posting it and they both understood it as I did, so I assumed, then others will understand it as well.

[Dmitry Andrejev]

Hi Alex,

Thanks for your reply - a bit rough, but I know you are always straight to the point guy...

Anyway here is what I did not get from your post:

1. Please explain why we need Manual Sender and Manual Recipient and will happen if I want still want all Emails to be send out/send to from main Admin Email account (specified under Configuration)? My guess is that it these 2 unchecked you can specify Custom selected Users/Email to receive Emails, but WHY we need to change all current Events to have "Manual Sender" checked?

2. Perhaps, Manual Sender and Manual Recipient can have a better names:

Manual Sender = Force From User/Email

Manual Recipient = Force To User/Email

3. Please describe the Login behind "Recipient Type: (*) To ( ) Cc ( ) Bcc - visible when "Manual Recipients" checkbox is used" so I don't miss anything.

If this is what I think - we should be able to SEND out ANY type of Emails at once to - TO CC and BCC, not just one of them. Imagine if Email Client would limit you on this like you described.

4. "Recipients: [ ....... ] - multi input control (like on custom field editing) - visible when "Manual Recipients" checkbox is used"

I suppose these are additional Email Receipts, but what type TO, CC, BCC? I say we should give an option (radio button?) for them to choose.

DA.

[Alexander Obuhovich]

1. When "Manual Sender" checkbox is checked, then administrator is able, but not forced to specify user/email used to send given email event. When nobody is specified, then site-wide email address from configuration is used as for now. We enable "Manual Sender" for existing email events for administrator to be able to set sender user/email as he can now, since administrator won't see "Manual Sender" checkbox (only visible for developers).
2. I was talking more about database field names, since "Sender" and "Recipient" words are as simple as they can be, but I agree, that "Manual" word could be replaced with something other. Maybe "Custom Sender" or "Automatic Sender" (with opposite logic as for now). Same for "Manual Recipient" field.
3. Logic is a follows:
1. As you know, then for example in "Microsoft Outlook" or any other email client you can specify emails (with or without names) that will receive given email ("To:" field), emails, that will receive email copy ("Cc", "Carbon Copy"), and "Bcc" emails.
2. Here we have combined list of all possible recipients no matter if they going to To/Cc/Bcc.
3. Because of that you need to specify what type of recipient each email will be (defaults to "To:")
4. Fields "Recipient Type", "Recipient Name", "Recipient Email" are virtual and are used to enter data in that "Recipients" multi-input control (same as "Value" field during custom field editing). We could group them by subsection if it's more intuitive.
   

[Dmitry Andrejev]

Hi Alex,

Thanks for your port and explanation. Please find my version of the form below:

- Send Email From: ( ) Default Website address (X) Custom Sender

--------------------------
- Send From Address: [______Email______] or [_________][user selector image] - Enabled (otherwise hidden, but I think we should NOT delete if had records) when "Send From" is Custom Sender - REQUIRED
- Send From Name: [____]

- Send Email To: ( ) Default Website address (X) Custom Recipients  -  Enabled (otherwise hidden, but I think we should NOT delete if had records) when "Send From" is Custom Sender 

--------------------------

- Recipient Type: (*) To ( ) Cc ( ) Bcc - visible when "Custom Recipients" radio is selected
- Recipient Name: [_____________________] - visible when "Custom Recipients" radio is selected (Required)
- Recipient Email: [____________________] - visible when "Custom Recipients" radio is selected

- Recipients: [ ....... ] - multi input control (like on custom field editing) - visible when "Custom Recipients" radio is selected

Just to clarify why I think Radio button will do a better job instead of Checkbox - it explains WHO it will be in both cases since it's NOT clear enough with YES/NO type of answer here. I hope you would agree.

I agree on the rest of fields - options.

DA.

[Alexander Obuhovich]

I think you meant to set Recipient Email, not Name as required.

Also we should delete or partially merge all other sections, that list data from same table.

[Dmitry Andrejev]

Hi Alex,

Yes, you are correct - Required is for  Recipient Email address only.

I have reviewed this whole form again and think may be we should do this all the way including support to specify In-Portal User and/or Group as a Recipient and not only the Email addresses? I know it's kind of adding more complexity to the processing, but in the end we should cover all possible scenarios - right? Also, I believe we already DO use this type of processing methods in Mailing List functionality when you can send emails to: Email, User, Group and will be processed through.

Here is a new layout of all aspects (as Alex put in his original port)

1. Refactor From/ToUser

------------------------------

- Send Email From: (X) Default Website address ( ) Custom Sender

--------------------------
- Send From Address: [______Email______] or [_________][User selector image] - Enabled (otherwise hidden, but I think we should NOT delete if had records) when "Send From" is Custom Sender - REQUIRED

- Send From Name: [____]

- Send Email To: (X) Default Website address ( ) Custom Recipients  -  Enabled (otherwise hidden, but I think we should NOT delete if had records) when "Send From" is Custom Sender 

--------------------------

- Recipient Type: (*) To ( ) Cc ( ) Bcc - visible when "Custom Recipients" radio is selected

- Recipient Address: [______Email______] or [_________][User OT Group selector image] - visible when "Custom Recipients" radio is selected - REQUIRED

- Recipient Name: [_____________________] - visible when "Custom Recipients" radio is selected

- Recipients: [ ....... ] - multi input control (like on custom field editing) - visible when "Custom Recipients" radio is selected

NOTES (on above):

a. for simplicity while adding NEW Events in I think it would sense keep "Default Website address" enabled for both "Send Email From" and "Send Email To". In most cases Developer will be not the person to fine tune these addresses, but Administrator will be or this is done at later point. Alex, I know you specified this differently in your initial task, but I have though about this a lot - when it was last time you have specified the Email address that will be used on Production while developing the actual Event?

b. as I pointed out above I think it's critical to teach system to process Users and Groups in "Recipient Address". The only thing we would need to keep in mind that in some cases Username might be User Email in the In-Portal.

c. Editing of "Recipient Addresses" should be properly handled - I guess what we have in Custom fields now.

2. add a way to edit ReplacementTags field (Alex's post - I agree on this)

-----------------------------------------

- Tag: [____________________]
- Replacement: [____________________]
- Replacement Tags: [ ....... ] - multi input control (like on custom field editing)

3. remove "E-mail Settings" section, that each module have, since it only duplicates "E-mail Templates" section.

 

Okay, but need to clarify some things - see questions below.

At this point we need to review/confirm above and move forward with the rest of the fields on the form.

I have additional questions that will help us move forward:

=============================================

1.  In Developers / Administrator modes what would be limitation and fields available for Editing? I guess we need to start with list of all necessary fields we want to have on the form and then decide what's visible or may be just a Label in Administrator's mode and what's not.

2. If we going to get rid of "E-mail Settings" this means we'll have only 1 single grid with "E-mail Templates" to manage (enable/disable) email Events and actual templates?

Thanks.

DA.

[Alexander Obuhovich]

We can't make "Send Email From" and "Send Email To" fields default to "Default Website address" because in such case administrator won't be able to enter any sender/recipients (see my original post), they will not be visible for administrators.

Making that field default to "Custom Sender" and "Custom Recipients" and not entering any actual email below will work same as "Default Website address".

That's the idea: if developer sets sender/recipients automatically, then administrator won't even see any control to specify sender/recipients.

What should be visible and what not is described in my first post.

[Dmitry Andrejev]

Thanks for commenting on this Alex.

I think we are missing a huge point here - we simply can not LIMIT the ability to configure the Event to the Debug mode!

Why? because there will be people who do not need to Enable Debug to change Sender or Recipient in the Event - it's just wrong to do it other way around!

I do realize that we need to limit some things in some cases, but we can't remove all E-mail Settings sections and simply restrict access - it should be done as an option. Let's try approaching this from the other side - what do you think we should ALLOW changing for ROOT user in Email Event?

Thanks!

DA.

[Alexander Obuhovich]

We only limit developer-related controls to debug mode. If developer considers, that administrator should be allowed to do something more with email event, then he will check proper options.

Because of that we enable "Manual Sender"/"Manual Recipient" (terms from my original post) for existing email events (more details in my original post) so administrator will add (if needed) custom sender/recipients later.

Only developers create new email events and only they know if recipient/sender is generated automatically and can't be chosen by administrator.

Root user is not developer and most administrators use it to access the administrative console, so I'm against any checks against "root" user.

[Dmitry Andrejev]

Hi guys,

After some further review and off group discussion we came to the following idea:

1. Refactor From/ToUser

------------------------------

- Allow Changing Sender [ ] - off be default and Visible in DBG only

- Send Email From: (X) Default Website address ( ) Custom Sender

--------------------------
- Send From Address: [drop-down with Email, User, Group options] [______TextField with Auto-complete based on drop-down______] - Enabled (otherwise hidden, but I think we should NOT delete if had records) when "Send From" is Custom Sender - REQUIRED

- Send From Name: [____]

- Allow Changing Recipient [ ] - off be default and Visible in DBG only

- Send Email To: (X) Default Website address ( ) Custom Recipients  -  Enabled (otherwise hidden, but I think we should NOT delete if had records) when "Send From" is Custom Sender 

--------------------------

- Recipient Type: (*) To ( ) Cc ( ) Bcc - visible when "Custom Recipients" radio is selected

- Recipient Address: [drop-down with Email, User, Group options] [______TextField with Auto-complete based on drop-down______]  - visible when "Custom Recipients" radio is selected - REQUIRED

- Recipient Name: [_____________________] - visible when "Custom Recipients" radio is selected

- Recipients: [ ....... ] - multi input control (like on custom field editing) - visible when "Custom Recipients" radio is selected

2. Since all this will be done for 5.1.0 - we would need to have 2 Tabs - General and Event Settings

General - lists all fields as we have now under 5.0.x 

Events Settings - lists the rest plus whats shown above. The exact order of the fields on this can can be worked out later.

3. Show Add/Delete Event buttons only in DBG mode.

I hope it finalizes it.

DA.

[S.G.]

One moment: I think that we need to retain option to add Cc & Bcc
recipients even if recipient is NOT set to manual. For example,
administrator may configure that all order notifications sent to
dynamic customer addresses always come as Bcc to his email address
(for more control of what email customers receive).

I suggest that in case when Send Email To is disabled by developer,
Recipients control still remain visible for administrator, but only Cc
& Bcc recipient types are available.

> On Mon, Apr 19, 2010 at 3:01 AM, Alexander Obuhovich <aik.b...@gmail.com>wrote:
>
> > We only limit developer-related controls to debug mode. If developer
> > considers, that administrator should be allowed to do something more with
> > email event, then he will check proper options.
>
> > Because of that we enable "Manual Sender"/"Manual Recipient" (terms from my
> > original post) for existing email events (more details in my original post)
> > so administrator will add (if needed) custom sender/recipients later.
>
> > Only developers create new email events and only they know if
> > recipient/sender is generated automatically and can't be chosen by
> > administrator.
>
> > Root user is not developer and most administrators use it to access the
> > administrative console, so I'm against any checks against "root" user.
>

> > On Mon, Apr 19, 2010 at 2:28 AM, Dmitry Andrejev <dandre...@gmail.com>wrote:
>
> >> Thanks for commenting on this Alex.
>
> >> I think we are missing a huge point here - we simply can not LIMIT the
> >> ability to configure the Event to the Debug mode!
>
> >> Why? because there will be people who do not need to Enable Debug to
> >> change Sender or Recipient in the Event - it's just wrong to do it other way
> >> around!
>
> >> I do realize that we need to limit some things in some cases, but we can't
> >> remove all E-mail Settings sections and simply restrict access - it should
> >> be done as an option. Let's try approaching this from the other side - what
> >> do you think we should ALLOW changing for ROOT user in Email Event?
>
> >> Thanks!
>
> >> DA.
>

> >> On Sun, Apr 18, 2010 at 1:36 PM, Alexander Obuhovich <aik.b...@gmail.com>wrote:
>
> >>> We can't make "Send Email From" and "Send Email To" fields default to "Default
> >>> Website address" because in such case administrator won't be able to enter
> >>> any sender/recipients (see my original post), they will not be visible for
> >>> administrators.
>
> >>> Making that field default to "Custom Sender" and "Custom Recipients" and
> >>> not entering any actual email below will work same as "Default Website
> >>> address".
>
> >>> That's the idea: if developer sets sender/recipients automatically, then
> >>> administrator won't even see any control to specify sender/recipients.
>
> >>> What should be visible and what not is described in my first post.
>

> >>>>> On Sun, Apr 18, 2010 at 5:08 AM, Dmitry Andrejev <dandre...@gmail.com>wrote:
>
> >>>>>> Hi Alex,
>
> >>>>>> Thanks for your port and explanation. Please find my version of the
> >>>>>> form below:
>
> >>>>>> - Send Email From: ( ) Default Website address (X) Custom Sender
> >>>>>> --------------------------
> >>>>>> - Send From Address: [______Email______] or [_________][user selector
> >>>>>> image] - Enabled (otherwise hidden, but I think we should NOT delete if had
> >>>>>> records) when "Send From" is Custom Sender - REQUIRED
> >>>>>> - Send From Name: [____]
>
> >>>>>> - Send Email To: ( ) Default Website address (X) Custom Recipients
> >>>>>> -  Enabled (otherwise hidden, but I think we should NOT delete if had
> >>>>>> records) when "Send From" is Custom Sender
> >>>>>> --------------------------
> >>>>>> - Recipient Type: (*) To ( ) Cc ( ) Bcc - visible when
> >>>>>> "Custom Recipients" radio is selected
> >>>>>> - Recipient Name: [_____________________] - visible
> >>>>>> when "Custom Recipients" radio is selected (Required)
> >>>>>> - Recipient Email: [____________________] - visible
> >>>>>> when "Custom Recipients"
>

> ...
>
> read more »


--
Subscription settings: http://groups.google.com/group/in-portal-dev/subscribe?hl=en

[Alexander Obuhovich]

I agree with Sergey.

Also there is a typing error here:

- Send Email To: (X) Default Website address ( ) Custom Recipients  -  Enabled (otherwise hidden, but I think we should NOT delete if had records) when "Send From" is Custom Sender

• "Send From" should be replaced with "Send Email To"
• "Custom Sender" should be replaced with "Custom Recipients"

[Dmitry Andrejev]

Sergey, Alex - agreed in regards to leaving CC and BCC available.

Here is the final version (with some corrections) of "From/ToUser":

- Allow Changing Sender [X] - field is ON by default and VISIBLE in DBG only

====== Always Visible, but Editable if DBG + "Allow Changing Sender" ======

- Send Email From: (X) Default Website address ( ) Custom Sender

- Send From Address: [drop-down with Email, User, Group options] [_ Auto-complete based on drop-down_] - REQUIRED
- Send From Name: [__text__]

============

- Allow Changing To Recipient [X] - field is ON by default and VISIBLE in DBG only

====== Always Visible, but Editable if DBG + "Allow Changing To Recipient" ======

- Send Email To: (X) Default Website address ( ) Custom Recipients

- Recipient Type: (*) To ( ) Cc ( ) Bcc - To visible when "Custom Recipients" radio is selected

- Recipient Address: [drop-down with Email, User, Group options] [_ Auto-complete based on drop-down_] - REQUIRED

- Recipient Name: [__text__]

- Recipients: [ ....... ] - multi input control (like on custom field editing)

============

NOTES on above:

a. Note changes in "Allow Changing To Recipient" field

b. Both "Allow Changing Sender" and "Allow Changing To Recipient" should be ON by default for all In-Portal Events. All OnNew Events can have it OFF since both Add and Delete Event button will be available in DBG only.

c. For Information purposes I think we should keep "Send Email From", "Send From Address" and "Send From Name" visible, but READ-ONLY when Allow Changing Sender.

d. Always give to edit CC and BCC records for Recipient exnt.cept that TO is only editable with "Allow Changing To Recipient" ON.

Please comment

DA

[Alexander Obuhovich]

And now I will say that it's time for the task.

[Dmitry Andrejev]

Hi Alex,

Here is a task - quite big, but I think everything is covered:

704: Improvements to "E-mail Template" editing

http://tracker.in-portal.org/view.php?id=704

DA.

[Dmitry Andrejev]

Hi guys,

We had a some questions about LIMITs on TO, CC and BCC fields.

The answer is that there is NO hard limit except the one set by ISP.

Here is a link where you can read on about some things related to these fields:

http://office.microsoft.com/en-us/outlook/HA012002371033.aspx

DA.

[Phil -- wbtc.fr --]

Hi Dmitry,

does this mean that In-Portal send mails 1 by 1 only in newsletter mode, and when we select users manually and send them a mail, each of them are seeing others recipient?

Phil.

2010/5/17 Dmitry Andrejev <dand...@gmail.com>

[Alexander Obuhovich]

This is the case, when trying is better then asking (no offense).

I can't tell about newletter, since I don't use them much, but using "bcc" to send emails to all group members is better, then sending multiple emails. In this case recipients won't see each other in email and will receive same email, e.g. "To" will be "In-Portal Newletter <newsl...@website.com>".

[Phil -- wbtc.fr --]

ok, thanks for replying, I didn't had time to test it at all for now, I'm afraid of spam filters and thus I'll prefer to use a wise, slow x by x mailsending than a big packet into Bcc. As said in Dmitry's link, it could lead to be threated as spam.

2010/5/17 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

Bcc is better, since it moves load from your site to mail server.

[Dmitry Andrejev]

Hi guys,

The Newsletter is totally different thing. Let me explain here:

1. Newsletters - can do Individual Emails when you need to address the
email to that particular subscriber and load Receipent object with
data so it can be pulled later during the mailings. Note that CC and
BCC won't do any good here.

2. Email Events - usually send 1 Email with specific TO's, CC's and
BCC's. We are NOT trying to cover the case when we need to send out
this email multiple times - it will go out just once.

I hope this explains things.

Thanks.

DA.

>>>>>>>>> records) when "*Send From*" is *Custom Sender *
>>>>>>>>>
>>>>>>>>> - "Send From" should be replaced with "Send Email To"
>>>>>>>>> - "Custom Sender" should be replaced with "Custom Recipients"

[Phil -- wbtc.fr --]

Hi guys,

Alex, you are right about the mail charge, but there's a great chance that your mail will go as spam if you have more than 2 recipient in BCC. For example, if you send more than x mails at the same time to hotmail, they will block you for x minutes.

I agree with Dmitry about the use of manual emails and email events for 1 to 1 mail only.

phil.