| Anonymous | Login | Signup for a new account | 21-11-09 08:16 GMT |
| Main | My View | View Issues | Change Log | Roadmap | Docs |
| Viewing Issue Simple Details [ Jump to Notes ] | [ View Advanced ] [ Print ] | ||||||
| ID | Category | Severity | Reproducibility | Date Submitted | Last Update | ||
| 0009687 | [phplist] Message Send Process | major | always | 08-04-07 01:04 | 18-02-08 14:08 | ||
| Reporter | wolfmagic | View Status | public | ||||
| Assigned To | |||||||
| Priority | normal | Resolution | fixed | ||||
| Status | resolved | Product Version | 2.10.4 | ||||
| Summary | 0009687: Confusing use of the word "Both", indicating one email with both text and html and not two emails | ||||||
| Description |
tried to find way to search bug database with zero success. so here goes... both txt and html formatted emails sent to whole list after reconciling with “mark all users to receive html” listen up folks. this is happening across the board to all emails on all accounts in version 2.10.4. it is perhaps only supposed to do it on the test, but the point not yet made clear is that this is many times reliably reproducible and regarding the test little is intuitive. now we're all a little irritated that our clients are ALL getting double emails which is classifiable as spam! [to paraphrase previous and now to quote direct] "Two emails of the same message in two formats? Completely unprofessional, ridiculous." total text html both PDF both 555 3 0 552 0 0 so basically, no matter what the user chooses when sending the message, that choice is overridden by settings that a good percentage of intuitive power users eager to start their email campaign would ever think of searching/finding/changing before believing all the relevant settings were set. i don't want, and will not, go find/edit the config file at all to achieve something so basic and core to the concept of email list managment - i'd rather log a bug and ticket to create link in ui to key documentation. main page > admin interface > manage users > reconcile users > select "mark all users to receive html" is nice advise that does not change anything. the problem stated is that all clients get two emails – both html and text – after reconciling users to receive html and selecting only html in the send off routine. problem is that in "reconcile users" a key link is missing. specifically: 1. mark all users to receive html ONLY AND/OR 2. mark all users to NOT receive txt another soul says: In the subscribe page choose "Don't offer choice, default to HTML", so all the people will get the html messages. nice advise again except that this relates not to the email list but to one single user who is choosing to setup their own account now this is just the 2nd hurdle for intuitive power users who resolved the first. when an intuitive user goes to TEST their message and has read enough to know it is to arrive in 2 formats then they will assume the sending of both formats is not going to happen when they select html only in the “send message” routine/ui. so it comes as a shocking surprise when the reports inform them that in fact they have sent text-only messages which is exactly what happened to us on our first real run post-successful tests. we had to find out the painful way that "reconcile user settings” related to format override the listadmin’s settings in the “send message module”. the listadmin must somehow intuit to first go to main page > admin interface > manage users > reconcile users > select "mark all users to receive html". but wait! your problems are only just beginning. we did that only to find that all customers would then get two emails – one for each format. great! stellar! phplist just created yet another non-intuitive hurdle. see the need? great. now fill it. total solution: a simple few words near the test button that says "more info" could link to a set of guidelines that spells out 3 extra prudent steps to do before launching a single email into the real world. seems obvious to some given phplist is stamped on both pieces of mail that will not earn points performing like this. but no. this problem was first logged 1 year ago. there is no acceptable workaround short of modifying the config file which makes this a high-priority item to resolve. i rate this a P2 by any good bug database standards. |
||||||
| Additional Information |
is there a good reason that finding a link to the bug url http://mantis.phplist.com [^] is so hard to find? i had to click phplist > support > search forums and then search it to find it in a post. might phplist put a link to the issue tracker like other sites do in the margin with a warning that asks people to check everything else first? |
||||||
| Tags | No tags attached. | ||||||
| Attached Files | |||||||
|
|
|||||||
Relationships |
||||||
|
||||||
| Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |