Closed (works as designed)
Project:
Simplenews
Version:
8.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
6 Feb 2015 at 13:26 UTC
Updated:
8 May 2019 at 09:44 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
ModernMantra commentedSmall progress and new starting point :). Need to work on this in way to provide update config function.
Comment #2
ModernMantra commentedCreated update config function. Tried with update database update function but did not succeed and could not provide useful patch for that (will need some instructions about that)
Comment #4
ModernMantra commentedMade some progress, thanks to @berdir and his instructions and tutorial. Currently after debugging and running update function i got an error
ALTER TABLE {node__simplenews_issue} CHANGE `simplenews_issue_subscribers` `` DEFAULT NULL;. Still a little more work on this, but i think this patch will be good starting point IMHO :-)Comment #6
ModernMantra commentedSmall fix, hope test should pass now...
Comment #10
ModernMantra commentedSetting to needs review, re-ran multiple times the test on local machine with applied path and there is no single failure. Seems random test fails...
Comment #11
miro_dietikerIt seems we have a random fail here:
So it seems that there is a random fail if the newsletter random string contains HTML brackets lt, gt. Let's investigate in a follow-up. To start, change testSendNowCron() line 281 to the value above and reproduce the bug.
Comment #13
adamps commentedComment #14
adamps commentedI found two instances where the subscribers value is still used.
1)
SendStatus::getMessageMaybe can just remove the ?: and always call simplenews_count_subscriptions?2)
IssueItem::setValueCan just delete this code I think.Comment #15
adamps commentedRe #14 First item is solved by latest patch in #3030432: Simplenews list page confusing/wrong "send status"
Comment #16
adamps commentedAfter thinking about it I think we should keep subscribers field = "number configured to send" because I see a valid distinction from the sent field = "number actually sent". Even when a newsletter issue has completed sending the two might be different because of skipped emails or errors that exceeded retry #3052714: Send failures retried forever. Let's not take time deleting something that has a little value!