Project

General

Profile

Bug #6674

Member RBE responses to document uploads

Added by Matt Gold over 5 years ago. Updated over 5 years ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Category name:
Reply By Email
Target version:
Start date:
2016-11-11
Due date:
% Done:

0%

Estimated time:

Description

A message just came in to the because a member replied to a document upload action.

The email notification, which includes the line "Go to the discussion to reply or catch up on the conversation." makes it seem like it is possible to have a discussion thread around a document upload event. If that is true, perhaps we can enable RBE for such actions? If not, perhaps we can find some way where users are automatically notified that their response will not go through to group recipients as they had intended?

Screenshot of the notification is attached


Related issues

Related to CUNY Academic Commons - Bug #6695: Member reply to announcement goes to Commons addressDuplicate2016-11-14

History

#1 Updated by Boone Gorges over 5 years ago

  • Category name set to Reply By Email
  • Assignee changed from Boone Gorges to Raymond Hoh

#2 Updated by Boone Gorges over 5 years ago

  • Target version set to 1.10.2

#3 Updated by Matt Gold over 5 years ago

  • Related to Bug #6695: Member reply to announcement goes to Commons address added

#4 Updated by Raymond Hoh over 5 years ago

If not, perhaps we can find some way where users are automatically notified that their response will not go through to group recipients as they had intended?

In the past, there was this line added to the top of non-RBE emails:

--- Replying to this email will not send a message directly to the recipient or group ---

I forgot to port this functionality to the new email system, but I've just done this in #6695.

We never sent back a reply to the sender.

If that is true, perhaps we can enable RBE for such actions?

This has to be done on a case-by-case basis and requires extra development time for each email action.

If we want to do this for file uploads, let me know.

#5 Updated by Matt Gold over 5 years ago

Thanks, Ray. I'd be in favor of NOT enabling RBE on file uploads but of sending an email back to a user who tries to reply to a file upload event. How feasible is that?

#6 Updated by Raymond Hoh over 5 years ago

but of sending an email back to a user who tries to reply to a file upload event. How feasible is that?

This introduces some complexity.

If we want to send a reply back with a custom error message for each custom action, we would have to track non-RBE emails and alter the RBE email address to something like:

example+noreply-docuploads@gmail.com

Or something more generic that would be sent regardless of action type would be simpler.

eg:

example+noreply@gmail.com

Then, for replies to this email address, I can check to see if "noreply" is in the email address and send back a response to the sender. The negative here is not all sites with RBE would want this functionality.

#7 Updated by Boone Gorges over 5 years ago

Ray, I'm not really familiar with RBE's internals, but wouldn't it be possible to do something like this: when an email is received, try to find a handler that matches the hash/email content, and if one is not found, then send a generic "your message could not be posted" message? This seems like it'd be enough - something like "a custom error message for each custom action" doesn't seem important.

#8 Updated by Boone Gorges over 5 years ago

  • Target version changed from 1.10.2 to 1.10.3

#9 Updated by Raymond Hoh over 5 years ago

Ray, I'm not really familiar with RBE's internals, but wouldn't it be possible to do something like this: when an email is received, try to find a handler that matches the hash/email content, and if one is not found, then send a generic "your message could not be posted" message? This seems like it'd be enough - something like "a custom error message for each custom action" doesn't seem important.

Currenty, RBE doesn't alter every email to add a 'Reply-To' email header; only those that require it.

If we follow your approach, we would have to alter every email to use the RBE email address. There are both pros and cons to each approach.

#10 Updated by Boone Gorges over 5 years ago

Currenty, RBE doesn't alter every email to add a 'Reply-To' email header; only those that require it.

Ah, gotcha.

I guess the cons of my suggested approach are:
1. it would take (your) dev time to build it
2. by having a Reply-To header, it might encourage users to reply (since this header triggers certain UI in mail clients)
3. more overhead for the inbox connection (PHP IMAP in our case; additional cost when using a third-party mail service)
4. the From address on non-RBE emails, on some sites, may go to an actual inbox that someone is reading, and the proposed change will break reply behavior in that case

Of these, it seems that 4 is potentially the most serious. But I don't think it's an issue for the Commons, since we don't really monitor the for this kind of traffic. I wonder if it'd be possible to have a Commons-specific RBE addon that does the following: (a) tells RBE to add the RBE Reply-To on all outgoing emails, and (b) provides a default handler for non-supported mail types (not sure if this is easy or possible given the way RBE's internals work - I'm imagining something like a do_action() hook inside of the `default` block of a switch statement?)

Three questions: (1) Have I captured the case against my suggestion? (2) If so, what do you think of the case for making the suggested behavior Commons-only? (3) Would it be a huge lift to build it?

For context - I don't think that responding to non-supported RBE types is a huge problem on the Commons. I don't monitor the inbox, but I'm guessing it can't be more than a small handful of emails per month, and most of those people probably figure out that it does nothing when they get no response :-D So if it adds a huge maintenance burden or something to do what I've suggested, maybe we can wontfix.

#11 Updated by Raymond Hoh over 5 years ago

  • Status changed from Assigned to Testing Required

I've added a bounce-back email handler in 1.10.x branch.

See:
https://github.com/cuny-academic-commons/cac/commit/a6e0b1dd8017b766e51c14623d3913a648c7de69

What I did was alter all BuddyPress emails to use example+bounce@gmail.com as the Reply-To email header, instead of the main admin's email address by default. (Note: I'm not modifying WordPress emails, but we could if we wanted to.)

If someone replies to example+bounce@gmail.com email address, RBE will send back a reply saying that their reply was not posted because RBE isn't supported for that particular email.

Here's the email message:

Hi there,

Your reply could not be posted because the item you are replying to does not support replying by email.

For reference, you were attempting to reply to "$parsed_subject".

Your entire reply was:

"$body" 

If you have any questions about this, please let us know.

Here's the subject line I've added for now:

'[CUNY Academic Commons] Your Reply By Email message was not posted'

Let me know if you'd like the email content changed.


You can also test this on cdev.

My test criteria was to create a 'group details changed' email, since RBE doesn't work on these emails. You can do this by:
- Navigating to a group's "Manage" tab.
- Change the group's description.
- Make sure the "Notify group members of changes via email" field is set to "Yes"
- Save.

This should send a 'group details changed' email. Next, attempt to reply to this and see if you receive the bounce-back email.

#12 Updated by Matt Gold over 5 years ago

Thanks for this, Ray. Would it be possible to include a link back to the post (or would that already be included in $parsed_subject?)

#13 Updated by Raymond Hoh over 5 years ago

Would it be possible to include a link back to the post (or would that already be included in $parsed_subject?)

A link back to the original post would be hard to parse.

However, the link should be available from the $body variable since that should include the entire reply, including the original email.

$parsed_subject is just the subject line from the previous email.

#14 Updated by Matt Gold over 5 years ago

Okay -- thanks, Ray

#15 Updated by Boone Gorges over 5 years ago

This looks great to me, Ray! If there are no objections, I think we can mark this one complete.

#16 Updated by Raymond Hoh over 5 years ago

  • Status changed from Testing Required to Resolved

Cool! Going to close this one.

Let me know if the email content needs to be changed.

Also available in: Atom PDF