List of outstanding, unconfirmed, anonymous subscription requests.

No there is not. Your patches are welcome. An other solution could be to delete all un-confirmed subscription requests after 1 day on a cron job.

Changing the version too.

Note that as of current 6.x-2.x implementation all register subscriptions are immediately visible in the subscription list.
However, they are initially inactive and wait for activation. (you can see this status!)
But for other subscriptions that need double opt-in (anonymous subs), this is not valid yet.

This could be improved much more by adding further status information and better tracking of those transitions.

Moving to 7.x?

Hmm... Possibly we need to improve the status info about subscriber. Something like "Unconfirmed", "Active", "Blocked".

The original issue is solved however. Subscribers are visible in the list even if they're inactive.
However, the status "inactive" can currently have multiple reasons like user blocking, unconfirmed subscription...
In future also receiving mail bounces might result in a new status like inactive due to spam feedback, user overquota, mailbox inexistent, ...

Also, some newsletter systems allow users to generally unsubscribe. This is something that's not per newsletter but a global flag (in addition to the per-newsletter unsubscribe). That would be an additional status too. Based on those states, imports / signups should process new addresses differently.

Currently we have these statuses:

/**
 * SUBSCRIPTION STATUS
 */
define('SIMPLENEWS_SUBSCRIPTION_INACTIVE', 0);
define('SIMPLENEWS_SUBSCRIPTION_ACTIVE', 1);

Small feature but much cleaner workflows.

Related to
#1315420: When mass subscribe exclude unsubscribed subscribers

Tagging as a possible issue to tackle tomorrow

The attached patch adds a new unconfirmed status and creates a subscription already when requesting it.

Also extends and fixes the existing subscription tests.

Note that not only subscriptions but also subscribers have a status (called activated), something like blocked should actually be on the subscriber I guess.

It's also possible that the new state needs to be checked in other places as well.

#9: unconfirmed.patch queued for re-testing.

In general this looks fine.

However now you need to expose the state to the admin interface also.
admin/people/simplenews Do we need a new action "Unconfirmed"? Seems not like a usecase that makes sense. The problem here is the symbol represents only Activation state, not the subscription state. Unsubscribed users can still be green here... Some filter states formally confuse me. (If i search for "all newsletters" the list suppresses users without any active subscriptions. Users that have unsubscribed on all newsletters suddenly disappear on list but are still present in the DB.)
admin/people/simplenews/users/edit/%subscription here we need a dropdown instead of a checkbox.
admin/people/simplenews/import consider unsubscribed NOT to be reenabled (list separately). possibly add new special option checkbox "resubscribe unsubscribed").
admin/people/simplenews/export here's "subscribed" missing unconfirmed state here.

There's a history with every subscriber when he subscribed / unsubscribed. We completely suppress those states. We could output the date per subscription per newsletter and the state for each of them.

Sometimes "status" is used for activation, sometimes it's for subscribtion/unsubscription state. We should use clean naming here. One term for each only.
- Activation state: Active / Inactive (Activation confuses me with Unconfirmed... hmm)
- Subscription state: Unconfirmed, Confirmed, Unsubscribed)
(Well i'm still not happy with this naming... too bad)

Additionally:
admin/people/simplenews/export Hmm.. For "Status" the word "users" confuses me here.
admin/people/simplenews/users/edit/%subscription Here we miss the

We finally need a much cleaner search state system. :-)

Oops, correct tagging.

Pushing this once to top of list.
I'm not too happy about the interface limitations...

Question is, how to proceed here? The existing patch makes the UI neither worse nor improves it but fixes the tests and implements opt-in conformation in a way that we already expected it to happen. Commit and then look into UI improvements or wait?

That's right. I think commit then and look into UI after.

Commited it is.

Pushing this missing UI improvement...

Since the patch seems to be committed to 7.x-2.x (see #16), would it be possible to port the patch to 6.x-2.x?

This is an essential feature and it would be greatly, greatly appreciated in 6.x-2.x.

Unfortunately, I am not good enough to make the patch, but I would be more than happy to help with the UI.

No that's impossible with 6.x-2.x.
Also 7.x does NOT contain the requested UI improvement. It just fixed some bug cases.

other issue which was submitted by me is somehow related to this. But still don't find new status called confirmed/unconfirmed while generating list using views(see screenshot).

As recently discussed, having a clean UI that allows us to understand what's going on under the hood with subscriber and subscription states is a major release target for our next 8.x release.

The message is misleading as very old commits from 7.x history show up here.
Patch needs port.

#2410265: Replace subscriber overview with views resulted in a lot of improvements already, with filters for active/inactive and the subscription status. Anything left that we need to improve here?

As Berdir mentioned, now we have a view for the subscriber overview with the fields including active/inactive status of the subscriber and also we have the filters by default (see the screenshot). So if anything needs to be improved it should be a separate issue and I think we can close this issue now.

I'm switching it then back to 7.x as fixed where we did so.

As discussed, this is still an open issue in 7.x, possibly one that will never see a complete fix, at least not by us, but closed (fixed) is the wrong status.