Adding Recipients to "To:" field for emails

[hkouns]

From comment on Issue #8 where this idea originated: " ....essentially adding them to the TO: field. In this case we would certainly want it to be a person in the database so that it can be tracked on their record, etc. For instance... We are sending an email to a bible Fellowship Class to invite them to a cookout ... then we remember, we should invite the pastor as well. Currently we would need to add them to a tag...or run a query. With this feature we could just goto the Org and email all members ... then add the pastor on the email page. It would probably would be best to use the standard search/add dialog box."

[nehresma]

Heath -- just a quick check to clarify how you'd like this to work. Do you want this to only show up when 1) you're sending to an org (via the "All Current Members" menu option on the email dropdown of an organization), 2) you're sending to individuals, parents, etc (via those respective menu options), or 3) sending an email via any method?

If 2, there is a multiselect box for "To" recipients. Do you want additional recipients added to this multiselect? The multiselect isn't there when sending to "All Current Members", which is why I had added this via a set of <li>'s on a floating (left) <ul>.

Let me know how you'd like this visually. If you have a sketch or something that might help too.

[hkouns]

First, I think I confused you when I was referencing sending an email to an organization in the original issue above. Normally when we do that we just click send to individuals… Not current members. The current members option is only used if we are writing a draft email and the org membership is expected to change. The location I had put the plus button was as an add on to the multi-select… So it was only available under your option 2. It was not present when sending to org members.

Regarding adding people to the multi-select… I like the way you're adding them to a separate list it makes it easy to identify who is been added. But there regarding adding people to the multi-select… I like the way you are adding them to a separate list it makes it easy to identify who is been added.

There are a couple things we probably need to consider:

• what happens if the person does not have a valid email? Currently if you send an email to a query or to the individuals in an org … The only people that show up in the multi-select are the ones that have an actual email.
• if you save a draft after adding a recipient… Should we save the extra recipient with the draft or just assume that it is a real-time option for now… That's probably the easiest.
• If you did add to the multi-select… Then we would also need to adjust the total line under the box… And add them to the temporary tag
• I need to test and see what happens if a person is already in the multi-select and you also add them as an added recipient. Do they get two emails?

[nehresma]

Thanks for the quick response. I can be a bit dense, so just to be clear -- leave the additional recipients as-is in a separate list, or add them to the multiselect? I suspect that if we add them to the multiselect we wont have the ability to click an X to remove them -- not sure if that's important or not.

Responses to you bullet points/questions in order:

• Good question. Since all the searching is handled by the standard "searchadd" functionality, I suspect that a predicate requiring an email address isn't included. I'll see if there's a way to filter those. Hopefully they've already got something in place and we just have to use it.
• At the moment the additional recipient does not get persisted on drafts. I actually had thought about that, but decided to avoid the additional complexity here initially. We can add that if it is desirable.
• Good point. See my question about being dense and clarifying where you'd like these.
• Yes, I suspect they would get 2 emails. I'm very much a LINQ novice, but it appears to me that the query is not performing a SQL distinct or group by operation: https://github.com/nehresma/bvcms/blob/e716a87d6889acb8fa27b52595736e7b8f3105b7/CmsData/Email/Emailer.cs#L474 I can add that too.

[hkouns]

I would leave the list as is for now. I will solicit some input from David and Karen on appearance and whether it needs to be extended to "send to current org members". Also I think for now let's avoid the complexity of trying to save the list with a draft. Let's do some testing on the sending duplicate emails issue and see what is happening right now and how it is getting recorded on the people record.

[hkouns]

@nehresma I did some preliminary testing and the fix for removing people from the Additional Recipient List seems to work fine.

I also found two things that we need to look at: 1) The process seems to hang when you send an email where you add someone as an Additional recipient who is already in the Original recipient list. The email never seems to complete... 2) You are only capturing the FIRST person from the Search/Add dialog box. The dialog box allows you to search and select multiple people before "Committing" ... but only the first entry is being returned to the <li> list

[nehresma]

For my sanity, known issues to deal with yet:

• handle duplicates
• layout issue
• deal with searchadd having more than one selected person
• deal with people not having an email address
• update count of persons in the gui

