Steps to recreate: 1) Pull up record of newsletter subscriber & note FLG and DATE field info 2) Go to /newsletter/existing for an email contact (I can give you a sample URL if you don't have one) 3) Don't change any flags 4) Submit updates 5) Recheck record to note FLG and DATE field info Problem found: When someone updates their email preferences at /newsletter/existing, the form updates/overrides all FLGs and DATE field info. This causes problems with our drip-email campaigns that rely on the Date & FLG field info. When the date is reset - the individual starts at the beginning of the drip series. This means people re-receive the welcome email and following email series (Ie Firefox Tips 24-week drip email campaign) Possible solution: When the form is submitted, logic checks to see if any fields were updated, and those FLGS and DATE fields are updated only. If the fields were not changed, the FLG and DATE fields remain intact.
Will be sure to take this into account during the port of /newsletter/existing to bedrock.
Assignee: nobody → dpoirier
In an IRC conversation :dpoirier suggested that basket should be the place to fix this. Now that the subscription work is handled async, which means that the user is no longer waiting for the calls to ET to finish, we can make an extra call to ET to check the user's current subscriptions, and only update the flags for the newsletters they're not already subscribed to.
Assignee: dpoirier → nobody
Component: General → Newsletters
Jess will test on https://www-demo3.allizom.org/en-US/newsletter/existing once /existing is working on Bedrock + Production (Bug 864916)
Depends on: 864916
Error found. Steps I took: 1) Subscriber: c049927d-cdf6-4125-92a5-c5f4b0223bdf Mozilla & You date was 11/21/11 0:00 and FLG = Y 2) Updated profile on demo3/existing (changed format to T and subscribed to Flicks, didn't touch Mozilla & You flg) Error found: After updating profile, I checked Mozilla & You Date info and it had been updated to 4/30/2013 12:00 AM
I've got a PR open against basket to fix this. https://github.com/mozilla/basket/pull/39 Next step is a review by :pmac.
Commits pushed to master at https://github.com/mozilla/basket https://github.com/mozilla/basket/commit/5a410dffb24d3274db84d79b5a7af94caf191ef7 Bug 827575 Don't change newsletter dates Don't change newsletter timestamps in ET when we're not changing the user's subscription. Change Basket to not send subscribe for newseltters already subscribed to, or unsubscribe for newsletters not subscribed to. https://github.com/mozilla/basket/commit/b1be99f038a107f3579d6535241f58b6496ef4c0 Merge pull request #39 from dpoirier/bug-827575-dont-change-newsletter-timestamp-unnecessarily Bug 827575 Don't change newsletter dates
This is now fixed in production in basket, so it is fixed for all services using it, including /existing/ on mozilla.org.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Steps to replicate bug: 1) Find someone who only has 1 Flag = Y & take note of all of their field values 2) Go to their /existing page 3) Don't change anything & hit submit 4) Check Exact Target profile for that subscriber & note that "MODIFIED_DATE" change = perfect, and FLG date that was Y didn't change. = perfect 5) Go to their /existing page 6) Change only the html/text flag & hit submit 7) Check Exact Target profile for that subscriber & note that "MODIFIED_DATE" change = perfect, and FLG date that was Y didn't change. = perfect 8) Go back to their /existing page 9) Subscribe to a new newsletter - don't mess with the other Y flag 10) Hit submit Error found: Check the subscriber profile in ET, when the new flag was passed through, all the other flags were set to N with today's date = good, however, the previously Y Flag's date is now today's date too. Expected behavior: For all Fields that have changed (including blank to N) to have the updated date of today; but for the previously Y field to stay Y.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This is now broken on Demo3 again.
Fixed on Demo3!
Looks great with Prod release today 6/5
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago → 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.