2657 - Intelligent Send preferences should apply to News

Status: RESOLVED INCOMPLETE

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[lchiang]

<contents of initial description taken from bugsplat bug 331285>

Intelligent Send preferences should apply to News

Reporter: Jean-David Beyer, ([e-mail])

Enhancement Request:
The following Intellieng Send preference should apply to News
  "When Sending HTML messages to recipients who are not listed as being
   listed as able to receive them Convert the message to plain text (may
   lose some formatting)".
It currently apply only to Mail.

Currently, when I have Netscape Properties for all newsgroups UNCHECKED the Can
receive HTLM messages and I try to post a rich text message, it ignore my pref
to convert the message to plain text and prompts me and puts up the Intelligent
Send dialog.  It should have enough information to know that plain text is what
I want.  Under Mail, it would use what I have set as my default Formating pref.

Note: This behavior occurs on 4.5 RTM builds including the Oct 20.2 Win32 and
Oct 13 Linux 2.0 build.  This is NOT a regression.  This problem also occurs in
Dogbert 4.07 and the original release of 4.00.

As far as I can tell looking through the old Dogbert specs on Intelligent Send,
it does not say if this pref should be applied for News as well as Mail.
Reference Dogbert Specs:
 "Intelligent sending of HTML messages" spec at URL:
    http://warp.mcom.com/client/dogbert/specs/mail/compose/HTMLmessages.html
 "New Message (Compose) Window" spec at URL
    http://warp.mcom.com/client/dogbert/specs/mail/compose/comp.htm
 "Mail and News Specification" spec at URL:
    http://warp.mcom.com/client/dogbert/specs/mail/mail2/index.html
 "Preferences for Dogbert" spec at URL
    http://warp.mcom.com/client/dogbert/specs/general/prefs/

Steps to reproduce problem:
0) Set the Edit|Preferences|Mail & Newsgroups|Formatting|Message Formatting
option
  => Checked for 'Use HTML editor to compose messages'
  => Checked for 'When Sending HTML messages to recipients who are not listed as
being listed as able to receive them Convert the message to plain text (may lose
some formatting)'
1) Subscribe to a newsgroup
   I was subscribed to News://news/mcom.test
2) Select "Mcom.test" in the folder pane of 3 pane UI
3) Edit|Discussion Group Properties
   The dialog "Discussion Group Properties"
   The check box option "Can Receive HTML" should be UNCHECKED.  If it is
checked, please uncheck it.
4) Close the dialog window.
5) Open a newsgroup
6) Click on the 'New Msg' button off the toolbar
   A HTML Compose window appears
   The default recipient type and address is filled in as  Newsgroup:'mcom.test'
7) Type in a subject title
8) In the message body, type in some rich text.  E.g bold some text.
9) Post the message
   The Intellient Send dialog appears.
   It ignored my preference setting for "When Sending HTML messages to
recipients who are not listed as being listed as able to receive them Convert
the message to plain text"


------- Additional Comments From laurel  10/26/98 13:44 -------

FYI:  From day one of 4.0, the Intelligent Send in prefs applied only to
mail and was told to me to be that way by design.  Not spec'd as such, I bugged
ui folks about putting wording in the prefs to indicate it was mail only.  (I
can't remember if I logged a bug about it or not -- am currently querying
bugsplat to see, but queries are taking a long time.)  I do know that I have a
response to my email to jonas from March of this year addressing the same point
-- that he spec wording for the prefs to indicate the html prefs are mail
oriented only.  He claims in a message dated 3/27/98 addressed to chuang,
trudelle, mcmullen, dora and bienvenu  and copied to me that he changed the spec
to include the word MAIL in the prefs panel.

I don't see evidence of that in the last image of the prefs panel in the spec,
but below the prefs image is an issue addressing this. Please also note the spec
NEVER hit M4/cast in concrete.

Anyway, Windows UI properly shows the word MAIL in the formatting prefs panel,
Unix and Mac do not.

Comment 1

[lchiang]

adding QA Contact to fenella

Comment 2

[Phil Peterson]

Dunno how important this is. Sending multipart/alternative to newsgroups doesn't
sound like a good idea.

Comment 3

[Phil Peterson]

Reassign to sspitzer, cc rhp and ducarroz

Comment 4

[(not reading, please use [e-mail] instead)]

this is something for the compose back end.  rhp creates the message, I just
post it.

re-assign to rhp.

Comment 5

[rhp (gone)]

I think this is more of the interaction between the user and intelligent send
dialogs. Just bounce it back if I'm wrong.

- rhp

Comment 6

[Jean-Francois Ducarroz]

move to M9

Comment 7

[scottputterman]

Moving to M14.

Comment 8

[sol]

I don't think this needs to be fixed for PR1

Comment 9

[selmer (gone)]

Since this bug is marked P4, moving to M17.  If you disagree, please let me know.

Comment 10

[scottputterman]

moving to future.

Comment 11

[varada]

Adding mail3 keyword.

Comment 12

[laurel]

For bug triage team:  Yes, this is still an issue. We always Ask what format
when posting to newsgroup, even though pref is set to convert to plain text.
(Didn't test all options.)

Comment 13

[scottputterman]

marking nsbeta1-

Comment 14

[fenella]

Assign it to Sheelar

Comment 15

[Sheela Ravindran]

reassign to esther

Comment 16

[Jonadab the Unsightly One (Nathan Eady)]

FWIW, GNKSA says always post text/plain to usenet unless ordered otherwise
by the user.  It should at least be possible to configure for that behavior,
and ideally it should be the default.  

Comment 17

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 18

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 19

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 20

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 21

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 22

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 24

[Rainer Bielefeld]

I am not sure whether I understand everything of the function correctly, but
I added "aioe.org" and "de.test" to "Can receive HTML", but nevertheless SM asked me what to to (send as HTML, Plain Text, botz?) when I tried to send my HTML-Mail to "de.test". So it seems to ignore preference. That sourl be " Bug 396395 HTML Mail/News preferences seem to not be applied (when news post is composed in HTML mode using identity of news account, always asked for send format)".

RESOLVED INCOMPLETE due to comment 22