[nehresma]

@hkouns I believe that with this last PR I've addressed the items we discussed here. If I'm leaving something out, please let me know.

[nehresma]

Talked with Heath yesterday after church. A few more items:

• Duplicates with the original Recipients are not being removed client side
• Active email flag check. Right now I'm just checking if they have an email address. Also need to check if it is active.
• Persist the additional recipients on the server. This will give us draft and scheduled email capabilities.
• Fix tense of the statement when saying n person(s).
• Merge with latest from the Church's branch. Actually, might as well just use the church's repo as my origin, rather than my fork.
• Look at layouts when resized down. He indicated that the layout with the button gets awkward when sized down.
• Merge the CC stuff over here
• Disable send button after sending

[hkouns]

Also, we discussed combining the CC/Reply-To changes into this branch... so that they could all be tested together.

[nehresma]

@hkouns I just realized that saving a draft doesn't actually save the recipients in bvcms: https://github.com/GSBCfamily/bvcms/blob/Add_Recipients_to_Email/CmsWeb/Areas/Main/Controllers/EmailController.cs#L95-L138

I also tested it by saving a draft email to several people then loading it back up -- it didn't retain the recipients.

I'm looking into saving them for scheduling the email now.

[hkouns]

@nehresma , thats right... it saves the recipients to a special tag when you first start drafting an email... but that tag is not maintained for a Draft.

Adding the additional recipients to the special tag is probably the mechanism to save them for scheduling an email: https://github.com/GSBCfamily/bvcms/blob/Add_Recipients_to_Email/CmsWeb/Areas/Main/Controllers/EmailController.cs#L187-L195

[nehresma]

Yep, I got a start on that yesterday morning. Luke and I did a 3am release today and I didn't have my normal morning for working on this. I'll hit it up again tomorrow.

[hkouns]

Gotcha... no problem.

The "Work" server seems to be working well (and it is more responsive than testing on my local machine)

I think we are close... once we get scheduling working and merge the CC/Reply-To Branch... I will work up a testing document and have Karen test.

[hkouns]

@nehresma one additional feature that we might want to include is referenced in our CC/Reply-To branch Pull Request (https://github.com/bvcms/bvcms/pull/75 )

Evidently in the old UI, the Send button was disabled after sending an email. (to prevent duplicate emails.) In the new UI, this protection was lost. ... we could look at adding it back if not too difficult.

[nehresma]

I believe I only need to merge the CC stuff into here yet.

I had a note to look at the layouts when resized for mobile -- I used the Chrome dev tools for the mobile resizing and it looked good to me on every device size I tried. Even all the way down to an iPhone 4. I should have written down more specific notes; do you remember specifically what the concern was there?

[hkouns]

Maybe it's not really an issue. I was just saying that I was struggling to achieve vertical alignment between the plus button and the note about Current org members.

It only applies when sending an email to current members and the button looks pretty well centered on a full screen but as I recall when you reduce the screen size, The button stays up towards the top of the text box.

[nehresma]

Ok, fixed a couple bugs. One was the result of a mis-merge, the other was an oversight from last week. For the rebase that David was asking for, I think that I'll create a third branch and rebase that one from bvcms master. That way we don't lose history in these other 2 branches.

[hkouns]

ok...sounds good... are you planning to do the rebase after testing?

[nehresma]

Yeah, I'm in the middle of it right now. Hope to have it pushed in a little bit.

[nehresma]

We've got changes in several branches (the original cc branch and the add recipients branch) that need to be rebased together off of master. This gets a little tricky to do a standard rebase. Would you mind if I did a squashed rebase, essentially putting all of the commits in the 2 branches together into a single commit?

[nehresma]

Just pushed branch gsbc_email_rebase that is a squashed rebase off of bvcms/master of both the CC branches from last fall and the add recipient branch from the past few weeks. The single, squashed commit for it is 32afcd3205120d6288c26e2af5d8c26cfee5431a

[hkouns]

Merged Adding Recipients and Adding CC/ReplyTo features ... submitted as https://github.com/bvcms/bvcms/pull/86