make Edition Count available

The use case of an email training course seems out of scope here, for the same reasons I give over at #940420: Ability to schedule a relative time.

As for an edition counter, that is something we could make available to the alter hook. Though this feature request is pretty old so I doubt the requester is around any more (and the stop count doesn't work at all on D6 right now...).

Bumping this to D7 anyway, for discussion of its merit and usefulness.

Try this one.. no test just yet

Re-queueing with patch for testing

This introduces new token [simplenews-scheduler:edition-number]

A good idea! :-) - And a short review.

+++ b/simplenews_scheduler.moduleundefined
@@ -613,6 +613,58 @@ function simplenews_scheduler_node_page($node) {
+            $count = simplenews_scheduler_get_newsletter_count($data['node']->nid);
+            $count++;

Documentation missing: If an edition was deleted after sending during a newsletter lifetime, numbering won't be clean. There will be duplicate "numbers".

+++ b/simplenews_scheduler.moduleundefined
@@ -613,6 +613,58 @@ function simplenews_scheduler_node_page($node) {
+  $count = db_query('SELECT COUNT(*) FROM {simplenews_scheduler_editions} WHERE pid = :pid', array(':pid' => $pid))->fetchField();

I think it's just too much on one line. Wrapping?

+++ b/tests/simplenews_scheduler.testundefined
@@ -91,6 +91,7 @@ class SimpleNewsSchedulerNodeCreationTest extends SimpleNewsSchedulerWebTestCase
+    $originalNid= $node->nid;

Missing a space.

" If an edition was deleted after sending during a newsletter lifetime, numbering won't be clean. There will be duplicate "numbers"."

What do you propose? do a left join and see which nodes still exist at that time?

I would just clearly document this condition/limitation.
When going through the code i see that the limitation isn't here yet anyway.
#1795674: Rows in simplenews_scheduler_editions getting orphaned
It never deletes any rows. We could avoid that limitation by persisting the simplenews_scheduler_editions for as long as the scheduled newsletter exists.

Alternatively we could also persist a counter column in the simplenews_scheduler table. We would then have no dependency to previous simplenews_scheduler_editions rows.

Advanced users might need a custom edition definition anyway:
Monthly edition creators wouldn't care about absolute numbers, but more about an YYYY-MM notation.
This can e.g. be built with rules.

you're making it complicated about what people should do/can do that is not the original request for this function, but yes, maybe even a simple variable_set('simplenews_scheduler_editions_set_'.$nid, $n++); could be enough

I just wanted to warn you about the side effects :-)
Using variables is possibly the worst solution but would work...

I'm perfectly fine with putting the code as-is into the repo, if you add documentation about the limitation. Maybe for some it's no limitation but even a feature!

I think a warning in with the token description might be a good too