Opened 7 years ago

Closed 5 years ago

#1483963 closed Feature Requests (fixed)

No Read Confirmation

Reported by: dorado Owned by: thomasb
Priority: 3 Milestone: 0.1-stable
Component: Client Scripts Version: 0.1-beta2
Severity: normal Keywords:
Cc:

Description

If you recive a mail with a read confirmation request, it don't shows you this request.

Change History (9)

comment:1 Changed 5 years ago by thomasb

  • Milestone set to 0.1-stable
  • Owner set to thomasb
  • Status changed from new to assigned

comment:2 follow-up: Changed 5 years ago by thomasb

First shot in [fba1f5ab]. Please report errors right here to this ticket.

comment:3 in reply to: ↑ 2 ; follow-up: Changed 5 years ago by kmn

Replying to thomasb:

First shot in [fba1f5ab]. Please report errors right here to this ticket.

Good implementation. The following are the further refinements I would suggest.

Essential:
The mail asks for sending a MDN even after a MDN is sent, when the mail is again opened next time. So once an MDN is sent, there should be some flag change, so that multiple MDNs are not sent (not asked also)

Desirable:

  1. It should be possible to make this a "forced prefrence", meaning this should work irrespective of recipient input. The recipient should not be able to skip it. So some feature in the config file to over-ride user cancel facility. The cancel button may be disabled through this config. This can be system-wide or user-specific.

By the way, Thomas, where are the files for this confirmation page, so that as a hack I can implement this over-ride till this feature gets into the SVN (if!)

  1. If I hit cancel, it would be nice to show this on the header as a warning "MDN required, shall send the message now?" as a reminder. Once the MDN is sent, this warning should disappear.
  1. The "sent read-receipt" mail does not seem to be logged in the sent folder. It would be nice to log this too.

Regards

kmn

comment:4 follow-up: Changed 5 years ago by kmn

Further comments.

  1. The matter of flag change when marking a message as unread.

When a message for which an MDN has been sent is subsequently marked as unread, it is not necessary to send the MDN once again when it is read afresh. So the flag change for "mark as unread" should not reset the MDN flag.

comment:5 in reply to: ↑ 3 Changed 5 years ago by thomasb

Replying to kmn:

Essential:
The mail asks for sending a MDN even after a MDN is sent, when the mail is again opened next time. So once an MDN is sent, there should be some flag change, so that multiple MDNs are not sent (not asked also)

It actually does. Seems like a caching issue.

Desirable:

  1. It should be possible to make this a "forced prefrence", meaning this should work irrespective of recipient input. The recipient should not be able to skip it. So some feature in the config file to over-ride user cancel facility. The cancel button may be disabled through this config. This can be system-wide or user-specific.

I guess this would be another ticket. However, since we use the javascript confirm() function it's not possible to hide the cancel button. But why should you? Either you configure RoundCube to automatically send a MDN when one opens the mail or the user can decide whether to send it or not.

By the way, Thomas, where are the files for this confirmation page, so that as a hack I can implement this over-ride till this feature gets into the SVN (if!)

The MDN is composed in program/steps/mail/sendmdn.inc with localized texts.

  1. If I hit cancel, it would be nice to show this on the header as a warning "MDN required, shall send the message now?" as a reminder. Once the MDN is sent, this warning should disappear.

I don't agree. Hitting cancel means "I don't want to send a confirmation" and it also sets the MDN flag. Regular mail clients such as Thunderbird behave the same.

  1. The "sent read-receipt" mail does not seem to be logged in the sent folder. It would be nice to log this too.

I'm not sure if this is necessary. It just fills up the users Sent box and I don't think that users care about what's being sent. Not adding the confirmation to the Send box is also "copied" from Thunderbird and I think Squirrelmail doesn't save it either.

comment:6 in reply to: ↑ 4 Changed 5 years ago by thomasb

Replying to kmn:

  1. The matter of flag change when marking a message as unread.

It doesn't actually. Must be a caching issue as well.

comment:7 Changed 5 years ago by kmn

Hello Thomas,

I applied the diff in 942. But the problem seems to persist. Emptied cache etc. No effect.

Regards

kmn

comment:8 Changed 5 years ago by kmn

Hello Thomas,

I have checked up the behaviour in Squirrelmail. The headers are shown below.

Headers for MDN in Squirrelmail

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

Header when "cancel" is hit.

Subject: mdn check1

From: "abcd" <test2@…>

Date: Fri, December 14, 2007 16:32

To: test1@…

Priority: Normal

Read receipt: requested [Send read receipt now]

Options: View Full Header | View Printable Version | Download this as a file | Spam | Not Spam

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

Header after "send read receipt now" is clicked.
The same header is displayed when send confirmation "yes" is hit initially also.

Subject: mdn check1

From: "abcd" <test2@…>

Date: Fri, December 14, 2007 16:32

To: test1@…

Priority: Normal

Read receipt: sent

Options: View Full Header | View Printable Version | Download this as a file | Spam | Not Spam

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

The sent message is stored in the "Sent" folder.

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

I agree that users couldn't care less about the MDN being sent. But as I have already pointed out in the list conversation, I am rolling this out in a corporate environment and receipts become "officially" necessary sometimes. So users should have proof with them that a confirmation has been actually sent, if management perchance contests a lapse on their side.

Regards

kmn

comment:9 Changed 5 years ago by thomasb

  • Resolution set to fixed
  • Status changed from assigned to closed

Made RoundCube's behavior for MDN requests configurable with [0ea88409].
Closing this for now. Please open new tickets for bugs or change requests.

Note: See TracTickets for help on using tickets.